- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Fork a kernel, kill an "OS" and revolutionize the desktop
|
|
|
Comments (32)
Some good points
9 earlier comments in the full thread.
Quoting:This is why we still, almost naturally, put up with performance issues on hardware which shouldn't know what a performance issue is.
Not really. The biggest cause in the Deskop scene over the last 3 decades is that we keep shifting to higher level languages and libraries. We came from ASM through C, C++, a whole host of libraries and now we're up to managed and interpreted code. Each step means trading in raw speed for ease of use, better coding, faster development, maintainability, etcetera.
If you want your speed back, start porting applications from Python to C. Start cutting large and easy libraries of favour of smaller, more bare-metal libraries, etcetera. But no-one does that. Because everybody knows that in two years time the hardware will have caught up (and they all conveniently ignore that in two years time we'll be using even more high level code).
Perhaps the current desktop "feel" is simply an equilibrium, a sweet spot, between speed and ease of development. Perhaps that is why desktops never get any faster. All the speed improvements of the hardware get absorbed by more functions and higher level code.
>If you want your speed back, start porting applications from Python to C. Start cutting large and easy libraries of favour of smaller, more bare-metal libraries, etcetera.
Ummm....
It's ok to mix and match languages -- especially when you have areas that are less performance intense. Lots of GUI stuff essentially just calls a method. The call doesn't need to be that tight (though tighter is better) if the underlying method is itself efficient.
GNOME is built on C libraries, KDE is built on C++. Other desktops use libraries at about the same level.
My first Windows box was 386SX running at 25mz. It was reasonably snappy. It did not have a fancy graphics processor. Modern boxes, when you account for architecture and speed changes -- are something on the order of 200 times more powerful -- or more, and that's not even accounting for dual-core machines. That much extra power should be able to swallow executables from today's compilers and breeze through a little bit of interpreted "stitching" code.
If, however, you wish to lay the problem at the feed of the developers who write the stuff, I won't object unless you seek to exclude the kernel developers.
Ummm....
It's ok to mix and match languages -- especially when you have areas that are less performance intense. Lots of GUI stuff essentially just calls a method. The call doesn't need to be that tight (though tighter is better) if the underlying method is itself efficient.
GNOME is built on C libraries, KDE is built on C++. Other desktops use libraries at about the same level.
My first Windows box was 386SX running at 25mz. It was reasonably snappy. It did not have a fancy graphics processor. Modern boxes, when you account for architecture and speed changes -- are something on the order of 200 times more powerful -- or more, and that's not even accounting for dual-core machines. That much extra power should be able to swallow executables from today's compilers and breeze through a little bit of interpreted "stitching" code.
If, however, you wish to lay the problem at the feed of the developers who write the stuff, I won't object unless you seek to exclude the kernel developers.
fyi
"As a specific fix, do you re-compile kernels with the 1KHz fully-preemptible options set?"
this is one of the diferences between the ubuntu live desktop cd and the ubuntu server cd.
"As a specific fix, do you re-compile kernels with the 1KHz fully-preemptible options set?"
this is one of the diferences between the ubuntu live desktop cd and the ubuntu server cd.
jsusanka:
So which one is fully preemptable?
So which one is fully preemptable?
> My first Windows box was 386SX running at 25mz. It was reasonably snappy.
But look at the size of executables then and now. The first version of Microsoft Office I ever had to use (from 1993) installed from a few floppies and required a few megabytes of disk space (I don't remember the size, but the machine I installed it on only had a 40MB hard drive). Current versions install from a full CD and the version on my work computer takes over 580 MB of disk space, and in my opinion don't really provide that many more useful features other than being able to handle larger documents. So basically, all of the performance gains made available by Intel and AMD have been negated by the code bloat from Microsoft and others.
And Linux hasn't been immune to that. My first Linux installation in 1994 was Slackware from about 40 floppies and I had what seemed like lots of disk space still available after setting up a dual boot configuration (DOS 6/Windows 3.1 and Slackware) on a 1GB drive. A popular distribution today, such as Ubuntu, requires a lot more space.
As suggested above, maybe we have found something close to an equilibrium where the vast majority of users don't care/won't notice if performance improves any further. And those of us who would like better performance are going to have to accept the status quo or get more involved in developing those improvements.
But look at the size of executables then and now. The first version of Microsoft Office I ever had to use (from 1993) installed from a few floppies and required a few megabytes of disk space (I don't remember the size, but the machine I installed it on only had a 40MB hard drive). Current versions install from a full CD and the version on my work computer takes over 580 MB of disk space, and in my opinion don't really provide that many more useful features other than being able to handle larger documents. So basically, all of the performance gains made available by Intel and AMD have been negated by the code bloat from Microsoft and others.
And Linux hasn't been immune to that. My first Linux installation in 1994 was Slackware from about 40 floppies and I had what seemed like lots of disk space still available after setting up a dual boot configuration (DOS 6/Windows 3.1 and Slackware) on a 1GB drive. A popular distribution today, such as Ubuntu, requires a lot more space.
As suggested above, maybe we have found something close to an equilibrium where the vast majority of users don't care/won't notice if performance improves any further. And those of us who would like better performance are going to have to accept the status quo or get more involved in developing those improvements.
>But look at the size of executables then and now.
I am painfully aware of the difference. Like I said, if you want to point fingers at developers, I won't stop you. I just think the use of higher-order languages is a sufficient explanation for the problem...
Unless you consider OO-itis to be a problem of choosing OO languages like C++. By OO-itis, I mean the tendency of developers to get clever with OO at the expense of the user's runtime experience --- you know what I mean: "Hey, the Moore's law will buy us out."
I am painfully aware of the difference. Like I said, if you want to point fingers at developers, I won't stop you. I just think the use of higher-order languages is a sufficient explanation for the problem...
Unless you consider OO-itis to be a problem of choosing OO languages like C++. By OO-itis, I mean the tendency of developers to get clever with OO at the expense of the user's runtime experience --- you know what I mean: "Hey, the Moore's law will buy us out."
Quoting:I just think the use of higher-order languages is a sufficient explanation for the problem...
It's not.
Higher order languages don't introduce all that much inefficiency (not enough that any person would notice), in most cases they compile close enough to metal that the difference is moot. In addition interpreted languages don't have all that much overhead, when was the last time you saw a well written VB6 application, or a VB.NET application on Windows fail to refresh it's GUI after you've dragged another window across it. I can tell it's very vary rare.
The problem is not language related. The problem is the paradigm the current kernel is optimised to for, and that's server processes. Desktop applications and GUI threads are simply not given the same weight as server threads. In fact on a desktop they should be given greater weight, as it's the users experience that matters far more than some lightning fast backend process.
Quoting:GNOME is built on C libraries, KDE is built on C++. Other desktops use libraries at about the same level.
But they are still layering library on library. Abstraction over abstraction. KDE4 has turned building spekkoek (http://en.wikipedia.org/wiki/Spekkoek) applications into an art form. Take phonon for example. It's an abstraction sitting on e.g. Gsteamer, which in turn sits on ALSA or OSS. And you bet that the application that actually uses phonon puts at least one other layer on top, maybe even more (e.g. applications that are not targetted at KDE specifically). And each of these layers is really two layers: the framework and the back-end that's plugged into it.
That's actually my main beef with KDE4. I like where they are going and it's going to be a big improvement, but they're trying to solve all their problems by cramming more abstraction layers between the application and the bare metal. And every call made will require some extra processing for each abstraction or layer it passes through. Sure, it's minimal. But it adds up.
The quickest way to performance boosts on the desktop is to stop adding layers or even to start removing them. If you need functionality that a library does not provide, don't add a layer to the cake but fold it into the library. I.e. send it upstream. It's open source. We can do that :-) And if upstream doesn't want to help out you can always patch the library yourself and link it statically. Free Software allows that too :-)
Quoting:If, however, you wish to lay the problem at the feed of the developers who write the stuff, I won't object unless you seek to exclude the kernel developers.
I'm not seeking to exclude kernel devs. It's a simple matter that I know nothing about the kernel's internals to comment about it effectively. I simply know userland better. The kernel devs do seem to suffer from some "layeritis" too. There was a thread on KernelTrap about how they wanted to add some API's to allow device drivers to be run in userspace. They thought more people would work on drivers if they could e.g. use Python. Python! The madness!
I think this layeritis patrly comes from the Unix mentality that a program should do only one thing, and one thing well. And that you create bigger things by putting all those small things together. That's nice for applications that you don't want to build on top of much, but not so good in the library department IMHO.
Quoting: jsusanka: "As a specific fix, do you re-compile kernels with the 1KHz fully-preemptible options set?"ubuntu does that for the desktop? if so, I'll have to check it out in more detail - I have a test box at home all ready. Maybe all the folks praising ubuntu's snappiness are onto something...
this is one of the diferences between the ubuntu live desktop cd and the ubuntu server cd.
Sander -
Sounds like you and I actually agree and that I misunderstood what you were saying. I thought you were laying more of the blame at the feet of high-level languages rather than the people who abuse them.
My bad.
Sounds like you and I actually agree and that I misunderstood what you were saying. I thought you were laying more of the blame at the feet of high-level languages rather than the people who abuse them.
My bad.
"jsusanka:
So which one is fully preemptable?"
From the official ubuntu book that I bought when LTS came out on page 151 it says:
"What makes Ubuntu Server a server platform?
The most significant difference is a non-preemptible server kernel with an internal kernel time frequency of 100 Hz instead of the desktop default of 1 kHz."
So which one is fully preemptable?"
From the official ubuntu book that I bought when LTS came out on page 151 it says:
"What makes Ubuntu Server a server platform?
The most significant difference is a non-preemptible server kernel with an internal kernel time frequency of 100 Hz instead of the desktop default of 1 kHz."
Quoting:Wouldn't it be nice for a Free Software world to suddenly churn out an OS which would end up being a paradigm shifter, so to speak, a wonder that noone ever imagined before except people like CK? Booting up in few seconds. Starting OpenOffice in less than a second. Audio and video real time processing working flawlessly without special configuration... etc.You mean like EROS? It had process persistence via a checkpoint-based VM copying to disk, so that something like a power failure would lose only a few seconds' work. You didn't "exit" a program, you merely "stopped" it. Therefore, you didn't "launch" a program, you "re-started" it. It had lots of other features, but it was amazingly recoverable.
It's the little things that matter the most to users. Like instant on and off instead of having a lengthy boot process. A lot of folks just want to fire up a computer quickly, balance their checkbooks or check email or hit a couple of websites, then turn it off and go do something else. I've long felt that something like a small, inexpensive, lightweight laptop with a normal keyboard and with limited functionality would be a big hit. The sticking point has been price, since the hardware hits a certain floor and can't go below that. Now we have the OLPC showing the way and causing much desire, so perhaps it will yet happen, though it seems there is a fossilized industry mind-set towards bigger, more powerful, and more expensive, but not delivering a more satisfying user experience.
Instant boot is a killer app. If my Palm Tungsten E can do it, why not my desktop and laptop?
"Suspend-to-swap" isn't quite instant-boot, but it's darn close.
However, Steven, your Palm Tungsten E gets its quick boot from two things, and one of them is a cheat.
First, it has fewer resources to validate, and those resources are fairly tightly controlled by the manufacturer. Apple's Macintosh gets a boost in POST speed from similar rigid controls.
Second, when you turn on your Palm, you aren't booting it, but rather waking from low-power sleep (suspend-to-RAM). The CPU may have halted, but it is still enabled and capable of receiving an interrupt, which is exactly what happens when you press the Power button. Corrupt application context from your previous session is still present, even if it isn't visible. The surest way to clean it out is with a true hardware reset (incl. the CPU), and that's where you see your actual boot time.
Finally, a general observation: Boot time for Windows is such a critical factor, because Windows has to be re-booted so often. There are still some normal maintenance/update procedures in Windows XP which *require* a re-boot. Isn't Linux considerably different in this regard? With such better stability, isn't Linux going to lose less productive time to the boot process? In other words,
In Linux: I get the latest nVidia driver I exit my desktop session "telinit 3" I update the driver files "telinit 4" (or 5) to start X w/ the new driver
In Windows: I get the latest nVidia driver I update the driver files I click "Yes" to REBOOT
The Linux update does appear more complicated from the user's view, but the reality is the Windows update grinds the system a lot more. Frankly, I'd consider a 20 minute boot time for Linux a small price to pay for the better stability it gives me.
However, Steven, your Palm Tungsten E gets its quick boot from two things, and one of them is a cheat.
First, it has fewer resources to validate, and those resources are fairly tightly controlled by the manufacturer. Apple's Macintosh gets a boost in POST speed from similar rigid controls.
Second, when you turn on your Palm, you aren't booting it, but rather waking from low-power sleep (suspend-to-RAM). The CPU may have halted, but it is still enabled and capable of receiving an interrupt, which is exactly what happens when you press the Power button. Corrupt application context from your previous session is still present, even if it isn't visible. The surest way to clean it out is with a true hardware reset (incl. the CPU), and that's where you see your actual boot time.
Finally, a general observation: Boot time for Windows is such a critical factor, because Windows has to be re-booted so often. There are still some normal maintenance/update procedures in Windows XP which *require* a re-boot. Isn't Linux considerably different in this regard? With such better stability, isn't Linux going to lose less productive time to the boot process? In other words,
In Linux: I get the latest nVidia driver I exit my desktop session "telinit 3" I update the driver files "telinit 4" (or 5) to start X w/ the new driver
In Windows: I get the latest nVidia driver I update the driver files I click "Yes" to REBOOT
The Linux update does appear more complicated from the user's view, but the reality is the Windows update grinds the system a lot more. Frankly, I'd consider a 20 minute boot time for Linux a small price to pay for the better stability it gives me.
Quoting:I thought you were laying more of the blame at the feet of high-level languages rather than the people who abuse them.
That's right, I remember (remember is the wrong word, I wasn't yet born then) Multics, the predecessor to UNIX, was coded in a 'rather high level' language, PLI (C didn't even exist back then).
Quoting:You mean like EROS?
EROS is dead. Long live (its successor) CoyotoOS! ( http://www.coyotos.org ) Actually, the most important thing about EROS/CoyotOS as I understand, is 'provable' security. One of the most important thing software lacks these days.
When talking about paradigm shifting OS, we sure might not forget Inferno. From what I read, Linux, Windows and Mac all are based on 1960/70s OS principles. Than along came Plan9, which took some MULTICS (UNIX) design principles even further. However, as I understand, plan9 sucked, which is why they invented Inferno OS in the 90's. Inferno works using 'only one layer', the virtual machine layer. This virtual machine can run native on a PC (without host operating system), but can also use Linux, Mac, BSD, Windows as a host. There's even a VM which is a plugin for IExplorer! On top of this, byte-compiled code runs.
In my opinion, it just takes a loooong time for new paradigms to reach the consumers. Look at how long it took for MULTICS (UNIX) paradigms to reach the (Linux) consumers; more than 20 years if you'd ask me. It might sound strange, but if you'd ask me, software, and especially OS design, is a very conservative non-innovative business.
Suspend to swap, suspend to RAM, however they do it, if it can be done with the low-power requirements of a Palm handheld, I think this should be standard on desktops and laptops.
In my shop here, I shut down the Linux box AND the Windows XP box every night. But most people keep their machines running 24/7 and rarely if ever reboot. In this regard, XP seems pretty stable. Our proprietary client software (Unisys Hermes) crashes between two and six times a day, but at least it doesn't take the whole OS with it (like in the Windows 98 days). All you have to do is restart the app. I'd rather it didn't crash, but it does. It's more due to poor app design than anything inherent in the OS. I'd try to run it under Wine, but I don't have install discs.
I suspect that XP's sleep mode is pretty good as far as power saving goes. What I'd like my Linux distros to do is spin down the drive. It may be more a function of hardware than software, but I have yet to see that feature work on my equipment.
In my shop here, I shut down the Linux box AND the Windows XP box every night. But most people keep their machines running 24/7 and rarely if ever reboot. In this regard, XP seems pretty stable. Our proprietary client software (Unisys Hermes) crashes between two and six times a day, but at least it doesn't take the whole OS with it (like in the Windows 98 days). All you have to do is restart the app. I'd rather it didn't crash, but it does. It's more due to poor app design than anything inherent in the OS. I'd try to run it under Wine, but I don't have install discs.
I suspect that XP's sleep mode is pretty good as far as power saving goes. What I'd like my Linux distros to do is spin down the drive. It may be more a function of hardware than software, but I have yet to see that feature work on my equipment.
Steven, the help you want is in hdparm(8), under the -S option. Also, try enabling laptop mode ('echo 1 > /proc/sys/vm/laptop_mode'). This makes the kernel less aggressive about flushing buffers and swapping, allowing the hard drive to stay idle longer.
One thing that CK completely messed up was his assertion that x86 hardware was a bottleneck to innovation.
I guess he never noticed how well Linux runs on SPARC hardware. Or M68000.
Really, really well. If I could _afford_ a multi-CPU SPARC system, I would.
I've installed Debian through the serial port on a SPARC, no graphics card installed at all, and even with a single 50MHz CPU it responded better than a 350MHz x86 laptop. But I was also requiring it to do different things.
Look at the prices for SPARC hardware on Ebay and elsewhere. I'm not the only one that knows this is wonderful stuff. Maybe CK should spend a little of his hobby time making OpenSPARC, LinuxBOOT and the Open video systems a reality.
That said, what we demand of our systems has changed. My first Linux install was on a 386-33 with 16MB Ram and a 100MB disk drive. Oh, and a CD-ROM linked through the Sound Blaster card. I'm sure someone here still has one in their garage.
The kernel booted so slowly on that machine that I could read and comprehend the entire boot sequence, one line at a time, in real time as it came up. But I was thrilled with 1024x768x16 graphics on a 4MB graphics card.
That same system had run WingCommander Privateer quite well, while the 2.8GHz hardware accelerated wunderlaptop I'm on now has its cooling fan on full blast when playing Vendetta, a game substantially similar to what Privateer was 13 years ago. Just a _LOT_ prettier and smoother.
But that is what people want.
The kernel is bloated, because it is asked to do more. The applications are bloated, because people demand features while only complaining about binary size. If they demanded small binaries rather than features, that is what would be produced.
I guess he never noticed how well Linux runs on SPARC hardware. Or M68000.
Really, really well. If I could _afford_ a multi-CPU SPARC system, I would.
I've installed Debian through the serial port on a SPARC, no graphics card installed at all, and even with a single 50MHz CPU it responded better than a 350MHz x86 laptop. But I was also requiring it to do different things.
Look at the prices for SPARC hardware on Ebay and elsewhere. I'm not the only one that knows this is wonderful stuff. Maybe CK should spend a little of his hobby time making OpenSPARC, LinuxBOOT and the Open video systems a reality.
That said, what we demand of our systems has changed. My first Linux install was on a 386-33 with 16MB Ram and a 100MB disk drive. Oh, and a CD-ROM linked through the Sound Blaster card. I'm sure someone here still has one in their garage.
The kernel booted so slowly on that machine that I could read and comprehend the entire boot sequence, one line at a time, in real time as it came up. But I was thrilled with 1024x768x16 graphics on a 4MB graphics card.
That same system had run WingCommander Privateer quite well, while the 2.8GHz hardware accelerated wunderlaptop I'm on now has its cooling fan on full blast when playing Vendetta, a game substantially similar to what Privateer was 13 years ago. Just a _LOT_ prettier and smoother.
But that is what people want.
The kernel is bloated, because it is asked to do more. The applications are bloated, because people demand features while only complaining about binary size. If they demanded small binaries rather than features, that is what would be produced.
Desktop Linux? Stick a Fork in It!
Quoting:On one side, you have Linus Torvalds and his true Linux "geekerati" underlings. These guys are mostly concerned with promoting Linux within the enterprise - i.e. Projects involving lots of parallel CPUs, massive storage and high-end TPC results. On the other side you have guys like Con who made it their mission to bring Linux on par with Windows and Mac OS X in the desktop arena. Things like smooth playback of digital content and better memory management for interactive users are what fuel their inner Linux fires.http://weblog.infoworld.com/enterprisedesktop/archives/2007/...
Con stood out from this crowd because he did more than just complain about the jittery video and sluggish virtual memory behavior of Linux. He actually went out and wrote patches for the Linux kernel that helped address these issues, for example, by altering the core scheduling algorithms to favor interactive tasks (like audio or video playback). These patches proved to be real lifesavers for users seeking a better desktop experience under Linux, and Con quickly gained a strong following within this particular sub-community.
InfoWorld isn't really on the ball, are they? That's quite an old story.
Yeah we've all had our say on it already.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
I don't know. We have a very configurable kernel, both at compile time and at run-time. We have patches that suit desktop users. How utopian is it to ask that a build or run-time process (I don't even care which) give desktop users the freedom to select a desktop-optimized kernel?