Re: Why Linux is doomed (was: Re: FENRIS (nwfs) 1.4.2 Source Code

Khimenko Victor (khim@sch57.msk.ru)
Wed, 23 Jun 1999 22:21:08 +0400 (MSD)


In <19990623141635.12078.qmail@convergence.de> leitner@convergence.de (leitner@convergence.de) wrote:
> In local.linux-kernel, you wrote:
>> > just saying we should try to assess the impact on the commercial Linux
>> > vendors, and try to give them adequate warning, but progress also has a
>> > price and I agree it's difficult tightrope to walk.
>> i think we can assume that the Linux filesystem architecture goes only
>> 'forward', so things will keep getting cleaner and it will be more and
>> more easy to integrate new filesystems.

> Oh yeah?
> To me, this is the complete opposite of what I have seen in the past.
> Yes, there are a lot of file systems out there. BUT:

> reiserfs fails to compile all the time. First the dentry stuff
> broken, then the semaphore initialization broke, now the buffer
> cache stuff, tomorrow what?

Something other will broke :-)) It's not very different from other OS'es.
For example when Windows98 was out it was needed half year to fix our
filesystem (since error was in Windows98 kernel, not our code and we had no
sources of that kernel; in the end fix was added: one internal function was
intercepted and stightlty modified).

> Please have a look at reiserfs. It looks like a great file system, and
> Hans is paying someone else to do the coding. Now, he _should_ just be
> able to concentrate on coding his file system and tree knowledge and use
> the well-publicized kernel API.

It's not how linux was created in first place and I'm doubt if it's superior
way.

> Wait, did I say well-publicized kernel API? The kernel API is not just
> not well-publicized, it changes all the time! Hell, how can it be that
> a supposedly stable kernel release does not even _compile_ without
> syntax error on non-x86 platforms?! This is not only embarassing, it is
> much more unprofessional than Windows NT needing BIOS support to install
> on Alpha.

It does not compile even on x86 platforms sometimes. Now what ? "If it'll broke
you'll have both parts". To me MTBF is MUCH more important then compilability
(and I had uptime measured in MONTHS even for development kernels!). I can
fix minor problems myself or I can wait for vendor for new "boxed" version of
kernel.

> Let me reiterate some things that happened to me recently:

> 1. I have an Alpha here. The vendor ships it with Redhat 5.2, which
> IMHO stinks. It has an old library, an old egcs, ...

It's supported. Or you MUST use what your venrdor gave you or you are on your
own...

> But my vendor (Quant-X, btw., whom I can not praise enough in
> public) installed a working 2.2.5 for me.

Great.

> 2.2.7 came out, I untarred the distribution, it did not compile. I
> had to fix some trivial things that _anyone_ must have seen who
> tried to compile the kernel, like an include file that was not
> included somewhere.

Linus does not compile kernel on Alpha. Linus is NOT support center.

> I cannot understand how a kernel like this can even be put on an
> FTP site without even trying to compile it on all platforms.

Huh ? Who'll donate Linus all possible obscure platforms and pay him for it ???
Linus is NOT VENDOR. And NOT SUPPORT CENTER as well.

> Anyway, 2.2.7 compiled with minor massaging, but randomly hung at
> boot time with a "spinlock stuck" message. I tried to get rid of
> that and tried to install 2.2.8. It would not compile. 2.2.9. It
> would not compile. I then switched to 2.3.6-ac1 that actually
> compiled.

Lucky you :-))

> 2. I have a laptop. pcmcia is a vital kernel part for laptop users.
> And frankly, I cannot understand why this is not part of the
> standard kernel.

There are was a lot of discussion on subject. But even if it's not part of
standard kernel it's part of most distributions anyway.

> I marvel at the quick turnaround time of the pcmcia guy at stanford
> who manages to adapt to kernel problems within hours after the new
> kernel comes out. Anyway, once it didn't work. Again, the semantics of
> something changed.

Which STABLE kernel it was ? If it was development kernel it's 100% Ok.
-- cut --
Linux version 2.3 is a DEVELOPMENT kernel, and not intended for
general public use. Different releases may have various and
sometimes severe bugs.
-- cut --

> 3. ALSA. ALSA is a must for me at home.

It's your problem. ALSA is in early development stage and is NOT supported
by ANY Linux vendor (AFAIK, anyway).

> The kernel sound driver for my 1370 not only clicks and pops all the
> time, it can also suddenly die off completely. So, I need ALSA.

No. You must ask vendor or manufacturer to fix driver :-)

> The ALSA guys recently did a new release that also works with the new
> semaphore stuff, but before that release came out, I had to fix things
> manually. So I looked at the kernel diffs but the resulting ALSA still
> crashed. For some enlightenment about how painful their compatibility
> layers have become so that ALSA compiles on many kernel versions, please
> look into the header files of the alsa-driver package. I can
> almost feel their pain when I see those macros.

Still it's MUCH easier then to develop working driver for Windows where you
must use non-documented functions and fix errors in Windows kernel "on the fly".

> 4. FAT. 2.3.7 does not compile with FAT file system. Excuse me?
> This is the single most frequently used file system besides ext2,
> and 2.3.7 does not compile with it? Because of a syntax error?!

This is development kernel as well. Why do you expect that this beast will
compile ?

> 5. Modules. I get unresolved symbols every other kernel. Does nobody
> try to compile everything in once and everything as module once
> before releasing a kernel? Yes, that is work. But how can you
> tell Ziff Davis that Linux is a professional enterprise-ready
> operating system if blunders like these happen?

What a problem ? You used some DEVELOPMENT version downloaded from net and
NOT SUPPORTED by your vendor ! Why are you complain about ANYTHING ?

> Management summary: stuff like this sucks. I am but a programmer with a
> SMP box that likes to run the latest kernel. And yes, I expect all the
> kernels to compile out of the box. I don't think that this is too much
> to ask.

It's WAY too much to ask. Or you use something from you verndor and have
support or you can play your own game. You can not have both in the same time.
It's REALLY REALLY hard task to clean out stuff enough for compileability
in all possible configurations. It compiled in configuration used by Linus :-)

> Nowadays, people do not compile their kernels anymore. Their
> distribution comes with a kernel, and they use that one. This shields
> us and Linux from most of the blame, since people think it's their fault
> if the new kernel does not compile. But this is no good situation. I
> can practically see before my mental eyes a Microsoft sales weasel
> showing people "make config" and then compiling a kernel where FAT does
> not compile! I mean, just the normal compilation messages look like
> martian cryptography to normal people, but if you tell them "see, now it
> broke", _nobody_ in the audience will actually tell you "but you have
> the source, you can fix it if you are smart enough".

I'll ask him to show the same with his OS kernel. Or just DDK driver will be
enough (there are quite a few drivers in non-compileable state :-)

> Thus, I propose these changes:

> 1. No More Function Renaming.
> People are actually using your test kernels.
> Yes, you warned them, but what does that help the user?
> I, for example, have to use a 2.3 kernel, because the 2.2 kernel
> just freezes when I NFS-mount my laptop.

You have choice: use 2.3 kernel and STOP COMPLAINING or use 2.2 kernel from
vendor and ask him for help.

> 2. No more incompatible changes.
> The whole idea with the VFS was that you could develop a file
> system modularly. If I wrote a file system (and I thought about
> this for a while), I would be royally pissed if I had to spend my
> development time working around changes in the kernel.
> Of course, there is the necessity to change things from time to
> time. But if you rename(!) a function in the kernel, is it too
> much to ask to do a global search-and-replace in the rest of the
> kernel?

This is simple test to find if this filesystem is still supported :-)

> 3. Create some decent abstractions.
> You can change all the semaphore stuff you want when you give the
> programmers some macros to create a consistent, non-changing
> interface.

It's not how linux is developed. Especially for development kernels.
For stable branch is can be considered like a good goal though...

> 4. When you do a change in the kernel, DOCUMENT IT.
> Let's create a new directory, Documentation/incompatible-changes.
> There you just create a new file for each change that says "if you
> get an undeclared symbol foo_bar then edit this file and rename it
> in your code to bar_foo". Then a driver developer can just grep
> there and be done. You don't actually expect a driver developer to
> read all the kernel patches and see if the same problem hit someone
> else before, do you?

Just one simple problem: it will not work. WHO will write this file ? Linus
will not do for sure.

P.S. Summary: you can use Linux as "normal" vendor supported OS. In this case
do not download anything from ftp.kernel.org (or mirrors) and ask your vendor
about problems. Or you can use Linux is Linux way: with manual fix when needed
with latest non-compileable development kernels and so on. Or you can grab Linux
source, create new OS (Leitux?) and try to convince uses to switch to you OS ...
I'm not sure if you'll be very successfull though...

-
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/