UFS, libc, and compat, oh my
Folks, the filesystem underneath won't *matter* to most of the users.
They just want it to work. To the hackers, well, that's why both Linux
and the BSDs support the cross-platform reads, but as extra options.
The BSD kernels support UFS far better, because that's what they've been
written to do; if we are, in fact, using the BSD kernel, it would only
make sense to use the default filesystem for the time being.
Granted, this means whatever boot manager we use *must* be able to grok
dealing with both ext2 and UFS, but this just shouldn't be all that hard.
I'm more torn on this one. Honestly, I think it would be easier to do
the work up front, and port glibc, but, on the counter, much like the
filesystem... the libc and the kernel are fairly closely tied together,
and until the *upstream* glibc actually works sanely on *BSD, I think
this is such a large effort that it should be left for compat mode and
things should, be policy, be encouraged to compile natively unless they
absolutely can't do so reasonably. I do want to see it fixed, but I think
that getting it fixed *now* is not a good use of our time.
Using /compat should be a *last* resort. For all that it's nice to have,
and runs decently, using non-native code will always be ugly. Trying to
boot from it is... well, just plain silly, in my opinion. On the other
hand, I *don't* believe that keeping the BSD userland, except for those
pieces which are unique to it, is a good idea. Why? Because, without the
GNU userland, most users won't think it 'feels' like Debian. That, and
some fair number of utilities make base assumptions about what they can
do using things like "cut" and "df"; forcing all of them to introduce
new package dependancies on which of these they can use is going to be
e2fsprogs gets replaced by ufsprogs, with most of the same binaries. Ok,
no big deal. What portions of util-linux aren't in bsdutils get replaced.
The modutils package and company get replaced with equivalents, if there
are any, or simply left aside. Etc.
Planning is good. However, we have now had... over a year to plan, and
nothing ever got done because nobody could agree on what the plan should
be. This is a great example of where "rule by committee" breaks down,
when the committee doesn't have a clear path to follow (committees are
fine once it gets started, but are horrible about giving it direction).
I'm very glad the advice showing up on the list is being taken; I'm also
very glad that it's being evaluated, and taken where it's useful. On a
side note, I would like to step into the "developer" circle, while folks
are picking tasks. Unfortunately, I don't have a spare box to try to boot
a BSD kernel and work on things just yet, but I may be able to fix that.
If anyone can provide access to one, however, I can certainly work there.
(And we should consider whether we need a box from someone, eventually,
for doing autobuilds et al)
Joel Baker System Administrator - lightbearer.com
- Re: vote
- From: Nero <firstname.lastname@example.org>