UFS, libc, and compat, oh my

[lucifer@lightbearer.com]

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
lucifer@lightbearer.com              http://www.lightbearer.com/~lucifer