Filesystems: 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. libc: 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. Other stuff: 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 rather unpopular. 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: 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 [EMAIL PROTECTED] http://www.lightbearer.com/~lucifer
