Linus on All Sorts of Stuff 339
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. "
Hurd (Score:5, Interesting)
Re:Hurd (Score:3, Funny)
Re:Hurd (Score:5, Informative)
I.e. it might be fun to play with, but it's not very useful for the average Joe.
Re:Hurd (Score:5, Insightful)
Re:Hurd (Score:5, Insightful)
Re:Hurd (Score:3, Insightful)
Or running servers. Web servers, print servers, file servers... heck, it might even work for supercomputers for all I know.
Re:Hurd (Score:3, Informative)
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.
Re:Some jobs are still too hard to do on GNU/Linux (Score:3, Informative)
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 br
Re:Some jobs are still too hard to do on GNU/Linux (Score:3, Insightful)
No, you can install k3b on redhat fedora core and burn away, but knowing that k3b is as easy to use as Nero, or even EXISTS is harder on Linux than Windows if for no other reason than the fact that you can't just go to the store and see all the cd burning software available, and buy what you need. Most CD burners come with some kind of burning software for Windows, but not for Linux. If I was a "user" with a new CD burner in my machine that runs Linux, being able to bu
Re:Some jobs are still too hard to do on GNU/Linux (Score:3, Informative)
I don't know what Fedora uses to accomplish this (I'm on Debian) but on my system Nautilus handles burning in th
Re:Some jobs are still too hard to do on GNU/Linux (Score:3, Informative)
Re:Hurd (Score:2)
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?
Re:Hurd (Score:5, Interesting)
Re:Hurd (Score:2, Informative)
It appears so [gnu.org].
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.
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.
Re:Hurd (Score:3, Informative)
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.
Re:Hurd (Score:3, Insightful)
I.e. it might be fun to play with, but it's not very useful for the average Joe.
Well, Linux started out as something barely usable even to hardcore geeks (kermit was the most complex application for a good while), and look what it turned into.
Re:Hurd (Score:3, Informative)
> 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.
Re:Hurd (Score:4, Funny)
Re:Hurd (Score:5, Interesting)
Flumotion? (Score:3, Funny)
*achoo!*
Cheers
Stor
My opinion (Score:3, Funny)
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.
Re:About to be /.'ed (Score:5, Informative)
Um, no [swbell.net] (third paragraph).
GNU/HURD (Score:5, Funny)
Re:GNU/HURD (Score:5, Funny)
Re:GNU/HURD (Score:2, Funny)
Re:GNU/HURD (Score:5, Funny)
Re:GNU/HURD (Score:3, Interesting)
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 actua
Re:GNU/HURD (Score:3, Funny)
Now I understand. Of course, that slows down development a lot, because idealism is rarely found these days. Probably the FSF has only outdated versions of idealism, running on old hardware where each compile needs aeons. Maybe they should rewrite the system to run on some more popular platform.
Probably you had an incompatible version of idealism. Actually idealism suffered from many different versions, having differences ranging from subtle to large. Th
Large software projects... (Score:3, Insightful)
Who is - (Score:2, Offtopic)
-thewldisntenuff
Non-profit (Score:2, Insightful)
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:2)
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.
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.
Re:I've always liked Linus... (Score:3, Interesting)
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 ma
Linus on what stuff? (Score:4, Funny)
I, for one, would have welcome our new Linus-run overlord stuff.
^_^
Re:Linus on what stuff? (Score:2)
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.
hmm.. (Score:3, Interesting)
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
Re:hmm.. (Score:3, Insightful)
"Infrastructure" (Score:5, Funny)
Heh, "provides some infrastructure" ??
Such a sweet deal would normally make one wonder...
Re:"Infrastructure" (Score:5, Funny)
Insigtful (Score:2, Insightful)
Of course, there are other [microsoft.com] public [georgewbush.com] figures [welovethei...nister.com] whose statements make a lot less sense; being deceptive rather than insigtful.
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.
Comment removed (Score:5, Insightful)
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."
Re:Words of Wisdom (Score:3, Interesting)
The 3D engine is a great example. Let's say you're a game company creating two 3D games at once. One game is a board game with a few 3D animations, the other is an immersive 3D experience. Do you develop an engine cap
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?
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.
Re:FSF doesn't rush anything, so chill. :) (Score:3, Interesting)
Anyone else hate... (Score:4, Funny)
the kernel is so far from mature, sigh (Score:3, Interesting)
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.
Re:the kernel is so far from mature, sigh (Score:3, Insightful)
So, what are you/the researchers waiting for? Fork it already and get busy. Linus ain't stupid, he'll put your patches/port your changes in if they are good.
Heck, do a good enough job and you could start the 2.7.x series.
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
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)
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.
Moderators on crack strike again. (Score:3, Insightful)
Re:The HURD problem (Score:3, Informative)
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. [apple.com]
Re:The HURD problem (Score:3, Informative)
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
Mach is not that bad (Score:3, Interesting)
Mach used to be bad around 1990 but the things have been patched up
Linus on All Sorts of Stuff (Score:3, Funny)
Hmm (Score:3, Funny)
Re:I'd be curious... (Score:2, Offtopic)
Re:Hurd (Score:2)
Re:Hurd (Score:3, Informative)
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.
Re:Linus isn't really one to talk. (Score:5, Insightful)
Re:Linus isn't really one to talk. (Score:4, Interesting)
This whole comment sounded a lot better in my head.
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.
Re:Linus isn't really one to talk. (Score:3, Interesting)
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
Re:Linus isn't really one to talk. (Score:4, Insightful)
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.
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.
Re:Linus isn't really one to talk. (Score:3, Insightful)
Re:Linus isn't really one to talk. (Score:2)
If it is so hard to change, and so incompatable, why are there so many versions and why are they all called Linux? :)
Re:Linus isn't really one to talk. (Score:3, Insightful)
In the desktop PC space, I can run anything I care to hook up, other than some shitty winprinters. Granted, some features are lacking like 3D accelerators and some multimedia hardware, but if you're careful choosing your stuff, it will work with Linux. I tossed Fedora Core 2 on two new PCs and a laptop, and it just works. I couldn't say that two years ago.
Even my iMac runs YDL with all of my hardware
Re:Linus isn't really one to talk. (Score:2)
Well, yes AND no. iMac != iBook != Powerbook != G5 Tower
It's gotten a lot better recently, but every new Mac model has new chips and architecture that need addressed. Granted, Apple knows what they are and includes the necessary drivers with each new OS disc once a machine comes out, but a machine released with (for example) 10.3.2 would almost certainly not be able to accept anything before
Re:Linus isn't really one to talk. (Score:3, Informative)
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
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.
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.
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.
Re:Linus isn't really one to talk. (Score:2, Informative)
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
Re:Linus isn't really one to talk. (Score:2, Informative)
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.
Linux hardware support, etc. (Score:3, Insightful)
Puzzling statement to say the least. I find the opposite is true. For example, Linux support for scanners is broader than that of Windows 2000 and XP (Linux is better with legacy devices). Linux support of 64-bit hardware is also more mature (where is Microsoft now on that front?). Mac OS X? That one floored me. Mac OS can be kludged into running on other platforms I guess, but it
Re:Linus isn't really one to talk. (Score:3, Interesting)
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
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?
Re:And Linus sayeth "I think Hurd is dead." (Score:3, Informative)