On Tue, 13 Jun 2000, Matthew Hawkins wrote:
> On Tue, 13 Jun 2000 James Sutherland <jas88@cam.ac.uk> wrote:
> > In some respects, perhaps, but unlike the Unix problems, Linux still has
> > the same kernel and most of the same utilities, libraries etc.
>
> Just about every distribution ships a non-Linus kernel, so the end user
> is not necessarily running the same kernel. Some of those patches
> require different utilities, some distributions take forever to upgrade
> to the new libc library, let alone any other library...
The distributions add some patches, but they don't write their own
replacement kernel. Debian might be using 2.2.15 with patch X, while Red
Hat ships 2.2.12 with patches Y and Z, but they are fundamentally the same
kernel, rather than just derivatives of a common ancestor kernel.
> > Indeed. One of the biggest problems with Unix was the way vendor
> > versions exploded, with lots of different licensing fees and
> > agreements, so every version came with different libraries, desktop
> > environments, compilers...
>
> You mean how some distributions ship with non-GPL'd software,
Almost all of them do, fortunately. GPL != open source.
> and some are based on libc5 and some on libc6 and some on 6.1,
IOW, there are two different C libraries out there, and not everyone uses
the same version. Hardly a major divergence.
> some come with GNOME and some come with KDE and some come with CDE,
ISTR quite a few come with both; last time I looked at my Mandrake login
screen, there were about a dozen options.
> and some come with gcc-2.7.2.3 and some with pgcc and some with egcs
> and some with gcc-2.95.2?
All different versions of the same compiler, really. They've all got gcc
of one sort or another.
> Some people claim that LSB is the answer to this, but last I heard the
> LSB consisted of representatives of different distributions coming
> together and being told by the Redhat folks "you will do it our way" and
> everybody doing the right thing and leaving in disgust.
Not a very constructive attempt, really. What they should have done is
excluded Red Hat, rather than excluding everyone else...
> I bet this is the same thing that happened 20 years ago. The lesson not
> learned is doomed to repeat itself?
Those who do not understand Unix are condemned forever to reinvent it,
badly...
> Anyway, my 2c on the reiserfs thing, the main argument seems to be that
> some people who haven't used it and some who have claim its not ready,
> the developers and others who have/do use it claim it is,
There have been perfectly normal situations where RFS b0rks horribly, it
seems.
> I thought there was an EXPERIMENTAL tag in the config for these sorts
> of things so those who wanted could use them and those who didn't
> don't even get to see it by default?
It's for new, experimental code - not half-finished code!
> Then with the extra feedback the outstanding issues (if any) could be
> resolved?
Right now, most of the feedback tends to result in a mudslinging contest,
where someone reports an area where RFS is completely broken, to which
Reiser replies with another benchmark showing that RFS is about the same
speed as ext2, only less reliable. (That's not quite his interpretation,
of course...)
> Hell, even ext2fs has bugs that are still being fixed - maybe for the
> same argument of not including reiserfs ext2fs should be removed, and
> people who need it can download it as a separate patch from sct's ftp
> site until all the outstanding issues with ext2fs have been resolved?
Nope. ext2 is properly integrated into the kernel, and does work reliably
in the vast majority of cases. The same is not yet true of RFS.
> Sounds fair and reasonable to me. Many people have to download all
> sorts of other separate patches (raid, alsa, nvidia dri, 3dfx, working
> tulip drivers, etc.), what's one more?
In the long run, once they are finished, those patches will probably get
integrated. There is already some RAID code included; some isn't yet
stable/finished enough to go in.
> <paranoid mode>
> Or do we have one set of rules for AC's friends and coworkers submitting
> patches, and another set of rules for everyone else?
> </paranoid mode>
Far from it.
> I agree that Hans Reiser may have made a bit of an ass of himself on
> this list, but Theo de Raadt had similar problems with the BSD core and
> I don't think it reflects on his code either. Plus Hans is only one of
> many people working on reiserfs. If patches that are WIP (eg, on the VM
> subsystem) can get in, why not patches that are far more advanced?
> Again, mark it EXPERIMENTAL. The only reason I can see for not doing so
> is political, not technical, based.
The VM changes have affected performance issues - they've been a matter of
tuning. RFS, on the other hand, is still eating data in some cases. It
just isn't ready, especially in the runup to a .0 stable release.
> I (like other subscribers) look forward to the joint contributions
> everyone involved in journaling filesystem support will make after they
> fight it out (er, sort it out :) at that conference thingy. United we
> stand, divided we fall.
I hope there will be enough ambulances on standby at the conference, with
weapons checks on the door... :)
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:27 EST