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 445682
To view parent comment, click here.
To read all comments associated with this story, please click here.
IkeKrull
Member since:
2006-01-24

a) a departure from the cryptic UNIX FHS

Like end-user cares. Nobody sees it, and
"C:\Windows\System32" does no make much sense either.


Users don't need to go hunting through there unless they want to do something with the Windows system files - the '32' is a little bit cryptic, i'll give you that.

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

And yes, users do see it. For example, whenever firefox can't handle a protocol and the user needs to find a program to handle it, they have to trawl through /usr/bin assuming they even know what that is.

Its a stupid system, and people who for some reason have become perversely attached to this stuff cos they've been dealing with it since the 1970s making excuses for something thats barely adequate instead of pushing for something good is the problem.

b) a useful, user-configurable linux->linux network filesystem that isn't NFS3 and probably isn't NFS4.

Samba is available


Sure, samba is available, but why would the linux desktop use the Windows workgroup/domain/permissions model when none of that stuff is actually implemented in the rest of the OS? Plus shared homedirs don't work properly on samba, locking is a problem on samba. Samba is a great tool for interoperability, but why doesn't Linux have something good, something best-of-breed?

c) filesystem ACLs by default.

I've managed systems with ACL since 1989
(remember Apollo/Domain ?).
No real big advantages.


Rubbish. 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.


d) one GUI, with one widget API, and one system services (installed components, configuration settings, device discovery) backend. Doesn't mean people can't offer different stuff on top of that, but its pointless for things to be split into such tiny bits for the desktop user.

Can you say MFC and .NET ?
Can you say XP an Win7 ?
Can you say Cocoa and Carbon ?


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, as well as all leveraging common low-level services in a way that Linux doesn't?, as well as actually representing progress instead of 'it was done this way in the 1970s so it must be right'?'


e) a driver API which supports backwards compatibility even while new features are added

Go read http://www.linuxdriverproject.org.
Linux driver model is superior, period.
Company just have to realize that there is no
advantages in closed-source drivers.

I am sure that you won't get it,
and call me an old farth, since I remember the
day that when you bought a printer, it came with
a programming manual.

[/q]

I've read it, I understand that point of view, but when all your drivers have to be updated every time a kernel point release comes out, its just painful. Why can't I use the webcam driver that worked perfectly well on linux 2.6.18 on 2.6.19 without having to recompile it from source? I mean, apart from the kernel developers desire to preserve flexibility, why?

Users don't understand the reason for this, because he reason why is only relevant to kernel developers. Users just see broken stuff. And stuff breaks, even the open source stuff breaks - see recent Nouveau driver problems where kernel driver changes forced userland API changes, making it impossible to use newer kernels with older X.org stuff. Theres no mechanism in place to allow API to be gracefully deprecated as it changes, there is no way in hell this situation benefits anyone but kernel developers.

And sure, the kernel developers are important, they wrote this stuff, but this is an example of why desktop linux isn't a reality, because this 'we don't need no APIs, we'll change whatever we want, whenever we want, and if your driver isn't in the kernel tree for whatever reason, go f**k yourself' isn't working well for desktop users.

Reply Parent Score: 4

lemur2 Member since:
2007-02-17

And yes, users do see it. For example, whenever firefox can't handle a protocol and the user needs to find a program to handle it, they have to trawl through /usr/bin assuming they even know what that is.


No they don't. When reKonq or Dolphin or any other native-to-the-desktop program needs to associate an unknown file type with an application, a dialog box appears which is a graphical mini-representation of the systems menu. You just pick an application as if from the menus, it even has the standard icons and application groups just as shown on the system's menu. For example, for a plain text file, one can choose the Kate editor icon from the Utilities group of applications to open it, just as one would from the system's main menu.

I'm not totally sure about Firefox, but it should use the same mime types as native KDE applications. I think there might be a Firefox plugin which sets this up.

Within Dolphin, the KDE File Manager, one can right-click on any file type and select "properties", and then click on the "configuration" icon within the properties dialog box. This lets you add or remove applications associated with that file type, again using a GUI selector of applications equivalent to the systems menu. One can also set the associated applications order of preference by moving applications up or down in the list.

Whenever one adds a new application, it claims file type as being associated with it, and so it is automatically added to the lists of the file types it knows how to handle, normally as the last preference in the application order. If one want to change the preferred order, one can do it through GUIs without having to know the application's executable name or its location within the filesystem.

At least on KDE this is all so, I can't speak for GNOME because I haven't used it in a while now.

Why do people persist with these outdated nonsense claims about Linux being supposedly hard to use? It is just utter rubbish.

Edited 2010-10-19 05:21 UTC

Reply Parent Score: 2

Panajev Member since:
2008-01-09

I'd be more inclined to believe you if I had never used Linux before and seen GUI's basically lying about the state of the system (DHCP server being active and already running, ok older RH release), not being able to customize all the aspects without going down to the terminal, etc...

Linux is not ready to be fully used, configured, and troubleshooted without using the Terminal. Windows is 98% near that goalpost, MacOS X is 96% (100% for some people) near that goalpost, but Linux is far from being anywhere near the goalpost mentioned.

Reply Parent Score: 3

lemur2 Member since:
2007-02-17

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.


Of course it isn't the right answer.

What you say to the manager type is this: "Give me text file listing of the usernames in group A, and another list of those in group B, the names of the folders you are talking about, and twenty seconds of my time, as the administrator I can type in four commands that will set that up for you. Using the GUI will take me a bit longer, but not much".

That is the right answer.

Here is just one way to implement the right answer for a scenario where such control over permissions might be required:
http://beginlinux.com/server_training/server-managment-topics/1038-...

Edited 2010-10-19 05:38 UTC

Reply Parent Score: 3

Icaria Member since:
2010-06-19

There are actually problems with ACLs on *nix related to umasks and inheritability. You can setup your read group and your write group but if someone in the write group copies a file to your shared folder, whether or not your read group can see/read that file is very much up in the air.

Reply Parent Score: 2

lemur2 Member since:
2007-02-17

Why can't I use the webcam driver that worked perfectly well on linux 2.6.18 on 2.6.19 without having to recompile it from source?


If you have a webcam that didn't have an open source driver, then how do you have the source? If the OEM provides source on a website but this isn't included in the mainline kernel, then you know all about this issue, as you would have had to locate the source code and compile it in the first place. So don't change your kernel without testing first. Blacklist kernel updates if you like.

If you don't even know what a kernel is, and you didn't compile any "driver thingy", then the webcam that worked with linux 2.6.18 will still work just fine for you on linux 2.6.19.

Enjoy.

Reply Parent Score: 2

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