Linked by Thom Holwerda on Mon 18th Oct 2010 21:54 UTC
Linux Well, it's been a while since we've opened this particular jar (box is not historically accurate) owned by Pandora. Desktop Linux... Yes, that ever elusive readiness of the desktop that is Linux-powered. Some story on ComputerWorld argues that the desktop Linux dream is dead, and apparently, the story is causing some stir on the web. Well, paint me pink and call me a lightbulb, but of course desktop Linux is dead. However - who gives a flying monkey? Linux is being used by more people than ever!
Thread beginning with comment 445707
To view parent comment, click here.
To read all comments associated with this story, please click here.
Icaria
Member since:
2010-06-19

However, 'Program Files' makes a bit more sense, doesn't it?


Sure, "a bit", but from the name alone, you're not going to deduce that Program Files contains your target binaries. Of course, the C:\ that preceded it and the \company name\ that proceeds it are about as descriptive at /usr, /dev, and the rest of the FHS' cryptic (and mind-bending, re: mounting partitions inside other partitions) nonsense.

When some manager type comes to you and says 'I need group A to have read access to this folder and group B to have write access to this folder' and you say 'sorry, can't do it with Linux', thats not the right answer.
I believe you were talking about the desktop, not the server room. You also seem to be confusing linux's shitty POSTIX ACLs for a lack thereof: linux and most of it's filesystems support ACLs. If it didn't, you might as well be running as root. Linux's ACLs suck but they're adequate for desktop usage. It's on the server that you begin to long for a proper UNIX from one of the big vendors, with ZFS/JFS/etc and standard NSFv4 support.

Can you say 'none of those technologies are 'horizontally fragmented', or mutually exclusive at all?, and all go out of their way to provide a seamless look and feel on their respective OSes


WTF. Mutually exclusive? Nay, a 'seamless look at feel' on Windows?? It's exceedingly rare for KDE/Gnome/etc apps to conflict in alien environments. The look and feel comment needs no reply.

as well as all leveraging common low-level services in a way that Linux doesn't?
Because it's not as if KDE and Gnome apps can leverage the same multimedia backend, or system bus, or device enumerator/manager, or sound server, or graphical server? About the only thing, besides the widget toolkit, that they don't share is configuration backends but so what? Apps on every platform do this. In the case of Windows, it's preferable that they don't, lest the unusable mess that is the registry becomes the slow unusable mess that is the registry. At worst, on the *nix desktop, you're looking at maybe 3 daemons for tracking config changes, using a total of perhaps 12mb of RAM and you'd have to be using a pretty broad range of software to land even that. Distributions like Ubuntu do create needless repetition and bloat, running both the apt xapian indexing daemon and aptdaemon/package kit daemon just to cover their various package management GUIs but that's got nothing to do with environment fragmentation but rather, the evolutionary nature of desktop linux. It's also why I'm stuck running HAL and udisks (which does create minor conflicts) due to the slow development cycles of Xfce.

when all your drivers have to be updated every time a kernel point release comes out, its just painful
Funny, DKMS handles this just fine for me.

I agree that desktop linux's problems are related to low-level architectural design decisions, like retaining a 20+yo graphical server protocol and just augmenting it with a perpetual cycle of unofficial add-ons that come and go every few years, or depreciating HAL almost as quickly as they decided to have it handle all device detection, or creating one sound server after another, rather than fixing the previous ones, then trying to ensure that the new server can plugin the old ones, providing hit-and-miss backward compatibility. Linux simply isn't designed with a desktop user in-mind. There's some great desktop software for *nix out there, providing robust and elegant environments far superior to the crap peddled by Apple and MS but the underlying technology consistently fails it. Porting KDE to Windows may one day prove to be the best decision the KDE team ever made.

Edited 2010-10-19 07:25 UTC

Reply Parent Score: 3

IkeKrull Member since:
2006-01-24


Sure, "a bit", but from the name alone, you're not going to deduce that Program Files contains your target binaries.


Yes, I think you would conclude exactly that. what else would you assume was there? Why would you automatically think your 'target binaries' were hidden away from you?

I believe you were talking about the desktop, not the server room. You also seem to be confusing linux's shitty POSTIX ACLs for a lack thereof: linux and most of it's filesystems support ACLs. If it didn't, you might as well be running as root. Linux's ACLs suck but they're adequate for desktop usage. It's on the server that you begin to long for a proper UNIX from one of the big vendors, with ZFS/JFS/etc and standard NSFv4 support.


The two issues are very much intertwined. A user-friendly OS is one that works for the users - in a business environment, this absolutely extends to file permissions. When a user has a requirement to access a file, the operating system and GUI should facilitate that - not work against it. Linux's primitive permission model is painfully limited.

And the ACLs are not 'adequate for desktop usage' - i think OpenSuSE might have some support for manipulating ACLs from the GUI, but generally speaking ACLS are wholly unsupported as user-visible attributes of files, and are immediately destroyed when a set of 'standard' 'rwx'-based POSIX permissions are applied. The whole thing is insanely fragile.

To argue that POSIX draft ACL support as it stands today in Linux is 'adequate for desktop usage' is to be incredibly out of touch with what the average user expects in terms of basic visibility,functionality and coherency.

When i, as a desktop user in a business environment with legitimate interest and authorisation from the company - wish to click on a file and assign it permissions, i should be able to do that. Why should i need or want to go running to a sysadmin who has to drop to a console and issue a bunch of 'setfacl' commands? This is not just an 'enterprise' problem - this issue is absolutely at the the heart of small business's ability to utilise Linux.

WTF. Mutually exclusive? Nay, a 'seamless look at feel' on Windows?? It's exceedingly rare for KDE/Gnome/etc apps to conflict in alien environments. The look and feel comment needs no reply.


Rubbish. try running gnome apps under kde and see font sizes go all over the place, window management straight-up fail to handle focus correctly, and all manner of inconsistency.

Run a carbon and a cocoa app side by side, or a MFC and windows forms app, and watch the users simply not notice any issues. To claim carbon/cocoa or MFC/windows forms have anything like the UI gulf between tham that KDE/GNOME have is to put your fingers in your ears and yell 'LALALA'

Its just not useful or helpful to click file-> open in two different apps and be confronted with two entirely different interfaces for selecting a file, along with two entirely different sets of 'favourite' folders etc.

Because it's not as if KDE and Gnome apps can leverage the same multimedia backend, or system bus, or device enumerator/manager, or sound server, or graphical server? About the only thing, besides the widget toolkit, that they don't share is configuration backends but so what?


So theres no problem?

Apps on every platform do this. In the case of Windows, it's preferable that they don't, lest the unusable mess that is the registry becomes the slow unusable mess that is the registry. At worst, on the *nix desktop, you're looking at maybe 3 daemons for tracking config changes, using a total of perhaps 12mb of RAM and you'd have to be using a pretty broad range of software to land even that. Distributions like Ubuntu do create needless repetition and bloat, running both the apt xapian indexing daemon and aptdaemon/package kit daemon just to cover their various package management GUIs but that's got nothing to do with environment fragmentation but rather, the evolutionary nature of desktop linux. It's also why I'm stuck running HAL and udisks (which does create minor conflicts) due to the slow development cycles of Xfce.


Oh yeah, there is a problem, isn't there.


Funny, DKMS handles this just fine for me.


Well, thats obviously the solution then. DKMS works just fine on Fedora, OpenSuSE etc. too, right? Or are there about 10 diffferent, incompatible solutions to a 'problem', which, apparently doesn't exist?


I agree that desktop linux's problems are related to low-level architectural design decisions, like retaining a 20+yo graphical server protocol and just augmenting it with a perpetual cycle of unofficial add-ons that come and go every few years, or depreciating HAL almost as quickly as they decided to have it handle all device detection, or creating one sound server after another, rather than fixing the previous ones, then trying to ensure that the new server can plugin the old ones, providing hit-and-miss backward compatibility. Linux simply isn't designed with a desktop user in-mind. There's some great desktop software for *nix out there, providing robust and elegant environments far superior to the crap peddled by Apple and MS but the underlying technology consistently fails it. Porting KDE to Windows may one day prove to be the best decision the KDE team ever made.


What desktop problems? You just spent ages trying to tell me i was wrong about there being problems, and now you raise a bunch of new ones. Are we really so far away from being in agreement that Linux has severe issues as a desktop OS?

And last i checked nobody on Windows needed or wanted KDE for anything.

Reply Parent Score: 2

Icaria Member since:
2010-06-19

Yes, I think you would conclude exactly that. what else would you assume was there? Why would you automatically think your 'target binaries' were hidden away from you?
It's called Program Files, not Programs (or Programmes, even). For the computer literate, that could easily be taken to mean libraries. For the layperson, that could easily be taken to mean the files produced by their programmes. Abbreviations and current usage aside, /bin is far more descriptive.

i think OpenSuSE might have some support for manipulating ACLs from the GUI
I think any file manager worth it's salt can. Thunar definitely can, nautilus could last I used it. I haven't used dolphin extensively enough to know, although considering KDE's kitchen sink mentality, it's absurd to think that it doesn't provide facilities for manipulating permissions. Thunar and nautilus also make it a might simpler than Explorer does, too.

To argue that POSIX draft ACL support as it stands today in Linux is 'adequate for desktop usage' is to be incredibly out of touch with what the average user expects in terms of basic visibility,functionality and coherency.
While arguing from your own personal ignorance is just dandy, it seems.

Rubbish. try running gnome apps under kde and see font sizes go all over the place
Tried it, hasn't happened to me. Opposite is true, though: Qt4's Gtk+ emulation fails to pick up font hinting settings, fails where the gtkrc defines more than one font (although it's rare that anyone does this), etc. Of course, it will still get it roughly right and doesn't break simply because you changed the font to something other than 8pt MS Sans.

window management straight-up fail to handle focus correctly
Tried it, hasn't happened to me. Had Xfce notification daemon windows steal keyboard focus in compiz but that's as close as I've gotten to focus problems when mixing and matching software (albeit, neither are desktop apps) and there was an adequate workaround.

Run a carbon and a cocoa app side by side
...and listen to the mac fags groan?

or a MFC and windows forms app
And get different menubar and toolbar widgets, a host of different ways of drawing MDIs and notebook tabs, totally different menu widgets. Hell, forget even the vanilla MFC and Winforms comparisons, just open some of MS' own software: open up outlook 2003 or above, Word 2007 or above, Windows Live Messenger, any version of Explorer, cmd.exe and enjoy the... what was it you called it? Oh, that's right:
seamless look and feel
And that's just the first party software. No Windows users are going to give a shit that programme X, in environment Y has font problems, when they're coming from a platform where no two apps look alike, attempting to so much as increase the font size results in the entire UI falling back to a 90's eyesore, half your fonts are still 8pt and the other half cause widgets to break, or become misaligned and before you even change anything, the UI is broken (unfocussed menubars, menus, broken dialogue windows in the control panel, focus-dependant scrollwheel) and contains lots of legacy cruft, with certain widgets randomly falling back to 90's ugly, or having unreadable text.

To claim carbon/cocoa or MFC/windows forms have anything like the UI gulf between tham that KDE/GNOME have is to put your fingers in your ears and yell 'LALALA'
To use 'Windows' and 'seamless look and feel' in the same paragraph, is to demonstrate that you're in lala land.

Never mind that comparing two disparate toolkits with quite different origins, to two where the latter was, from it's outset, designed to harmonise with the former, is stacking the deck in your favour.

Its just not useful or helpful to click file-> open in two different apps and be confronted with two entirely different interfaces for selecting a file, along with two entirely different sets of 'favourite' folders etc.
This doesn't happen with Qt4, does with Gtk+. That's at least half true. Meanwhile, enjoy your oh-so-consistent printer dialogues, titlebars, menubars, titlemenubars, toolbars, titletoolbars, ribbons and toolmenubars.

So theres no problem?
...

Oh yeah, there is a problem, isn't there.

I'm sure life must be difficult when every second word that dribbles out of your mouth is demonstrable bullshit but don't try to take credit for my criticisms.

Well, thats obviously the solution then. DKMS works just fine on Fedora, OpenSuSE etc. too, right? Or are there about 10 diffferent, incompatible solutions
Works fine in Debian and it's derivatives, works fine in Fedora. Can't speak for SuSE but it's inconceivable that it's not available for SuSE.

to a 'problem', which, apparently doesn't exist?
Now you're just strawmanning yourself, as much as you are me. You placed 'common gui foundational stack' under article d) and kernel drivers/modules under article e). Now you're conflating them. I never said there was no problem to begin with. In fact, after I dealt with your ill conceived notions of just what's wrong with the desktop stack, I offered my own ideas as to where the problems lie, which you generously tried to pass off as your own. DKMS has nothing to do with any of this.

What desktop problems? You just spent ages trying to tell me i was wrong about there being problems
No, I spent the requisite time for making one post on OS News to address your assertions regarding the source of the problems. Some of your points I agreed with; others, I did not.

and now you raise a bunch of new ones. Are we really so far away from being in agreement that Linux has severe issues as a desktop OS?
Are you really this obtuse?

And last i checked nobody on Windows needed or wanted KDE for anything.
I want KDE on Win 7 and I don't even like KDE. I'd settle for a decent update to bb4win, a port of wmctrl/xdotool and a non-fucked file manager in 7, though.

Reply Parent Score: 1