Re: Debian (would like) to do list
On Fri, Jul 26, 2002 at 08:16:27PM -0400, Joey Hess wrote:
> Drew Scott Daniels wrote:
> > Some programs use static code for things like regex expressions and
> > handling tar archives. A program to go through the source code of all
> > the programs (or a developer effort) may help to find common code that
> > could be put into a library or that already is in a library. This could
> > make packages smaller, but if we're not careful, creating new libraries
> > could increase the overall installed size for a program. (before, now)
> > An additional benefit would be fewer places to change code (good for
> > security, good for efficiency, good for all updates). Are there any
> > security issues to exporting code from packages? (This should be looked
> > at whenever code's exported.)
>
> Very cute idea.
Being a proponent of code sharing and reuse, and having made some
halfhearted attempts in this area before, I must say that there are some
nontechnical issues to consider here (in addition to the nontrivial
technical issue of maintaining a proper shared library). For example,
upstream developers are often wary of (or downright hostile toward) the idea
of introducing additional dependencies in their packages. In a Debian
environment, dependencies are in general so smoothly managed that this is
not something that we worry about, but it is not an easy thing to convince
some program authors to merge some of their functionality into a library.
Some crazy people still insist on building their software by hand, and this
makes life more difficult for those people (misguided though they may be).
> > http://lists.debian.org/debian-mentors/1999/debian-mentors-199901/msg00051.html
> > talks about putting datasets into Debian or non-free. I wonder what has
> > become of this particular dataset and if there has been a policy developed
> > for datasets. I would like to see astronomical, meteorological,
> > geographical and other data sets easily available. If a data set is
> > DFSG-free then I feel it should be put in main, but segregated somehow (in
> > extra?). Data sets may require maintenance too. For example, recently new,
> > more accurate data was collected about the distance certain stars are from
> > our sun. When I did some more investigation, I found out that a vote to
> > include a dataset section was made and it was decided to create a dataset
> > section. No such section was created and the astronomical data is sitting
> > with the person made this proposal. Special handling of datasets may be
> > required to reduce the impact on Debian distribution infrastructure. I
> > recommend updates and distribution only be allowed through diffs or some
> > other method that uses less bandwidth than is used now.
>
> Yes, that idea seems to be stalled.
The best way to get this project going would be for one of the proponents to
set up a private archive to manage this, and run it as an experiment for a
while. If it seems to work out, then we can work through the storage and
mirroring issues.
> > Create Debian backup procedure and program(s) (debian cleanup, cruft to
> > backup, dpkg --getselections > myselections, backup config files possibly
> > checking md5's which more than should be in every package), now.
I've been doing these kinds of backups in various custom ways for a while
now, and would very much like to see a tool which understands FHS and a
little bit of Debian which could be used by an average user.
I have in mind something like the Backup/Restore applet on the Zaurus. With
a few taps of the stylus, the user can back up all of their data that is not
part of the stock system, wipe it, install a new one, and restore their
data. I think that this is achievable for Debian.
> > [live Debian CDs]
>
> Somebody please do this, mmmkay? IIRC I saw Robster and someone discussing
> this on irc the other day.
For Debian Zaurus, I wrote a little init script which, given a read-only
root filesystem, creates and mounts a read/write one (in this case flash
memory, but the same could be done with a RAM disk, etc.), copies on
pre-populated symlink farms, and then pivot_roots into it, producing a
read-write system of which the read-only components are symlinks into the
read-only filesystem and the read-write components are copies of the initial
system state. This makes it possible to (for example) install additional
packages (requiring only enough space for the package contents), mess
around, whatever, and "roll back" to the base read-only system at any time.
If anyone is interested in using something like this for a live Debian CD,
feel free to get in touch with me.
> > One of the reasons for the delay of the release of Woody was said to
> > have been security concerns. It has also been reported (see the glibc
> > example at http://www.debianplanet.org/article.php?sid=568 ) that it
> > takes a long time for security patches to get through due to the
> > compiling and testing on the 68k and arm architectures. I would like to
> > bring forward the idea of using emulation to help speed things up. There
> > was recently (March?) a patch for UAE (a 68k emulator) to support
> > running Linux. There are also emulators for the arm architecture such as
> > arcem (
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no\&bug=136844 for
> > details ). arcem is said to be quite fast on Intel architecture.
> > Emulation of old architecture brings two advantages and one
> > disadvantage: it's usually faster, it's easier to get, it could have
> > trouble being a completely accurate emulation of the original hardware
> > (bugs not emulated or new bugs not yet found/patched).
Making an emulator both accurate enough and fast enough to fill this role is
a challenge, and I am not sure that any emulator is up to the task of
running an autobuilder.
Things like ccache might prove to be of more benefit in this situation, but
there are arguments against it as well (increased complexity and unknowns,
lack of disk space and network bandwidth).
> > Many of the patches and programs found at
> > http://www.theaimsgroup.com/~hlein/haqs/ can be quite useful. The programs
> > can be packaged. The patches, when useful, should be added to existing
> > packages or modified to make them run time options. For example the idle
> > connection traffic patch for ssh may be a useful option that may be
> > possible to be chosen at runtime.
The ssh example that you use is:
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=100283400026301&w=2
yes? Current versions of ssh have both KeepAlive and ProtocolKeepAlive
which serve this need well enough for me. That message is quite old; it
is possible that these features did not exist when it was written.
--
- mdz
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: