LWN: Comments on "Does the Linux Desktop Innovate Too Much? (Datamation)"

Does the Linux Desktop Innovate Too Much? (Datamation)

jospoortvliet — 2009-07-27T09:43:57+00:00

Twofold. First, innovation is good for the developer community - keeps
things interesting and fun. And we need developers... Secondly, if you
want to beat your competition, you have to be better. And copying is a
sure way to never be really better. If you're Microsoft, you don't have to
cuz you can use your market power, smart marketing and other tricks to
still outsell your competition. We don't have those, so we have to have
something which is clearly ahead.

Does the Linux Desktop Innovate Too Much? (Datamation)

nix — 2009-07-03T20:18:59+00:00

2) Xrender effects themselves sllllooooowwwww ddddooooowwwwnnn ttthheee dddeessssssskkkkktttoooppppp ddddrrrraaassstttttiiiiccccaaaallllllllllyyyy !!

sysprof the sloth (on an otherwise-idle system) and post the profiles on the xorg list. I had a problem like this with text repainting and scrolling with a 9250 and KDE 3.5.10's Konsole, and it turned out to be a combination of XAA sucking and (when I switched to EXA) the EXA glyph cache needing a defragmenter.

In typically amazing style, Michel Dänzer had a patch by the end of the day (though it took a few months to shake the bugs out).

If you provide enough info for people to diagnose problems, it's amazing how fast they can get fixed. But providing the info is *crucial*.

Does the Linux Desktop Innovate Too Much? (Datamation)

Duncan — 2009-07-03T12:06:50+00:00

Heh, yeah, KDE's 3.5.10 version of the translucency feature may be
primitive, but at least it actually works, without bringing the whole
desktop to a crawl, or worse yet, killing it.

Graphics card? I have what was for years top of the line for freedomware
support, a Radeon 92xx, near the last of the r200 chip series. I'm
running at dual 1920x1200, stacked for 1920x2400. It works well in
2D/exa/composite, but OpenGL is limited to a 2048x2048 square, so the
bottom half of my main (bottom) monitor doesn't get OpenGL support.

But it doesn't appear KDE4's system can deal with that, so it disabled the
OpenGL effects for the entire thing. Well, that wouldn't be that much of
a problem, except for two things (as of KDE 4.2.2, I haven't tried newer
tho I have both 3.5.10 and 4.2.4 installed, I use 3.5.10 pretty much all
the time).

1) Switching to xrender only effects doesn't disable or otherwise indicate
that the OpenGL effects won't work, so the only way to find out what works
is by trial and error, with most effects apparently being OpenGL-only and
thus doing absolutely nothing. Perhaps this is fixed in 4.2.4, or at
least hopefully will be in 4.3.0. But that has been one of the biggest
frustrations, having all these effects to choose from, but no indication
of what will actually work in xrender mode, with most of them doing
nothing.

2) Xrender effects themselves sllllooooowwwww ddddooooowwwwnnn ttthheee
dddeessssssskkkkktttoooppppp
ddddrrrraaassstttttiiiiccccaaaallllllllllyyyy !! If the supposed
primitive KDE 3.5.x can handle it without serious slowdowns, what's wrong
with KDE 4.x that it can't handle exactly the same basic features
(transparency, no drop-shadows, no fade) at at least the same speed, if
not faster, since it's supposedly new and improved? Yes, that's as close
as I can get to apples2apples comparison, only transparency enabled not
the other effects, same xorg config and hardware, etc, yet the 4.2 version
has been terribly slow. Actually, it's so slow the system automatically
disables it at times, which it should if it had to be that slow, but that
the same features on 3.5.10 work with little slowdown (as long as I'm
running exa not xaa, which I am), while 4.2 is so slow the system is
automatically disabling it, says a lot about the issues 4.2 still has, or
at least had at the 4.2.2 stage when I last tried booting it.

The biggest other problem isn't desktop performance, but an apparent lack
of a decent replacement for the kicker ksysguard applet. As I mentioned,
I've a decent amount of screen real estate, and on 3.5 (and from 3.3 or so
I think before that), I run a big kicker panel at the top, mostly filled
with system performance plotters (4x core usage, 1 min load average,
physical memory usage, swap, multiplexed disk activity, downstream and
upstream network, 4x core temps, 2x other system temps, 16 plotters @ 93
px wide each, 300 px high, total width 1488). I've yet to find a similar
working solution in KDE4. It has ksysguard, but I don't see a plasma
applet for it, and a standard app just doesn't work like a panel applet in
terms of interaction with other apps (always visible, maximize comes to
the edge of it only, not covering or being covered).

I've been going to try to code up a karumba/plasma applet to handle it,
but haven't gotten the appropriately rounded tuit, yet. I keep hoping
there'll be a ksysguard plasma applet appear, but haven't found it yet if
it has.

But KDE 4.2 was vastly better than previous 4.x versions. It's getting
there. I don't know if I'll get around to trying 4.2.4 before 4.3 comes
out, but I'm hoping with 4.3, it'll work well enough to actually finally
switch, even if I do have to spend some time adapting. I also expect to
upgrade to an r500 based Radeon sometime soon, which should eliminate the
OpenGL and other graphics performance issues, I hope. We'll see. With
that and KDE 4.3, I'll have some serious recustomizing and habit changes
to do, but I expect/hope it'll be worth the pain of the switch, once I get
used to it.

Make the problem go away

xoddam — 2009-07-03T02:33:35+00:00

Good point, thanks. Clean file-backed pages (not just executable ones but anything that's mmapped) are indeed pushed out to make way for other pages and can 'thrash' back in to a limited space in exactly the same way as swap-backed anonymous pages.

Therefore we are indeed still likely to see some 'thrashing' behaviour well before the OOM killer 'picks a guy'.

I wonder is this behaviour affected by /proc/sys/vm/swappiness, or does that only apply to swap? Is there another way to discourage or prevent the vm from evicting some class of clean pages (eg. executables), or is that too much to ask for?

I do find that running swap-less has pretty much eliminated such churning, ever-increasing-latency situations for my desktop use as memory gets tight: sure it slows down but in practice the system is responsive enough that I can kill stuff with the window manager, sometimes even cleanly shut down the offending process (usually a long-running browser). I suppose therefore that the pool of physical pages available for clean file pages doesn't get too small in my specific use cases.

Does the Linux Desktop Innovate Too Much? (Datamation)

gvy — 2009-07-02T21:01:24+00:00

Did you ever understand "don't fix what ain't broken"?

Make the problem go away

lysse — 2009-07-02T04:12:52+00:00

Not exactly. The same mechanism that drives swap, as I understand it, also drives the loading of executables into memory... and if this is the bit that's thrashing, if you're trying to have every piece of code you're executing share the same 4k page because all the others are dirty, then you'll end up in the same hole as before. You'll just get there faster (and end up deader) without a swap partition... on the other hand, assuming you can wrest a command line from the machine, you can add a temporary swapfile, which should alleviate the pressure enough to allow you to bail the system out.

Does the Linux Desktop Innovate Too Much? (Datamation)

njs — 2009-06-26T06:59:59+00:00

> (yea there is gnome-open but "gnome-open *" is not the same as selecting all those icons and typing ^O), besides why should I have to know what DE I am running (there is "kde-open" too...)

'xdg-open *' works for me. (I recommend 'alias o=xdg-open'.)

Does the Linux Desktop Innovate Too Much? (Datamation)

cantsin — 2009-06-26T06:44:10+00:00

Why can't the command line "mail" run my mail setup?

What do you mean with "mail setup"? A configuration dialogue for your E-Mail client or MTA? (If you mean reading your mail, then "mutt" or "pine" does what you ask for. If you have no use for the traditional Unix mail command, you can alias "mail" to mutt.)

Why isn't there an "open" command that "does what double clicking the icon does".

There is - "run-mailcap" (respectively "see"), a command that's probably decades older than Gnome and KDE, or the more recent "mimeopen".

besides why should I have to know what DE I am running

Exactly.

Better yet, why not just have a filename be a "command" to the shells and it acts like double-clicking?

You mean, enter the filename in the shell and have the file opened with the associated program? That's already the default behavior of the shell I use, zsh.

Why isn't there a reliable "ask question" command that pops up a dialog, or a more elaborate "construct this dialog box, let user fill it in, and return when they hit OK"?

man dialog. Dead-easy - there is no simpler way of creating what you describe.

Then scripts could have GUI's.

They already can - see above. For more complex X11-based stuff, there are GTK and QT bindings for all major scripting languages.

Better yet, lots of GUI programs could *call* these programs to do things.

Sorry, but your posting really seems to be the practical proof that the current design philosophy of Linux GUIs cripples, hides and makes people forget what has been possible (and standard) in Unix since its earliest days. Unix is all about that any program can call any another program, redirect standard output and input, and even run nested programs to construct its input parameters.

If Linux programs called something to do the file chooser and users could replace this program, I think within a few months it would go from having the worst file choosers in the world to having the best ones.

Yes, GUI programs would only need to follow the Unix standard of runtime arguments and input pipes, and the file choosing mechanisms could be abstracted and generalized. On the command line, this has been standard since 1969. This is why, for example, all command line programs benefit from the advanced file completion ("choosing") mechanisms of bash and zsh, and not just a handful of hypothetical programs specifically written for one of the two. The nightmare of having a bunch of "bash-native" command line programs and a bunch of "zsh-native" tools, and another bunch of tools which could use neither the advanced features of any of the two shells, is exactly the kind of design fragmentation and usability nightmare existing on the Linux desktop today.

So, yes, KDE and Gnome have thrown out the Unix baby with their GUI bathwater, and created a mess. We still have to wait for a desktop/graphical shell that honors the standard OS mechanisms to give people the full power of Unix.

Does the Linux Desktop Innovate Too Much? (Datamation)

walters — 2009-06-26T04:15:26+00:00

Why isn't there a reliable "ask question" command that pops up a dialog, or a more elaborate "construct this dialog box, let user fill it in, and return when they hit OK"?

zenity --help-question

Does the Linux Desktop Innovate Too Much? (Datamation)

alankila — 2009-06-25T21:49:35+00:00

"Bah - we *NEED* the choice so we can occasionally get the stuff *WORKING*!"

I'm fond to argue exactly the opposite.

If there is just a single solution there's a lot pressure to get that single solution do what everyone wants. If there are multiple solutions in the same problem space, this push to get one thing that works for everybody tends to vanish. People start to talk about "right tool for the job" etc. Soon there are 10 different solutions all targeting the same problem space---sort of like what we have with audio now, and then nothing really works properly anymore.

At this point it would be quite helpful if people would stop championing putting OSS back into Linux. It's not likely to happen given the investment already put into ALSA.

If would also help if people stopped pining after dmix. High-quality audio mixing, resampling and effect processing is a complicated enough problem that it should be solved by userspace. Given the lack of reliable hardware-assisted mixing and resampling, it's clear that we need some kind of software solution to paper over what hardware used to be able to do and isn't able to do anymore.

I wish that application developers just got with the program and made pulseaudio plugins for their software. I've written pulseaudio driver for one thing I care about and it was ridiculously easy.

Does the Linux Desktop Innovate Too Much? (Datamation)

spitzak — 2009-06-25T21:03:32+00:00

I'd like to ask the opposite.

Why can't the command line "mail" run my mail setup?

Why isn't there an "open" command that "does what double clicking the icon does". (yea there is gnome-open but "gnome-open *" is not the same as selecting all those icons and typing ^O), besides why should I have to know what DE I am running (there is "kde-open" too...). Better yet, why not just have a filename be a "command" to the shells and it acts like double-clicking?

Why isn't there a reliable "ask question" command that pops up a dialog, or a more elaborate "construct this dialog box, let user fill it in, and return when they hit OK"? Then scripts could have GUI's. Better yet, lots of GUI programs could *call* these programs to do things. If Linux programs called something to do the file chooser and users could replace this program, I think within a few months it would go from having the worst file choosers in the world to having the best ones.

Make the problem go away

xoddam — 2009-06-25T02:14:48+00:00

Turn off swap.

You can't prevent memory overcommitting (and you would waste much of your expensive RAM unused if you could), and you will likely see more of your processes unpredictably killed 'OOM', but you can *completely* avoid the issue of thrashing swap killing performance, and therefore being unable to shut down a memory hog.

This is *not* a solution -- swap has a purpose and it should be possible to use it without such complications -- but turning it off will definitely make the thrashing problem go away.

Does the Linux Desktop Innovate Too Much? (Datamation)

modernjazz — 2009-06-25T02:00:59+00:00

Thanks for the "long, rambling" response! It's kind of what I thought was
happening, but it's nice to hear it's not a figment of my imagination.

Well, here's to hoping someone has a bright idea about how to solve it!

Does the Linux Desktop Innovate Too Much? (Datamation)

nix — 2009-06-24T19:17:10+00:00

Given that the CUPS author has said that every single complaint in that
review was addressed before the review was even published, sure.

(I still prefer LPRng for one major reason: file(1)-based scripting of the
translation pipeline is much easier because you can just use shell
scripts. As far as I can tell with CUPS you need C. Annoying.)

Does the Linux Desktop Innovate Too Much? (Datamation)

muwlgr — 2009-06-24T16:21:34+00:00

Eric Raymond wrote a pair of nice reviews about his CUPS experience, remember ? Do you think our continuous innovation has made these reviews less true with the run of time ?

Does the Linux Desktop Innovate Too Much? (Datamation)

fergal — 2009-06-24T14:40:48+00:00

I think when they say "perfect" they actually mean "ideal" or "utopian". If that actually worked perfectly then everyone would just do that. There would not even be an autospawn feature and it wouldn't be on by default in Ubuntu Jaunty. I suspect a search for "pulseaudio" and "hang" or "crash" or "silence" would explain why the "perfect" solution is not actually deployed.

To get back to my original bug, as far as I can tell, if I start pulseaudio with no options, it will quit immediately if it finds another instance of the server. This makes sense but now I really have no idea how I ended up with 1000s of them running at the same time.

Does the Linux Desktop Innovate Too Much? (Datamation)

nix — 2009-06-24T13:34:27+00:00

Er, they were fixed. The fix is called CUPS.

The GUI obviously needs to change as well, because it has to *ask* the user about things like duplex if the user is going to be able to configure that (and it's something the user might reasonably want to configure differently for each job). If you choose to use LPR (and in KDE at least you can choose your printing backend every time you print something: CUPS has an lpr command too), then you lose that functionality.

Does the Linux Desktop Innovate Too Much? (Datamation)

nix — 2009-06-24T13:32:17+00:00

The PulseAudio site's 'Perfect Setup' has for *years* stated the preferred way to use PA, which is simply to start a single copy at session-startup time and kill it at session-shutdown time. The startup involves a simple

/usr/bin/pulseaudio

no parameters, no nothing needed.

If Ubuntu chose to do something more elaborate and it went wrong, then they shot *themselves* in the foot. PA is likely not to blame.

(Another configuration is possible --- a single systemwide PA instance. This is lower-performance and lacks features for security reasons, plus allows people to interfere with each others' sound playback, so is deprecated.)

Over our collective head?

nye — 2009-06-24T13:04:54+00:00

>> I have no idea how so many people have had all these problems with sound.

>Probably because you never tried to do any more complicated then music playback.

I don't really know what counts as 'more complicated than music playback'. Thing I was doing at the time included playing music, watching DVDs (so the audio needs to be synced), and being able to play more than one sound at once (or, similarly, be able to play sound while some other audio application is paused). All those things still work for me with ALSA (though I had some latency issues with ALSA in the early days), which also supports hotplugging quite happily.

(Can't really comment on PulseAudio now since I haven't tried it since last year, and by all accounts it's improved dramatically in that time)

So no, I'm not trying to snychronise A/V over a network, or use any audio manipulation applications with sub 20ms latency. Nor do I have any hotplugging requirements that go beyond 'I plug in this headset and now I can use it'. Is that the sort of thing you're talking about? Have I just had an unusually lucky selection of hardware or do large numbers of people really have more complex requirements than that?

Does the Linux Desktop Innovate Too Much? (Datamation)

fergal — 2009-06-24T10:41:29+00:00

I don't see how *any* design could have made an ordinary command-line program resistant to forkbombing. It can't tell something is running it over and over again!

I don't know the design of pulseaudio but it seems like a user should never have more than 1 pulseaudio process running, yet somehow I ended up with 1000s. Yes it's probably a bug in the distro but really it should be very difficult to produce such a situation. Looking in pulseaudio's man page I see --kill, --check, --fail. Presumably multiple invocations using some combinations of these is necessary to correctly start up the daemon and conversely there are many ways to invoke it that go horribly wrong. Good interfaces make it easy to do the right thing and hard or impossible to do the wrong thing.

Rummaging around a bit further I suspect that autospawn was the real problem as every command I ran sent some pulse audio errors to the terminal. It seems like autospawn is only there because the daemon is expected to crash.

To look at it another way, the distros have already managed to get esd and artsd run stably, why is it that they haven't yet managed it for pulseaudio? It was in Ubuntu 8.04 but 2 releases later it's still flaky (and this is not a quirky hardware problem, hardware problems should not lead to 1000s of processes if the setup is correct). It's not as if Ubuntu and Fedora are inexperienced amateurs and have never before transitioned to a new core software system.

Does the Linux Desktop Innovate Too Much? (Datamation)

cantsin — 2009-06-24T08:41:36+00:00

It's a good example indeed - if such issues exist, they need to be fixed in lpr (i.e., more generally, in the general operating system infrastructure), and not in the GUI.

Over our collective head?

Pc5Y9sbv — 2009-06-24T08:36:37+00:00

Unfortunately, there is a lot of cyclic reinvention of simple stuff and not enough analysis of the real hard problems to actually "innovate" a better user experience.

For example, it is hard to argue that the perpetual stream of userland "mixing daemons" of one sort or another have really been a good use of developer or user time, or really improved the range of operations that are possible. It seems patently obvious that the system abstraction for sound should allow an app to generate sound and it is the kernel (as hardware abstraction layer) which ought to mediate the sharing. It was wrong-headed to leave out driver-based multi-app mixing on devices that became simpler over time, and this set us back a long way. Imagine if we had spent the decade never having MD, LVM, or loopback block devices but instead a procession of userland block-mixing daemons!

I find it very troubling that people keep trying to create a new OS within the OS, where things only work properly when they are all in the same userland ghetto, whether that is KDE and GNOME, ALSA, Java, etc. We have an OSS system, and we should be collaborating to improve how the layers work together, rather than having these turf battles where the layers try to work around each other. The FUSE layer is cute and enables some nice user experience in the filesystem space, but it would have been a disaster if this had been favored to the exclusion of proper kernel-level block devices and filesystems...

Instead of reinventing mixing daemons over the past decade, somebody could have been focusing that effort on separating the policy problem. What is the range of behaviors that people would want? Let's make the kernel device abstraction support that range, and let some userland policy daemon configure the more complex behaviors like alternate mixing modes and signal routing. Meanwhile, the kernel could have sensible default/failsafe behaviors to satisfy all app requests in some way in case the userland policy daemon is not present.

Does the Linux Desktop Innovate Too Much? (Datamation)

Pc5Y9sbv — 2009-06-24T07:46:24+00:00

While not experiencing the exact problem you describe, I've experienced similar. My take is that it's a statistical result of the much expanded amount of memory compared to the page size since those early Linux systems, combined with the huge software bloat in userland. Also a factor, ironically, is the much increased speed of disks and increase in request queue depths etc to optimize bandwidth, because there is so much more going on in the system in the relatively unchanged time interval of human interaction.

There are ludicrously many more pages of code and data involved in processing those window management buttons and mouse events than there was in the old days of twm or fvwm. There are also ludicrously more opportunities to allocate pages and purge "stale" pages from RAM while the human ponders what to do next.

By the time you get around to trying to click, all the pages you want to exercise are swapped out. Plus, while the system struggles to make space and move your page back in to process the click, the non-interactive application continues to force page-out as fast as it can. So the system is making these slow round-trip fetches of one page at a time in between this utter storm of page requests from your numerical code or what have you. The code executing your click is jumping sparsely through a huge number of pages and process contexts before the kernel ever receives a system call requesting a process to be killed.

As a system architect, I think the obvious statement is that there is a dire need for differentiated service classes. But the involved developers are (rightly) afraid of the messy world this implies, and they cling to the hope that over-provisioning can allow simpler "fair" algorithms to work well enough. The core challenge of differentiated services is to create policies that properly distinguish the more important activities; it is much easier to enforce the policy that it is to write it in the first place.

Ideally, you could imagine a system that understood in totality which pages were necessary for the control interfaces (like the mouse, keyboard, screen, and window manager, and window manager buttons) so it could protect them from interference by bulk app and filesystem pages. Whether protection means locking them in RAM or just prioritizing their swap behaviors is really not important, so much as the system even knowing that these infrequently used pages and code execution paths are qualitatively much more important than one more iteration of the inner loop of your numerical code.

But this is not just a kernel problem. You would need to structure all of your apps to isolate the important low-latency stuff from the rest, e.g. the stop or kill application buttons should be protected, but not by locking in a huge amount of mostly unrelated image cache to provide fancy animated window animations! What is high priority to you, the user, is a very fleeting and contextualized notion---very difficult to map into actionable QoS policies or compensation behaviors in the system.

Sorry for the long, rambling response. This is pretty much _the_ classic systems problem, to manage sharing of limited resources according to complex global utility metrics.

Does the Linux Desktop Innovate Too Much? (Datamation)

nix — 2009-06-24T07:34:59+00:00

Printing is a pretty good example. It used to map lpr, and still can: but
people expect to be able to e.g. control the doublesidedness of their
printing from a GUI, and there's no way lpr can do that. (It has options
you can set --- they differ on a site-by-site basis and many sites have
none. Great.)

They expect to be told when the printer is out of paper. They expect to be
told when printing has finished. lpr, even LPRng, can't do that.

Does the Linux Desktop Innovate Too Much? (Datamation)

nix — 2009-06-24T07:31:05+00:00

I don't see how *any* design could have made an ordinary command-line
program resistant to forkbombing. It can't tell something is running it
over and over again!

PA the *daemon* *does* have a lot of requirements --- working sound with
relatively bugfree drivers, working hrtimers from userspace, working
capabilities, working HAL, working PolicyKit...

... but except for the drivers (which it can't avoid requiring) and
perhaps the hrtimers *none of this is radical stuff*. A distro which
breaks PA is going to be breaking other stuff too: PA is just the most
noticeable example.

Over our collective head?

Kit — 2009-06-24T02:50:52+00:00

KDE can use PA in 4.x through GStreamer, and likely the other backends as well (not sure which of the others support it, I think at the very least Xine does as well).

And in the 3.x series, you could easily disable aRts with basically the only application impacted being KNotify, which just requires you to tell it a different command to use to play the audio if you still want the audio notifications.

Does the Linux Desktop Innovate Too Much? (Datamation)

MattPerry — 2009-06-24T00:11:59+00:00

> We need to tighten down the weak points, but we also need to innovate.

Do you need to innovate or just want to innovate? What are the risks of not innovating at all?

Over our collective head?

man_ls — 2009-06-23T22:14:54+00:00

Sure; that is a different (but related) problem. A stable API is a stake in the ground for innovation -- can be worked around but always keeps you from straying too far. Actually for applications there is POSIX, but it lags behind in areas like precisely audio. And for graphical toolkits there is GTK 1.x, which is a fairly stable API.

Anyway in many areas we don't have that stable API. GregKH and others have explained their reasons for this lack in Linux (the kernel), but I think that the actual explanation is simpler: Linux simply does not have the resources. It could choose to keep supporting the vast amount of devices available, or it could support a limited number of devices with a stable API. But it does not have the mastodontic resources and vendor support that Windows has, so it cannot support everything with a stable interface. So it selfishly chooses the first option, support more devices with less stability, because it is more gratifying and more fun. This explanation might also be applied to other areas like graphical toolkits or audio.

Over your head?

kragil — 2009-06-23T21:45:21+00:00

Bitter much?

What was the purpose of your comment besides hitting on KDE for giving you grief in the distant past?

And besides other people obviously have different opinions than you about PA. I would argue that a lot of people say(troll) the exact same thing about PA that you say about KDE.

Think about it.

Does the Linux Desktop Innovate Too Much? (Datamation)

boudewijn — 2009-06-23T21:15:07+00:00

Many of those things you mention, such as wrapping "find" and "grep" were
wrapped, in the early days, and it turned out that wrapping them would
never give a satisfactory user experience. And that holds for nearly
everything in your list. It's been tried, and found wanting: and that's
the answer to your why's.

Over our collective head?

drag — 2009-06-23T20:38:53+00:00

Which KDE? The one people actually use (KDE 3.5) or the latest development-called-stable release of KDE 4?

Personally I've solved my KDE problems long ago by simply avoiding to use any programs that use KDE. It's gotten quite a bit easier to do that lately, of course.

But when KDE uses PA (either directly or through one of the dozen commonly used libraries which in turn can use PA) all of this will be a non-issue.

Over our collective head?

drag — 2009-06-23T20:36:23+00:00

> I have no idea how so many people have had all these problems with sound.

Probably because you never tried to do any more complicated then music playback.

Anything beyond that things begin to fall apart rapidly. Beleive me, I've helped dozens of people with Linux on their systems and sound performance is a cronic problem. Go look at the error messages in mplayer if you don't beleive me. For them they claim the majority of performance problems are going to be related to audio sync.

I've put a huge amount of effort in the past trying to understand sound in Linux and it's no easy matter.

PA is definately a improvement and is the only 'solution' that has come along so far that even pretends to address the majority of problems linux audio faces. Everything else I've seen has been 'rewrite your program to this new API', if even that.

Does the Linux Desktop Innovate Too Much? (Datamation)

ejr — 2009-06-23T19:33:47+00:00

Just verified it's working with Debian now, too.

(And strike the "added last week" part. I only looked at the shortlog, and it's not mentioned.)

Does the Linux Desktop Innovate Too Much? (Datamation)

cantsin — 2009-06-23T19:27:56+00:00

I dare to opine that the big Linux DEs "innovate" on the wrong end - trying to match (or outdo) the usability and appeal of Apple's and Microsoft's proprietary desktop offerings by essentially hiding the Unix/Linux-GNU operating system and giving users no access to and clue of its core strengths. It starts with such simple things as pipes: why do KDE and Gnome have to invent, throw away and reinvent their own incompatible interprocess mechanisms with every major release, while stone age X11 apps such as gv actually support standard Unix pipes? Why don't desktops natively integrate support for revision control systems like Subversion and git? Why don't their file managers use rsync to speed up file copying? Why can't a drag-and-drop printer icon map the lpr command? Why don't desktops make use of the power of regexs and tab completion, or have decent GUI wrappers for find and grep [instead of implementing their own sub-par file search and indexing software]? Why can't they interface with FUSE for virtual file systems? Why can't there be ultra-efficient desktop control of remote computers via ssh [just by sending Unix file manipulation commands over the line]?

The list could go on and on. Of course, I'll take the point that I should write or initiate such a DE myself for which I don't have the time or skills. Still, the disconnection between the quality of low-level tools of Unix/Linux and Linux GUIs is sometimes is quite depressing.

Does the Linux Desktop Innovate Too Much? (Datamation)

martinfick — 2009-06-23T17:35:01+00:00

That used to be true. But seeing as I own for vehicles, and all of them were made last millenium, I cannot agree with this statement. When I rent a vehicle these days, I am thoroughly confused and uncomfortable driving/using it for the entire time I am renting it. The vehicle does things I do not expect, and it does not always do the things I do expect.

Even something as essential as blinkers have been insanely altered these days, I trigger an instantaneous left and the thing continues to blink for a while after I let go of the button! Don't get me started about figuring out whether the lights will go off or not (how long do I wait in the parking lot staring at the car at night)? And why do they chose to sometimes randomly lock my doors for me? Did the designers ever uses these vehicles? Come, on, the passenger doors lock on you while you are loading/unloading your kids in and out of their seats. With the proliferation of buttons, one of the last things you will figure out (which should be the first, before you even start a car), is how to adjust the seat. Just like with computers, vehicle basics are no longer sane. :(

Does the Linux Desktop Innovate Too Much? (Datamation)

rsidd — 2009-06-23T17:16:47+00:00

All true, but if you can drive one car, you can still drive another with about half a minute of looking around, and feel entirely at home in it within half an hour. If you're used to GNOME -- much less Windows or Mac -- you'll be unproductive on KDE for days.

Does the Linux Desktop Innovate Too Much? (Datamation)

nye — 2009-06-23T16:58:12+00:00

>First, as users we limit ourselves to what works. I've experienced this numerous times in development. We learn to work around bugs and flakey bits, and unless we write them down as we run into them, we forget

So true. It's very easy to get so used to the problems with something that you don't even notice them any more, and honestly think it's ready for general consumption. The result of this is that a new user tries the software and they find it unusable because of problems that you didn't even think about, or thought were trivial. (Or to put it more succinctly: a hundred minor bugs add up to a major usability problem.)

Does the Linux Desktop Innovate Too Much? (Datamation)

pr1268 — 2009-06-23T16:26:07+00:00

Didn't you know that the Xorg-Intel memory leak is one of the innovations Mr. Byfield is commenting on?

Just kidding. :)

Over our collective head?

nye — 2009-06-23T16:15:32+00:00

I have no idea how so many people have had all these problems with sound.

When I assembled a computer in 2001 I used a sound card that cost less than £30 at the time (this is before all motherboards had sound on-board), which was about the cheapest I could find. With all the hardware and software I've used since then sound worked perfectly and without effort until the advent of the hated PulseAudio, which brought everything back to 1997 again. I chose to switch back to Debian where I can remove PulseAudio without having to wrestle with a system that Knows Better.

Does the Linux Desktop Innovate Too Much? (Datamation)

leoc — 2009-06-23T16:04:45+00:00

Here's another positive vote for PulseAudio. Works great for me on all the machines I've tried it on.