Why isn't desktop Linux "finished"?

Posted May 2, 2011 8:27 UTC (Mon) by jrn (subscriber, #64214)
In reply to: Why isn't desktop Linux "finished"? by Cato
Parent article: Poettering: Why systemd?

> This isn't an Ubuntu flame, as I'm not sure other distros are any better

I don't know --- have you tried other distro (or other Ubuntu release) livecds? If you are used to Ubuntu LTS and prefer to stick with it, have you tried reporting bugs?

Kernel mode-setting in particular is something where you'll probably find a more up-to-date graphics stack (or one old enough to precede kernel mode-setting altogether) works better. Finding the right fixes to backport to an old graphics stack can be hard, unless there are active users with the same hardware reporting bugs.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 9:36 UTC (Mon) by Cato (guest, #7643) [Link] (13 responses)

Good point about KMS - since most distros will have KMS in the kernel+Xorg already, I think the destabilisation is probably fairly widespread - see http://www.google.co.uk/search?q=kms+hang+linux for examples.

Sounds like KMS probably shouldn't be in an LTS release at all... however, 18 months since its introduction in Ubuntu 9.10 should be enough to stabilise it on an older Intel GPU which has had open source drivers forever.

Of course I should do some bug reports but the sheer number of issues I've had, and seriousness of some of them, make it hard to spend the time logging bugs.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 14:23 UTC (Mon) by bazsi (guest, #63084) [Link] (12 responses)

At least in one case I've found similar problems when _upgrading_. Reinstalling from scratch fixed most of my issues. Especially CUPS rang a bell, but I had similar problems with video (nvidia though).

And I'm not that reinstall if there's a problem kind of guy, but finding obsolete files scattered in .d directories to fix problems takes an immense amount of time.

When I realized the root cause (obsolete packages leaving .d files around), I started to feel they are not such a good idea after all, or at least dpkg/apt should support them better.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 15:08 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (10 responses)

In my experience with Debian, obsolete .d files are typically left behind by packages which have been "removed" but not "purged" (status "rc" in the output of "dpkg -l", or filter "?config-files" in aptitude). They're considered configuration files, and thus not automatically removed along with the package. Purging removed packages with "apt-get purge <pkgname>" or "aptitude purge <pkgname>" should eliminate them.

I agree that the package manager could support such files better. Perhaps there could be a separate directory for configuration files belonging to removed packages pending reinstallation or purge, where they wouldn't interfere with the rest of the system.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 21:05 UTC (Mon) by bazsi (guest, #63084) [Link] (9 responses)

I know. But when you do a dist-upgrade, sometimes packages get obsoleted, and not upgraded. And apt-get dist-upgrade doesn't purge, and cannot be told to purge.

And that's when the battle starts to find out why a function doesn't work.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 21:41 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (7 responses)

dist-upgrade may not purge packages automatically, but it isn't very difficult to simply purge all the obsoleted packages via aptitude after the fact. Set the filter to show partially-removed packages ("l" key -> "?config-files"), select the installed-packages header, press "_" to purge, then "g" twice to apply the changes. Or, if you don't want to use aptitude, you can filter out the package names from "dpkg -l" where the status is "rc" and feed that list to "apt-get purge" or "dpkg -P":

$ dpkg -l | awk '/^rc /{print $2;}' > pkg-list
$ $VISUAL pkg-list # review packages to be purged
# dpkg -P `<pkg-list`

Why isn't desktop Linux "finished"?

Posted May 3, 2011 6:43 UTC (Tue) by Cato (guest, #7643) [Link] (4 responses)

That's not very difficult for a techie Linux user, but for someone who's switched from Windows to Ubuntu, it's very hard to discover what to do, and they are more likely to just run into problems.

Obsolete config files are an issue, but only 1 of the 4 problems I encountered was due to an old config file - the rest are just new features not working properly.

Hence I'm more interested in discussion of why Upstart and KMS are not finished and working well over 18+ months after Ubuntu adopted them and 12 months after use in an LTS release.

Why isn't desktop Linux "finished"?

Posted May 11, 2011 19:06 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

KMS isn't finished because graphics cards are insanely complicated devices these days (by far the most complex device in the system, possibly even including the CPU), are damn close to general-purpose computers in their own right, are in many ways much *more* powerful than the CPU, change very frequently, are often very under-documented, and are variable in their capabilities. In addition massive changes on the userspace side are required just to allow userspace code to get at some of the cards' capabilities (e.g. just supporting OpenGL 2.1 meant implementing a whole compiler, for shaders).

KMS won't be finished for ages. The job is just too huge.

Why isn't desktop Linux "finished"?

Posted May 12, 2011 6:04 UTC (Thu) by Cato (guest, #7643) [Link] (2 responses)

I can see your point - however, from a user point of view, desktop Linux is now much less stable for many graphics cards than it was a few years ago. I'm not that the minor benefits of KMS are worth the apparent years of instability.

Apart from the technical elegance, why did the Linux community decide to make the kernel and even typical recovery boot processes dependent on the GPU, which as you say is very complex, fast changing and under-documented?

I have still not managed to get recovery boot working on Lucid, all thanks to some combination of KMS and framebuffer devices - I've tried many boot strings and made some progress, but I gave up after many hours. On this Intel GMA3100 hardware, which should be well supported, KMS has made things much worse than the previous Ubuntu LTS.

Why isn't desktop Linux "finished"?

Posted May 12, 2011 10:48 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

desktop Linux is now much less stable for many graphics cards than it was a few years ago

Is it? I thought that before I tried KMS, and, y'know, I haven't had a single problem on the three Radeon cards and two Intel that I've tried. (I haven't tried nvidia because I actively avoid them and all their works.)

There was no choice about making the kernel boot process 'dependent on the GPU', if by that you mean using KMS to display the boot process, because the time is coming (and it is not terribly far away) when text-mode support will disappear from these cards. So it's graphics or nothing, and the only non-conflicting way for the kernel and X to display stuff on the screen is KMS, at least if you want to retain any acceleration at all in X.

I'm not that the minor benefits of KMS are worth the apparent years of instability.

The 'minor' benefits include support for any version of OpenGL above 1.5, which is ancient; the possibility to see kernel panics even when X is running (I don't know if this works yet but at least it is possible); much more reliable suspend/resume; and the ability to actually use most of the card's capabilities (it's not a framebuffer anymore, it's a massively parallel computer with an address space partially disjoint from the CPU's, and there is no hope of userspace modesetting modelling any of that).

There was a choice: go KMS, or have almost no improvements in X graphics for the foreseeable future. (Actually it would probably go backwards because the userspace modesetting drivers are not pleasant to maintain.)

Why isn't desktop Linux "finished"?

Posted May 18, 2011 13:26 UTC (Wed) by Cato (guest, #7643) [Link]

I can see the reasons for going with KMS and it sounds like it works for you - however I'm now having to make another trip to upgrade from 10.04 LTS, to solve the "freezes every day or two" problem, which I'm guessing is KMS related though it's hard to tell.

The 10.04 LTS upgrade has been a disaster, the person using has said she wants to stop using Ubuntu as a result. Hopefully going to a more recent Ubuntu (maybe 10.10) will fix the Intel KMS problems.

Can anyone recommend a good Ubuntu or similar distro version (Mint, Mepis, Debian, with reasonably quick security updates) that has KMS working well on Intel GMA3100 or similar, without random freezes? I don't want to try getting a newer Xorg and kernel working on 10.04, as the idea of this PC is to be low maintenance and reliable for the next 2-3 years.

Why isn't desktop Linux "finished"?

Posted May 3, 2011 15:07 UTC (Tue) by jzbiciak (guest, #5246) [Link] (1 responses)

While that may work, you'll forgive me if I note that it isn't particularly obvious or user friendly...

Why isn't desktop Linux "finished"?

Posted May 5, 2011 16:32 UTC (Thu) by Thalience (subscriber, #4217) [Link]

The Synaptic front-end provides a way to do it that is, if not obvious, then at least discoverable.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 22:16 UTC (Mon) by Tobu (subscriber, #24111) [Link]

aptitude purge \~c purges leftover conffiles and data (don't do it for a database though), and install/remove/upgrade commands take a --purge-unused flag that purges while uninstalling.

Why isn't desktop Linux "finished"?

Posted May 2, 2011 16:12 UTC (Mon) by Cato (guest, #7643) [Link]

I agree about upgrading to some degree, that certainly covers the xmodmap issue - however the CUPS failure to start and the KMS failure on recovery mode don't seem to be upgrade config related, and are really down to new features not working properly.