Slashdot Mirror
Linus on All Sorts of Stuff
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. "
Does anyone here even use Hurd? How do you like it?
Interesting point on the HURD. I hadn't thought of it that way before, but I discovered and used Linux in 1994 when I wanted a cheap or free way to learn Unix. I've followed the HURD off an on for the past couple of years because I think it's a neat idea with potential, but it has no immediate use to me besides geek appeal, and there are many other things with better utility and geek appeal to me.
(I still hope the HURD will be something someday.)
"Preston: What's the latest happening in the kernel development?
Linus Torvalds: Oh, it's been more of the same. Worrying about drivers, fixing interfaces to make it harder to write bugs by mistake, and just keeping up with new hardware and new ideas. The kernel is definitely maturing in the sense that a lot of the exciting really _new_ things are all in user space, and the kernel is sometimes called upon to make them easier to work with..."
Let's stay at the word "maturing". I'm more interested in opinions from.. mature programmers. Is there a point that when it's reached - in the case of the linux kernel in about say.. 10 years - then software is only touched for fixing minor bugs? Or is the hardware/marketing/rest software world changing in a way that something can never ever be called mature but only 'for the time being'?
-someone
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!
OMG man you are funny....
the hardware support of even the latest Linux distributions is inferior to that of Windows or even Mac OS X
funny how there are more drivers for linux than there are for windows XP. and I can run Linux on more processors and different system types than every other Operating system ever made put together.
the world of linux is not the silly "home user" demographic you seem to be obsessed with. It runs on almost everything, including hardware without MMU's or Floating Point Processors. I can run linux of Big IBM iron to a pocket device....
something that is 100% impossible with microsoft and OSX combined.
linux supports much more hardware than windows could ever dream of.
Just because it does not support a crappy $9.00 webcam you bought on a whim means nothing.
This whole comment sounded a lot better in my head.
When you get to hell -- tell 'em Itchy sent ya!
I can run Linux on more processors and different system types than every other Operating system ever made put together.
You can, but do you?
You have a point but in the realm of a desktop PC, the fact that you can run Linux on a bunch of different architectures is meaningless, especially when a lot of software is difficult to compile because short-sighted developers code them to compile and work on x86.
What was being taken out of context here (desktop PC is the context, not servers or embedded devices) is that being able to run any WLAN card in a linux box is incredibly sketchy. The same goes for graphics cards. The ability to take a piece of hardware from a chain store and be able to use it is the context.
Installation support needs to be improved too. The days where a different package needs to be made for each major distribution and revision should have been gone a few years ago.
Just because it does not support a crappy $9.00 webcam you bought on a whim means nothing.
Just because you don't care doesn't mean it is an irrelevant point. Maybe you don't care if Linux becomes a mainstream desktop, not all Linux users want it. If you do, the ability of a typical user to run on existing, paid-for hardware is of critical importance for it to take off. No one is going to dump Windows if they find they have to replace several pieces of hardware to do what they want to do.
The kernel is mature he thinks. Everyone he works with agrees with him. Such a failure of imagination....
I think this is the difference between researcher/architect types and coders.
To a researcher, there is so much that needs to be done to enhance the kernel that
the problem is picking one thing to focus on.
To coders, ok, Linux now does everything that Unix did 5 years ago, what more can be done?
The coders were needed back when there was no free version of Unix. Now that there is one, some of these old guys (30 something and managing to be over the hill, CS is a great field....) need to step aside and let the researchers take the lead.
The sad thing is that of course they won't. They'll just keep right on copying plan 9 and everything else 5 years old, and probably do well in the market, sigh.
The problem with HURD is that their fundamental design is performance ineffective. Having a grand vision is not the problem, having a mistaken vision is.
It would be nice if BSD came back to life.... that was researcher driven, and they did a lot to advance the state of the art.
He is a nice guy though.
A quick search of the web -- or heck, just SourceForge -- 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.
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.
It's been TWENTY YEARS since they started working on a GNU kernel. As even RMS admits, they picked the wrong design for a kernel, but as he won't admit, they're too stubborn to change it.
Don't blame me, I didn't vote for either of them!
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.
This is so true in most cases. To this day it surprises me how the intel 10/100 card requires dozens of drivers on windows from model to model on Windows, but only the e100.o on Linux. Sometimes there is no interest or not enough information to create a Linux driver, such as with the 802.11g drivers. The ndiswrapper is a neat hack, but is very limited and unusable on amd64.
The only option left is to wait for a company to step up to the plate and write a driver from the start. This is why all my 802.11g cards are running Ralink chipsets, because they have a Linux driver.
Can I get an eye poke?
Dog House Forum
I think it depends on what angle you look at it from. Looking at this from the commerical development side (worked on by many people in one location, not necessarily proprietary), as opposed to the open source (many people, many locations) distributed development side, I've done far too many "small" web applications that get big.
Originally, they are there to fufill a specific task, and then a month later, when we're still working on it and adding functionality, we find we have to rewrite most of it from scratch because the foundation we designed initially is not flexible enough to support a large application (ie, not putting effort in to make it modular, since it has one task and thus one 'module').
I agree that you can overdesign, from what I've seen most overdesigning tends to be because of management issues and not coding. A friend of mine is working on a course management project for a university, and it expanded and added a bunch of scheduling functions and mail etc support (partly because it HAD to have that). It turns out there was another group at the university that has been working on a very similar project (except it's specifically the scheduling part, and a couple other things). They found out what he was doing and it caused a big uproar - because they've been working on it for two years or something, and while they have a fair chunk of code, none of it works and it's still a year off from even being complete. My friend's not even been working there for a year yet, and his entire system is already on-line and in production use. The biggest difference is their team has one coder (who is a freelancer outsourced from the US somewhere) and like 4 management people making design decisions, while on his side it's him coding and desiging most of it, with a bit of input from the faculty.
They both basically have the same architecture - his system is easy to expand - but theirs is overdesigned in the sense that too many people have their fingers in it and it takes forever to get anything done.
It's a similar issue with being "scared away" by the size. You can't work on a big project, you HAVE to break it down into smaller sub-tasks and pieces. Then it becomes a lot more manageable, and as long as you concentrate on one thing at a time, you should be ok.
I somewhat disagree with this. This logic leads to cutting corners because you can get away with it. For example, maybe you hardcode something because it's easier than writing some stuff to handle reading it from a config file or whatever. That sort of decision can make a LOT more work later on in development when the program gets bigger and you need to have a config file to change things - now you have to write the config handler anyways, plus go through and find all the places something got hardcoded. Much easier to miss something that way, and end up chasing it down later when it gets filed as a bug report.
This is absol
Speak before you think
...doom and gloom for Hurd...has yet to happen and it's not going to.
More like Hurd has yet to happen and it's not going to. The doom and gloom already happened a long time ago. Sure, they've got a few developers and hangers-on, I even ran it a few times about 3 or 4 years ago. But every time I check in on it, it hasn't progressed a whole lot, they're just catching up to some minimum level of usability that Linux/BSD has had for years. What's the use of all the "advanced" features if they don't actually advance anything?
You had me at "dicks fuck assholes".
For the question
"Do you have any advice for people starting to undertake large open source projects? What have you learned by managing the Linux kernel? ",
as I was reading the reply...
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.
for some reason I was mentally comparing it to the stand that the Bush administration has taken in the "war on terror" and the "desire to spread liberty". I could not help but think, that here is the exact reason why it is flagging and possibly destined for eventual failure.
Listen,
:-)
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.
The revolution will NOT be televised.
Examples for systems using Mach are MacOSX and IBMs AIX.... ;-)
Mach used to be bad around 1990 but the things have been patched up