Slashdot Mirror
Linus Speaks With c't On Clean Design And ReiserFS
Daniel Burckhardt writes: "There is a nice interview from the german c't magazine with Linus Torvalds.
It's no longer about getting hit by a bus but instead about dropping into the atlantic ocean. He talks about his dislike for keynotes, the importance of "good taste" in os-design and why nobody wants 2.4 (they are all happy with 2.2).
And for some real news: Expect ReiserFS going into 2.4.1."
It's a longer interview than online translators like: babelfish choked on the translation for me, and only got about halfway through it; the systransoft engine, on the other hand, worked like a champ and yielded a smoother translation to boot.
`Was users do, are never false '
Linus Torvalds to history and future of Linux
Star guest of the LinuxWorld at the beginning of of Octobers in Frankfurt was
Linus Torvalds. The success of Linux has the free operating system and its
`Erfinder the ' far beyond EDV world admits made.
1991 had begun Torvalds from its discontent with the PC operating systems
existing at that time, a its own, to program Unix similar operating system.
Originally Linux was only for the computer at that time of the 21-Jaehrigen
meant; but after publication of the version 0.01 in the InterNet Linux won very
fast trailers and a constantly growing crowd of developers. Meanwhile the open
SOURCE system on all usual hardware architectures runs and particularly with
the InterNet servers a fixed workstation captured.
c't: Linux what you wanted originally, but already some years ago achieved. Why
did you continue at this point?
Torvalds: The targets changed. At the start it concerned to me above all to
make something interesting and have fun. I assumed that I would be the only
user, and made also no concrete plans regarding the features. I knew, what I
expected from a Unix; but I was not interested for example in diagram, because
I wanted to only edit and compile source code.
After I had published Linux in the InterNet, however different users asked for
features, of which I had never thought, and ever more new ideas arose. Instead
of a Unix for my own Desktop Linux should become now the best operating system
at all. By the desires of other people and later then its Patches and
assistance it became many more interesting. In the meantime most work is made
by others.
Meanwhile it concerns to me a good operating system Design, which is useful for
other people also. My activity did not change at all so much: I program and
read a quantity of enamel. In view to my original plans Linux is long finished;
but the many new areas of application for Linux motivate me to continue. If I
had not placed Linux in the InterNet and these other users were not, I would
have probably already terminated the work on Linux 1992.
c't: How long do you want to continue with Linux? You see one point sometime in
the future, at which you will say: `Jetzt has I enough of it?'
Torvalds: I do not believe that there is a special point there. I always
stopped with individual things, and began already very early. Completely at the
start for example I provided for all applications: I had - additionally to the
work on the Kernel - portieren which Shell, the compiler and the libraries.
Therefore then however very early different people worried, and I could
concentrate on the Kernel. Nowadays I operate still on the Kernel, but I am
limited now to a large extent to central functions such as memory and task
management and the fundamental Design.
Likewise I stopped to a large extent speaking on meetings like this LinuxWorld.
I participated here in the panel discussion, but no key note held, because me
such things dreadfully stresses. I assume I will concentrate on ever more
special areas; but I do not believe that I will stop completely with Linux -
until someone comes perhaps sometime, which is better than I, so that I
withdraw myself.
c't: If you sometime no more desire on Linux have - as then the organization of
the Linux developers could turn out?
Torvalds: I do not see that in foreseeable time occurs; but there is a quantity
of people, which could do my work. Meanwhile I hardly still program, but I show
`guten taste ' - I make decisions regarding architecture. But there are other
people, which have likewise `guten taste '. I am a type central start place,
process enamels, read her, send her to the correct people.
Meetings are obviously PR work, and there are enough people, which could do
that just as well. Zurzeit is most important it to be a type identification
figure for Linux purely for psychological reasons. Meanwhile one knows Linux of
companies such as SuSE, IBM or talks has; but long time was Linux this radical,
movement aforementioned by Linus Torvalds.
If the airplane from Frankfurt would fall now to San Francisco, everyone could
- now well, perhaps everyone, but a quantity of people could not take over mine
job. It would not be surely only one person. The fact that it is for the moment
a person has historical reasons. In reality Linux is not only one person: I do,
what I do, and [ the XFree86-Entwickler ] my technical work on the Kernel makes
its job for Dirk Hohndel for example could several people complete.
If one regards, how Linux is actually developed: I do not touch for example the
Kernel 2,2, make all [ the Kernel hacker ] Alan Cox. now have we soon the
Anwenderkernel 2,4 finished, and then Ted Ts'o [ developer of the
ext2-Dateisystems ] will worry about the Kernel 2,4. I can concentrate then on
the Entwicklerkernel, because me in most interested and because the developers
thereby are content, as I do. But it is not like that that that could not do
anybody to others. It would surely give a quantity to excitement in the media,
if I fell over the ocean, but for the Linux development I am no longer
important so.
c't: Can you tell us a little more about it, how the development of Linux is
organized?
Torvalds: We take a simple example. There someone has an idea. First he will
discuss that with acquaintance and on the Kernel mailing list: I need this
feature for those reasons, operate there someone to? If nobody announces
itself, he will program it. Then it uses the new feature only once, speaks with
people in its environment more drueber and postet it on the Kernel mailing
list, if it liked that its code is received into the Standardkernel. He knows,
how it runs, and does not send not equal a Mail to me.
If it is perfect code, it is called perhaps alike in the mailing list: we want
to have `Ja, that.' But does not occur in practice. The reaction looks rather
in such a way: `Wir understand, what you want, but like that are that
considerable muck. I would like to make something something similar, but does
not go together with your code.' And then one modifies the interfaces, so that
both goes at the same time, and it comes to modifications, in which other
people are interested.
That can last for a very long time. Above all large modifications can circulate
even several years as Patches in the Kernelliste, while and even a quantity of
people the new code is discussed to begin. I receive such Patches and
discussions on the list; and I decide sometime then that the code is so useful
that it is to become part of the Standardkernels. Perhaps particularly with
important questions I discuss along and legend: `Ich sees, for which you are;
but from view of the Kernelarchitektur that is the false way '. The code flows
sometime then into my Standardkernel, or it remains an external Patch for
special purposes.
c't: How are you to the possibility of a code Forking in the Kernel? The Linux
boss at IBM about said recently that a Kernel cannot cover all request of the
Embedded DEVICE up to the enterprise-critical server.
Torvalds: Forking constantly occurs. Only because my Kernel is considered as
the official, that does not mean that there is not a quantity `inoffizielle '
Kernel. For example most Distributoren has own Kernelversionen with special
features. SuSE about attaches much importance on ISDN, because in Germany is
important; for the remainder of the world ISDN is however no topic. Different
distributions address themselves to different classes of users; SGI for example
is interested particularly in the SGI market with computers with hundreds of
CPUs. The SGI Kernel will contain therefore features for the application on
large machines.
I try to maintain a common Standardkernel; but that is not Kernel for everyone.
Naturally supercomputers and Embedded DEVICE make completely different demands,
and the Kernel will be never the same. I try to keep the differences as small
as possible to insert and new things in such a way that they do not obstruct
extreme applications.
c't: During the work on the Entwicklerkernel 2,3 there was a quantity of
discussions around the store management...
Torvalds:
c't: If one wants to address large quantities in servers at primary storages,
one needs a store management, which is not so efficient in systems with few
RAM.
Torvalds: That is a classical example. A quantity of things seems to be
incompatibly together. There I need page on the support for small devices, and
on the other page are large machines with 16 nodes, everyone with its own
memory and altogether hundreds of GByte at RAM. The solutions for it must look
naturally completely different. The first response consists usually of two
different code watering gene, simply because it makes work to few - the code
does not have to consider so many possibilities. But the maintenance of the
code becomes more difficult, because one must have interfaces to both code
watering gene.
But then it comes to a Virtualisierung of the store management. That was one of
the things, on which we operated during the 2.3-Entwicklung: to virtualisieren
the term of a `Speicherknotens '. A small device is then the same like a large
machine, with the only difference that it has only a memory node, while the
large computer has several this node. The small device becomes in such a way a
simple case of the large machine.
From the same code then different Kernel develops over an appropriate
configuration option. In the source code there is a loop over the nodes; but
with a node the loop runs from zero to zero, when compiling is away-optimized
and is missing in the Binary any longer. That makes the maintenance of the
source texts many simpler, and with such Design questions I deal with myself.
Naturally that cannot be done always in such a way. Sometimes one has simply
different devices, which need different drivers. One must with the Design the
decision meets, which code is general, and when one writes different code for
the different cases. Therefore it goes in the long run into the computers
Science.
c't: The Kernelquellen is meanwhile very extensive...
Torvalds:
number ready, but there is about three million lines code. The Kernel is
enormous, and nobody could maintain him, if not very most driver completely
independent of it were. In addition, driver development is not simple, because
one must out-iron all the weaknesses of the hardware.
c't: Programmers know the problem that they modify something in a place in the
code and the program falls then in another place.
Torvalds: Occurs such a thing with the Kernel also.
c't: How do you kriegt such difficulties into the grasp?
Torvalds: There is only one solution: clean interfaces. Ideal way should give
it never surprising of bug or to interactions, of which one never thought. The
interfaces must be so clear that one knows with a modification of the code in a
place, in which places one otherwise still modify must. I do not state that the
interfaces are always so clean in Linux, but we operate on it. Many of the
modifications in the Kernel 2,4 direct in this direction. It in most cases
concerned more to sketch clean interfaces to write than actually new code.
Frequently the program code does not fit however what one considered oneself;
that makes a modifying of the interfaces so laborious. But it is enormously
important, even if the user can detect only no advantage therein - until it
discovers a new machine, where the modified interface is necessary.
c't: I do not even want to ask, when the Kernel will appear 2,4...
Torvalds:
c't:... but would interest me, where the problems with the new Kernel were
situated.
Torvalds: A fundamental difficulty is not at all technical type, but is
situated in the fact that most people do not want to upgraden at all on a new
Kernel. They are not content with the Kernel 2,2, have larger problems thereby
- why should they try a Entwicklerkernel out? It is a certain group of users,
who test new Kernels; and before the publication of a new Anwenderkernels at
least a section this user must have tested the new Kernel. The developers have
their own view of new versions, we need external users for testing. That is not
only with Linux a problem; some software producers pay even people for trying
new beta versions out.
But there are also still a few technical difficulties. We know of some genuine
bug, for which partly even already solutions exist; however all developers are
not convinced that these solutions are also really good. In this regard there
are still some open questions: Frequently the developers want better solutions,
which guarantee that a certain problem does not occur in the future any
longer.
Beyond that there are also problems in communication. The people, bug find, are
usually the developers themselves and do not describe the problems completely
differently, than that would do a developer. That costs simply much time.
c't: A while ago you already spoke of the Kernelerweiterungen of the Linux
Distributoren. SuSE for example delivers the Anwenderkernels 2,2 with the
Logical volume manager and the Journaling file system ReiserFS. Even ones over
ReiserFS intensively discussed the Kernelentwickler - with the decision not to
take up it yet to the `offiziellen ' Kernel. What do you hold of such
`Eigenmaechtigkeiten '? You had nevertheless surely your reasons for the
decision against ReiserFS.
Torvalds: Particularly in the last year new groups of users were added, and
even SuSE - to want to speak without now for SuSE - co-operated much with large
customers, who are interested in LVM. For the administration of several hundred
disks one needs such Tools. And also, if the system does not fall, but, is not
acceptable e2fsck-Laeufe of several hours is only occasionally again gebootet,
so that one will take dear ReiserFS. Such applications arose only lately, and
it needs simply its time to integrate such a thing. LVM is since a half year in
the Entwicklerkernel 2,3, but still last week we operated on it. ReiserFS
wanted to take up I in no case before the Kernel 2,4, because I always thought,
briefly before the code Freeze to be and no completely new questions more into
the discussion to bring wanted. SuSE and others tested ReiserFS in the
meantime, therefore we will probably take up it to the version 2.4.1. nglish:
Which users do, is never false. I cannot prescribe the Linux Usern
nevertheless, what her to do to have. My opinion always was: Which the people
want to always do, it is correct. I can make only decisions, how architecture
is to look, those enabled, or notes to give, how one can obtain the same result
with another beginning. ReiserFS will come, and I cannot say easily `nein ' to
it. Perhaps for me it goes only around the timing and some modifications, in
order to integrate ReiserFS better into the Kernel.
[ SGIs Journaling file system ] XFS is another thing. **time-out** it be not
yet so far like ReiserFS, and I can not say, whether it in a year section the
Standardkernels be will. [ the successor of the Linux standard Dateisystems
ext2 ] ext3fs is again another affair. Already there the code is, and there are
users, who already use it. ext3fs could be quite integrated into the
Kernelserie 2,4 or at an early point in time in the Kernel 2.5. It concerns to
me flexibility. Open SOURCE means that one can make all possible one with the
code.
That does not mean that I use ReiserFS or ext3fs. Which interests me in it, is
something else. ReiserFS, XFS and ext3fs will have obviously a quantity
together. What means for the Virtual the file system [ the Kernelstruktur,
those the interface to the file systems forms ]? Perhaps take we sections code,
which several of the file systems contained - even if they do different things,
it concerns and tries in the long run the same -, to create for it a common
interface. Makes work real such a thing. Until the VFS can deal with
Journaling, still two or three years will probably offense; but then the file
systems do not have any longer so much work thereby. That is the type of
questions, with which I deal with myself.
c't: What is to time the most interesting technical developments with Linux?
Torvalds: With most things it does not concern at all the Kernel. Naturally
there are there exciting developments, for example the scaling barness - that
was technically extremely interesting. But the really fascinating things make
other people. The whole excitement around DVD was very interesting, although
perhaps something discouraging. And then naturally the Desktop and things,
which are quite unusual actually for Unix. If I look for example television, I
do with a Linux computer, whose fixed disk serves as video recorder. If one
used such a device times, one wants to never touch again a classical video
recorder. I use such devices only for films, which there are not on DVD.
c't: And generally in the IT world? Finally you operate in a Hightech company.
Torvalds: These whole wireless stories. I have for example a great Handy, a
laptop and a Palm. If I on the way am, use I mean laptop, in order to read
E-Mail; and then I want to use the Handy as modem. But does not go; this type
communication does not function simply yet. I think, in five years all these
devices to communicate together will be able. Interesting thereby the
technique, but the conversion to applications is fewer.
c't: If you on the long history of the development of Linux back-look: Were
there things, which surprised you there?
Torvalds: Very few. Naturally I would have been at the start very surprised, if
I had known, where Linux would develop. But when that all occurred, nothing
really surprised me of it. When I placed the version 0.01 in Internet, I
counted on comments. Perhaps came at that time somewhat more reactions, than I
had expected; but I believe, not times that was really like that. After some
months there was 50 instead of the expected five people, then some hundreds;
and that surprised me already somewhat. But I at the same time experienced the
development of five over ten and twenty to fifty Usern, therefore there was no
point, at which I said myself: `Mein God, which occurs there? ' Then the
commercial interest, which increasing medium echo - which think most people,
which is everything in the last two years occurs, but actually developed it
slowly of the last nine years. Companies began to support Linux - sometimes it
was surprising to be seen, in which extent, approximately at IBM nobody counted
on the fact that IBM would go so far. In addition, there was not these one
point there, at which I would have been really surprised.
c't: Does it give somewhat, what annoyed you?
Torvalds: Not much. The most unpleasant surprise was this Mindcraft study [ one
of Microsoft financed study, in in April 1999 Linux in relation to Windows NT
very badly had probably cut off ]. I remember still, how sour at that time I
was. Meanwhile it does not annoy me any longer, since it went out at the end
well. Perhaps most surprisingly the constantly positive reactions are opposite
Linux. The developer municipality was from the outset very friendly, despite
all these discussions around the Linux Kernel, which can work occasionally very
violently.
c't: There there is a quantity of ugly discussions...nglish:
Torvalds: Yes, with discussions around their technical ideas the people become
very heated and unpleasant.
c't: Is typical for the open SOURCE municipality? For example this strong
antipathy opposite Microsoft...
Torvalds: No, not only. Are there very similar to Mac user. Internet makes it
easy to talk simply straight on and then it comes fast to Fleming Wars. One
does not know the people, with which one argues, and then exaggerates one it
easily. That is not definitely only with Linux like that - if one all `Advocacy
the Groups ' there outside regards... it is amusing. The arguments between
Linux and FreeBSD fans for example are still many more violent, because these
groups know each other and know well, where it pain-does. The people argue
simply gladly. It is a social competition, one shows so its superiority other
one opposite. Many of these fundamental debates are in the meantime completely
past, for instance the argument around vi versus Emacs (odi)
You can't possibly believe that Linux is the only operatingsystem that has got buggy device-drivers. Device-drivers ARE fully capable of crashing your machine.
:) Some of them actually make the kernel crash. Others don't provide needed information -- like a stack dump.
:)
Oh, I know. QNX and Multics are the only OSes I know that can survice a driver crash. The scanner would opps the kernel without the scanner driver being loaded. It was just the usb-uhci code oopsing, before I even had the scanner.o compiled. It works fine on my home machine, as long as I don't turn off the scanner while it's in operation (otherwise... oops).
What's so broken about the semaphores/spinlocks in the v2.4 kernel?
To be honest, I dropped the 2.4 kernel after test-6 and retreated to 2.2.16 and 17, which were also broken (race conditions, oopsing on upping the sempahore). Now we're doing FreeBSD, as I cannot lose more time waiting for things to be fixed.
But imho, none of the proposals [streams/EAs] posted on the LKML during the entire debate was sane either.
Ours was posted off-list, by invitation from Viro and Cox. Since they simply told us to shut up and added us to their killfiles, we dropped it. I'll post our proposal to the list if you'd like.
But face it, NTFS, HFS and BeFS will never be the native filesystems on a Linux-machine.
I don't think anyone ever suggested that; just they they exist and Linux should be capable of supporting them. Interoperability.
I'm pretty confident Alan must have given you an explanation why [he rejected the prink patch]?
He did not.
It should print long long's without any trouble, at least in the v2.4-series.
That's our patch, I think. It was accepted for 2.4, but not for 2.2. Because 2.2 is the 'stable' kernel, a working printk is useful now The 2.4 will be nice when that kernel stabilizes (in terns of interfaces).
No, Linus doesn't have to accept code he doesn't like, but if you try to imagine how much code he has to accept every week,
It's silly for Linus to have to look over every patch. That's what I'm talking about -- a lack of guidelines, coding standards, etc. means that delegation doesn't happen. Viro's nominally in charge of filesystems, but that doesn't stop Linus from tossing in new ones (DevFS, JFFS). There's no clear control. If there was -- if the kernel had clear areas of responsiblity, that is, if it were modular, then Linus would not have to even look at patches for systems he had delegated.
He does a DAMN good job, though
So does Alan Greenspan, but central planning still has its limits.
People who don't realise that they can't patch
their own kernel to add the kernel debugger
It's more that, because good support for debuggers is kept out of the kernel, applying one of the kdb patches doesn't help as much as it should. We've tried them all.
However, I believe he will sooner or later begin using BitKeeper. Maybe already for v2.5
That would rock!
But you have to realise, that it's impossible to work 48 hours/day.
Viro is notorious for making changes without warning and then not documenting them. It's hit or miss with everyone else. And I'm not expecting people to work 48 hours a day; I'm saying, if you don't have time to do it right the first time, do you have time to fix it later?
you'd probably not appreciate the kernel no matter what changes are made.
Not true. If I simply hated Linux and didn't care if it improved, I would simply have kept my mouth shut and used FreeBSD, or something. THe fact is, I want it to improve. I like it. I'm not blinded to its faults, though.
The reason I considered your post trolling wasn't because of your opinions on Linux, but because you implied that people reading Slashdot automatically would flame you, send spam to you, direct ICBM's at your house etc., just because you have a different opinion.
Only because it's happened in the past. The voice of experience and all. I figured that if I pointed out in my message that that type of response isn't constructive, it would prevent that type of response. It has worked so far, for the most part. Lots of people start of posts of controversial opinions with "this isn't a flame; don't flame me."
Thanks! I'm glad someone is willing to debate the ideas I presented, and not my spelling, shoe size, etc.
________________________________________
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Just a note that the Fish is run on Systrans Translation Engine. How ironic.
Now I understand why the geek community loves Linus: He speaks like Yoda!
If had been written "e-mail", the word would have been translated correctly. The word "email", however, is a French word that refers to a type of enamel. The translation is spot-on.
--
"Where, where is the town? Now, it's nothing but flowers!"
In round two, everyone realises that these problems have been going on for some time now and aren't new. Like, almost the whole 9 years. The only way in which they're any worse is that there are more developers fighting for their ideas, more ideas (more of which are bad, simply by proportion), and more lines of (largely useless) code. The process, bizarre and apparently disorganised though it is, has worked thus far, and there is every reason that it will continue to do so. Cooler heads concede your argument, but recognise that it's mostly spin, and take round two.
In round three, we spar over posix compliance. It's no contest; without posix we're all sunk. Posix is an uneasy compromise attempt to reunify unix after 20 years of fragmentation and dirty infighting. It's the only thing that offers you any real assurance of compatibility, the only real standard out there. If we don't follow posix, then porting to and from Linux becomes tens of times more work, and thus requires tens of times more benefit (or sales, in the commercial world) to make it happen. That's a lose; it restricts us to linux-only unportable, unmaintainable garbage software like util-linux -- any porter's or distribution maintainer's nemesis -- instead of clean, fairly uniform software like the GNU set and for that matter 90% of everything that's out there. You can't bitch at microsoft or sun for ignoring or subverting standards and then do it yourself. Posix is the standard, and we're team players. Being big doesn't mean you should ignore the standards. Posix takes round 3 and comes close to a tko.
Finally, just a light jab against a bit of unnecessary propaganda: I'll get back to switching over to FreeBSD
Me, too...oops, no, it only runs on i386, an inferior architecture with no future, and for that matter, no present. Call me when you can support my SMP Sun Ultra 2 as well as Linux does. In the meantime I expect we'll release 2.4, steal your admittedly much superior VM, drop the completely useless and divisive NTFS altogether, and in short make everything right with the world. A bit of positive spin concedes round 4 and proposes a draw.
I read your post on Slashdot and I followed much of the original discussions via KT ( Only kernel developers need read the 1000+ messages a week on LKML ).
I can't comment about clean code because I don't speak Assembly or C but I can make a guess about Enterprise scalability.
What are the alternatives to having the official Kernel scale up to 64 CPUs that would pleas the people who need 64 CPUs ?
You thought only of a fork in the Kernel. However the other way is to have entirely different Kernels running on those systems.
According to IBM marketing; AIX 5L will do just that. Essentially a system that will compile software written for Linux consistently and will also run Linux binaries built for the same CPU.
In other words IBM will be able to sell you a Linux system and seamlessly switch to an AIX system when your needs outgrow Linux.
Thus leaving the main Linux development free to concentrate on the vastly more important ( I'll define important latter ) Small server, Desktop and embedded areas.
I define important in terms of the number of users. Most people work in small organizations. the kind that a single Linux system running the 2.0 Kernel can adequately serve. Anyone can use an embedded device and most people, both in small and large enterprises and at home or school use desktops of some kind. Well, I mean could use since much of the world doesn't even have electricity.
By contrast only those with truly vast jobs to accomplish can use enterprise systems. When the Hardware costs $2,000,000 and the application software costs more it doesn't matter whether or not you pay for the OS. That leaves access to the source code as the main advantage of a Linux Kernel on Enterprise systems over other larger OSs.
But wait. If you are a huge enterprise and are pushing the limits of your enterprise OS you can do two things the rest of us can't. #1. You can tell the vendor when to fix bugs and #2. You can often obtain access to the source code.
In other words the Free ( Gratis and Libra ) nature of Linux is a huge advantage on small systems but irrelevant on large systems. Except as a matter of principle. Despite RMS' efforts the principle of Free Software for it's own sake hasn't taken root yet. Especially not among IT managers.
So yes. I have no response for any of the other concerns but if Enterprise scaling adds even slightly to the problems on the low end then the choice has to be against that. After all there are easy ways out. IBM seams to be the 1st enterprise vendor to have figured out that escape route.
If FreeBSD, OpenBSD or even Hurd can be coerced into running on enterprise systems and made to seamlessly support Linux software you will have all you ask for in spades.
--= Isn't it surprising how badly I spell ?
"I am a type central start place, process enamels, read her, send her to the correct people."
--Linus Torvalds
The reason most people will stick with 2.2 is its extreme level of maturity. I am determined to not put a 2.4 kernel on any server boxes I run (www.thesilicondragon.com). 2.2 series has already been installed, tempered, and well adapted for a variety of applications. In many cases, this makes 2.4 irrelevant. However, once we see a 2.4.(n > 10), 2.2 will likewise become irrelevant. Take a look at the Debian project. Their thinking is to use what is tried and true for the utmost. Only in Potato are they now out of the 2.0 series. It's good thinking and Linus shouldn't sound so meloncholy when he says that 2.4 won't be vastly accepted in the immediate future. :-)
I'd say that the reason that people aren't interested in the 2.4 kernel is they they have lost faith in the development process.
Over the last two years, people have repeatedly posted on the LKML in one way or another that the emperor has no clothes. They've been nice, they've been rude, they've even posted good ideas and patches to provide some clothes. But, universally, the response from the LKML acolytes has been a variant of "the emperor isn't naked; he is in fact wearing a 3-piece suit, and if you don't like it, you can get your own emperor, you idiot."
It's very sad. Criticism is what keeps any public enterprise honest and productive, and the denizens of the LKML don't have any tolerance for it.
The linux development process has little direction, no planning, little to no leadership, meaningless feature freezes, and little to no documentation and guidelines. The kernel itself *is* spaghetti code inside, no matter what people say. They try to maintain control over what people use by not exporting some functions from the kernel
It is very difficult to alter some part of Linux because of all the unintended consequences. It's difficult to get needed features and clean-ups into the kernel because of cronyism and a narrow-minded religious devotion to Posix. Go back and read up on the NTFS-streams thread for a good example of that (Alan and Viro actually invited everyone talking about streams to an off-list discussion, and then notified them that they had been added to their killfiles).
Clean code? Just look at the 2.4.0-test-pre-pooch-screw series of debacles, where the VM is rewritten every few weeks, and new features are tossed in while there's still massive bugs to fix in the code that's already there, and in spite of repeated "feature freezes". That would all be fine in a 2.3.x series kernel, but judging from the version number, "2.4.0-test" is supposed to be pretty stable except for bug fixes -- not have major features added and subsystems being rewritten.
Linux has terminal featureitis. No one wants to work on the hard things; they just want to add features. Quickly.
And Linus, to make things worse, claims that a kernel debugger is counter-productive; that debugging with printk puts hair on your chest. Never mind that you can't debug race conditions well, if at all, by adding printk statements everywhere, because they change the timing of the code when it runs. Never mind that essentially every other 'modern' OS includes a kernel debugger, and that many of those OSes are better designed, better implemented, and perform better and run more reliably than Linux (FreeBSD, HPUX, Solaris, and even NT come to mind).
Linus must be right. In fact, he's declared himself to be infallible -- he will not allow a kernel debugger to be added, and has publicly stated that he thinks people who use debuggers are dummies and that he won't work with them. But never mind that; he's the leader of the mo vmentarians
- set realistic goals for a release
- defer any further feature creep until the next
release
- concentrate on fixing bugs in the pre-release cycle
- aim for modularity, stable interfaces and good
documentation to make upgrades and new feature
addition easier and the learning curve less steep
- provide robust methods for troubleshooting the
system to make development and debugging easier.
Linux does none of these things. By design. So continue to kvetch about idiots like me (and IBM, and SGI, and HP, and Reiser, and about 1000 other people and companies) pointing out that Linux is fundamentally screwed.The most common response to criticism is a variant of "love it or leave it." Keep suggesting that we go write our own damn OS if we don't like it; your love it or leave it response will be accepted one day, and we will leave Linux. I actually think it would be a good idea for the major external linux players to fork the kernel, clean it up, and maintain their own version. I don't doubt that it would shortly become the defacto standard kernel, because it will be cleaner, more stable, more scalable, more extendible, and will probably be released on time and respect feature freezes. SGI, IBM, Reiser and a lot of other people and companies have a lot of good code and ideas to contribute, not to mention full-time developers, years of experience making scalable and robust systems, and a willingness to release all that work under the GPL. And if they fork the kernel, they can do it without having to be named "Ted", "Ingo", "Alan", "Linus" or "Rik".
One day the question will be, are *you* relevant? Why should we accept *your* code? Is it clean? Is it modular? Is it safe (see LWN article about C code with undefined behavior being included in the kernel). Of course, a fork can always be re-merged with the holy penguin pee version. In the meantime, all the people who want to run Linux on enterprise systems rather than PDAs and webpads can have a stable, working kernel with adequate features.
It would be useful if people would make substantive replies to this message, rather than engage in the usual comments about rioting, sending spam reports, saying "love it or leave it," moderating it as a troll, port-scanning my mail server, attempted hacks and other juvenile/illegal acts, sending spam reports, threatening violence, etc. Of course, substantive debate is really hard to come by on either the LKML or Slashdot, so I don't expect it. So, go ahead, get started telling me to sod off. I'll get back to switching over to FreeBSD, although I would prefer if someone would take up a rational refutation of this message instead. Show me the Emperor's Clothes.
________________________________________
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
A flurry of new .sigs is going to result from the publication of this interview.
"I do not go believe comes out therefrom that I will concentrate on always more special zones."
--Linus Torvalds
"Until perhaps sometime someone, am better that than I so that I withdraw."
--Linus Torvalds
"Organizations are obvious PR-work, and there are enough people who could that just as well."
--Linus Torvalds
"A classic example is that. A quantity of thing seem incompatible together to be."
--Linus Torvalds
"At the same time fewer the technology is interesting, but rather the conversion in uses."
--Linus Torvalds
c't really needs to start an English language version of its most excellent magazine. There's already a Dutch version, so why not other languages?
I thought about submitting this, but decided against it because it's a long article in German. There's still a chance an English version is going to show up, maybe if people would mail them? Certain popular articles usually get translated. So start sending in the requests.
- Also Sprach Doktor Merkwurdigliebe
To quote the babelfish FAQ: Translation requires significant resources on our servers. To serve as many users as possible, we translate a maximum of 5k of text. If the page exceeds this limit, you see "Translation ends here" in the text.
Too bad the other site seems frozen--aparently, it's slashdotted ALREADY.
My favorite part of the translation: I program and read a quantity of enamel
Need a website host? Try out http://WebQualityHost.net
"What users do is never wrong"
Linus Torvalds about the history and future of Linux
The star guest of the LinuxWorld in the beginning of October was Linus Torvalds. The success of Linux has made the free OS and its "inventor" well-known to a far bigger public than just the IT world.
In 1991, Torvalds had started to program his own Unix-like OS out of discontent with the PC operating systems that existed at the time. Originally Linux was only intended for the computer of the then 21-year-old; but after the publication of the version 0.01 on the internet Linux started to gain users and a growing hoard of developers very fast. Today the open source system runs on all common hardware architectures; it has attained a strong position above all on internet servers.
c't: Linux has already achieved what you wanted some years ago. Why did you continue at that point?
Torvalds: The aims have changed. In the beginning my main objective was to do something interesting and fun. I thought I would be the only user and didn't make any concrete plans concerning features. I knew what I expected from a Unix; but e.g. I wasn't interested in graphics because I only wanted to edit and compile source code. But after I had published Linux on the internet, other users asked for features I had never thought of. Instead of a Unix for my desktop Linux suddenly turned into a project for the very best OS. Because of the wishes of others and - later - their patches and help it became much more interesting. Today the bulk of the work is done by others.
Now I aim for a good OS design that is also useful for others. What I do hasn't changed that much: I program, and I read a lot of email. Concerning my original plans, Linux has since log been complete; but the many new domains of use motivate me to go on. If I hadn't published Linux on the internet and if there weren't those other users, I probably would have ceased working on Linux in 1992.
c't: How long go you plan to go on with Linux? Do you see a point somewhere in the future where you will say: "I've had enough of it now"?
Torvalds: I don't think that there will be a certain point. I always have handed over some things from time to time, and that started very early. In the very beginning e.g. I was concerned with all the applications myself: I had - additionally to the work on the kernel - to port the shell, the compiler and the libraries. But very soon other people started to take over so I could concentrate on the kernel.
Nowadays I still work on the kernel, but only on central features like the memory and process management and the basic design.
I also have almost stopped to talk at events like this LinuxWorld. I have taken part here in the panel discussion, but I haven't held a keynote because these things put me under stress incredibly.
I think that I will concentrate more and more on special areas; but I don't think that I will cease to work in Linux completely - perhaps until someone comes who is better than me so that I retire from it.
c't: If at some point you don't feel like continuing with Linux - how would the developers organise?
Torvalds: I don't think that this will happen soon; but there would be a lot of people who could take over my position. Today I hardly code myself; I "show good taste" instead - I make decisions concerning the architecture. I am a sort of central coordinator, deal with email, read it, send it to the right people.
Public events are obviously PR work, and there are enough people who could do that as well as I. At the moment my most important function is that of an identification figure for Linux, purely for psychological reasons. Nowadays people think of companies like SuSE, IBM or Redhat when they think of Linux; but for a long time it used to be this radical movement led by Linus Torvalds.
If the plane from Frankfurt to San Francisco crashed now, everyone - okay, probably not everyone, but a lot of people could take over my job. It certainly wouldn't be a single person: I do what I do and [XFree86 developer] Dirk Hohndel does his job. My technical work on the kernel for example could be shared among some people.
If you take a look on how Linux is actually developed: I don't touch the 2.2 kernel e.g., that's all done by Alan Cox. Soon we'll have finished the user kernel 2.4, and then Ted Ts'o [ext2 developer] will take care of that. I will be able to concentrate on the developer kernels because that's what I'm most interested in and the developers are happy with how I do it. But it could as well be done by other people. It would certainly cause a lot of agitation in the media if I dropped into the ocean, but I am not that important any more for the development of Linux.
c't: Can you tell us a bit more about the organisation of Linux development?
Torvalds: Let's look at a simple example. Someone has an idea. First he will discuss that with people he knows and on the kernel mailing list: I need this feature for these reasons, is someone working on it? If not, he will code it. Then he uses it himself, talks to people in his vicinity, and posts it on the kernel mailing list, if he wants it to get into the standard kernel. He knows how it works, and doesn't send mail to my from the beginning. If it's perfect code, maybe the mailing list says: "Yes, we want to have that." But that doesn't happen in practice. The reaction is more like that: "We understand what you want, but like that it's more or less bullshit. I would like to do something similar, but that doesn't work with your code." And then the interfaces are changed so that both things go together, and other modifications are made that make other people interested. That can take a long time. Major changes can live a few years in the kernel list while they are discussed and even a lot of people use them. I take notice of such patches and discussions on the list; and at some point I decide that the code is so useful it should become part of the standard kernel. If important questions are discussed, I join in and say perhaps: "I can see your point, but from the point of view of kernel architecture that's the wrong way to go". At some point the patch becomes part of the standard kernel, or it continues to be an external patch for special purposes.
c't: What is your position on a possible fork in the kernel? The Linux boss at IBM e.g. said some time ago that a kernel can't fulfill all requirements from the embedded device to the mission-critical server.
Torvalds: Forking happens all the time. The fact that my kernel is considered the official one doesn't mean that there aren't many "unofficial" ones with their own features. For instance the most distributions have their own kernel versions. For SuSE ISDN is very important because that plays a part in Germany; for the rest of the world it's not important. Different distributions are targeted at different classes of users; SGI e.g. is mainly interested in the SGI market: computers with hundreds of CPUs. Therefore, the SGI kernel will include features for the large machines.
I am trying to maintain a common standard kernel, but that's not a kernel for everyone. Of course supercomputer and embedded device require different things, and there will never be one kernel. I am trying to keep the differences at small as possible, and incorporate new things in a way that doesn't hinder the extreme cases.
c't: During the work on the 2.3 developer kernel there was a lot of discussion on memory management...
Torvalds: ... they still go on.
c't: To address big amounts of memory in servers you need a kind of memory management that's not as efficient in small systems with little RAM.
Torvalds: That's a classical example. A lot of things seem to be incompatible with each other. On one hand I need support for small devices, and on the other there are big systems with 16 nodes, each with its own memory and a total of hundreds of GB's of RAM. The solutions look totally different, of course. Usually, the first answer consists of two code branches, simply because it generates the least work - the code doesn't have to take into account that many possibilities. But maintaining the code becomes more difficult because you have to have interfaces to both branches.
But in the end it comes down to a virtualisation of memory management. That was one of the things that we worked on during the 2.3 development: virtualising the concept of a "memory node". Thus, a small device is the same as a big machine, with the sole difference that it only has one memory node, whereas the big computer has several of these nodes. So the small device becomes a special case of the big machine.
By a configuration option, different kernels can then be compiled from the same code. In the source there is a loop through the nodes; but if there's only one node the loop goes from 0 to 0, is optimised away during compilation and doesn't appear any more in the binary. That makes maintaining the source much more simple, and that's the kind of questions that I occupy myself with.
Of course, it doesn't always work that way. Sometimes you simply have different devices that need different drivers. In design you have to decide what code is common and when you write different code for the different cases. That's what computer science is all about in the end.
c't: The kernel sources have become very comprehensive...
Torvalds: ... around 55 MByte source code; I don't know the exact number, but there are about three millions of lines. The kernel is huge, and nobody could maintain it if it wouldn't consist mainly of totally independent drivers. But driver development isn't easy either, because you have to iron out all the glitches of the hardware.
c't: Programmers know the problem when they change something somewhere and the program crashes somewhere else.
Torvalds: Things like that also happen with the kernel.
c't: How do you deal with such difficulties?
Torvalds: There is only one solution: clean interfaces. Ideally, there should never be any surprising bugs or interactions that you would never have thought of. The interfaces have to be so clear that if you change something you just know where the you have to adapt the code. I don't claim that the interfaces in Linux are always as clean as that, but we aim for it. Many of the changes in the 2.4 kernel go in that direction. In most of the cases the main task was to sketch out new interfaces, not to actually write new code. But often the code doesn't fit what you have thought out; that's what makes changing the interfaces so tedious. But it is very important, even if the users first can't see any advantage in it - until they some across a machine that needs the new interface.
c't: I don't want to ask to start with when the 2.4 kernel will be out...
Torvalds: ...I hope it will be this year...
c't:...but I am curios about the problems with the new kernel.
Torvalds: There is a basic difficulty that isn't of technical nature: most people don't want to upgrade to a new kernel at all. The are satisfied with the 2.2 kernel, don't have any major problems with it - why should they try a developer kernel? It's only a special group of users who test new kernels; and before making public a new stable kernel at least part of these users have to have tested the new kernel. The developers are focused on new versions, we need extern users for the testing. That's not only a problem for Linux; some software producers even pay people to test beta versions.
But there are also still a few technical difficulties. We know of some real bugs for which there are already solutions; but not all developers are already convinced that they are good. In this regard there are a few open questions yet: Often the developers want better solutions that guarantee that a certain problem won't arise any more in the future.
Beyond that, there are also communication problems. The people who fix bugs are normally not the developers themselves, they don't describe the problems like a developer would. That simply takes a lot of time.
c't: You have already talked about the kernel extensions of the Linux distributors. SuSE, e.g., delivers the 2.2 user kernels with the Logical Volume Manager and the ReiserFS. The kernel developers have thoroughly discussed ReiserFS and come to the conclusion that it shouldn't be incorporated into the "official" kernel yet. What do you think about such acts of arbitrariness? You surely had your reasons for the decision against ReiserFS.
Torvalds: Mainly last year, new groups of users joined, and SuSE - without the intention of speaking for SuSE - has worked together a lot with big customers who are interested in LVM. Management of hundreds of disks requires such tools. And also if the system doesn't crash but is only rebooted occasionally, e2fsck runs of several hours are unacceptable, so that ReiserFS is preferred. Such applications have only arisen recently, and it simply needs time to integrate things like that. LVM has been in the 2.3 developer kernel for half a year, but just last week we have worked on it. I wanted to keep ReiserFS out of the kernel in any case before 2.4 because I always thought to stand immediately before the code freeze, so I didn't want to bring entirely new questions in the discussion. SuSE and other have tested ReiserFS in the meantime, so we will probably incorporate it into the version 2.4.1.
What users do is never wrong. I surely can't command the Linux users what they shall do. I have always seen it like that: Whatever people want to do is OK. I can only make decisions on how the architecture should look like which makes that possible, or give hints how you can reach the same goal with another approach. ReiserFS will come, and I can't simply say no to it. For me it's only a question of timing and maybe of a few changes to integrate ReiserFS better into the kernel. XFS is a different matter. It's not got as far as ReiserFS, and I can't say if it will be part of the standard kernel in a year. ext3fs, again, is a different matter. The code is already there, and there are users who already use it. ext3fs could well be integrated in the 2.4 kernel series or at an early point into the 2.5 kernel. I am concerned about flexibility. Open source means that you can do everything with the code.
That doesn't mean that I use ReiserFS or ext3fs myself. I am interested about something else. ReiserFS, XFS and ext3fs obviously will have a lot in common. What does that mean for the virtual file system [the kernel structure that constitutes the interface to the file systems]? Perhaps we will take parts of the code that is common to several of the file systems - even if they do different things, eventually it's all the same - and try to build a common interface. Until the VFS itself can deal with journaling two or three years will probably pass; but then the file systems won't have as much work with it any more. That's the sort of questions that I occupy myself with. c't: What are the most interesting technical developments of Linux at the moment? Torvalds: Most things don't concern the kernel at all. Of course there are fascinating developments, e.g. scalability - that was extremely interesting technically. But the really fascinating things are done by other people. The whole business around DVD was interesting, even if maybe it was also a bit disappointing. And then of course the desktop and things that are actually uncommon for Unix. When I watch TV e.g. I do that with a Linux box that uses its hard disk as a VCR. If you have used such a device once you never want to touch a classic VCR again. I only use such devices for films that are not yet available on DVD.
c't: And in the IT world generally? You work in a high tech company, after all.
Torvalds: All these wireless things. I have a great cell phone e.g., a laptop and a palm. When I am away from home I use my laptop to read email, so I want to use the cell phone as a modem. But that doesn't work; this kind of communication simply doesn't work yet. I think in five years all these devices will be able to communicate with one another. The technical aspect is less interesting than the applications.
c't: When you look back at the long history of Linux development: Were there things that surprised you?
Torvalds: Very few. Of course I would have been very surprised at first if I had known where Linux would go. When I published version 0.01 on the internet I was prepared for comments. Perhaps there were a little bit more reactions that I would have thought, but I don't even think so. After a few months there were 50 instead of the 5 people that I had expected, then a few hundred; there I was a little surprised. But I witnessed the development from 5, 10 to 20, 50 users, there wasn't a point at which I said to myself: "My God, what's happening here?" Then the commercial interest, the media coverage - most people think all that happened in the last two years, but in fact it developed slowly over the last nine years. Companies started to support Linux - sometimes it was surprising to see to which degree, e.g. IBM. Nobody thought that IBM really would go that far. But there either wasn't a point where I would have been really surprised.
c't: Has there been anything that made you angry?
Torvalds: Not a lot. The most uncomfortable surprise probably was this Mindcraft study [a study financed by Microsoft in which Linux had looked very bad compared to Windows NT in April 1999]. I can remember how angry I was then. Not any more, because it turned out well in the end. What is most surprising are perhaps the generally positive reactions to Linux. The developer community was very friendly from the beginning, despite all that discussions about the Linux kernel that can seem violent sometimes.
c't: There are a lot of ugly discussions...
Torvalds: Yes, when it comes to discussions about their technical ideas people become very passionate and unfriendly.
c't: Isn't that typical for the open source community? E.g. this strong aversion against M$...
Torvalds: No, not only for that community. Mac user are very similar there. The internet makes it simple to just say something, and that easily generates flame wars. You don't know the people you are arguing with and so you easily overdo it. That's definitely not only true for Linux - if you look at all the "advocacy groups" out there ... it's amusing. The arguments between Linux and FreeBSD users e.g. are again much more violent because these groups know each other well and know where it hurts. The people just like to argue. It's a social competition, like that you show that you are superior to others. Many of these basic debates have stopped entirely, e.g. the argument of vi vs. emacs.
and now for something completely different
Unlike Windows, most people running linux find it quite stable and usable. Unless you want to do things like USB or firewire (for which there are patches for 2.2, anyways), there's no real NEED to move over. People running windows will often move to the newest beta in hopes that it will actually work. With Linux, there's no such need. You have to really want to test the new system.
I have two systems at home, but one is used by my roommates, and me, on a regular basis (including as a sound source (MP3) for the stereo). (Un)fortunately, we have ADSL, so I also have a Web page on it, and we dual boot over to windows way too often for game playing. As a result, I'm transitioning my second box to serve the web page so that I don't have to worry about it being unavailable. In other words, I have two machines that I just don't want going down for random reasons. If I get a third box (quite likely), I'll dedicate it to testing the new kernel and things like that.
It's not that I don't trust the new kernel to be at least as stable as your average Wintendos box (kof, kof). I don't trust me. This really is just for testng. I don't want to find that I'm spending a week trying to repeat a wierd problem -- with my roommates wanting to listen to their music or people wondering why my web page is down.
`ø,,ø`ø,,ø!
Free Software: Like love, it grows best when given away.
I think that once the word about 2.4 starts buzzing around, there will be a lot more people who want it... I am running a dual-CPU setup, and I have seen a remarkable difference between 2.2 and 2.4.
Things I like about 2.4:
-- much better SMP support (more deserialized)
-- better disk caching (doesn't waste twice the space it needs, integrates the read and write buffers)
-- USB support, built in
-- same with firewire
-- good AGP/DRI support for XFree4.0.1 (more on this in a minute)
-- integrated UDF && DVD support
-- all of these integrated into one
Specifically, I have two celeron 366, and trying to play back DVD video did not work well with kernel 2.2 and XFree3. It would skip on the audio a lot. Now, with kernel 2.4 and XFree4 and Xvideo extensions and DRI and stuff, it works *so* much better. Same with the OpenGL stuff.
To sum it up: 2.4 ROCKS.
-----
Wow, I'm absolutely impressed with your comment. It has been the best thing I have read on /. for a long time.
:) Also, it would need a different focus. I imagine that Linux may split in three directions. Small Medium and Large. Maybe Linux could have clothing labels! Have LinuxS, LinuxM, and LinuxL, and maybe even add LinuxXS and LinuxXL, and then go further LinuxXXS (for molecule programming) and LinuxXXL (for a future OS that runs like Seti).
I was talking to a vendor at my work (I won't say who they are, but you know them). They told me that they want kernel support for 64 processors. The CEO went to Linus himself, and ask him straight on to please let the official kernel have support for this. Linus replied that he wanted no such thing.
I replied to the vendor, that they should go ahead and support it themselves. Yes, I would actually love to see linux fork. And I have a hunch that so would Linus. This would really be a good thing.
I look back at some bad forks, and nothing sticks out more than the many Unix that were about. But the one thing that made it a bad fork, was that it was closed source. Each vendor trying to out due the other, making none of them pleasable. But just think if you have the same thing, but with the exception that you could incorporate code that looks good in one and place it in the other. Or a a enhancement. It may have its troubles, in maintenance, but this could be worked out.
Lets have several companies (HP, SGI, IBM, etc) go out and create a new kernel based off of Linux. But it would still need to be GPL, thus open for all to see and use for your pleasure.
In New York, I watch Linus Torvalds talk about having the same operating system run both your refrigerator and a mainframe. They may both be the same size, and have the same cooling system, but they have too entirely different tasks and that they should only share the same code that makes sense. If you browse the Internet from you fridge as well as from a mainframe, then maybe the TCP/IP stack could be the same. I totally agree with this statement.
I have no problem with the BSD fork, and think that Linux should have a similar fork but all need to have the same license (The BSD license is the only thing I don't agree with, but its better than other choices
I'm one of the biggest Linux advocates at my corporation and I am often asked about forking. My reply has always been (and still is) forking is good, when it is open, and in an open environment, forking only occurs when a need needs to be satisfied.
I'm glad Gtk/Gnome came about. (I know this is not technically a fork, because they never were "one") I never really liked the look and feel of KDE. Altough I just recommended KDE to a coworker because of his background, he seemed more the KDE type. And he is very happy with it. So, I say, "to each their own, live with it!"
Steven Rostedt
Steven Rostedt
-- Nevermind