Some good points

Story: Fork a kernel, kill an "OS" and revolutionize the desktopTotal Replies: 28
Author Content
tracyanne

Jul 25, 2007
7:39 PM EDT
I'd love to have a Linux Desktop that performed the way I would like a desktop to perform. Desktop performance may indeed be "unquantifiable" as Con Kolivas has been told by other kernel developers, but from a desktop users view point I can see a number of issues that I put down to a poor threading model. Things like application windows not being refreshed properly - There are time when, for example, I'm waiting for a long running (1 or 2 minutes) process to complete I can clear the contents of a window, and it will not rewrite those contents for some period of time.

Personally I don't give a rats how blazingly fast a Linux box is on the server. I want a responsive desktop. The sorts of things that really annoy me never happen on a Windows box - any version. I want a kernel that is optimised for desktop use.

Call me a newbie, and if you are a kernel developer, flame the crap out of me, but the things I see wrong with the Linux desktop have not changed in the 5 years I been using Linux.

It's about time they were fixed.
nikkels

Jul 25, 2007
11:35 PM EDT
I seem to agree with above
gus3

Jul 25, 2007
11:49 PM EDT
Quoting:The sorts of things that really annoy me never happen on a Windows box - any version.
How about "focus-stealing"? I have yet to see a Windows version that didn't clobber menu selections while the desktop was still loading. Uh, hello Redmond? If the system isn't ready for my input, why does it accept part of it and then send me back to square one? Yes, I know it can happen in X, but the window manager can be configured to prevent it; AFAIK it's impossible to prohibit in Windows.

As for desktop stuttering, I can show you a couple XP systems where I work that stutter horribly when the hard drive is active (probably for swapping).

Regarding a general fix, have you done "hdparm -u 1" for the swap drive(s)? It allows the system to do other things while swap I/O is working. Not perfect, but better. Distros don't usually enable it by default, due to the man page warning: "this is dangerous!" And I agree, better safe than sorry for "what everyone gets," but I'll use it for "what I use."

As a specific fix, do you re-compile kernels with the 1KHz fully-preemptible options set? (CONFIG_HZ_1000, CONFIG_PREEMPT, and CONFIG_PREEMPT_BKL all set) Using those options makes visible differences on my desktop behavior: no mouse stuttering, and windows re-draw steadily (although sometimes more slowly under test load, as expected).

Your points are valid. Ignore the flames. And, if you find some setting or knob that seems to unleash your system, please let us know!
tracyanne

Jul 25, 2007
11:55 PM EDT
Quoting:How about "focus-stealing"? I have yet to see a Windows version that didn't clobber menu selections


That happens to be one of the many things that I find annoying on a windows box.

So what, I want my Linux box to not to do the things that a good desktop should not do. And I don't want it to to do crappy things that never happen, or rarely happen on a windows box.

You can come up with all sorts of corner cases for wonky things that happen on Windows that also happen on Linux, but for must desktop operations those things simply don't happen on Windows, whereas they are the norm on Linux. I don't want those things to be normal operation on Linux. I simply don't care if they happen to occur in a small number or evn a large number of instances on Windows, the fact is for most desktop use Windows is very responsive, where Linux is not.
jacog

Jul 26, 2007
12:04 AM EDT
Agreed. I have hope for KDE 4 though.
tracyanne

Jul 26, 2007
12:31 AM EDT
KDE 4 may have some improvements, but Con Kolivas' issues are related to how the kernel affects the responsiveness of the desktop, and what needs to be done to fix that. So I can't see KDE 4 or GNOME 3 or whatever really fixing the root of the problem, anything done at the GUI level is still going to depend on how the kernel prioritises work.
dinotrac

Jul 26, 2007
3:48 AM EDT
tracyanne -

Yup.

I suspect, however, that KDE has enough problems that KDE 4 will make noticeable improvements.

Will also be interesting to see how the new completely fair scheduler works. Too bad the kernel wonks are too important to do silly thinks like write nice documentation. That is one of the things that a real company with real clients can force a developer to do -- or at least take part in -- to get an important idea through a thick and contentious skull. IOW, ok, this is so great and I'm so wrong, you provide me with directions for getting my desktop to work as well as Windows or the Mac.
Libervis

Jul 26, 2007
4:24 AM EDT
The Free Software Desktop should not work as well as Windows or the Mac. It should work a whole lot better, and faster. That's the whole point. GNU/Linux is pretty much still stuck with the rest. We have a lot more choice, a lot more freedom, a lot more reliability, security and maybe a bit more performance. But it shouldn't be just good enough.

Reading CK I really got the impression which I don't usually have, that the computer world is pretty much screwed up. And that's because of lack of choices and diversity and the monopoly of Microsoft which pretty much standardized mediocrity. This is why we still, almost naturally, put up with performance issues on hardware which shouldn't know what a performance issue is. We get all happy about GNU/Linux for being so much better as if it's really a technical revolution. But it's not that. It's a social and ideological revolution (Free Software), but our OS isn't technically all that much different than others.

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. GNU/Linux just isn't there, and talking about these performance figures, it doesn't seem like it ever will be.
hkwint

Jul 26, 2007
4:35 AM EDT
Quoting:And that's because of lack of choices and diversity and the monopoly of Microsoft which pretty much standardized mediocrity.


We can't blame Microsoft for Linus&co not wanting to give us the choice between CK (designed for desktop use _ONLY_) and CFS (designed for everything), do we? Because it is actually Linus himself who is stopping CK from being a choice for the mainstream Linux-users, even though CK patches exist since back to Linux-2.4. Actually, it seems Linus isn't any better than the bosses of MS when it comes to not giving users a choice, and limiting their users.

What I'm intending to say is, if there were enough choices (for the users to make) in the Linux kernel to optimize it for desktop or, in contrary, for the server, we probably wouldn't need a fork, only the kernel config would need to be forked towards servers or desktops. Though the idea of a desktop-fork of the Linux kernel sounds nice, I think it would be better not to fragment the (already fragmented) Linux-kernel development team any further; or is that just me?

ED: Uhm, well, rereading the above, it seems more a utopia than real world.
dinotrac

Jul 26, 2007
5:29 AM EDT
>ED: Uhm, well, rereading the above, it seems more a utopia than real world.

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?
Sander_Marechal

Jul 26, 2007
7:24 AM EDT
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.
dinotrac

Jul 26, 2007
7:50 AM EDT
>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.



jsusanka

Jul 26, 2007
10:32 AM EDT
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.
NoDough

Jul 26, 2007
10:40 AM EDT
jsusanka:

So which one is fully preemptable?
acrider

Jul 26, 2007
10:55 AM EDT
> 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.
dinotrac

Jul 26, 2007
11:11 AM EDT
>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."
tracyanne

Jul 26, 2007
1:24 PM EDT
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.
Sander_Marechal

Jul 26, 2007
1:40 PM EDT
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.
herzeleid

Jul 26, 2007
2:02 PM EDT
Quoting: jsusanka: "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.
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...
dinotrac

Jul 26, 2007
3:33 PM EDT
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.
jsusanka

Jul 26, 2007
3:55 PM EDT
"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."

gus3

Jul 26, 2007
9:29 PM EDT
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.
tuxchick

Jul 26, 2007
9:57 PM EDT
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.
Steven_Rosenber

Jul 26, 2007
10:43 PM EDT
Instant boot is a killer app. If my Palm Tungsten E can do it, why not my desktop and laptop?
gus3

Jul 27, 2007
1:46 AM EDT
"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.
hkwint

Jul 27, 2007
1:56 AM EDT
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.
Steven_Rosenber

Jul 27, 2007
9:10 AM EDT
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.
gus3

Jul 27, 2007
9:58 AM EDT
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.
Bob_Robertson

Jul 27, 2007
11:59 AM EDT
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.

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!