This message is being sent primarily to the debian-policy mailing
list, with a carbon-copy to another low-traffic list; I've set a
reply-to to the policy list and myself, but don't know if it will
stick.
I write to you as someone who wants to tell you what I wish to see in
a Debian distribution who is seriously considering a switch as a user
from RedHat (due to a lack of reponsiveness). First off, I am
concerned that the current stable release uses a kernel quite a few
years old: for stability, that is great, and should continue to be
supported for that reason, however it is a sorry state of affairs for
those of us who have been working for 4+ years on capabilities in the
kernel that are finally now released and we expect to start seeing
widespread acceptance, application development and implementation of
(e.g., IPv6, standarized threads, etc.).
As I have not inputted this into the Debian beaurecratic machine that
I see mentioned at http://www.debian.org/devel/constitution and
http://www.debian.org/vote/, I hereby request that you, where "you" is
those of you who are able to do so, please do so where appropriate to
further these concerns.
1. Fully switch to FHS 2.0 (http://www.pathname.com/fhs/) by the next
freeze date.
* I converted my system from an old 1994 Slackware distribution to
FSSTND by hand, and that took about one full (hacker's) day. It
saved me more than quadruple that amount of time in future
incompatibilities due to filesystem differences: sticking to a
standard really helps in this case. I was annoyed by FSSTND's
lack of heterogeneous environment support, however.
* I was annoyed to see FSSTND change names to FHS and change, but as
soon as I cracked FHS open, my annoyance flittered away for the
most part (exception being the odd names of everything and lack
of aggression to fix those crazy names, but a standard is a
standard and that is definitely what counts); I was happy to see
that most of it centered around two important things: refinement
and the new ability to handle heterogeneous environments, my
chief complaint of the FSSTND which otherwise served me very
well. Of course, I was sold immediately, and converted to FHS
2.0 immediately. This also took almost a day. I have since
encountered no problems, am very happy with FHS 2.0, and
advocate its adoption by everyone at this time ("immediately").
It is definitely my opinion that the idea of FHS/FSSTND is good,
the specific standards are good, and going with FHS 2.0 is the
right way to go. It should be in the next release. It saves that
much time to do it; I mean, the time put into it will be rewarded
by less time maintaining it later on. I recommend an intent of
and attempt at "full" FHS compliance, but would (begrudgingly)
accept a few lingering fixups that will wait until the following
stable release. FHS 2.0 already isn't a pie-in-the-sky perfect
holy sacrament; therefore not doing it exactly would be ridiculous
(I could hardly stand *two* unholy variations of an imagined
perfect theme!!!).
Hint: when you send configuration patches to package maintainers
nonspecific to Debian, please say something to the effect of ``The
directory and file paths in the Debian/Linux configuration for
this package have been upgraded from FSSTND 1.2 (or whatever it
was) to FHS 2.0; please see FHS 2.0 at http://www.pathname.com/fhs/
for details on FHS'', in case some other package developer or
maintainer is still running a FSSTND system (so as to prevent
upgrade loops).
2. Get a Linux 2.2 kernel and GLIBC 2.1 based distribution out soon.
A freeze date of September 1st has been proposed. Waiting for the
Perl upgrades has been proposed. FHS is the only other thing. I
propose that a freeze on everything besides FHS issues happen so
that we may concentrate on FHS-izing everything; it's kind of a
flag-day item, anyway, so this is OK to do it like this. Then, a
freeze of the FHS stuff can finally happen, and a release worked
on.
Those good-feeling release dates that make us more media-savvy --
sorry, I cannot promise that. But it does make sense to get
something out which has a current stable kernel version in it
soon.
3. On a minor note, I find the "ip" program written by Alexey Kuznetsov
<kuznet@ms2.inr.ac.ru> available at ftp://ftp.inr.ac.ru/ip-routing/
which replaces the "ifconfig" and "route" commands to be very well
written in terms of usability and consistency, and recommend it to
everyone who uses Linux 2.2+ and to the Debian distribution in
general; I have not actually cracked open Potato so do not know
the status of "ip" and the old "ifconfig"/"route" crap.
Above other things, "ip" understands IPv6; "ifconfig" and "route"
have many versions which do not: administratively, this
trivializes the concept that the new and improved "ip" program
(more stable, easier to use, more consistent, and more capable)
will of course support IPv6 whereas the others are ``good luck,
you'll need it''. In both cases, you need to compile properly to
get IPv6 functionality. This brings me to my next paragraph.
To repeat, replace "ifconfig" and "route" with "ip" in
administrative utilities, initialization scripts, etc. I
recommend that "ip" be *included* and *supported* by the next
release (but not (necessarily) the initscripts, etc.), with the
scripts switched over to using "ip" by the *following* release, if
the next release is to come soon (i.e., less than two months);
otherwise, to *very strongly* consider switching to "ip" in all
initscripts, etc. by the next release completely.
4. I recommend the following time-release plan for IPv6 support:
Here I work under the assumptions that IPv6 is not supported at
this time by Debian (OOTB) and that a good plan for it does not
exist; assumtions that may be woefully wrong since I have not
actually looked; please interpolate as appropriate.
IANA is now assigning IPv6 IP numbers (and consequently the
regionals). It is now the time for IPv6 to ramp up. While the
task of *fully* IPv6ifying Debian may be daunting and too large a
chore for the very next stable release, I do recommend that at the
very least the core-core-core packages be compiled with IPv6
enabled so that the progression to a Debian distribution with IPv6
is much, much easier due to the incremental nature of something as
large as this type of upgrade.
What this means specifically is that the kernel (v2.2) and the
"ip" utility be compiled with IPv6 support compiled in (that is
only two packages and trivial to do by a freeze date even less
than a month away; I think it's ok to do IPv6 as a module in the
kernel). Other packages with IPv6 support can come in at the
speed that they make it naturally. So, under the assumption that
the next release will not be fully IPv6 ready, it can be
considered a semi-IPv6 release (kernel & "ip" program), with some
document somewhere describing what is and what is not yet IPv6,
with a future release down the road sometime being a full IPv6
release.
If this is done on a slow-track, I recommend next stable release
have kernel and "ip" utility with IPv6 compiled in; following
release have most of the *simple* upgrades, such as those packages
which already have IPv6 versions but just haven't been put into
the Debian distribution until this prodding came up to do so
(examples are some of the basic utilities such as ping,
traceroute, etc., and, for backward compatability, the IPv6
enabled versions of "route" and "ifconfig" despite how much I hate
them, as well as some of the larger packages such as Sendmail,
FTP, Apache, DNS, etc. which have already had IPv6 upgrades
applied to them in various places). Finally, a third stable
release in the future can be considered a fully IPv6 enabled
release, where every package is tested to work well on an IPv6
network; this is more involved, but the incremental nature of this
IPv6 compliance I propose should severely reduce the amount of
work involved in such a final test. Also, by that time,
environments where this testing can actually take place will be
more plentiful by then (until the development of the third stable
release begins, some of us may still be "in the dark"). I think
this is a reasonable expectation for the Debian project.
Thank you for your attention. Please cc: to me as I sometimes don't
track the mailing lists.
Brad Allen
<Ulmo@Q.Net>
Attachment:
pgpFwQOQh7DtD.pgp
Description: PGP signature