Slashdot Mirror
Linus Torvalds Speaks Out on Future of Linux
SlinkySausage writes "Linus Torvalds has laid out his plans for the future of Linux, including the 3.0 kernel [there probably won't be one], problems with the Linux release cycles and which distro he personally runs on his home PC. '"Compile everything by hand" ones simply weren't interesting to me,' Torvalds says."
already slashdoted
Debian has apt-build if you really want to waste your time manually compiling stuff...
apt-get install apt-build; man apt-build
Peace sells, but who's buying?
http://apcmag.com.nyud.net/7012/linus_torvalds_tal ks_about
Linus Torvalds, creator of the Linux kernel, has, along with others like Richard Stallman, literally changed the world of software forever.
;)
Linux-based distributions seem to pop up every day, more and more devices now run Linux at their core, from mobile phones to inflight entertainment systems, to the world's mission critical server infrastructures.
The development of the kernel has changed, and Linux is just getting better and better. However, with a community as large and fractured as the Linux community, it can sometimes be hard to get a big picture overview of where Linux is going: what's happening with kernel version 2.6? Will there be a version 3.0? What has Linus been up to lately? What does he get up to in his spare time?
I had the opportunity to chat with the original creator of the Linux kernel, Linus Torvalds, in a number of email exchanges.
APC: Writing an operating system kernel is a hard job. Why did you write Linux in the first place?
LT: Kernels may be hard, but partly because of that they are also interesting. I've always been more interested in "down to the hardware" details than in fluffy stuff like user interfaces etc, and an operating system kernel is about as down to the hardware as you can get without actually building it yourself (which I've also done - I was at a CPU company for seven years, after all). So I'm not into soldering irons etc, but I very much enjoy working at a low level, and thinking about how my software actually interacts with the CPU and other parts of the system. Besides, I really didn't realize how hard it would be. I really never expected to be still working on it 15+ years later
APC: What's the Linux Foundation?
LT: Heh. I just work here, you should ask some of the people who are actually involved in all the other things that LF does. It's basically the combination of OSDL ("Open Source Development Labs") and FSG ("Free Standards Group"), and is a vendor-neutral place for different organizations to discuss the issues they have, and trying to help Linux along. Part of what LF does is pay me to maintain the kernel.
APC: What are you doing with the kernel now? Are you working on it full time? What parts of it do you work on the most?
LT: I very much work on it full time, but I no longer really work on any particular "part"of it - I end up spending almost all my time on not writing kernel code myself, but on working with the flow of code and merging it all.
In fact, the biggest amount of actual source code I've written in the last two years is not in the kernel itself, but in the tool I use to just track the kernel development (called "git" - a source control management system).
So I still get to write code (and I send out suggested patches quite often - but usually they are along the lines of "so here's how we could handle this issue..." in order to prod others to actually do the final patch and testing). But what I do a lot more is go through other peoples changes and say "yes" or "no".
APC: The 2.6 series kernel has been around for a long time. Why?
LT: We used to have these big and painful development releases that took several years, and it worked reasonably well and people got very used to it ("2. is stable, 2. is development"), but it had serious downsides too.
In particular, the release cycles were so long that all the commercial vendors effectively had to back-port a fair amount of new code from the development kernels, and so development code ended up in the stable releases. Also, conversely, the vendors fixed problems in the stable versions, and sometimes the fixes were missed or weren't easy to then forward-port to the development series, because the two were just very far apart.
Basically, a multi-year development cycle simply doesn't work. It was reasonable and required for a while (we did some pretty radical changes there too), but with 2.6, the base kernel is in good shape, and we've improved our development process enough that we just don
here http://apcmag.com.nyud.net/7012/linus_torvalds_tal ks_about
p.
Linux doesn't have a GUI, dude. You should read about Linux more, and write about it less.
Linus is the creator of, and remains deeply involved with the development of the Linux operating system kernel. "The GUI" isn't his concern. (Though providing the underlying services to support it is.)
Also, I don't think Linus much cares about Linux being "mainstream". He just wants it to be the best!
-Peter
With the new gcc I think 4.2 -march=native does what you want.
https://www.fsf.org/associate/support_freedom
If Intel adds more or wider SSE registers or otherwise adds to or changes the thread specific state, the context switcher in the kernel will have to be updated to support that.
Hetrogenous cores could also cause changes to the scheduler -- ie having a small number of OOO cores, and a larger number of in order cores -- some threads will run better on one type of core than another.
But for the most part, he's probably right -- the days of rapid large scale architectural changes to the kernel are over.
Ian Ameline
"Run a compiled KDE/OpenOffice system from gentoo with the appropriate flags for your CPU in make.conf
Compare the performance to the pre-compiled Gentoo, Fedora, or Ubuntu performance
The taste (err, performance) is a lot better with the compiled yourself. And you don't get asked 40-50 questions, or if you do, you forgot to set batch mode."
I call that BS.
binary packages perform as well as any self compiled code out there. i had the same discussion a couple of years ago, when gentoo was all the rage. i went home, dowloaded the source code of both Glibc and GCC and ran a series of kernel compilations first with Debian's i686 optimized packages of both Glibc and GCC, then ran the same tests this time with athlon optimized packages (my CPU at the time was an athlon Tbird running at 1.4 GHZ). The result was a statiscaly negligible 1% (yes, ONE percent) in favor of the athlon optimized code.
You know why such small diference ? it's because modern CPUs are capable of optimizing the code internally themselves. Anandtech and tom's hardware have lots of articles about how this kind of stuff happens. the point being that you can run pentium-optimized code in an athlon or AMD64 optimized code in an intel 64bit Core 2 without loss of performance.
in other words: compiling the code yourself to get better performance is (in the best penn jillette style) BULLSHIT!!!
Oh, and there's another thing. as a professional syadmin, I always favor vendor compiled packages for stability and support. try convincing a middle manager of a fortune 100 company about the advantages of self compiled code, and he'll be glad to staple a copy of their site-support contract with Sun/IBM/HP/Red Hat/whatever to your pink slip.
big companies loathe this kind of adventure with the code that runs their business. whith their asses on the line, they want someone to fix any mistake quickly and efficiently (and binary packages are waaaay quicker than compiling), and if it doesn't work, they want some external party to blame and pay contractual fees.
welcome to the real word, kid.
What ? Me, worry ?
You're a fucking idiot.
mov eax, 0
CPUID
I hope he was told the truth about Drop Bears and that he was kidding...
Tells you *everything* you want to know (possibly even MORE than you wanted to know). I doubt it, Windows seems to know what type of CPU I have when I go to 'my computer'. When I was using my AMD system I knew that it was a K6 processor type, and I downloaded the appropriate kernel/binaries for it though, surely it's not that difficult to do a bit of googling to find out what processor you have?
bork bork bork!
If you are installing untested software (regardless of distribution) on your production servers, you deserve everything you get. Except when a rogue ebuild borks your system like
bork bork bork!
If you're looking for MIDI recording that generates notation for you in linux, check out Rosegarden. If you know of this program already and don't think it's easy enough to use, my apologies for assuming.
More likely that one of those installs has java disabled. That makes a big difference in startup time.
Sorry, but it's completely impossible that the code optimized for your processor is 400% faster than the non-optimized version on something as general as Openoffice. Most of the time spent loading OO is disk IO anyway.
I don't know how you got your numbers or why they are what they are, but they definitely aren't due to differences in optimization flags to the compiler.
There are many reasons why you would not want the CPU type automatically set; One such reason having been mentioned by another poster (the machine might be a "build machine", so you wouldn't really want everything built for a dual processor, dual core Opteron when you are building for another processor type). It would be nice, now that some folks are putting together a GUI installer for Gentoo, if they added that functionality, though.
You are still failing to understand the build process for Gentoo, though. If I type 'emerge (package', I am never asked any questions. The build options needed are pulled from
To answer your last question, probably not, but I'll counter by telling you that you are worrying about the wrong thing. Anyone wanting to try linux can try Ubuntu or Knoppix. Virtually everything is guessed for them, very few questions asked, many pieces of hardware are detected automatically (and properly, even!), and setup/configured for them. If someone is gung-ho about trying linux, and they *really* want to try Gentoo, then they just need to be prepared to do some things manually (like editing three lines in their make.conf). If they decide they don't want to, then they need to reexamine their priorities. Ok, so my question is:
Why, if this information is available, doesn't the "emerge" pull that info in instead of forcing the user to do it?
Seriously, this is Why Linux is not liked by many, many people. (I really want to get off Windows!)
In the above scenario, a person will be asked a lot of questions unless they put in a "magic" configuration that is readily available by parsing the output of a simple command. Why even ask the user the questions unless the parse of said command fails to return the proper CPU? Am I the only one thinking this?
bork bork bork!
I think the OP was referring to the installation time, and not performance.
No I know. It just seems that since people have claimed that the performance difference is felt most on large complicated pieces of software like OO, you would want to go to the trouble of compiling it.
I just recently switched from Gentoo to Ubuntu, and there was one application in particular that I've noticed a huge speed decrease, and that's eclipse.
Yeah eclipse is a pig on my laptop as well (Debian). I don't know how Ubuntu handles it, but Debian installs a version of eclipse compiled with GCJ by default. Seems backwards, but that version actually seems to run slower than the one that runs on top of the Sun Java VM. I switched to the vm package and it seems better.
But as far as I know, it doesn't. Can you ask it for a list of all USE flags that will get involved in recursive compilation before you start, or get it to prompt you as you go? Because from what I saw, if you didn't know that mpg123 was going to get installed as a deep dependency, you'd never know that you needed to configure for it before you started. FreeBSD won't prompt you up-front, either, but at least it can ask you at each new step in the process.
Dewey, what part of this looks like authorities should be involved?
Uh, if you compile something using -march=athlon-xp and then try to run it an intel procesor, it will likely segfault (intel doesn't have 3dnow for example). There is a big difference in terms of performance between using -march and -mtune. -mtune optimizes it for a certain processor while still making it possible to run on others, by using -march you make it compile for ONLY that processor, any processor-specific registers, ops, etc. are used wherever possible which ends up meaning that it can segfault when running on different processors. So you can compile something with -march=i686 -mtune=athlon-xp if you want it to cater slightly to athlon xp's, but still run on any 686 processor. Many packages are compiled with -march=i686 which makes it fairly fast for any modern processor, but those compiled with -march=i386 -mtune=i686 or some such. . big difference when you switch to -march=athlon-xp. .
Basically for a bit extra effort you can squeeze out more performance out of your box (at the cost of time installing packages), and depending on the package used and what it is normally compiled with, the difference can be huge (I've seen a speedup of ~25% on certain programs just by messing with flags). With gentoo, even "hello world" will get optimized with 3dnow, sse, mmx,etc. if possible. .
If you are about to mod me down, keep in mind that this post was most likely sarcastic.
I've read that thread before and it never really seems to get into microkernel vs. monolithic, it's really more about Andy starting a fight by saying "Linux is losing" and then Linus responding, in his fasion, though most of the skirmishing happens outside of the kernel structure argument.
Linus basically says, "Yeah, it's monolithic, but it provides a complete Unix userland and runs on i386 and is libre." AT's response is "What difference does it make if it's libre if you need this weird 'Intel' chip that no one has to run it, and only the 'elite' has FTP access to download your code!" (this was 1992). Tenebaum is also pretty dubious about Linus being able to "herd 1000 prima donnas" and keep Linux kernel development on track. There's a little sniping over how a monolithic kernel has multithreaded filesystems "for free" and Linus makes a revealing comment about how he thinks message queues are "ugly things" (little remarks like this give you and idea about how much Linus hates the very idea of messaging). His point in the end is that though his kernel was (at the time) not portable, it was quite compatible with any Unix software existing at the time, and that hardware agnosticism wasn't as important as providing a stable and ubiquitous platform.
Don't blame me, I voted for Baltar.
I think you're thinking of the feature flags. that'll just get you things like "GenuineIntel", "AuthenticAMD", or "CyrixInside".
you'd probably want to use:
mov eax, 1
cpuid
and then a whole lot of bit mask comparisons on ebx, ecx, and edx. AMD did another set of extensions to it, so now you have more than 4 valid things to load into eax (0-3), but I forget where they start. mostly, those just give very processor specific oddball features that aren't of much use to anyone except compiler writers and people optimizing operating systems, and the like.
No.
The Tao of math: The numbers you can count are not the real numbers.
Use the new discussion system (D2?) and click on the title of the comment. It collapses and hides all its descendants.
Works for me.
So you're the kind of person that would hate http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/ Gentoo/FreeBSD then?
:)
Suck it down my friend - Gentoo is the meta distro.
Don't like the Linux? Swap it with FreeBSD + libc + userland.
Only x86 atm.
Sparc64 is almost there - FreeBSD 7 should solve the last issues with with Gentoo Toolchain - namely loading kernel modules.
Actually FreeBSD-7 should also enable Gentoo/FreeBSD on all our arches to be viable as FreeBSD-7 is moving to gcc-4.2 as its base compiler.
We also have a few people working on integrating DragonFly, NetBSD and OpenBSD into the Gentoo fold as well.
Gentoo is NOT about CFLAGS
Gentoo is NOT about speed.
Gentoo is just a platform for developers by developers.
At least, that's my take as a Gentoo dev.
If Joe User wants to use Gentoo then more power to him! He may end up a developer
Isn't FreeBSD developed by a committee? It seems to do ok.
Look for some of my postings to xemacs-beta around 1997/1998. I did comparative XEmacs benchmarking with pgcc -vs- stock gcc/stock options and got substantial performance improvements.
I'm certainly willing to believe it's possible - I've been there and done that and posted the results to the world.
It's been years since I've seriously looked at the guts of gcc and whether or not it's significant now, I can't say. My guess is that the work involved in tailoring compiler optimization for a specific flavor of CPU (other than a gross optimization like preferring a specific machine instruction not available on all types) is sufficiently difficult that if the CPU manufacturer doesn't do it, it probably won't be done. My understanding was that the pgcc patch came from Intel, but with the issues it had, I can certainly understand why only portions of it were merged very slowly into the mainline. try convincing a middle manager of a fortune 100 company about the advantages of self compiled code I do not believe that was ever the issue being discussed. Where did enterprise software come in? I do not doubt your credentials only your presentation and it sounds like you have personal issues that it would be in your best interest to resolve.
As much as I liked the performance of code compiled by pgcc -O6, I never let code it compiled touch my production servers. But that wasn't what we were talking about. welcome to the real word, kid. Oh, you must be new here. Do you see those two large keys towards the bottom of your keyboard labeled "shift"? You press them while typing on a letter to get an upper case letter. Upper case letters are best used at the beginning of sentences to demarcate them from other text.
Sorry sir, your post isn't +5 informative as much as it should have been flamebait. Fortunately for you, it seems to be yet another free crack for moderators day.