Slashdot Mirror
The story of the Linux kernel
Todd Bradshaw
wrote in with an
excerpt from Linus' chapter in "Open Sources: Voices from the Open Source Revolution".
Linus' number one rule for keeping the kernel healthy is to
avoid new system interfaces.
← Back to Stories (view on slashdot.org)
Linus-worshipping morons may stop at the Slashdot alter and offer a prayer to him.
"Oh Lord Torvalds, highest form of life, please stray us from BillGatusBorgus. You are the greatest thing since sliced bread! Your divine OS is the best thing that ever was and ever will be! Please bring lightning down upon BillGatusBorgus and all of his Macro$haft minions. "
Get a life.
The FlameMaster
Well, I don't care much for emacs myself. I wonder what Linus uses... ed? vi(m)? pico(haha)?
This is already present: the sendfile()
system call. All we have to do now is
to have web servers like apache use this
call.
How about splitting off the drivers??
Possible categories:
Net
FS
Sound
FBCon?
ISDN
...
Surely there could be some benefit from separating them?
Its nice to actually have Linus talk about how the kernel does things and about design issues (even though most of it is still over my head.. and then some). It would be cool if Linus could write a column (monthly/quarterly/whatever) in Linux Gazette or something to talk about technical issues many people never see.
Also liked the last paragraph.. when Linus talks about the future.
Let's see, you have to press *how* many keystrokes just to leave the goddamn editor? Gee, I'd like to bring emacs with me to a client, too bad it'll take up 27 floppies.
...vi.
I think he is right. But you have to be sure to look at it from a kernel developers perspective. Not from a "Linux" users perspective (Linux as in GNU/Linux or a distribution or whatever a system based on the Linux kernel). If you are talking just about the kernel there is no doubt about it that GCC is the most important part of the FSF software that has helped out the Linux kernel. I think this is just saying this has been especialy useful for the kernel and we are greatfull for that.
:-).
He is just giving GCC the credit it deserves.
Gotta love Linux and the FSF
Benefit: About 800% more HD space usage on mirrors.
The BSD license isn't a GPL. If we just took the BSD utilities wouldn't linux be primarily based on
the BSD license? This isn't a good thing.
Oh no! Now the large and well-funded anti-linux organizations know how to destroy the kernel. Pose as real kernel developers and develop lots of new kernel code adding lots of interface crap, then drum up lots of fake grass-roots support for the new code to try to persuade Linus into adopting it. It will bog down the kernel with crappy, bloated interfaces and/or drive Linus mad by the long and difficult process of separating the wheat from the chaff.
I think it's happening already!
First there was joe, then there was emacs, briefly we had jed, but ultimately we'll use VIM!
Hey! After Linux, Emacs is my favourite operating system. (Floppies? Networks!)
It's not a "text editor". emacs is an editor builder and lisp interpreter, and provides a "complete" operating environment.
who disliked the essay? I know Linus isn't a native speaker of english,
but he seemed a bit egotistical. For example, I haven't read any other
computer scientist that calls their peers ideas "stupid" (well at least not
in something as formal as a book). Certainly, the ideas of the
folks behind Plan9/Inferno (some of whom have been involved in operating
systems since Linus was in diapers) must have more merit than to be called
stupid. Perhaps they aren't the best, or most efficient designs, but that
goes without saying when one is developing something from scratch that
tries to push the boundries of current knowledge. Also, of course Emacs is
big and slow. Lisp programmers know the value of everything but the cost of nothing.
Sure, what baggage would that be?
Ignore user space. Concentrate on Linux (as that was the focus of the article). What baggage from UNIX is holding Linux - the kernel - back?
I also got the impression that during his college years he got his heart broken by a microkernel programmer.
"I'm not going to go so far as to accuse micokernel programmers of being child molesters, but you really have to wonder..."
Emacs isn't just a text editor (it's a way of life!, er, sorry 'bout that), it's a complete LISPy development environment. Of course it's bigger than "ed".
And who needs that damn glibc, anyhow?
Could be a power computing G3
Had to use that last quarter. Biggest piece of s*it textbook I ever bought.
I believe Linus uses Micro Emacs. Its not the
philosophy that the problem, just the bloat.
Linux has never, ever crashed on me, or even flaked out ..
and my system has BAD SIMMS that make windows crash approx. every 15-20 mins.
Linux is saving me heaps of money that I just can't afford to spend!
ps.. any idea why it DOES do this?
The os's job is to provide the basic services that a system needs to run. So for a webserver-only machine, the kernel handling simple web requests makes sense.
I think the proper architecture for this sort of this is a module that defines only a simple interface, to register the full server binary. The kernel module would sniff the incoming packets for web requests, check the url, and pass ones it couldn't handle up to the server.
This is something like an extendible network file system.
Lisp programmers know the value of everything and definitely the cost of everything, otherwise their programs would not be usable.
C(++) programmers don't know the cost of everyhing, specially _development_ costs.
If you want to talk about Lisp, really learn how to program in it (not like in those stupid little courses where the teachers know little more than DEFUN, CAR and CDR.
All lispers know C, many actually use it, and some do C++ do (against their will), so when we go C(++) bashing, at least we know what we are talking about.
BTW, I've never programmed in Emacs lisp. That's not a particularly good lisp, but at least it's _much_ better than AutoLisp.
What is needed is consolidation of all those
uCLinux, RTLinux, ELKS, etc. projects into the main Linux code base, so that you don't have to go taking pieces from here and there.
Makes donwloads longer? So what? Buy a CDROM.
[Independently obtainable specific subareas would be good though].
You might check the Linus vs Tanenbaum thread, but then again you already did since you specifically ask for the Minix authors comment :)
Bedev #E-1516 (hope its still valid)
Your logic can be applied the same way on vi.
I don't think Linus flamed Emacs because it was hard to learn but the fact that Emacs is bloated and tries to do too much.
Personally, I use XEmacs but only as an editor. I can do without filehandling, web-browser, news-reading, MULE, Debugger and tons of more things that I have forgotten to mention.
I feel sorry for you and Linus. I hope that, one day, you will see the light! Emacs is truly an amazing and competent editor.
Running Gnus (a mail/news client) in XEmacs is very nice, though.
Maybe, never used it though.
But using XEmacs as a web-browser is a horrible experience. Also the info system truly sucks. I know you can convert into to html and that makes a little better.
/AC two levels above
You don't know many people, do you?
I admit that I know a few hardcore types who has learned vi from above the basics.
I do use vi for editing configuration files, but for real programming Emacs is a must.
GNUS is nice.
I decided to stop using emacs when I realized that GNUS is a MUCH better as newsreader that emacs is as an editor.
yes i know i not logged i have reg'ed yet will soon. just wanted to say you guys scare me. How old are you guys? I mean I'm just a year out of college working on a msce and damn! you guys know everything.
Bah, it's called "optimization". So, the main kernel base has two different schedulers based on what you are using it for. So what? Make it run-time configurable to switch schedulers if you want even. Heck, put in 3, 4, whatever is needed. But, why have a seperate code base? If the scheduler module is modular enough, *plop* drop in a new scheduler and you are good to go.
:) ) Though there may be other technical problems, as Linus himself said, technical problems are usually pretty easily solved.
*shrug* I guess I just don't see the problem here for schedulers (and yes, I've written my share of schedulers, even in the embedded world.
Off topic... but another good "French computer book" is Object Oriented Software Construction by Bertrand Meyer. Great OO primer and a fun read.
Tom - tcopeland@comdt.uscg.mil
>>Hence, my requirements for a working environment are better matched by a shell than by an editor. :)
Ah, but that's the beauty of emacs.. it's both!
Why don't we all just try to compromise and run emacs in vi-mode. :)
By Godwin's law, this thread is now dead.
Penguin's are cute. Buffalo's are ornery.
Torvold's is an endearing symbol. GNU's Stallman is less so.
-ac (but not anamalous and not a cowherd)
If you want a religous war; join the Kosovo Liberation Army.
Nope, you're not the only one.
Just another AC from University of Helsinki
Hmmmm....
:!rm -f -- --badfilename
Works for me....
Practicality seems more important than ego (to Linus), which to me is a very respectable trait.
I agree; moderators are deleting only contraversial stuff; not many of the truly stupid posts. If a moderator is offended; he deletes. I'm just glad Linus is saying something like "emacs sucks". Otherwise it would be supressed.
-ac (but not anamalous and not a cowherd)
P.S. I wish navigator text boxes had "vi" mode.
Yes. He's even said that he'd work there, if they would offer him an interesting enough job. Linus' level-headedness must annoy the religious zealout types to absolutely no end. Go Linus! :)
Wow, you guys are idiots. Linus said that that was one of the best books to learn OS design from, and indeed it was what gave him his start. There's really no other book like it on the market.
Wow, an actual engineer/computer scientist posting to Slashdot, imagine that. Of course you're right. But there's a bunch of buttheads on Slashdot, so don't expect any support. You are quite correct.
How do you know about elisp, or can compare it to AutoLisp, if you've never programmed in it? You sound like a mindless language advocacy type, sorry.
Duh. "Stupid idea" is hardly equivalent to "not the most efficient design". There's no such thing as politese.
Actually, joe does accept the normal cursor keys, etc. It's very easy to configure different key bindings (that's how the mail client works). I've found that v2.8 (1995) works rather naturally.
Besides, ZED's dead.
What exactly do you mean by "first there was joe?"
You're not the only one. I was especially disappointed to see Linus throwing the term
"stupid" around. If someone does something different
than Linux, they're "stupid". If something
wrong is done inside of Linux, it's because
of past stupidity.
I don't know why microkernels are "stupid" or
"dishonest". I think the people researching them
were/are motivatived by the same factor Linus
was... "Hey, it's a cool idea, let's write some
code and learn about it." If Linus doesn't like
them, or if research shows they _aren't_ the
way to go -- fine. But we'll never know until
somebody "stupid" goes and researches them.
With that exception, I did enjoy his writing
style. Simple, to the point, informative: a
lot of native English writers could take some
lessons here.
besides that, it's a buffalo holding his "blankie" while sucking his thumb.
That logo doesn't exactly indicate RMS even _wants_ to act like an adult.
Not a buffalo.
Despite the Linus-worshiping in the other postings, I personally found Linus's attitude to be arrogant and abrasive. His attack on microkernel researchers and, following that, his trivilization of the GNU utilities was plain rhetoric and down-right juvenile. He should show some maturity. He's not in college anymore.
What I found most interesting was Linus' opinion of forking in the Plan9 process model. It seems that Bell Labs has stopped work on Plan9 and I think that's a big shame. I would like to hear more of his opinions on Plan9 in general, because I think Unix (Linux included) DOES carry a lot of baggage that is holding it back.
In particular, I think distributed OS's hold a lot of promise in the new era of "everything's connected". This is an area which I would like to spend a lot of time on....
Ports are hard to count.
Linux people usually count ports by the CPU.
There are at least 8 working Linux ports if
you count that way, perhaps more when you
include experimental ports. This is about the
same as NetBSD has, perhaps a tiny bit more.
(finally NetBSD can do sparc64 like Linux!)
NetBSD people usually count ports by general
hardware similarity. This makes the Atari and
Amiga ports different, even though Linux once
used a single kernel binary to handle both.
Counting this way, Linux crushes NetBSD with
an awesome 29 ports.
We've been over this before, and there is an
old Slashdot post that enumerates all 29 ports.
You might find it by searching for a whole bunch
of different architectures.
That's been discussed to death many times in the past. I believe the concensus was it just isn't worth it: the bulk of the package is in the drivers, not the architectures. Hmmm, someone with access to the sources correct me if I'm wrong, but I think the code for all the archs put together is smaller than the core+net+fs (and I'm not including specific protocols or file systems).
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
With the GUI off, you don't get multitasking (even the usual approximation thereof), networking, protected mode operation or much anything else that DOS didn't offer.
:)
Funny how much stuff MS has built in to their GUI...
Posted by wraith-q:
Torvalds has accomplished much with his skills, he has earned the respect and admiration of the Linux community. So what have you done with your life? Make it count, or shut up.
I'm really sorry to hear Linus say this. First of all, calling Emacs an "editor" is a bit dishonest. Yes, it is an editor, but it is *so* much more. It is a file manager, an IDE, a gaming platform, etc.
I was using Emacs long before I was using Linux, and will continue to use it for many years to come; it is my Swiss Army knife. Just the other day, I had horked myself experimenting with some arguments to tar. I ended up with a huge file with a name that started with "--". How did I delete it? That's right: DirEd! Thank you, Emacs.
As for the size of Emacs, if you really only want an editor, there is micro Emacs.
Personally, I am the worst of pig-editor users: I use XEmacs. And I like it that way.
If you wanna use vi, fine. But know that Emacs is a great, multi-faceted tool, not just an "editor."
Is there any reason why one couldn't choose an appropriate scheduler at config time, based upon the target machine?
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
Oh my god what bullshit.
If there is one thing I learned from that article, it's that Linus is not nearly as humble as I thought he was.
He seems to want to make a point of pissing on everyone else ("microkernels suck and the people who made them are stupid, everything from GNU except GCC is lame, etc") for some reason. What an ego.
I agree wholeheartedly.
I used to think Linus was humble and I respected that. It's a great thing to do something great and still be humble about it.
It's quite the opposite to do a great thing (albeit with the help of thousands of others) and in the end use it as a platform to insult others and minimize their accomplishments.
I have to say, RMS may have some radical ideas, and he may support them pretty strongly, but I can't remember the last time I heard of him calling someone else stupid or minimizing their accomplishments.
Unfortunately I'd have to agree with you. This wasn't an interview, where one can make mistakes in an instant, this is a written work where one should look back and think about the implications of such things. I must admit to being quite disappointed.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Here is a site which aims to list all the supported and experimental ports.
h tml
http://www.ctv.es/USERS/xose/linux/linux_ports.
This list isn't organized per processor architecture though and it doesn't carry information about the current state of the port. For example the Sun3 port just recently got into a state where it can boot to a working system with userspace applications. The problem is that they can't share binaries with the rest of the m68k ports because of the different page size (8kB vs. 4 kB).
I'd say it could be accounted as a benefit for the NetBSD that a some of these m68k platforms (and some others) are better supported under it but on the other hand nowadays the said platforms are exceedingly hard to find anywhere.
Yes, that's certainly true. This kernel archive splitting business has been beaten to death many times. It's even in the FAQ.
:) The kernel source is such an attractive data set don't you think?-) In future I'd like to include more detailed breakdowns of the various parts and maybe do some analysis and predictions of the future growth.
m l
Btw. here's a link which illustrates the growth of the kernel archive. (thought I had to advertise this somewhere since I bothered to do it
http://www.helsinki.fi/~amlaukka/kernel-size.ht
Don't mind the script. It's a result of couple hours worth of spontaneous hacking. It's interesting to see that since the late 1995 the growth has been pretty linear and amounts to about 200 kBs worth of bzip packed kernel source per month.
For consumer versions of Windows, this makes sense. For something intended as a server platform, this is a bad decision, in my view.
Servers don't normally need good GUI performance; they're not trying to do complex rendering or animation, and most of the time nobody's anywhere near their consoles. What's important is that they're robust and reliable, have the necessary administrative capability, and have good I/O and sometimes computational performance. If the GUI preempts disk or network activities to update some flashy widget, the server's ability to do its job is compromised. If a bug in the display driver (and display drivers tend to be complex) locks up or crashes the system, likewise. If some alert box pops up and the system can't do anything until someone manually dismisses it, it's also not very good.
This suggests that NT Workstation (where graphics performance actually may be important for some applications) and NT Server should have different design goals, but that doesn't seem to be the case.
I haven't heard RMS speak on the topic, but if he's disappointed, it's more likely (IMHO) to be because Linus credits gcc more than the GPL. I certainly don't think that RMS expects everyone to like emacs -- it's just an application, after all -- and certainly the utilities could have been written by someone else, but the free, well-ported compiler is the linchpin of the whole enterprise.
And note that Linus said "...are for Linux insignificant IN COMPARISON." That's a long way from saying that they're truly insignificant.
As it stands now, the user space code can come awfully close to it:
fd = open(translated_URI, O_RDONLY);
addr = mmap(fd, random_mmap_args);
write(socket, addr, whatever);
Obviously, there's all sorts of stuff involving retries, tail ends, and so forth that I've left out, but the upshot is that most of the data never actually makes it into user space. mmap simply does the mapping; the data doesn't fault in until someone actually requests it, and if the user program never touches it, it doesn't get copied into user space.
However, there are things that could be done at the kernel level to strip away even this kind of overhead. The fd>fd copy (with retries done at the kernel level, rather than the user level) is one possibility. Another possibility is a system call to actually copy a file to a file descriptor, thus avoiding the user-space open(). This seems a bit of a stretch.
However, there's another approach that might yield a big payoff, which is actually to embed some knowledge of the http protocol in a kernel module. This isn't as far-fetched as it sounds; NFS servers have been doing this for well over a decade, explicitly for performance reasons. While http is a stream-oriented protocol, it's actually quite a simple protocol indeed, and completely stateless. Even the keepalive option introduces no state beyond a persistent socket; each http transaction is logically independent of anything else.
So the basic idea here is that the user-space http daemon registers mappings between URI's and filesystem locations, and the kernel-space http daemon intercepts these requests and processes them without involving the user-space daemon at all.
This is very schematic, and doesn't address issues such as cookies, filesystem permissions, and such. But it's certainly a possible architecture for this kind of beast.
Well, I'd argue glibc is pretty key too.
sigs are a waste of space
Actually, the irony of that is that it's actually a result of a key restriction in the BSD license which does not exist in the GPL. With the BSD license you are required to credit the "Regents of University of California" during startup of any derivative work you make. The GPL has no such restriction (hence a lot of GNU software goes uncredited).
sigs are a waste of space
I think the thing that shone through in this article is that Linus is one of the world's great diplomats. Although he'd probably deny it, saying he's just pragmatic, I think it's true. He's just modest, a trait that goes hand in hand with being diplomatic.
:)
Take, for example, the way he manages to mention Windows NT several times in a less than complimentary way, without ever sounding like he was being condescending, or "Microsoft bashing".
Or the way he manages to bring home his point against microkernel architecture. He made points that coming from most people would have been flamebait, but from him seem little more than quiet assertions of the truth, due to his modest and humble manner. Then again, Linux is probably proof that this assertions are in fact truth.
I'm not saying that the article was brilliant, in fact I thought it served to highlight the difference between a great author and a great computer scientist. That is, the article, while doubtlessly interesting and informative, lacked an artist's touch (much like certain operating systems in fact). However, it did yet again highlight what makes Linus such a good kernel maintainer - his people skills are first class. It's something that unfortunately can't be said for enough CS people, which is probably why Linus stands out so much.
I think this is the reason why many people, myself included, have the greatest amount of respect for people like Linus. For in being a pragmatist, while the world hasn't benefitted (or suffered!) from any great ideas of his own, his contribution in helping people come from often vastly different views to meet in the middle ground has more than made up for that.
So while I respect RMS as the rightful "Saint of free software", as I respect various other "celebrities" of the free software/open source world, I think that what Linus has done is far greater. That is, in the way he has managed to bring people together (not just with code, but also with his words) rather than tear them apart over a relentless pursuit of an ideal, as some have done. Perhaps he realises, in his more balanced world view, that the end does not justify the means, nor, just as importantly, does the means justify the end.
It's probably no coincidence that Linus is generally reluctant to offer his opinion on things, and when he does he tends to be brief and to the point. Perhaps that's a hint that I've said enough!
"Now watch what you say or they'll be calling you a radical, liberal, fanatical, criminal." - Supertramp, The Logical So
Editors are a religous thing. But if you want to learn to use emacs. Try the O'Reilly book. It is very good.
I personaly love emacs, but will admit it is very hard to learn to use.
Erlang Developer and podcaster
2 keystrokes. One finger holds down control while two others hits x then c (and these keys are right next to eachother on a QWERTY keyboard).
I thought Linux used pico.
Credit where credit is due.
--
Linus has said on many occasions that his has no problems with Microsoft as a company.
He objects to the quality of MS operating systems, but that's it. He's even complimented MS application software.
--
My problem with emacs is that I've tried to learn it three times (using the built in tutorial), and each time I've given up, frustrated, and gone back to vi/elvis/vim/vile
I don't *think* I'm stupid, but emacs makes me feel inadequate... while vi makes me feel powerful...
--
Not really, since I never had any trouble learning vi.
Of course I know this is purely personal, and I know that many people *do* have trouble learning vi. I just found it very logical and consistent straight away.
--
It's obvious this guy has resigned himself to accepting blue-screens, and the inevitable three-fingered-salute which must follow, as the accepted norm in fixing a problem!
He might not actually know there are OTHER operating systems out there (FreeBSD, Linux, Solaris, Tru64 Unix or whatever Compaq are calling it this week, etc.), that have a decent command-line interface and can actually handle long file names!
NT isn't even a true multi-user operating system!
Linus can always say: "Hey, that interface is crap and it's not going into the kernel. You can put it in user space".
So Linus may speak!
I think you're overlooking that fact that NT is a piece of bloated crap based on a flawed operating system design!
Microsoft deserve nothing less than what Linus said. Designing an operating system that can only handle 8.3 file names is, indeed, STUPID!
That's about as dumb as the drive-lettering scheme in Microsoft's "operating systems". Just put another hard drive into your NT box and watch all your drives swap letters, and then watch all your programs fail because they can't find C:\whatever...
Challenge to Microsoft: write an operating system that is *HALF* as good as Linux/Unix/BSD!
On the other hand let's look at vi(*)
:)
Lessee
[esc]:wq![enter]
I count six
Don't get me wrong, I *like* modal editors (anyone familiar with isredit on VM/MVS/OS-390?), it's just that I don't think "keystrokes to leave the editor" is a good argument for the virtues of one editor over the other.
Ahh - My eye!
The doctor said I'm not supposed to get Slashdot in it!
I don't know for certain, but I suspect that emacs is fine for people who spend most of their computing time editing/compiling/debugging.
:)
That's OK, but I don't. I spend most of my system time looking at logfiles and process displays, searching text files, checking disk space, and editing config files. Hence, my requirements for a working environment are better matched by a shell than by an editor.
Horses for courses folx
Hi-ho silver!
Ahh - My eye!
The doctor said I'm not supposed to get Slashdot in it!
Ah yes. Vi, the lowest common denominator of all Unices.
/etc/fstab on a system that could not determine the terminal type of it's own console.
Were it not for my knowledge of vi, I would not have been able to talk (over the phone) a newbie through editing
"Alright, now type 'jjwwwcwc0t0d4' etc."
Ahh - My eye!
The doctor said I'm not supposed to get Slashdot in it!
Does he mean something like a system call that could directly copy from file descriptor to file descriptor?
Isn't that what sendfile does?
I think your comparison of Glide vs. DirectX (or Direct3D) is a little unfair. Think about the ioctl's. In comparison to them, glide and DirectX both appear "thick", since they are higher level APIs that talk to the hardware driver itself. I think that's what is really important in defining something as "thick" as opposed to "thin" - where the interface is implemented, rather than what it represents. DirectX may abstract the hardward while Glide better represents the hardware architecture, but they are both higher level, programmer-oriented interfaces. You'd never see the Glide interface implemented in the kernel as sys-calls, which is the point Linus is trying to make.
Great article. =)
Operating Systems--Design and Implementation by Andrew S. Tanenbaum
Hardly used. Read only once, in fact. The are no markings in the book. Unlike most text books, you wont find highlighted sections with annotations marking all of the useful and helpful areas of the book.
[esc]ZZ
depending on whether you are editing text or not, it is either 2 or 3 keystrokes.....
Life is complete only for brief intervals in between toys or projects -- John Dalton
Linux, OTOH, is so efficient that it keeps the CPU running all the time causing it to overhead. Either that or it spends all its time in interrupt handling routines.
Maybe I'm just making this all up :P
self: *THWACK*
Life is complete only for brief intervals in between toys or projects -- John Dalton
When the video-driver-in-the-kernal thing gets dredged up, I always wonder if it really matters.
Servers generally run really generic SVGA or S3 drivers, which don't crash on NT 4, and from a normal user perspective, if your video driver crashes, you pretty much hosed anyway. (Unless the normal users you know like a command prompt.)
If it's a server, why not just not bother? That is the whole point, with NT, you have no choice.
Linux doesn't have video drivers in the kernal pretty much only because Unix has never done it that way and Linus doesn't want it. But video on Unix has always been an afterthought, whereas on a client OS like Windows, it's practically the most important thing.
Not strictly true. SGI for example, put minimal drivers in the kernel. Even newer versions of Linux do. It is not a good idea to give user space processes direct hardware access. The hardware drivers should therefore be in the kernel.
I think Linux will allways run quite well on machines in the $1000 to $3000 proce range. When such machines have 64 CPUs (or 64 hardware level threads, maybe not as many physical CPUs) then the base Linux will run quite well on it. After all that's what most Linux developers have, so thats what will get the most work. It will allways run somewhat less well (but still decently) on the cheaper and more expensave machines. At least if the future follows past trends.
However I don't see any signs pointing to cheep large scale multiprocessing. The prices on 2 CPU machiens have dropped dramatically over the last few years, but the price of 16CPU systems has been fairly stable compaired to single CPU systems. The Mediaprocesser (the only cheep general purpose multithread CPU that was aiming to go comercial) has sunk without a trace. The only two comercial multithreaded CPUs I know of are the Terra which is only being sold in really large machines (think bomb testing, and weather simulations, not kick ass raytracer), and um, that thing I just read about in EDN which is targeting 8bit and 16bit systems.
I would love a 64way machine. I do raytracings (when I'm not coding, sleeping, or watching TV, actually I frequently raytrace while sleeping, watching TV...), so lots of compute will do me good, even if I only have a one giant lock kernel.
I have to say you're probably right. I'm as much of an emacs-phile as anyone: I compile, edit, debug, read email, news, etc, in emacs, write emacs packages, etc. But when I have to look at logfiles and checking disk space, I normally use the shell. Well, if it's one-off stuff... for big disk cleaning, I do use dired with some scripts I wrote to find usage hotspots.
Note that this is dependant on having a decent shell, namely bash. If I have to use anything else, I tend to do things more from Emacs, because it can compensate for faults in other shells, like not having both ! and C-r histories.
I thought it was interesting how he made some design decisions that were intended to make it easier for him to work with the other developers out there and it also ended up being a good decision on technical merits.
I wonder if the free software community's dynamics help create better design decisions as opposed to a corporate environment. I'm not talking about the often-cited advantages like having lots of people pounding on the code and such; I'm talking about the need to have many developers working in parallel affects technical decisions in a way that are benificial.
It is an interesting thought to ponder, and one I'm not qualified to answer from lack of experience.
Your password has expired, please login to change it.
Smart people can have stupid ideas. It is more politic to say "they aren't the best, or most efficient designs", but that's just politese for "they are stupid ideas."
I beleive so, or something like it. I'm thinking that simple requests could be recognised as normal file requeses and just handed off to the filesystem, with the web server `root' somehow configured
(/proc/.../web_root or somesuch, probably).
But wouldn't the web server still have to process the URI... open() the requested page and then make the fd to fd copy system call?
I guess this is what I was confused about. To have the kernel be able to handle HTTP requests would seem to go against linus's philosophy... I suppose you could have a web server kernel module, though, but that just seems like something that should be running in user space.
--Rob
Yup:
# du -sk linux-2.2.1/*
20 linux-2.2.1/COPYING
54 linux-2.2.1/CREDITS
2401 linux-2.2.1/Documentation
19 linux-2.2.1/MAINTAINERS
14 linux-2.2.1/Makefile
15 linux-2.2.1/README
3 linux-2.2.1/REPORTING-BUGS
8 linux-2.2.1/Rules.make
8655 linux-2.2.1/arch
27993 linux-2.2.1/drivers
3945 linux-2.2.1/fs
6298 linux-2.2.1/include
36 linux-2.2.1/init
63 linux-2.2.1/ipc
253 linux-2.2.1/kernel
55 linux-2.2.1/lib
258 linux-2.2.1/mm
3959 linux-2.2.1/net
355 linux-2.2.1/scripts
--Rob
I have to say, that was a very well written article. I enjoyed reading it.
I was interested in what Linus had to say about web serving, but I am a little curious what he means about the kernel handling requests for static pages. Does he mean something like a system call that could directly copy from file descriptor to file descriptor?
--Rob
I will read Linus again and again.
English is not even our favorite Finn's first language, but his article was a joy to read, and just the right length too.
Other comments in response to the Gates book were about how BORING Gates is. Linus isn't boring at all.
If tits were wings it'd be flying around.
Something that always amazes me about these self congratulatory love fests is how little Linus, Eric Raymoyd, etc, etc, give any credit at all to the people who blazed the trails for them. I haven't read the book yet, but it seems devoid of any interviews of people like Ken Thompson, Dennis Ritchie, Brian Kernighan, Alfred Aho and many others.
Sorry, boys and girls, but without those guys there would likely be NO 'Open Source Movement'. They were the first to do readily available, accesible research on practical, NON PROPRIETARY, non big iron requiring O/S's, languages and scripting tools, and for the sheer pleasure of it at that. Linux is a direct descendent of their work, and with a healthy supply of Unix-alike tools and utilities (without which Linux would just be a curiosity).
Cmon, Open Source 'leaders'... does it really hurt that bad to give a little credit to the guys that got you here?
Can you recognize sarcasm? Apparently not.*
*******************************************
Superstition is a word the ignorant use to describe their ignorance. -Sifu
if it's more than a line long, you probably aint doin' it right.
paulzilla
Hmm. In one of those weekend magazine liftouts
(no URL, I'm afraid, though it might've been a mirrored, ahh, syndicated article online elsewhere.) in the Sydney Morning Herald, they had an article on Linux. Obviously, they bunged up Linus' goofy face on the first page, but they also had a smaller picture of RMS (replete with borrowed laptop with "GNU/Linux inside")
Anyway, the point is, Linus in the article was very forthright about his and Stallman's relative
contributions to the system, giving RMS plenty of credit. I can understand why RMS is pissed tho', since he's an idealist, and idealists tend not to appreciate having their ideals diluted.
As for the further development of Linux, if you don't like what Linus is doing, fork the bitch!
:) If it means that the kernel for embedded systems has to take a different course to large scale systems, so be it. I think the "movement"
is big enough and ugly enough to handle it.
... so sprach Graham the Happy Scum
I don't see any irony in the fact that a non-commercial OS gets ported to obscure platforms (cough, Amiga, cough), where a commercial OS that has a revenue stream does not.
Microsoft had a MIPS and PowerPC port. Haven't seen many Non-SGI MIPS or Non-Mac/Non-AIX PowerPC boxes lately have you? They only could push their thumb in Intel's eye for so long before they did the logical thing.
--
Business. Numbers. Money. People. Computer World.
So, when GNU formed in the early eighties, it was in order to fight Microsoft?
--
Business. Numbers. Money. People. Computer World.
Well, I think Linus has the valid concern of keeping Linux the same on all architectures.
If you started to see home made platform-specific kernals, I can imagine the situation where that might become standard enough that people would submit patches just for the platform-specific kernal, and not the Linus kernal. This effectively forks the code, especially if RedHat or someone picks up on the patches.
--
Business. Numbers. Money. People. Computer World.
When the video-driver-in-the-kernal thing gets dredged up, I always wonder if it really matters.
Servers generally run really generic SVGA or S3 drivers, which don't crash on NT 4, and from a normal user perspective, if your video driver crashes, you pretty much hosed anyway. (Unless the normal users you know like a command prompt.)
Linux doesn't have video drivers in the kernal pretty much only because Unix has never done it that way and Linus doesn't want it. But video on Unix has always been an afterthought, whereas on a client OS like Windows, it's practically the most important thing.
The thing Linux has, that Windows doesn't is compartmentalization. Sure you can run Linux on your 4 meg 386, just disable everything you don't need including X. Microsoft always designs their product around absurdly low standards for marketing reasons (486SX/25 with 16 MB is minimum spec for Windows NT), yet has to make everything kinda-sorta-run. That's why you don't see things like network-transparency with the Windows GUI - it would price them out of the unrealistically low-end market.
--
Business. Numbers. Money. People. Computer World.
That wouldn't be a "Macintosh G3" would it?
--
Business. Numbers. Money. People. Computer World.
Yeah but turning off the GUI in Windows doesn't give you Windows-with-no-GUI -- It gives you good ol' 640K MS-DOS!
(Someone did hack a 32-bit no-GUI DOS using Win95 VxDs - it had networking and file system caching, but nothing really ran on it.)
--
Business. Numbers. Money. People. Computer World.
Correct. NT WS and NT Server are exactly the same operating system - except for the price, and the fact that WS doesn't include server services.
--
Business. Numbers. Money. People. Computer World.
Good Point
- I think the video-in-the-kernal thing was one of the things that had WinFrame on NT 3.51 only for a long time.
--
Business. Numbers. Money. People. Computer World.
"Linus Torvalds explains what makes the Linux kernel great."
I'd rather have someone else do it, personally, someone a little less partial - seems to me that Linus would be a little biased. Why not ask the author of Minix to explain it? >;) Microkernels - just a way to get more research dollars. Of no use in the real world.
-lx
Oooh! Harsh! I love it. :)
-lx
i think the implication was that Linus didn't read it well enough. At least, I hope it was. :)
-lx
It seems to me that quite a lot of my distribution owes its ancestry to BSD or others (Messages about "Regents of the University of California ..>" or "Copyright Caldera...." during bootup from a whole slew of drivers/modules).
...
These may be on the GPL, but the're NOT developed by the FSF.
Just my £0.0125
*--BigMan--- Time flies like an arrow.. but personally I prefer a nice glass of wine!
This is a really big deal when you're maintaining, say, 300 servers that are 21 floors and two elevators away from you. It's an even bigger deal when you need to deal with a server from home.
Of course, most PC hardware limits your capability in this area regardless of the OS you run. I've run lots of NetBSD/i386 systems with serial consoles, but that still doesn't give me access to the BIOS setup. With a Sun server, on the other hand, using a terminal server to talk to the serial port is just as good (better, in fact), than having a graphics console on the machine and being there.
cjs
The world's most portable OS: http://www.netbsd.org.
Linus's bald claim that Linux is the most ported operating system that runs on the PC really burns me, because I don't think that anyone who actually examined the issue would disagree that NetBSD has a strong claim to this. (I believe it's stronger than Linux, myself, but that's just my opinion.) I expect that this will be perceived by the free software community outside of Linux as yet another typical example of Linux hogging the spotlight, rather than sharing the fame. There are not an insignificant number of people out there who see little difference between Linux movement and Microsoft; in both cases the promoters tend to gloss over flaws and ignore other technology, instead giving the impression that they are the one and only option.
The link given above, http://www.ctv.es/USE RS/xose/linux/linux_ports.html, is a little optimistic in what it considers a `port'; The VAX port isn't anywhere near bringing you to a single-user shell prompt yet, for example. (This is typical of most `Linux ports' pages I've seen; they don't indicate which ones are real and which are currently vapour to some degree or other. Again, more Microsoft-style marketing.)
If you're going to discuss this issue, it helps to make clear exactly how you're approaching it, as I've done a href="http://www.cynic.net/~cjs/computer/os-ports. html">here. (Note that this page is getting old and needs an update; I'll get to it as time permits.) Some of the questions you have to deal with are:
I have another comment on Linus's article, but I'll put it in another post.
cjs
The world's most portable OS: http://www.netbsd.org.
Most of his comments on portability are quite ignorant. The Linux kernel is *not* very portable internally in many ways. Compare the device driver model Linux uses to NetBSD's bus_space and bus_dma structure for a look at the difference between portable and non-portable. (And if you're going to argue this point, please actually *read* the source code first, before spouting off. Though I'm a NetBSD developer, I read a fair amount of Linux kernel code before coming to this conclusion, so I'm not talking through my hat.)
cjs
The world's most portable OS: http://www.netbsd.org.
I'm not at all impressed with this article, and I must say it's reduced my opinion of Linus considerably. I've mentioned a few of the things that have bugged me in other posts, but I'll summarise here.
1. The claim that Linux is `the most widely ported operating system available for PCs' is certainly arguable. It's unfair to ignore the lesser known systems (such as NetBSD) in an article with such wide distribution.
2. He's insulting. There's no reason for calling the people he's discussing `dishonest' or `stupid.' That's immature.
3. He's not correct that the OS research world had abandoned monolithic kernels for microkernels or felt that only microkernels offered good prospects of portability. Around the time Linus started his first i386 work, Berkely and other folks were busy making 4BSD (which is monolithic) more portable, and moving it on to several other architectures. The period between 4.3BSD and 4.4BSD showed a dramatic portability and ports increase.
4. Linux is far behind the curve in terms of internal structure for portablity; NetBSD is unarguably significantly better in that regard. Take a look at device drivers, for example; Linux has a proliferation of machine-dependent drivers where NetBSD uses machine-independent drivers almost everywhere. Linux doesn't even have a structure to support MI device drivers! (See NetBSD's bus_space and bus_dma work for an example of what such a structure can look like.)
In short: he insults others, denegrates the work of others that Linux was built on, and he frequently ignores the work of others. Either he's lacking in technical knowledge, or he's willfully ignoring other stuff out there that `competes' with Linux. This article is marketing, not information, and is only going to worsen the reputation Linux already has as a `Microsoft' among the non-Linux free software community.
cjs
The world's most portable OS: http://www.netbsd.org.
In the article, Linus mentioned that, after the Alpha port, it became clear that he did not want to manage more than one source tree. So, all the architectures have been merged into one tree.
.bz2's for each architecture, the world would be grateful. However, I think Linus should just continue to do what is easiest in that regard, which is to keep all the files together, to keep them most manageable.
If someone with FTP space and bandwidth wants to take the kernel releases, and make up different
Such vehemence against GNU... I bet Linus Torvalds is the only guy who could get away with saying such things about GNU, without being ripped on by 250 posts or so.
He'd probably also get a -2 or so moderation if he posted that here...
I can see having 64 processor server machines in the future, but I think they'll be far from common. I think that the current trend towards one high speed processor will continue in desktop machines and low-end server machines into the future, mainly for cost reasons. Even on high-end server boxen, a 64 processor machine would be reaching, or above, the complexity/speed vs. price threshold.
The whole point of a server is stability and reliability. You want to setup a server to perform certain services (file service, print service, mail service -- or daemon depending on what world you come from) and that it would just do it's job with very little intervention from the
administrator. Ideally, all the administrator should be doing is to continually customize the services the server is performing to meet the
needs of those receiving service. However, things not being ideal, an administrator has to worry about hardware failure and hence must add
tape backup, RAID, etc. to his server for fault tolerance, insurance against data loss, and to minimize down time. Now concerning the issue
of whether or not to put certain drivers in the kernel, you must look at your application. In a server environment, you want to maximize
stability and reliability. Therefore, the ideal situation is to minimize the number of factors that can directly affect stability. Device drivers are included in that category. With the creation of new hardware comes new drivers. The question is, is the driver updated enough to run the risk of failure? Patches and fixes are great, but you still have the possibility of failure present if such patches and fixes
are needed. The question when looking into the operating system's design, and determining what drivers to include, do the drivers present
a danger? Are they patched frequently? Are they stable? But those are all relative to what we know about the driver and it's history? What
about rare and unknown bugs? Bugs that show up under unusual circumstances. Ever had a machine crash once out of the blue without knowing why? I have. Only God knows why in such situations. Maybe it never happens again. But it still happens. So what does one do? Do we accept that it will happen infrequent enough that we won't have to deal with it again? If you want stability, that is not acceptable. You cannot
just leave such unknowns unanswered. NT and Linux both have such vulnerabilities since they both can have drivers present in the kernel.
Getting back to the server, what do we do? Well, a design which I have been very impressed with in terms of an operating system is QNX. I do not know how many of you are familiar with it. It has a small message
passing kernel and runs everything else as protected and separate entities. I found their microkernel model to be very impressive. I
downloaded their demo and was very impressed with it also. For a server environment, it is a much better design than Linux or NT. I hope that
someday Linux and NT will follow it's example. Perhaps two versions of each operating system. One version with a QNX-like model for servers,
and one for high-performance workstations that don't need that kind of reliability. Another thing of noteworthiness that I wanted to look at
deals with a difference between linux and NT. GUI interfaces are nice and pretty and are sometimes easier to use than a console. But if you think about it, on NT, the GUI is always running wasting precious memory and cpu time. I mean, how often does an administrator tinker with his server. Not often unless he is experiencing a high demand for changes from his users. Linux allows you to run the GUI if you want to, when
you want to, and shut it down when you are done. In my opinion, that makes it a better design. I hope that microsoft will go back to the Win
3.xx/DOS model that is similiar to the X-Windows/Linux Model. It would certainly improve their server product. One of the engineers that
designed VAX VMS worked on NT as you probably know. I believe at the heart of it, the microkernel is pretty good. It is all those nasty
libraries on top, the integrated GUI, and the registry (yuck!!!had to mention that) that mess everything up. Hopefully my logic on this stuff is sound, but if someone finds fault, please reply and set it all straight. The point of discussions like this is not about who wins the argument, but that we find the best answer. One additional note about QNX, it is designed for embedded systems and the currently do not seem interested in the server market. However, I have heard rumors about Cyrix and QNX getting together to build ultra-cheap boxes for web-browsing or something. If you access their search engine, it provides detailed explanations about the QNX microkernel. I hope you all will read up on QNX. Linux and NT could definitely learn some things from it.
Does this sound diplomatic to you?
Not only is this not diplomatic, it isn't even entirely rational. Once upon a time, emacs was an unusually large program, now it's only about average. And emacs has plenty of excuses to be larger than a simple text editor, because it does a lot more... sure, there are other ways of doing most of those things, but so what? You might as well complain about Perl being larger than it needs to be because you use Python.This makes me wonder if some of the anti-RMS sentiment that you see is really the result of a deeper ideological split than open vs free software: it all goes back to the vi/emacs wars.
After LinuxWorld, I was actually a lot less impressed with Linus than I had been previously. It seemed to me like he'd gotten his fingers burned in the past by shooting his mouth off, and had concluded that he should never say anything. Look at his old style back in 1992, during the famous "Linux is Obsolete" argument with Tanenbaum: Linux is Obsolete (This is also reprinted in the back of the "Open Sources" book).
If you want to see a real diplomat in action some time, check out Brian Behlendorf.
This also enables you to resume a command line session by typing Mode co80 at the "you may shut your computer off now" screen. Also, add the line Logo=0 to msdos.sys to get rid of that stupid splash screen. BTW, this all works in w95, I've not tried it on 98.
multitasking, no. Old games, yes. Ability to actually _do_ something when windoze corrupts the registry (again), yes. I just wish NT had a similar front door. :) Hey in a year or two I won't need to use windows at all, only doors.
send all spam to theotherwhitemeat@ropine.com
Here Here..
I have been using emacs for 5 years now and although it may be a bit large if you just use it for an editor, but many don't as explained before.
In fact I was on contract this summer and was asked to choose the IDE (Java was the implementation language) of my choice. The company had set aside 1G. After some heated discussions i broke down and agreed i would spend one week trying different IDE's on the market. I tried JBuilder, VisualAge, Cafe, and basically they all stunk.
I choose emacs with JDE cause it was by far the most powerful. While it is not for everyone (including Linus apparently) I consider it one of the most usefull programming tools i have, and to me Linux without emacs is only half as useful.
-7021
Just because those things aren't in the Kernel doesn't mean we can't use them. It's probably best that they stay out of there, anyway. If the GUI were in the kernel (*cough*Windows*cough*), there would be lots more problems with debugging and with possibly switching if Berlin ever turns out. Wrappers for the low-level interfaces keep things clean.
I know RMS has isssues with Linux (or GNU/Linux, take your pick) in general (some of which I have to agree with), and in this article Linus seems to ignore the importance of all the utilities GNU provided, but the kicker is Linus's quote "I think that all the other projects from the GNU group are for Linux insignificant in comparison. GCC is the only one that I really care about. A number of them I hate with a passion; the Emacs editor is horrible, for example." OUCH!
Kernel modules are a new idea to me, and I was glad to read what he said. // I used to be an editor some time ago (Electronic Design). /editing, either.)
The content and style are great; I do agree that
calling other ways "stupid" and such is a bit strong, but it *is* concise, and he doesn't seem to be personal when he says it, just to the point.
HOWever... If this is the actual text that appears in the book, shame on them! It's not the best copy editing. Linus does fine with English (try some Finnish, if you doubt me), but a courteous square-bracketed word or two would help in a few spots.
Also: There are some typos and/or detailed editing errors that shouldn't get into an O'Reilly book. I expect better of them. (If this is still a draft, fine).
(Fwiw, this msg. is no great piece of writing
Legacy hardware/software addict. Midnight hacker, 1960. Codepage 819 in DOS: Total Latin-1 compatibility (no boxes/lines
Would it be a good idea to split the different architectures that the Linux kernel supports into different packages? It would certainly reduce the size of the download for most people...
I became a Linux convert the day that NT crashed five times on me.
"I disapprove of what you say, but I will defend to the death your right to say it."
- Evelyn Beatrice Hall
I learned vi at age 8 on a Tandy Model 16 running MS-Xenix, this was roughly 15 years ago. I still use it today, people look at me funny but vi is the BEST example of efficiency and elegance when it comes to editors. Oh BTW this reminds me of a really lame college computer class I took in high school where the instructor actually marked me incorrect for using the term text editor instead of word processor!? WTF Anyway... just my little vi ancedote
Arrogance is Confidence which lacks integrity. -- me
Though throwing money at one is equally pointless.
Tannenbaum started the microkernel thing. You can read it at a link above (or below depending on your preferences). ast said Linus deserved an "F" for writing a mono-kernel in the 90's, he also started the usenet thread bashing Linux.
In a reply though, Linus said he probably wuold get an "F", because he got into a verbal argument with his OS teacher over something completely unrelated. I guess Linus' diplomatic skills are about average.
Diplomats don't call things stupid or horrible or say that they hate them. Linus does that throughout the article. Not that he's wrong :)
My diplomatic replacment for "stupid" etc. is "non-optimal". Unfortunately, my co-workers seem to have caught on. Bunch of cow-orkers...
Mike
--
Mike
--
"Wi nøt trei a høliday in Sweden this yër?"
I have to agree with you. It seems that the guy was already pissed about Linus a while ago, and now, he replys by saying something like this.
I also think that Linux being free software, it should have a certain aliance with gnu (even if we don't always call it gnu/linux), because, after all, it's just the same comminity. The anti-microsoft community...
Papi
- Chernobyl used windows
I think everybody should hate a text editor that takes 124M tar.gzipped.
Ok, it has niffty features like reading mail, but, if I want to read my mail, I use pine.
Vi is the wave of the future (actually, it was, in the early days of UNIX, but anyway...)...
Papi
- Chernobyl used windows
Hmmm,
I think you need some time away from your computer or something. He is everything you said (to a lesser extend), but, you looked like you were asking him out or something....
Papi
- Chernobyl used windows
If you check out the source code, it is briently designed as it is. Go take a peek at lxr.linux.no (linux source crossed referenced) you will realize that the tree is fine as it is.
/usr/src then just type:
Also, to save yourself some bandwidth, use kernel patches, they are easily installed, and fit in 600K.
(To install a patch, if that is your problem, take the patch in bzip2 format and put it in
bzcat | patch -p0)
You would get the same upgrade result that you would have gotten with a full download....
Papi
- Chernobyl used windows
I beleive that he was talking about main memory management. As you know, to be able to perform multitasking, the kernel must share memory between precesses.
To do so, the hardware must do some work for us (like being able to translate virtual adresses to phisical ones and vice versa). It does so by spliting the total amount of memory into pages (4K on i386, 2K on alpha).
What he meant (to my opinion) handling requests to static pages is that when a process wants to get memory for himself (when is is started, or by a malloc call or so), it asks the kernel for a certain number of pages. Then, the kernel gives him descriptors to these pages, and alocates them when the process actually uses them (so if you malloc(10000000) and don't use it, you won't realy waste memory).
Also, when he was talking about "sane architectures" and page handling, he meant (I think) that all basic architectures use such schemes. It's just that the number of levels of page caching changes (3 for alpha, 2 for intel).
Maybe you already knew all that, or maybe I suck at explainig stuff, but, if you want to know more about this, go get "The linux kernel" from ldp. Or even better, if you understand french go get "programmation linux 2.0 api système et fonctionnement du noyau" by Rémi Card (author of the ext2 file system) and the only good french computer book I've ever read.
Papi
- Chernobyl used windows
Good thing. Now, the only thing left for us to do, is burn all windows cds and kill (or making him suffer very much) Bill Gates...
Now, all the pieces fit....
Papi
- Chernobyl used windows
Maybe Linus doesn't have time to write about the kernel. But, if you are really intersted in design issues, you can pick up a copy of "The linux kernel" from ldp.
This book is written by a kernel hacker that made the port to alpha possible. It's not Linus, but he is a very knowligeable individual, and he explains design issues very well. Plus, there are pointers to files in the source tree so you can read the code while following his book...
Papi
- Chernobyl used windows
Vi is said to be the only text editor for UNIX gourus. Probably because it is so old, and that really good unix users used it for like 15 years...
Switch to nedit instead....
Papi
- Chernobyl used windows
After reading the future plans for linux, I saw a big problem. Linus wants Linux to be able to run on embedded systems -- great! But he also wants it to run on 16 processor super servers. From my understanding of kernels, it seems these are conflicting goals.
So far, Linux has been able to work on Palms and on 4 processors. But if all goes as Linus plans, there will be a much bigger discrepency in the scale of systems in the future. And this will just hurt the performance of Linux on either of these systems.
For instance, does it make any sense to have red-black tree virtual memory areas on an embedded chip running 2 processes? Or should the scheduler be as simple as it is for a machine with 16 processors?
I am afraid Linus will hold back scaling Linux up. He even mentions that one will only be able to use a modified (non-standard) version of Linux if you want to run on 64 processors or more. It is true that in order to scale, you need to make things more complicated and possibly slow for single processor machines, but this should be done. I mean, how many 386's are there running Linux nowadays? How about in 5 years?
I would bet money that there will be many 64 processor machines out there in 5-10 years. Moore's Law is going to give out eventually on the single processor and the only where to move will be in the parallel direction. Linux should be prepared for this.
-tbd
Most current keyboards have keys that traditional Unix editors simply ignore. I'm used to Home, End, Del, function keys, etc. and I much prefer pressing two keys to invoke a command than six.
Flame me as much as you like but vi(m) as well as emacs, joe, etc are predominantly for masochists, gurus or not.
But when you think about it it's not very surprising that the ease of porting depends most of all on how good your design is, even if you designed it with only one platform in mind.
One of the troubles with M$ products is that marketing reasons can take over pure technical ones. One such decision (I read it somewhere here) was to place the video driver in the kernel space to make the GUI run faster in NT 3.51. The other obvious example is the attempt to bury the web browser as deep as possible in the OS only to limit the market share of a rival product.
I am aware this is off topic but please post more examples if you know such. The Windows user lives with the undying hope that the next version will finally get rid of the bugs and will become stable. But it would be good Linux advocacy if we are able to prove that they are consistent in sacrificing reasonable solutions for the sake of greater revenue.
Linus talks about how Linux will inevitably be replaced by another OS once when the hardware evolves enough. But at the same time he tries to ensure that Linux is designed in such a way that it lasts as much as possible. M$ on the other hand don't need an OS which lasts more than 3 years because how else could they convince you to buy their next one if you are comfortable with the current. 'But please, try our new one. It's not only richer in features but we got rid of the bugs. Really! This time for sure!'
There's a few other texts worth reading from Open Sources too. I would especially like to point out Larry Walls essay which can be found online at http://kiev.wall.org/~larry/onion/onio n.html. Also worth a read are Bruce Perens article, which unfortunately doesn't seem to be reprinted online anywhere.
.. that Linux was written originally for the Intel platform, but now it's more widely ported than WindowsNT.
:)
Linus does a good job of being modest, but bashes Microsoft while he is doing it
And we shouldn't forgot to thank RMS and the FSF for gcc.
I think I've come to not understand what people mean by "flames." I almost never see posts that have no redeeming value whatsoever. Most posts that get categorized as flames are contreversial or ill-worded, not worthless. A lot of what Linus said in the article (microkernels are a joke, Emacs sucks, gcc is the only really good GNU tool) would surely get him a low score on /.
"Whatever happened to fair use?"
-- Duff-Man
calm down...
no need to get all sensitive
linus just says what he thinks...
it may be right - it may be wrong
take it or leave it, but FGS don't start crying
Embedded systems that run a standard OS?
Transmeta is developing an ultra low-power chip?
Total world domination! Linux in your car, linux in your palmtop, linux on your desktop....
Yes, but glibc didn't come into play until recently. gcc has been there since the beginning
--------------- "Well HELLO MR FANCY PANTS! I've got news for you bub, you ain't leadin' but two things, Jack, and
Sorry but this is not correct:
:-)
"video on Unix has always been an afterthought, whereas on a client OS like Windows, it's practically the most important thing"
Windows is still an afterthought, even on W98. That's why you can still switch it on an off by setting the GUI=YES parameter in the config files. Sorry, I forget which one, but it's hidden in the windows directory so we can't find out
I also don't understand when you say:
Microsoft always designs their product around absurdly low standards for marketing reasons (486SX/25 with 16 MB is minimum spec for Windows NT)
I don't think 486 with 16 meg would be absurd by todays's standards, let alone when NT was designed 10 years ago.
I suspect you have been exposed to some impartial opinions, as I don't know where you get these ideas!
I like Linus's informative style. Most of the time, we just get to read the guy's interviews.
Very nice indeed. A newbie like me learns quite a bit from reading this type of stuff.
== I am not Me.
From my experience linux is much more sensitive to faulty hardware than windows is. I had a p5 system in which the processor fan went bad. Linux would boot up just fine, but after a minute or two almost every program that was ran would produce a core dump.
But under windows the system was much more stable. Talk about a confusing problem. Once I had the machine apart and noticed that the fan wasn't spinning, I got the idea that it was overheating.
I replaced the fan, and underclocked the system, and it has been working fine under linux since.
Mike
P.S. I'm being facetious
-- A wealthy eccentric who marches to the beat of a different drum. But you may call me "Noodle Noggin."
Quando Omni Flunkus Moritati
Mumble mumble emacs mumble vi.
Mumble mumble sucks!!!
Mumble mumble better than mumble mumble
stupid mumble mumble editor mumble mumble
vi mumble mumble emacs.
Emacs is to vi as rutabaga is to parsnip.
That's "Mr. Soulless Automaton" to you, Bub.
I don't know if I have to say this, but Linus seems to be missing the point for the sake of being *productive*. First of all he is totally dumb on the microkernel issue. Microkernels aren't meant just for portability. Portability, in fact, is just some secondary advantage of a microkernel. Among some well known advantages are that a microkernel can support multiple OS'es, open-ness, distributed computing, flexibility... whatever. The reason why microkernels were conceived was definitely not only portability. That's just too funny to claim for a CS grad. like Linus... About the interface of Linux, I don't know if that doc. project about Linux API has been completed, but the last time I'd checked it, it had few entries. I mean even if you keep the monolithic interface tight an' slim, there are other things you gotta deal with. I think OO ppl will have a lot more to speak on this. Third, It is definitely not TRUE what Torvalds the Magnificient says on GNU tools. I think that the Linux project, for instance depends a lot on ash, bintools, filetools, this tools that tools. I think he is just getting it too personal. Weak character or something. Now about modularity, I use those kernel modules, and we all know they're handy. But still, it seems very funny that a simple dynamic C/assembly module/package implementation gets this much credit. Of course it's necessary but it's trivial. It's just something that had to be there. One point I agree with Linus is his views on GPL. I think GPL isn't very well defined. It depends a lot on current compiler technology... I'm getting the impression that GPL has some fatal flaws. Then he talks about Portability (again). It seems to me that he is too proud of his work. May I remind that AmigaOS could load device drivers and libraries dynamically in the 84 or so.. Just to remind that Linux isn't the only kernel which can do that. (Though it's free, and we should celebrate that) Huh?
--exa--
I don't know if I have to say this, but Linus seems to be missing the point for the sake of being *productive*.
First of all he is totally dumb on the microkernel issue. Microkernels aren't meant just for portability. Portability, in fact, is just some secondary advantage of a microkernel. Among some well known advantages are that a microkernel can support multiple OS'es, open-ness, distributed computing, flexibility... whatever. The reason why microkernels were conceived was definitely not only portability. That's just too funny to claim for a CS grad. like Linus...
About the interface of Linux, I don't know if that doc. project about Linux API has been completed, but the last time I'd checked it, it had few entries. I mean even if you keep the monolithic interface tight an' slim, there are other things you gotta deal with. I think OO ppl will have a lot more to speak on this.
Third, It is definitely not TRUE what Torvalds the Magnificient says on GNU tools. I think that the Linux project, for instance depends a lot on ash, bintools, filetools, this tools that tools. I think he is just getting it too personal. Weak character or something.
Now about modularity, I use those kernel modules, and we all know they're handy. But still, it seems very funny that a simple dynamic C/assembly module/package implementation gets this much credit. Of course it's necessary but it's trivial. It's just something that had to be there.
One point I agree with Linus is his views on GPL. I think GPL isn't very well defined. It depends a lot on current compiler technology... I'm getting the impression that GPL has some fatal flaws.
Then he talks about Portability (again). It seems to me that he is too proud of his work. May I remind that AmigaOS could load device drivers and libraries dynamically in the 84 or so.. Just to remind that Linux isn't the only kernel which can do that. (Though it's free, and we should celebrate that)
Huh?
--exa--
Dump it, it's for the best. His word is the one true word. Praise Linus! --NARF!
"DARLING NO BAAAKAAA!!!
DAAARLING NO BAAKAAA!
Well stated ;). However,
;).
Glide is "thinner" than DirectX in the sense that it is a thin wrapper around the hardware as compared to DirectX which is hardware-independant. Perhaps it wasn't a good example - I'd hate to see user interface stuff in the kernal
That brings up the point - what about the new fb features? These are in the kernal - the key difference being that because the kernal may not have it programmers cannot assume it is there - therefore, they design their *own* generic interface between the display logic & the program. Ie berlin. The difference with MS being that because each interface is purpose-built for the usage required of it, it is more efficiant and because of the kernal being in source form ppl learn not to "build" upon interfaces.
In summary, Linus appears to be saying that the OpenSource Way *allows* ppl to build eff. interfaces for a program easily (out of the kernal) instead of building on (possibily) poor interfaces because they have no choice.
Just me rambling along,
Great review! My rambling thoughts...
/proc + /dev file systems. So, Linux is actually using "low-level" interfaces, ie interfaces which are "thin" as apposed to "thick" (example, glide vs DirectX).
/.ers
Especially interesting from an engineering pov is the separation of interfaces from modulisation. The idea of writing the OS in C and basing "portability" on the portability of the compiler is a cool idea.
But, I suggest that you do need "interfaces" otherwise how can ppl use the devices? The "interface" in Linux is the
In effect, we have a trade-off against "portability" towards usage. This, I agree with totally.
Cheers
read mode
cat vfat.c
write mode
cat > vfat.c
He ripped on Emacs for bloat, but I think he showed appropriate reverence for GCC and the GPL.
While his discussion of GNU userland programs might get RMS's hackles up, it is clear to me that he cares more deeply about the Linux kernel and its design than any particular implementation of an OS that includes it. It's more kernel hackers arrogance than irreverence of the great GNU.
Most bigger sites contain out of dynamic content where static content (as served by sendfile) does not play a big role (you only need a big pipe for e.g. pictures). I said this already in the kernel discussion, but Linus contradicts himself here - it is a new interface and one which needs improvement.
What? You mean like this G3 running LinuxPPC? Never happen.
:)
-- "I've always believed that the mind is the best weapon" Sylvester Stallone, Rambo First Blood, Part Two
But he speaks the truth. The fact that Linux uses the GNU `ls' or `grep', etc. isn't what made it what it is today. Most of these utilities could have been grabbed from the BSD distribution. GCC is the absolutely essential piece of the puzzle that allows Linux to run on all of the architectures that it does today, and there is nothing else that would do the job. Linus realises this and that was his way of showing just how important GCC (and the FSF) is to the system.
Very enjoyable read. Linus is very much concerned with the essentials. /. coverage of Linux et al with CNN's coverage of the Gulf War. Thanks Rob.
I think M$ suffers a more fundamental problem. Interfaces. APIs. Big fat bloated interfaces.
Linus' "The first very basic rule is to avoid interfaces." is dead on target. You can recover from a bad implementation. You cannot recover from a bad interface. A bad job of doing the right thing works better than a good job of doing the wrong thing. Note: You cannot get rid of all the interfaces, but other things equal, the fewer the better. Much better.
Ever wonder WHY Windows requires a reboot after minor configuration changes? M$ has lost control of their own creation. For contrast, I think I've seen something about compiling a new Linux kernel and switching to it without rebooting! A slight pause to switch in-core stuff and back in business. Risky maybe, but you don't even consider such shenanigans unless you are in total control.
It is going to be very interesting to watch the development of Linux. I would go so far as to compare
This may help explain. a little.
Subtle timing differences. Different access patterns. Could go either way.
If you have a screwey BIOS, Linux will solve your problems. I would not trust Windows error messages -- often way off.
Take a fast look at AutoLisp.
It really is a lisp, but it is a baby lisp, with extensions to access some internal AutoCad stuff. Despite being infantile, it adds enormous power and flexibility to AutoCad.
AutoLisp is missing basic stuff like DEFEXPR so you cannot make your own SETQ function. Advanced stuff like backquote is way off the horizon.
Someone who knows lisp, not I -- completely lost trying to make sense of backquote, can fairly readily and accurately tell what kind and level a lisp is.
I have to disagree. This is the kernel. Throwing the term "stupid" around is appropriate even if unpleasant. The kernel is a bad place for stupidities. For something to play with, "Cool Ideas" are good. For something that everything else depends on, "Cool Ideas" are not good. If the cost of a good kernel is being labeled stupid for something that is 98% right, the price is cheap.
As for the idea of a microkernel, it sounds good, but if I understand Linus, it works out too much like emulating a VAX on x86. It loses more than it gains.
I feel obliged to comment on this topic...
/etc/init, and maybe even a /bin/sh binary"
I have to agree w/ CJS on his topic of what constitutes a "port", versus what I would term a "porting effort". Linux/VAX certainly would not qualify as a "port" in my book, if it does not even boot to a shell, nor would Linux/68000 (referring to the page given of "Linux ports") when I see on their page the comment:
"Stay tuned while I try to build a libc.a and an
hmm... am I to consider this a "port" when they don't even have a working init process??? Sounds somewhat like "vaporware" to me... "I have this great new 3D game, blows Quake away!!! Stay tuned while I write the 'main()' routine and a mouse input routine... and *maybe* some display code."
But, go to the Linux/PA-RISC page and you'll see they have a bootloader that can actually load a dummy kernel!! No kernel, but they *DO* have a large web site full of info about it. Maybe they should spend time writing code instead of web pages??
Now, don't get the idea that I don't like Linux.. I certainly think it is a good OS, but I don't like the way some of the "Linux ports" (if you can call them that) sell themselves. Maybe I've been jaded by too many of the vendors I've dealt with over the years selling goods they never deliver. I still have a "caching SCSI controller" (5+ years old now) that the vendor advertized for over a year as "WinNT drivers coming soon!" (NT 3.1 at the time) and they never made true on that. One of our minicomputer vendors advertised an "ODBC interface" for their proprietary database... a nice glossy flier... and when I called they were "in negotiations with a 3rd party to have them port their code" to their platform. It took two years, but they did finally release them... if you want to buy a new $10K intelligent ethernet controller and $10K worth of software (for 10 clients).
I have nothing wrong with hyping the porting effort to a new platform, but please don't group it in with all the "working" ports as if its functionally crippled.
NetBSD seems to have a good way of doing it. They seperate out their "ports" into "formal release ports" and then "experimental ports", which are basically working systems but may be buggy or don't yet support a large range of hardware, and then there are "not yet integrated porting efforts" which are works in basic development. Seems like a much more professional and controlled method of development...
I'm mainly a NetBSD user(I do have a Linux machine and an OpenBSD machine).. why?? Because I happen to have two VaxStations, two MicroVAX II's, a DECstation 5000/125, several Mac's, a Sun 3/260 and several 3/60's plus two Sparc's, and an HP475T system... and NetBSD runs on them all, fully supported in a "formal" release. I could hook any one of them up and run it as a web server, today! Now, *that* I consider having a real working "port".
One of my projects I am working on is porting NetBSD to the Apollo DNxxxx series workstations. I don't have any flashy web pages, just a little blurb in the "projects" section of the NetBSD site to let people know I'm working on it. Maybe when I get a bootloader and a kernel going (working on the bootloader now) and can get a single-user shell on one system, I'll try to get listed as a "porting effort" on the NetBSD site. I have 5 different models of Apollo's to test with (every SAU level I'm planning on supporting) and when I get it working on all of them and get a working userland toolset going, then maybe I'll become an "experimental" port...
I'm not looking for an ego boost from having my name all over web pages that I'm working on a new "port"... I'm just looking to get a reasonably up to date OS running on some old machine's I've collected. If someone else benefits, great! If noone else is still running one, at least I get a decent OS out of it.
I'm sure I could go on here, but I've got an "appointment" to go play pool and have a good time, and then maybe write some code for my bootloader tonight...
Pete
>...optimization...choose a scheduler at config time...
Ding! right answer. SGI's machines have interestingly different schedulers for their various machines, because the hardware architecture does vary so much (single processor machine, older SMP machines, newer cc-numa machines with the concept of "local" and "remote" memory (local is obviously faster). Here, the scheduler is picked at kernel config time, although it's done by linking the right .o's together; not by some #define in the code or whatever. Regardless of the actual mechanism, "during the creation of the kernel" is the right time to do this magic hand-waving.
>...64p machines common / not common...
You're trying to talk about whether *intel* machines will grow to 64p or not. They will. Note that 16-64p machines are the meat and potatoes of SGI's business today; not the neat whiz-bang desktops, but the large servers. Yeah, we're talking different markets here, but I hope my point is made - look beyond the desktop market, there's a whole nother world out there.
vi is the "guru's editor" because virtually any unix box capable of supporting CRT terminal displays has it. Even a 486 being used as a router :)
Hey LameMaster...err FlameMaster, there's a difference between worship and respect. I don't see any "Linus-worshipping" going on. The man did a lot, more than you, that's for sure, and he deserves respect for it.