.comment: The Wit and Wisdom of Linus Torvalds
By: Dennis E. Powell
Wednesday, January 31, 2001 08:10:02 AM EST
URL: http://www.linuxplanet.com/linuxplanet/opinions/2980/1/
Glimpses of a Guy You'd Like to Know
The chances are that you've seen an interview or two, in print or on television, with the fellow who a decade ago had the sheer audacity to sit down and start writing his own version of Unix. If you have, you've probably been impressed with a polite and self-assured young man who was probably giving rote answers to the same questions that are asked in every interview.
Perhaps you've heard the stories, the tales of the early Linux conference in the U.S. where that fellow began his talk, "I am Linus Torvalds and yes, I am your god."
To a distant observer, operating systems are dead things, little magnetic marks on some spinning gadget that somehow do something that lets you do something, or something like that. To typical computer users, operating systems are the malevolent force inside the computer that causes things to go wrong. But in no wise would they seem to be fertile soil whence grow cults of personality.
Yet to people who spend vast time with their machines, those who have become imbued with the zen of it all, operating systems have distinct personalities. No operating system has a more distinct personality than does Linux. That has a great deal to do with the vast number of truly original personalities who built it. They're all over the place. Their mark is made in the comments they place in the code and in the way the code itself works. Their code is an extension of themselves as surely as a painting is an extension of its painter. And of these unique personalities, none is more interesting than the guy who started it all.
The interviews don't really capture him. To do that, you need to watch him at work, which for most of us is limited to reading the kernel development mailing list -- which for most of us would be a heavy burden, in that the kernel list some days spews 200 messages. The vast majority of those messages are understandable only to serious kernel hackers or, at least, those who are heavily into operating system theory (yes, there is such a thing).
If one were to read the kernel list (which I do, and I believe some of it will have soaked in by the turn of the century), one would be amazed by the competence of the huge number of people involved in creating the kernel. But more than that, one would be amazed by Linus himself. The guy is tremendously bright. He also knows an enormous amount. ("You really know your kernel," someone wrote to him not long ago. "That's why I'm paid the big bucks," was his reply.)
Some of his posts are technical delights, prose interspersed with illustrative bits of code, the way a reporter uses quotes. Some of his posts are delights for other reasons, and those are the ones that are the subject of this column.
This week in New York City there is a huge trade show, the sole subject of which is Linux. Stop for a minute and let that sink in: The piece of code that Linus Torvalds set loose in the world a decade ago has grown to such an extent that great corporations are coming to the convention cathedral to pay homage to it. (And like goldfish fighting over a flake of food, they'll all be seeking to pull it in the direction of their choosing, to take it off for their own use. They won't succeed, but the attempt is worth noting, because it shows just how important Linux has become.)
In observance, then, of LinuxWorld Expo, I've gone mining in the recent archives of the kernel list, the work leading up to the release of Linux-2.4.1, and have turned up what I think are some real gems from the keyboard of Linus. Though it's not been possible to divorce them entirely from the discussions of code, my goal has been to get a sense of the fellow himself, what he thinks, how he does things.
A word of warning: Though I'm making every attempt to keep the meaning intact, the quotations are of necessity out of context. They are in nearly every case part of a larger discussion, and are merely places where Linus has emerged briefly from the technical to say something amusing or philosophical, or to address a broader issue that is of interest, or are a place where it seems to me that we're given a glimpse of how the guy works. To the extent that this excerptation is awkward, the fault is mine. Also note that some of Linus's posts have been widely circulated -- his discussion of RedHat's decision to ship gcc-2.9.6, for instance, or his famous announcement of Linux-2.4.0. Because they are already well known, they're not included here.
Linus on operating system design
You have to understand what the primary objective of an OS is: to create a virtual environment that is simple and sane to program against....
Have you learned nothing at all from DOS and Windows?
Have you no taste?
And do you not realize that features never get dropped: they just end up increasing the binary size and icache pressure forever?
-----
I'll talk really slowly.
HFS has resource forks. They are not directories. Linux cannot handle them well.
I'm all for handling HFS resource forks. It's called "interoperability".
It's also realizing that maybe, just maybe, UNIX didn't invent every clever idea out there. Maybe, just maybe, resource forks are actually a good idea. And maybe we shouldn't just say "Oh, UNIX already has directories, we don't need no steenking resource forks."
-----
I actually think that Linux with the stuff that is going on in 3D, desktops, etc., has a chance to become the first real user-friendly UNIX.
-----
Hey, that is an implementation issue, not a design issue, so that's the point where I don't care all that much any more. I'd not be all that likely to use this feature (I still do "zcat < file.tar.gz | tar xvf -" instead of using "tar zxvf file.tar.gz", because I'm an old-fashioned old fogey. I don't need my tar-files auto-mounted for me).
-----
I care about the fact that our internal design has to be robust. It doesn't have to make everybody happy, but it has to be clean both conceptually and from a pure implementation standpoint. I don't want a "hack that works."
-----
This is not negotiable. We used to have a damn mess in 2.2.x with all the capabilities stuff, and 2.4.x finally cleans it up and gets it right across different CPU's, exactly because we have a clean "this CPU can do X" approach without any if's, but's and why's.
The fact that 2.2.x has bad control over capabilities and is messy is NOT an excuse to screw up forever.
----
Bad design. I'm not touching it with a ten-foot pole.
-----
But no, vendors aren't everything. And there are other vendors than just SuSE and RedHat. So take all of the above with a pinch of salt. And remember: these are just the 2.4.x rules - it's a different game when the development kernel opens again, and "vendor wishes" are much less of an issue when that happens. In the meantime, I see the stable kernel mainly as a way to support vendors, and am thus always weighing things from that angle when worrying about 2.4.x features.
-----
Never over-design. Never think "Hmm, maybe somebody would find this useful". Start from what you know people _have_ to have, and try to make that set smaller. When you can make it no smaller, you've reached one point. That's a good point to start from - use that for some real implementation.
Linux on hardware
[On some PCMCIA cardbus implementations] Who makes those pieces of crap? And who buys them? I can understand it in embedded stuff simply because the chips are simpler and smaller, but in a laptop you should definitely try to avoid it.
-----
ANYBODY who does driver development without taking the real world into account is a dangerous person. Stacks of papers, diagrams and rules are absolutely WORTHLESS if you can't just understand the fact that documentation is nothing more than a guideline.
Once you realize that documentation should be laughed at, peed upon, put on fire, and just ridiculed in general, THEN, and only then, have you reached the level where you can safely read it and try to use it to actually implement a driver.
-----
If you have 512MB or RAM, you can probably afford another 40GB or so of harddisk. They are disgustingly cheap these days.
-----
And if anybody else understands pirq routing, speak up. It's a black art.
-----
I'm not worried about a certain class of features. I will predict, for example, that disk subsystems etc will continue to get smarter, to the point where most people will end up just buying a "file server" whenever they buy a disk. THOSE kinds of features are the obvious ones when you have devices that get smarter, and the kinds of features people are willing to pay for.
The things I find really doubtful is that somebody would be so silly as to make the low-level electrical protocol be anything but a simple direct point-to-point link. Shared buses just do not scale, and they also have some major problems with true high-performance GBps bandwidth. . . .
Just wait. My crystal ball is infallible.
-----
Also, can people who have had unhappy relationships with their eepro100 please try to cuddle and make up again?
Linus on other operating systems and programs
Shades of Windows, in my opinion: "yeah, we know it is broken, but we preferred some hard-to-trigger filesystem corruption to breaking a legacy program that couldn't understand the new filesystem features."
-----
Either
(a) Solaris has solved the faster-than-light problem, and Sun engineers should get a Nobel prize in physics or something.
(b) Solaris "scales" by being optimized for 10000 entries, and not speeding up sufficiently for a small number of entries.
You make the call.
-----
If I understood the GNU make syntax correctly (which is possibly not the case - GNU make is possibly the only example of "overkill" to rival GNU emacs), this looks like a reasonable idea.
-----
This is why I'd love to not see silly work-arounds in apache: we obviously can fix the places where our performance sucks, but only if we don't have other band-aids hiding the true issues.
-----
Maybe somebody should tell gcc maintainers about programmers that know more than the compiler again.
-----
The fact I dislike about the HP-UX implementation is that it is so obviously stupid.
And I have to say that I absolutely despise the BSD people. They did sendfile() after both Linux and HP-UX had done it, and they must have known about both implementations. And they chose the HP-UX braindamage, and even brag about the fact that they were stupid and didn't understand TCP_CORK (they don't say so in those exact words, of course - they just show that they were stupid and clueless by the things they brag about).
Oh, well. Not everybody can be as goodlooking as me. It's a curse.
-----
Also note how I said that it is the BSD people I despise. Not the HP-UX implementation. The HP-UX one is not pretty, but it works. But I hold open source people to higher standards. They are supposed to be the people who do programming because it's an art-form, not because it's their job.
-----
Think of all the security scares sendmail has historically had. But it's a pretty secure piece of work now - and people know if backwards and forward. Few people advocate switching from sendmail these days (sure, they do exist, but what I'm saying is that a long track record that includes security issues isn't necessarily bad, if it has gotten fixed).
Linus on project management
I wrote code that works. I didn't test it, but the discussion is closed. It might have syntactic problems, but it does work. Better than any kernel extension ever would. End of story.
-----
I'm inclined to mark loopback DANGEROUS because there apparently still isn't a maintainer for it. And the next person who suggests using it instead of a real filesystem (ramfs, cramfs, JFFS) should be forced to actually make it work right first!
-----
So it may actually be that we can honestly claim that the half-fix is actually a proper fix. I would have to look a lot closer at the issue to be able to guarantee this, though. Comments? Anybody?
-----
We can add a comment to the Makefile. That's trivial.
What's not trivial, and what I WANT DONE is to make sure that when somebody wants to maintain link ordering, he can do so in an easy and obvious way. Not with Yet Another Hack.
-----
Now, the above won't work for drivers/net, but I think it will work for just about anything else. So let's just leave drivers/net alone for now. Simplicity is good.
-----
Anybody want to try out something like the above? (And no, I'm not applying it to my tree yet. It needs about a hundred pairs of eyes to verify that there isn't some subtle "lost wakeup" race somewhere).
-----
Can other people try the test-program and see if we have a pattern (ie "it happens only on Athlons", or "Linus is on drugs and it happens for everybody else").
-----
Did I mention my belief in the true meaning of "intelligence"?
"Intelligence is the ability to avoid doing work, yet get the work done".
Lazy programmers are the best programmers. Think Tom Sawyer painting the fence. That's intelligence.
Requiring almost no effort is a big plus in my book.
It's the "clever" programmer I'm afraid of. The one who isn't afraid of generating complexity, because he has a Plan (capital "P"), and he knows he can work out the details later.
-----
It's entirely untested, but it looks good and compiles. Ship it!
Linus on project discipline
So fix the stupid API.
The above is just idiocy.
-----
The "p_page" should be a "b_page". Duh.
-----
Are you all on drugs?
Get your acts together, guys. Stop blathering and frothing at the mouth. . . .
. . . So I repeat: are there known bugs in this area left in pre5? And with "bugs", I don't mean fever-induced rants like the above (*).
(*) And yes, you can smack me on the head for that outburst if it turns out that I just didn't see anything. I'll apologize. But right now I'm irritated.
-----
Ehh, I think I found it.
Hint: "ptep_mkdirty()".
Oops.
I'll bet you $5 USD (and these days, that's about a gadzillion Euros) that this explains it.
-----
Ok, the guy who made the netfilter Makefile was probably on some really interesting and probably highly illegal drugs when he wrote it.
-----
Help me out, and I won't ever call "netfilter" a heap of stinking dung again. Do we have a deal?
-----
Yeah, yeah, it's 7PM Christmas Eve over there, and you're in the middle of your Christmas dinner. You might feel that it's unreasonable of me to ask you to test out my latest crazy idea.
How selfish of you.
Get back there in front of the computer NOW. Christmas can wait.
Linus "the Grinch" Torvalds
-----
Life does not end at 2.4.0. Think of it more as a "no more excuses" release.
-----
Stop re-designing something just because you want to.
-----
Stop blathering, and answer the question.
The code on both sides of the #ifdef is the same.
WHY IS THE IFDEF THERE?
Don't bleat about standards and ATA-4/5/6. They won't make the code behave any other way.
Why do you have a config option that doesn't do anything, except restate the exact same test in two different ways?
Doing the same test in two different ways and making it look like two different tests is confusing. Your explanation seems to be that "the standards are confusing, the source code had better be confusing too". And quite frankly, that is not a very good reason.
-----
The linux kernel has had an interesting release pattern: usually the .0 release was actually fairly good (there's almost always something stupid, but on the whole not really horrible). And every single time so far, .1 has been worse. It usually takes until something like .5 until it has caught up and surpassed the stability of .0 again.
-----
Maybe somebody else comes up with a better way to do it, or with a really compelling reason to.
"Feel free to try" is definitely the open source motto.
-----
Tabs are 8 characters. They are NOT adjustable. Never have been, never will be. Anybody who thinks tabs are anything but 8 chars apart is just wrong. It's that simple.
And two spaces is not enough. If you write code that needs comments at the end of a line, your code is crap. It's that easy. There is never a reason to comment a single line, and multi-line comments the the right of multi-line code to the left is a recipe for disaster. In short, you don't do comments to the right of code - you do them before code.
-----
When I say multiple mails, I mean multiple mails. NOT "26 attachements in one mail." In fact, not a single attachment at all, please. Send me patches as a regular text body, with the explanation at the top, and the patch just appended.
Why?
Attachements may look simple, but they are not. I end up having to open each and every one of them individually, remembering which one I've checked, save them off individually, remembering what the file name was, and then apply them each individually.
See the picture? Attachements are evil.
Linus on those little tragedies that sometimes arise
Actually, I bet I know what's up.
Want to bet $5 USD that suspend/resume saves the keyboard A20 state, but does NOT save the fast-A20 gate information?
So anything that enables A20 with only the fast A20 gate will find that A20 is disabled again on resume.
Which would make Linux _really_ unhappy, needless to say. Instant death in the form of a triple fault (all of the Linux kernel code is in the 1-2MB area, which would be invisible), resulting in an instant reboot.
-----
I'm a stupid git. I even remember thinking about the syncing issues at some point, and then obviously just forgetting about it completely.
The simple fix is along the lines of adding code to fsync() that walks the inode page list and writes out dirty pages.
The clever and clean fix is to split the inode page list into two lists, one for dirty and one for clean pages, and only walk the dirty list.
Ho ho ho. I so enjoy making a fool out of myself.
-----
And hey, if you think the above is confusing, try making your /dev/null a regular (writable) file by mistake. Now THAT will be confusing as hell: things will actually work surprisingly well, but some things really don't work the way they are intended to. And chasing it down is an exercise in futility. Yes, I've done that at least twice as root by mistake.
-----
De gustibus non disputandum.
-----
And yes, I forgot to update the Makefile release number - sue me, I'm too lazy to upload a new patch with that fixed ;).
-----
Now, I'm not saying your filesystem is toast. I'm just saying that if you booted up in pre6, I'd suggest a quick reboot into a better kernel might be a good idea (be a jock, and do a sync and just push the reset button to force a proper fsck when it comes up - just in case).
Linus on the new kernel
We're still waiting for the Vatican to officially canonize this kernel, but trust me, that's only a matter of time. It's a little known fact, but the Pope likes penguins too.
-----
[Following Alan Cox's expressed desire to make 2.2 faster than 2.4.0:] Ahh.. The challenge is out!
You and me. Mano a mano.
-----
I personally think 2.4.x is going to be as fast or faster at just about anything. We do have some MM issues still to hash out, and tuning to do, but I'm absolutely convinced that 2.4.x is going to be a _lot_ easier to tune than 2.2.x ever was.
Linus on family matters
Due to the birth of my third daughter last week (yes, I got /.'ed), if you sent me patches that aren't in pre2, you can pretty much consider them lost.
-----
Because of the newest (human) addition to the Torvalds family I didn't have any time to debug this until the day before yesterday.
-----
If somebody (you? hint, hint) wants to do this, I'd be very happy -- I can do it myself, but because it's my birthday I'm supposed to drag myself off the computer soon and be social, or Tove will be grumpy.
And you don't want Tove grumpy.
Linus on the big philosophical issues
And in the end, reality always tends to hit theory hard in the face when you least expect it.
-----
Oh, I can agree with that. Discipline can be good for you.
-----
"Give them rope", as Joan of Arc used to say.
-----
I strongly believe that trying to be clever is detrimental to your health.
-----
Give it your worst. After you recover from being hung-over, of course.
Linus on why he'd be one tough editor
I think that throttling writers is fine and good, but as it stands now, the dirty buffer balancing will throttle anybody, not just the writer.