Slashdot Log In
Linus on All Sorts of Stuff
Posted by
CmdrTaco
on Mon Oct 25, 2004 03:23 PM
from the do-a-little-dance dept.
from the do-a-little-dance dept.
Linux Times.Net writes "
Linus Torvalds
tells of some other programming venues than the Linux kernel, predicts a shadowy outcome for GNU/Hurd, gives some advice to anyone wanting to undertake a large software project and updates us on the latest in kernel development in this email interview by Preston St. Pierre. "
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Hurd (Score:5, Interesting)
Re:Hurd (Score:5, Informative)
I.e. it might be fun to play with, but it's not very useful for the average Joe.
Parent
Re:Hurd (Score:5, Insightful)
Parent
Re:Hurd (Score:5, Insightful)
Parent
Some jobs are still too hard to do on GNU/Linux. (Score:5, Insightful)
Which would put it on a par with how useful the Linux kernel was when it was young. It wasn't useful unless one was extremely technical, and even then it lacked a lot of hardware support and one couldn't do a lot of commonly useful things with it. In time, the HURD can mature and become competitive. This doesn't mean GNU/Linux is a piece of cake for jobs people want to do.
But what I find interesting is Torvalds' answer to the question following his HURD answer:
Here, unlike in previous questions, I think Torvalds uses the word "Linux" to mean a complete operating system in which the Linux kernel is being used (typically, a GNU/Linux system), so I'll interpret the answer in that vein.
The main point I wanted to draw out is that it took ten years, by Torvalds' estimate, to get where things are now. I'd argue that that estimate is wrong by half (the free software community began 20 years ago), but even if we take the ten year figure at face value, the HURD hasn't been running on anyone's machine for ten years yet. And even now there are people (such as a fellow I had on my radio show last week who was addressing a caller saying the same thing) saying that the modern GNU/Linux system is too hard to use, too complex to install and to complex to do some jobs with when compared against Microsoft Windows or MacOS X. Those jobs include:
All of these jobs are possible but way more difficult to simply do than they ought to be. And few (if any) distributions make it easy to do these things by including the free software packages available to make them work right out of the box.
Configuration is too hard; getting these things working rely on one's skill with a command line interface or editing technical configuration files. ESR's printer essay was right on the mark when it came to his perspective on hooking up a printer--adding a printer should be automatic and the system should do more network scanning and autoconfiguration to suit what most people most of the time will want.
So, even for those who would complain the GNU/HURD system is too far out of reach, I'd say look closer to home and see the problems that exist for GNU/Linux. GNU/Linux is a heck of a lot closer to what I think people yearn for, but that's no reason to trash GNU/HURD.
Parent
Re:Hurd (Score:4, Informative)
Wheee, let's map our whole filesystem into virtual memory.
Then again, it's not that bad. Definitely not ready for production use, but not unusable either. Apparently the limitation is slated to be removed sometime. For comparison, have you seen the recommended partition sizes for OpenBSD?
Parent
Re:Hurd (Score:5, Interesting)
Parent
Re:Hurd (Score:5, Interesting)
Some quotes:
The Hurd throws this historical garbage away. We think that we have found a more flexible solution called shadow filesystems. Unfortunately, support for shadowed filesystems is not yet implemented.
Eh? throw the (working) garbage away before the new solution is implemented?
You are using IRQ sharing; GNU Mach does not support this in the least.
Yeah, because that's such an uncommon thing for hardware to use.
GNU Mach does not support loadable kernel modules. Therefore, you will have to compile a new kernel and only activate those device drivers that you actually need.
So much for a microkernel then.
The Hurd will just as happily swap to any other raw disk space and overwrite anything it finds. So, be careful!
Thanks for the warning. That will make me want to install it on my machine.
This FAQ document was probably secretly written by Linus Torvalds to ridicule it, and promote his own views on software development.
Parent
Re:Hurd (Score:5, Informative)
In contrast to Windows which will overwrite your bootloader, reorder partitions, and change partition types of existing partitions without you asking it to.. I don't think its fair to ridicule Hurd for warning you that it is possible to destroy data if you go out of your way to initialize a non-swap partition as a swap partition.
You can run mkswap in Linux on any partition regardless of weather it is set to "Linux swap" type or not. Somehow that hasn't been a huge problem for me either.
Parent
Re:Hurd (Score:4, Funny)
Parent
Re:Hurd (Score:5, Interesting)
Parent
About to be /.'ed (Score:5, Informative)
Article text
Linus Torvalds: ''Desktop Market has already started''
Preston St. Pierre of Linux Times interviews Linus Torvalds.
Linus Torvalds tells of some other programming venues than the Linux kernel, predicts a shadowy outcome for GNU/Hurd, gives some advice to anyone wanting to undertake a large software project and updates us on the latest in kernel development in this email interview by Preston St. Pierre.
Preston: Your life has been dedicated for quite some time to the Linux kernel. If this project was no longer yours, what kind of project would you most like to take on next (games, user applications, another kernel, development tools, etc)?
Linus Torvalds: I like being close to the hardware, and doing good visuals (ie games or GUI's) is not my forte, so I'd probably work on development tools or similar.
In fact, the only project I've actually spent some time on in the last year (apart from the kernel, of course) has been this source checker application that does some extended type-checking for the kernel. So very much a development tool.
Preston: What is your favorite interpreted programming language, and why?
Linus Torvalds: Heh. I don't much do interpreters. The only one I end up using consciously (ie not part of somebody else's scripts) end up being just the regular shell. It's not that I dislike things like perl/python, it's just that I tend to either just write C, or do _so_ simple things that shell works fine for me.
I might admit to having a soft spot for basic, but I haven't actually used it in closer to twenty years or so. But it was what I started with, so it will always be special
Preston: Do you have any advice for people starting to undertake large open source projects? What have you learned by managing the Linux kernel?
Linus Torvalds: Nobody should start to undertake a large project. You start with a small _trivial_ project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision.
So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way _useful_ first, and then others will say "hey, that _almost_ works for me", and they'll get involved in the project.
And if there is anything I've learnt from Linux, it's that projects have a life of their own, and you should _not_ try to enforce your "vision" too strongly on them. Most often you're wrong anyway, and if you're not flexible and willing to take input from others (and willing to change direction when it turned out your vision was flawed), you'll never get anything good done.
In other words, be willing to admit your mistakes, and don't expect to get anywhere big in any kind of short timeframe. I've been doing Linux for thirteen years, and I expect to do it for quite some time still. If I had _expected_ to do something that big, I'd never have started. It started out small and insignificant, and that's how I thought about it.
Preston: From a user's prospective, what improvements do you see the Linux kernel offering over Hurd? Do you think Hurd might eventually become as popular as Linux?
Linus Torvalds: I think Hurd is dead. See above on why. It has a "big vision", and people forgot about the details, and forgot about admitting when they went wrong. So the project stumbled, and _still_ didn't bother to look down on the ground. But hey, I might be wrong. I haven't actually followed Hurd in any detail, and maybe the project is more down-to-earth now, and more concerned about getting things working, and less about "design". And less
Re:About to be /.'ed (Score:5, Informative)
Wrong (and jealous?):
-- http://en.wikipedia.org/wiki/Linus_Torvalds [wikipedia.org]
Double check if you like, it's well-known history.
Parent
Re:About to be /.'ed (Score:5, Informative)
Um, no [swbell.net] (third paragraph).
Parent
GNU/HURD (Score:5, Funny)
Re:GNU/HURD (Score:5, Funny)
Parent
Re:GNU/HURD (Score:5, Funny)
Parent
the HURD (Score:5, Interesting)
(I still hope the HURD will be something someday.)
I've always liked Linus... (Score:5, Insightful)
He's not a god or anything, but a very down-to-earth person when it comes to software and the linux kernal in general. He is absolutely correct on what happens to "big vision" software. Too many projects that started big have fizzled, and small applications that work tend to grow and morph into ground-shaking applications as they mature. Take web-browsers for example.
JMD
Re:I've always liked Linus... (Score:4, Informative)
Or PHP for example - originally short for "personal home page" , it was a series of perl scripts for tracking who was looking at Ramus Lerdorf's online c.v.
Now its somehow morphed into something that runs millions of websites worldwide. If thats not a good example of Linus's "think small" philosophy, i dont know what is.
Parent
Re:I've always liked Linus... (Score:5, Interesting)
A quick search of the web -- or heck, just SourceForge [sf.net] -- will show a plethora of projects that "started small" which have also completely fizzled.
There is nothing wrong with thinking big when starting a project - there are some types of project that simply can't be done on a small scale. Mozilla is pretty damned big, for example, and while it started off with Netscape source code, much of it was discarded. Eclipse is likewise a big project.
The key to doing a big project is you have to really put your nose to the grindstone and work your butt off to get something online in a reasonable timeframe. The biggest problem I see with large scale projects that fail is they get bogged down in minutae, which slows down their release cycles so much that they don't achieve any developer or user attention. We all forget with Firefox 1.0 imminent how the press used to claim that the Mozilla project has failed a few years back because it had taken them a few years from the time Netscape Open Sourced their browser code, to the point where it was usuable. And yet now we're celebrating the release of a world-class Open Source browser.
That's a big project which didn't start off small which is going to be a rousing success. Yes, projects which fail to gain traction because of lofty ideas and infrequent releases to tend to fail in the long run. However, there are an order of magnitude more small projects which similarily fail. The only difference between the two is we tend to hear about the "big" ones, but nobody cares one whit about the tens of thousands of small projects which come and go.
Yaz.
Parent
Linus on what stuff? (Score:4, Funny)
I, for one, would have welcome our new Linus-run overlord stuff.
^_^
What a terrible "interview" (Score:5, Insightful)
The interviews in ACM Queue [acmqueue.org], particular the one with Jim Gray interviewed by David Patterson, was much much more intriguing.
"Infrastructure" (Score:5, Funny)
Heh, "provides some infrastructure" ??
Such a sweet deal would normally make one wonder...
Re:"Infrastructure" (Score:5, Funny)
Parent
Words of Wisdom (Score:5, Interesting)
Re:Words of Wisdom (Score:4, Insightful)
I don't buy it. And perhaps it's because I fall into the young category and might be lacking the "real world" experience.
e're taught from day 1 to look at code reuse and to break large chunks of logic into smaller bits. That requires a bit of planning ahead. You need to make some good guesses about where things will go. Right now you don't need to worry about transferring data via sockets, but there's a good chance one day you will need to. So you design the way your program breaks down its funcionality so that it's a trivial matter to take the output from one function and direct it torwards another that begins/handles the transfer process.
Lets take it up a notch in complexity and look at planning the development for a 3D game. You build a modular system so as things change, you can move to a different sound engine, or 3D engine, or whatever, and don't have to rewrite half the code of the system. But to build modular, you have to plan, you have to see where, down the road, that modularity is going to give you a benefit.
That's what makes the HURD really nice is all the modularity is planned and laid out. There's a structure and you know the direction the development will take. Big picture stuff.
There's a reason the captian of the ship pilots from the bridge, where he can see what's in front of him. Linus seems to want to pilot his ship from the engine room.
Parent
Re:Words of Wisdom (Score:5, Insightful)
Take a look at CPAN for a good detraction to your argument.
Most CPAN projects start pretty small and fill only a few features. Since search.cpan.org contains a pretty thorough revision history of most of these projects, you might find that useful.
Anyways, no one builds an app in perl with one all-encompassing module. They take bits and pieces that do what they need
You can see a good example of your argument being executed poorly by examining some popular PHP applications, or you can just take a look at slashcode, which I apologize, should never have been released to the public.
PHP 4 in particular has horrid OOP support. I know perl's isn't much better, but I'll gladly take horrible perl OOP over that joke of OOP that's is the representation in PHP 4. It's much better in 5 I hear.
Anyways, that's just context, only to lead to the point. As a result, many of the applications in PHP lead to shoe-horning OOP features into a procedural interface - which is fine if you know what you're doing, but not really in anyone's best interest unless they still refuse to admit that OOP has merit and a place (only the biggest curmudgeons in the software industry - like jwz.
Either way, a lot of PHP authors try to implement things like plugins, namespaces, all sorts of crap which PHP 4 was not meant to do by craftily using includes and manipulating the names of functions.
I'm only using the PHP vs. Perl comparison because the distinct lack of features in PHP 4 that appeal to a designer of large applications fosters this kind of problem, and while it's pretty rude to make this assumption, only those who can't see that ahead of time doom themselves by writing large applications completely in PHP 4.
A good rule of software design: If you can't realize it without getting crafty, you've already done something wrong. Unnecessary complexity will always lead to failure. Take a look at windows.
Amongst other problems with PHP (like it's lack of a built-in database API that supports binds for all databases), that's why you see these applications on bugtraq all the damned time. Applications like Zope which are built on a foundation made to give the features an application like Zope needs help eliminate the most basic design flaws.
Just to bring my argument down from the heavens, I have on two occasions gone to great lengths to design giant API's that were flawed as soon as I plugged them into the editor. One of these designs kept me away from my editor for nearly 6 months, unless I was writing documentation. So, I would like to think that I'm speaking from experience on what
If I had said, "what do these things really need to do", written them, and then said, "how can I make them operate better", I don't think I would have been in that position.
Parent
Re:Words of Wisdom (Score:4, Interesting)
Not so much young as that what you can see and think scales linearly while the hidden complexities tend to scale exponentially.
The devil is in the details and as noted elsewhere "The biggest problem I see with large scale projects that fail is they get bogged down in minutae." It's not just the complexity of the final product, you have to deal with all the complexities all along the path toward creating that final product and most important choosing which path at each fork in the road.
There's a reason the captian of the ship pilots from the bridge, where he can see what's in front of him. Linus seems to want to pilot his ship from the engine room.
Sounds good until you get grounded on a submerged reef.
It's even more fun in uncharted waters.
Wisecrack from a master sculptor. "I just removed the parts that weren't David."
At a particular level that is exactly what happens. Linus is right when he says "And if there is anything I've learnt from Linux, it's that projects have a life of their own, and you should _not_ try to enforce your "vision" too strongly on them. Most often you're wrong anyway."
Parent
FSF doesn't rush anything, so chill. :) (Score:5, Insightful)
Okay, maybe HURD isn't where we all want it, that is -- on our desktops and running everything... BUT...
Lets not forget, HURD is FSF/GNU, and they've proven time and time again that they are presistant, don't rush to complete their vision, and go the extra distance on a lot of things.
If HURD achieves both the standards and the quality of forethought that all the other FSF/GNU code that has been released so far, then it will doubtlessly be a marvel of OS technology. It has a tall order to fill, though, and honestly -- it there's no rush to see it pushed into production, then I'd let the politics play themselves out. However, it *is* the goal of the FSF. How it finally winds up-- well-- I'm anticipating to see like everyone else, but I've become a believer in the FSF's patience, skills, and collective vision.
hey, no rush (Score:5, Insightful)
Who's kidding who?
Parent
yeah yeah, but (Score:5, Interesting)
I give mad props to RMS for the legal hack of the copyleft, and when the chips are counted he'll probably be given saint-hood by several developing countries, but I don't get the impression it'd be fun to work with him. And at the end of the day (and especially in the middle) that's mostly what you need to get through a large complex project.
I could be wrong, I've never met him. But I've got a short fuse on dogma. To get a thing done, at some point you just have to do it.
On the good side, open source says "less defects because we didn't rush it", but there's that other side that says to ship something shoot the engineer. There's a point to that too.
Parent
Anyone else hate... (Score:4, Funny)
Linus's just this guy, you know... (Score:4, Funny)
The HURD problem (Score:5, Interesting)
Microkernel architecture is really hard to get right. If you get it right, microkernels are fast and stable, like VM for IBM mainframes and QNX. Both have long, long uptimes, run important systems, and are modified very seldom.
But most architects don't get it right. If you get it wrong, like Mach, no amount of patching will fix it. Because open source development has a "patch" mentality, it's almost impossible to fix fundamental architectural problems in an open source project.
The HURD people finally dumped Mach and went to L4, which is a half-finished academic microkernel. That's not working either.
I'd like to see a high-security microkernel OS in widespread use, but the HURD guys aren't going to deliver it. And we really need one.
Re:The HURD problem (Score:5, Insightful)
Parent
Re:The HURD problem (Score:5, Interesting)
Far more reliable, and secure.
Even a "kernel" bug isn't a root exploit. You can have highly secure systems by just finely tuning the level of privlidge you want to give a process. Even if there's an exploit, you can't break-in. Basically, nothing runs as "root". Think ultra-finely-tuned jails, automatically, for everything.
Even the most low-level drivers malfunctioning doesn't cause a crash or a reboot. If any of your drivers has a problem, crashes, corrupts memory, etc, it's contained to just that driver, and it will be stopped, and restarted, without your even knowing about it.
A microkernel can really wipe the floor with a monolitic kernel. QNX really makes Linux look fragile. For a better example, look at OpenVMS. Even after all these years, it's still got an unbelievable reputation.
You know why even computer experts wouldn't trust their lives to computer-controlled systems? Because they've never used a microkernel-based system.
No monolitic version of Linux/BSD is ever going to be able to replace a microkernel-based system.
Parent
Re:Linus isn't really one to talk. (Score:5, Insightful)
Make up your mind. Is it ``immensely flexible'', or ``monolithic and slow-to-change''? I'm pretty sure it's not both.
As for ``too monolithic and slow-to-change to be easy to toss onto a new PC'', try Knoppix. It makes installing Debian easier than installing Windows.
Parent
Re:Linus isn't really one to talk. (Score:5, Insightful)
Parent
Re:Linus isn't really one to talk. (Score:4, Interesting)
This whole comment sounded a lot better in my head.
Parent
Re:Linus isn't really one to talk. (Score:4, Insightful)
By comparison, shortly after the device comes out a reverse-engineered driver will be available for linux. It will be clunky and hard to install, slower, more buggy, etc. Later versions will fix the bugs, then fix the efficiency, then fix the installation issues, then tie in with hardware autodetection. Soon enough, the linux drivers exceed the windows ones.
So, if you get your hardware the moment it is released to the public, you will probably find the windows drivers better. If you wait until things become affordable then you're probably going to find linux drivers at least as good.
Parent
Re:Linus isn't really one to talk. (Score:4, Insightful)
- Any performance improvement you get from having a highly-optimized driver is typically swallowed up by the general inefficiency of Windows itself.
- While the hardware vendor's coders may know their hardware, they don't (and CAN'T, due to it's closed nature) know the Windows internals and how their code will interact with Windows, hence the need for Microsoft to certify the drivers. IME, A *HUGE* number of BSOD errors (perhaps even the majority) are due to misbehaving or buggy vendor-supplied drivers.
The only place Linux falls behind is support for bleeding-edge hardware. This generally isn't a problem for me as I rarely if ever buy leading edge hardware due to it's lousy price/performance ratio. One or two steps back from top-of-the-line usually gives you >90% of the performance for 50% of the price.Parent
Re:Linus isn't really one to talk. (Score:5, Insightful)
In Linux, you may have to install fewer drivers, but the ones that you do have to install are difficult to do so with. This is what prevented me from making the switch to Linux a couple years ago: I couldn't get my wireless NIC running.
It's easy to say that I should buy hardware more carefully, or (as another poster said) it works on everything except "those shitty winprinters," but that avoids the problem. I need it to run on the hardware I've got already, or it becomes cheaper (and easier) for me to go buy a Windows upgrade.
I'm hardly a computer guru, but I'm definitely more competent than most people I know when it comes to them. Nonetheless, every time I've tried to switch to Linux (on average, once every year or two since '96), I've been put off by a piece of hardware I couldn't make work.
First it was sound, then it was printing, then it was a NIC, then it was a video card, then it was a wireless NIC.
*shrug*
I'm sure I could learn how to do it, but I already spend 50+ hours a week fighting with computers at work, I don't want to struggle when I get home.
Parent
Re:Linus isn't really one to talk. (Score:5, Insightful)
But that's not to say your comment won't be applicable in a year, you'll just have to say 'bluetooth' instead of wireless, or whatever the hot new technology of 2005 is. My feeling is that for most people, linux will 'just work' first time now. This was less true two years ago, and it will be even more true in two years time.
Parent
Re:Linus isn't really one to talk. (Score:5, Insightful)
There are many reasons why Linux won't go to a "shadowy fate." It is largely deployed in the enterprise. There are thousands and thousands of people either directly developing on it or for it. There is millions of dollars being shoveled into it by the likes of IBM and Novel. If all these folks thought that Linux was headed for a shadowy fate any time soon, do you think they would waste their time and effort on it? Do you even read Slashdot? (:
It's not neccesarily just about open source vs closed source, it's about superior product in the market place. Open source is a partial factor, depending on your targeted demographic. I'm not sure how its immense flexibility is a bad thing, or how Linux is too slow to change, but it's true that all people may not be able to enjoy it. Even that is rapidly changing, with easy-to-use distros like Linspire, Ubuntu (or whatever), and Fedora.
More on usability: Because I am a technically-abled person, I prefer to use Linux on the desktop (home computer and work computer). When my laymen friends ask if they should install Linux, I shrug and ask them what's wrong with their Windows? I hope that I will be able to give them an enthusiastic yes within a year or two.
Parent
Re:Linus isn't really one to talk. (Score:5, Insightful)
When my laymen friends ask if they should install Linux, I shrug and ask them what's wrong with their Windows?
Overwhelmingly, it seems to be adware/spyware, and the all the other stuff that people install intentionally or accidentally. Within a year or two, the average windows machine gets bloated with semi-removable crap.
The people I've moved over to linux have no problems using it. It's installing it, getting all of the hardware configured, and installing all of the strangely named multimedia software/codecs that is the tricky part. This all usually comes preinstalled on Windows, so it's an unfair comparison.
I am always sickened when I have to use a fresh Windows installation, and it comes without a DVD decoder, a CD burner, a decent text editor, a PDF reader, a popup blocker, an FTP client, or a graphics file converter - all stuff that comes standard with most linux distro, or that I can install (for free) with *one command*.
That's what's wrong with Windows.
Parent
Re:Linus isn't really one to talk. (Score:4, Insightful)
Linux needs to focus on progressive discoverability - Only expose as much of the interface, programs, and power as necessary. Keep it all in reserve for people who want it, but don't constantly throw it and the millions of settings right in a new user's face.
Parent
Re:Linus isn't really one to talk. (Score:5, Insightful)
I call shenanigans on this. The last count I saw showed that Red Hat FC2 has more than 3 times as many drivers as Windows XP out of the box, assuming that you only count Intel-compatible platforms (if you count all platforms, Linux has an even wider edge).
E.g. my scanner and TV capture card are both supported out of the box under FC2 and not supported at all under XP. The scanner came with Win95 drivers, but no newer ones are available for Win32 and the old ones don't work with Win2k and later. I can't remember exactly which Windows version broke support for the capture card. I have no intention of buying a new scanner when mine is a great workhorse oversized flatbed with true 1200x1200 resolution that still outperforms the modern cheapo models handily.
And while my wireless LAN card is theoretically supported under Windows, it locks up every 10 minutes when WPA encryption is enabled (WEP is forbidden in our environment for security reasons) but runs for weeks with no problems under Linux--and Linux supports advanced features like running it in host AP mode (as a basestation).
Windows has better support in some areas--brand new 3D graphics cards is one, new winprinters and winmodems are others--but as far as overall hardware support Linux is way ahead.
Parent
Re:Bah! (Score:5, Funny)
Maybe there is a war, but you can't kill something that's already dead. Or haven't you hurd?
Parent
Re:the kernel is so far from mature, sigh (Score:4, Insightful)
Oh, horsehockey. I work with a bunch of computer science researchers who work on high performance computing topics. Guess how most of 'em do their OS-level research? They take Linux and make their wacky new file system/interconnect/etc. ideas work with it. Seems to work pretty well for them.
Another thing to remember is that a lot of CS researchers write half-arsed code that isn't ready for prime-time. They're usually thinking proof-of-concept, not production deployment. That isn't unique to academia, either; it amazes me how much utter crap escapes from big corporate research labs claiming to be a "product".
[/me decides to quit before this degenerates into YA rant about the fact that physicists are often better at production-quality software engineering than computer scientists]
--Troy
Parent