>>>>> "re" == Robert Elz <kre%munnari.OZ.AU@localhost> writes:
re> might have been if we were talking about adding LFS to NetBSD,
re> but that was done years ago, the question now is whether to
re> remove it, not whether to add it.
since it's broken, it's really whether to keep it, remove it, or leave
it in but broken.
You're laying out choices as if ``let's keep it'' required 0 work and
made 0 problems except the allegation something else might be faster.
Since it doesn't work right now, that's not the case.
And most of my post was about the huge gap between ``seems to work
enough to be excited about'' and ``works well enough to actually
use''---with filesystems, more than half the work comes after the
excitement, and LFS has never even crossed that hump.
The real no-action choice is to leave it nominally, meaninglessly in,
but broken. Broken as it has been all along, it's just more broken
now.
re> The worst scenario is for someone who upgrades then finds that
re> their LFS filesystems no longer work
I've no doubt someone will pipe up and say, ``omg! omghai! yes I
have an LFS! scurry around and do all this work so I don't have to
find blank space and use pax.'' But AIUI it never worked well enough
that any reasonable person could rely on it for permanent storage, and
this is not the first time LFS has worked less well in a newer formal
release than in an older one.
re> I'd submit that NetBSD 5 needs to include, at the very least,
re> a read-only safe LFS implementation
please, NO, do not connect the already glacial release of NetBSD 5
containing the critical-to-survival thread fixes to the demand for a
stable LFS, which has been unmet for over a decade. saying ``oh, but
it can be a from-scratch read-only implementation!''---is that
supposed to make it EASIER?!
What's more, you don't use it yourself. I _have_ used it. At this
stage, let the person who wants to hold up the 5.0 release by
insisting someone else fix LFS for him, let that person speak up, so I
can disagree with him. strawmen are bad enough, but pandering to
straw men is ridiculously bashful.
re> (that it has more or less always been listed as experimental
re> provides some excuse for simply dropping it, but not really
re> enough).
how about that it's always performed as experimental: worked better
and worse from one release to the next, caused lots of panics and
borkenness and lost data, never shipped with a reliable lfsck? Its
obvious behavior should make a stronger warning than the note in the
man page.
There is obviously a limited amount of interest to work with. I think
it's silly for people not interested in doing the work to argue about
what others should do, and that's what I was doing, so I should stop.
But saying ``5.0 cannot be released without working LFS'' is even
*worse* than what I'm doing, which is saying, ``having some workable
filesystem for >1TB volumes, like the multiple options Linux and
FreeBSD have and the single option Solaris has, is more important than
preserving the ability to read experimental datasets written by broken
code in old versions of NetBSD.''
Whether you want to ``keep'' LFS or not, in terms of typing 'cvs
delete' or not (which makes no direct irrevocable difference), or more
meaningfully, keep talking about it or not, or more realistically,
keep encouraging people to work on it by saying ``no we don't want to
start importing ZFS/HAMMER/whatever because we already have LFS which
is almost working and much better'' (which is the standard NetBSD way
of encouraging people to work on something), all that ASIDE, binding
working LFS to 5.0 release is worse than all those things, is a
disastrously bad idea because you will frustrate the release and end
up with only minimally-working toy LFS at best.
Attachment:
pgpTP7nVLN4V1.pgp
Description: PGP signature