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. "
This is moments from being /.'ed to death...
;)
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
I.e. it might be fun to play with, but it's not very useful for the average Joe.
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. You forgot NetBSD.
> Nonetheless, the hardware support of even the latest Linux distributions is inferior to that of Windows or even Mac OS X, and it's difficult to see how this is going to change when manufacturers continue to make their drivers closed-source and binary so that they only work with one kernel version, one distro, one libc
OS X doesn't have that much hardware to support. Have you seen how much hardware Linux supports today? Most hardware support under Windows is provided by third parties. If you get the latest sound card you won't get any sound under Windows (unless the soundcard is recognized as compatible with a previous model) without the manufacturer's drivers. My SBLIVE is not supported under Windows XP without Creative's drivers but is under Linux with the mainstream EMU10K1 driver. If you get the latest video card, you won't have Windows support for it, my RADEON 9600 is not supported under Windows XP without ATI's driver, but Linux has a generic ATI driver for the framebuffer interface.
Second: I'd rather that software developers distribute binary Linux drivers for a single distribution/libc than Windows ones. Why? Because at least for me they are easier to reverse engineer.
> In a way, its immense flexibility is a bad thing. Open source is a nice thing, and has the potential to take over - just look at Firefox. But Linux is just too monolithic and slow-to-change to be easy to toss onto a new PC and get up and running with. There's a proliferation of different versions, all incompatible, making ease-of-use impossible to attain.
I half-agree with you on this one. I think the real problem is not the flexibility. I've always argued that monolithic kernels aren't good for desktops, and this, in my opinion, is the only thing slowing down Linux acceptance on the desktop.
How exactly is the hardware support in Linux in any way inferior to that of Mac OSX? I love OSX just as much as any other unix geek, but to pretend that it's hardware support is superior seems a bit misguided considering the fact that they only support the hardware that they themselves build, along with a few peripherals tossed in. Linux on the other hand, will run quite nicely on their hardware, along with 85-90% of the rest of what's on the market.
The major difference is new hardware, and new hardware capabilities. New device drivers is the most obvoius one, but also things like new ways of doing existing things require ne algorithms for optimal performance. E.g hyperthreading. Any SMP-aware kernal can use hyperthreading, but for optimal performace you have to be aware of which CPUs are actualy on the same chip, share the same caches and busses etc...
As well, people want to put more features in the kernal. The maintainers have been very good at only apply the things that need to be in the kernal, but there will always be new network protocols, new filesystems, new security modules etc...
According to WHOIS, the domain was created about a month and a half ago, apparently owned by Linaire.
Last time I played with it, yes, the 2GB limit was still there.
;)
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?
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.
Does it say if it still has a 2 GB limit for partition sizes
It appears so.
I think the preferred distro of Hurd is Debian. Check here for details about K7 released 25-Sep-2004.
Yes, LinuxTimes.net is new. Yes, there have been a lot of copied stories up until now.
However, over the next few weeks there will be a plethora of new interviews, published exclusively on LinuxTimes.net.
-Preston
Note to self: preview posts.
A ~2GB filesystem limit isn't unusable for a development OS (or even a production one).
Yeah but look at the start date for The Hurd.
(hint: it's actually older than Linux!)
Over-design is an understatement. The Hurd is a perfect example of what happens if you try to design a "perfect" (in a Computer Science way) system. You never get anything done. All design and no product.
You'll need to port it to Sparc first though, but I suppose that would be a learning experience and progress for Hurd!
Yours Sincerely, Michael.
> Well, Linux started out as something
> barely usable
Yes, but the Hurd has had a lot longer to stop sucking than Linux has, as it was already in progress before Linus got started.
One can argue that this is because all the developers flocked around Linus ( I think Stallman has made this argument from time to time ) but given that world+dog has given up on the whole microkernel thing, it's more likely that the hurd just sucks.
Sitting Walrus Blog
The "embedded" market is indeed huge. But the vast majority is inexpensive 8 bit (and even 4 bit) microcontrollers that typically have 32k or less Flash/EPROM/mask-ROM and 1k or less RAM, and chips as small as 1k of code and 64 bytes of RAM are very popular, due to their small size, low power and most importantly, their low cost.
Recently, 32 bit ARM7 chips have started to appear on the market at prices competitive to the upper end of the 8 bit controllers. Slashdot even carried an article about Atmel's much-hyped new ARM7 chips coming out soon. But they have flash sizes ranging from 32k to 256k, and RAM ranging from 8k to 64k. These 32 bit chips can't run linux. Most will run either a custom app, or a tiny RTOS like http://www.freertos.org/">FreeRTOS or http://www.ucos-ii.com/">uC/OS.
Ask yourself why you'd choose linux for some application where you are selling the hardware with the firmware embedded. Because it's cool? Because you want to include megabytes of additional memory, extra board space, and a more expensive chip with external bus pins rather than cram it all into the 128k of on-chip memory in a less expensive processor without an external bus? Because you'd rather distrubute your source code to customers and competitors alike, rather than go with a bsd-style license or one-time license payment. Because you'd rather go to market with a higher cost of goods sold than your competitors?
Sure, there are some very high complexity products that need the features of a system like Linux or WinCE. But the vast majority of embedded apps don't need that complexity, and the extra cost just isn't commercially competitive.
PJRC: Electronic Projects, 8051 Microcontroller Tools
I'd like to see a high-security microkernel OS in widespread use
Would MacOS X count?
The fundamental services and primitives of the Mac OS X kernel are based on Mach 3.0... Mach 3.0 was originally conceived as a simple, extensible, communications microkernel.
WARNING: If accidentally read, induce vomiting.
Thanks for the warning. That will make me want to install it on my machine.
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.
You can run mkswap in Linux on any partition regardless of weather it is set to "Linux swap" type or not.
Yes, but Linux will only swap onto partitions that have been prepared with mkswap, which makes it somewhat less likely you'll clobber a partition you meant to keep. That's really the only point of mkswap; everything else could be done perfectly well in the kernel.
However, in Mac OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks.
It had to be done that way because the IPC system Mach bolted onto a BSD kernel is slow. Retrofitting message passing onto a kernel that wasn't designed for it seems to consistently result in a slow message passing system. This is because message passing has to be tightly integrated with CPU dispatching to get really good performance. It's not the data copying that kills you. It's the extra trips through the scheduler.
Mach has simplex ports, like UNIX pipes. Big mistake. To get high performance message passing, you have to make subroutine-call like operations work really efficiently. The basic operations in QNX are MsgSend/MsgRecv/MsgReply, which has the effect of a subroutine call between two processes. Process A does a MsgSend to process B, which is hopefully waiting in a MsgRecv for some work to do. Process A blocks, and process B unblocks. The trick is that when this happens, the normal case, where process B is waiting, is handled by an immediate transfer of control from process A to process B, without a pass through the scheduler to find the next ready to run process. To return, process B does a MsgReply, which immediately unblocks process A.
If you do this with Mach-type simplex ports, where the primitives were ill-chosen, it requires several trips through the scheduler, because the primitives don't lend themselves to simple transfer-control semantics. A does a write, which unblocks B but doesn't block A. So A keeps going. Then A does a read, which blocks A and causes a trip through the scheduler, at which point B is found ready to run and started. The same thing happens in the other direction. Two extra trips through the scheduler.
Worse, if there's another CPU-bound process ready to run, a trip through the scheduler may pick it instead. After all, it's been waiting longer. So each interprocess call results in a chance of losing your current time slice. This adds latency.
This is why message passing and CPU dispatching must be well-integrated, or performance is terrible. All the retrofits of IPC to UNIX type kernels seem to suffer from this problem.
Incidentally, MacOS X is based on Mach 2.x, which is a modified BSD kernel with Mach extensions. Mach 3.x, CMU's rewrite and a true microkernel, never really worked very well. But a few pieces of it made it into MacOS X, which gives Apple some Mach 3 bragging rights. But it's not a microkernel. It's a BSD kernel with extensions.
burning CDs and DVDs on some distributions (like Fedora Core)
Is it hard to do that on Red Hat? I haven't used Red Hat recently, but I'm just curious. (Though I personally use Debian) I used mandrake not long ago and it was literally as easy as installing it then running k3b which is as easy to use as Nero - in fact I'd give the crown to Mandrake over WinXP in that respect. In fact all of those things except OCR (which I've never heard of) and modems (which I have no experience of in mandrake) are a breeze. You don't ever have to use the command line.
But anyway, why is Red Hat different burning cd/dvds?
I don't know what Fedora uses to accomplish this (I'm on Debian) but on my system Nautilus handles burning in this manner. It's just as you say: Open the location burn:/// (or something similar) and drag the files there. However, on my system this works with ISO-images too. In fact, then it's even easier, just right click on the ISO and select "Burn image to CD" or something like that.
This is just for data-CDs though, Nautilus doesn't handle music-CDs yet, which is a shame. K3B is ok but I really think it's interface isn't clean enough. It's easy to use but the interface just has a clunky feel IMO.
:wq!
Clearly the Hurd has gone the way of Gentoo and BSD; down the path to oblivion. Surely no one can doubt this now that Linus hath spoken.
I appreciate the software freedom GNU/Linux and other free software grant me; this is the main reason I stick with GNU/Linux and why I advocate its use elsewhere. But there is a lot of room for improvement. I look back over the past 20 years and see all the progress that has been made, so I'm not raising these issues as an alarm. These things can and will be improved. It's about whittling down how they should work and making them work that way (and ignoring the technocrats who want to overburden the situation with a vast array of preferences and tweaks).
What follows is long, but it gives a more complete picture of what I've been through with GNU/Linux and a brief bit about my experience with a couple of non-free OSes. I thought your question deserved a full response.
Installing K3B is not done by default and the name ("K3B") means nothing to someone looking for a CD/DVD burner. If you do install it, you have to run it as root to make it work (obviously a showstopper for a multi-user installation and not a good idea for a single-user laptop or desktop system either). Nautilus tries but doesn't work due to (I'm told) a kernel issue. Nautilus also won't burn a number of CD formats K3B can burn, including audio (which I think a lot of users would want to burn).
OCR is available as free software but isn't shipped in Fedora Core (or Ubuntu, as far as I know). There is another free software OCR program (whose name escapes me at the moment) and it is trainable because it is aimed at reading ancient texts. This approach might be useful to academes, but it is very complex to use for ordinary text one comes across in newspapers and magazines, and it doesn't come with training by default. The interface for both programs are each quite unlike other programs which steepens the learning curve. Right now, OCR doesn't "just work" on GNU/Linux.
Plug and play access to hotplug devices still eludes GNU/Linux for the most part. If I hook up a printer, I want that to be my default printer. Same for modems, fax modems, scanners, joysticks, and anything else I can hotplug. I can get scanning to work when there is only one scanner--plugging in my Epson Perfection 1260 via USB and starting up XSane (with its non-HIG interface) does work on Fedora Core. I am not sure what would happen if I had two or three scanners.
Without significant technical reconfiguration, Fedora Core doesn't like USB memory sticks. They don't do the right thing as far as I can tell. Does Mandrake handle multiple USB memory sticks correctly? Or is it really just a hack that isn't exposed until you have more than one plugged in at the same time?
I realize hotplug stuff in general is being worked on and should improve. I'm describing the state of affairs as they are today. I look forward to seeing improvements and paying to see more improvements implemented as free software.
The last time I tried Mandrake it couldn't get my printer (a Brother HL-1270N connected via ethernet) working and the install screen offered absolutely no help. Mandrake also made a user login for me that I couldn't actually log into and use. I had to use root for everything and even then many things were obviously screwed up by default so I couldn't get jobs done which I knew other GNU/Linux distributions could do with ease. I switched back to Fedora Core. I'll try Mandrake again later, when I can see someone else's installation doing things I want to do with no reconfiguration at the command line.
Documentation to fix these things is often non-existant ("Read the source, Luke") or geared at the technical user (man pages with lots of references to things that are never introduced, or man pages for programming add-on software). I have yet to get Samba working well, for instance, because the interface to doing this is too clumsy and the docs are quite poor. I'm making my way through one of those Samba in 24 hour books. I'm told NFS is a pain to keep going and yet GNU/Linux offers no simple disk and printer sharing n
Digital Citizen