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

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.


Don't forget /usr/bin, and /usr/local/bin, and /opt, and /sbin and /usr/sbin. i don't think its particularly descriptive at all, since many programs these days, e.g. python apps aren't even binaries in many cases, and an abbreviation for 'UNIX System Resources' isn't particularly clear. I can understand why some people might prefer the 1970s UNIX way, its just that most people don't, and this is a big reason why desktop users find Linux difficult to deal with.

If you started with a clean sheet or paper, would you honestly end up with /usr/local/bin?


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.


GNOME support for ACLs is an addon application, network file systems don't support them by default without specific mount options, and most bundled archiving utilities won't support them by default either. Any change to file permissions that doesn't use setfacl will also blow the ACLs away. This is really poor from a user's point of view. I'm not talking about the basic ability to manipulate ACLs, its the inconsistent and fragile underlying implementation.

Samba ACLS, NFS4 ACLs, POSIX draft ACLs are all different, its a mess. And the current status quo largely stems from the POSIX requirement that a POSIX chmod operation must result in the files having no more expansive permission than that specified in the chmod bitmask. This requirement is pretty much completely incompatible with a useful ACL system.

While arguing from your own personal ignorance is just dandy, it seems.


I have plenty of experience with ACL problems on Linux, thanks.

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.


So widget incompatibility is an issue then? I mean, I know its an issue, which is why i mentioned it. This is a problem, its a user-visible problem, and solving it, one way or another, would make the Linux desktop much better. Toolkit fragmentation is a very user-visible problem, and while it may be improving, its been a nightmare for years.

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.


Well theres one issue you've managed to avoid. Thats something I suppose.


...and listen to the mac fags groan?


Seriously, implying that people who use macs are homosexuals? Thats wholly inaccurate, and very stupid.

]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. "

Hasn't happened to me.

]To use 'Windows' and 'seamless look and feel' in the same paragraph, is to demonstrate that you're in lala land.


I think apps using windows GUI APIs do seem more polished and consistent than apps using Linux GUIs, in my opinion, yes.

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.


How can the deck be stacked in my favour when Windows has all the problems and Linux doesn't?

I mean, either there are serious user-visible issues with toolkit proliferation on Linux, which makes the deck stacked in Windows' favour because of its corporate-enforced 'somewhat consistent' UI APIs, or those problems (which you have been so stridently arguing against) don't exist on Linux which would mean there was no stacked deck.

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.


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.


I didn't try to pass any of your work off as my own. How do you figure that?

And if DKMS has nothing to do with this, why bring it up at all? Its obvious there are problems with the lack of a kernel API, everyone who writes a driver, closed source or open that isn't integrated into the kernel tree has a problem with this. And everybody who wants to use any driver, open or closed source, that is maintained outside the kernel tree has a problem with it too. People saying 'well <X> works for me, so shut up' doesn't mean the problem doesn't exist.

A stable kernel API would be good for Linux, standards for interoperability are a good idea in general. The 'We must force people to open source their work and integrate it into the mainline kernel by severely inconveniencing them for doing otherwise' is a very childish foundation on which to build a desktop operating system that driver developers should be encouraged to target.

Its not that I don't understand the kernel developers' standpoint, I just think its counterproductive if the linux desktop is to become a reality.

Are you really this obtuse?


I guess so, are you really this aggressive, bigoted and rude? I guess when you disagree with me its perfectly justified but when I disagree with you its all gay, obtuse bullshit?

Reply Parent Score: 2

oiaohm Member since:
2009-05-30

lkeKrull "A stable kernel API" The bugger exists.

Its called Fuse Buse and Cuse. In those you can write about 80 percent of all Linux drivers kernel and distribution neutral. Driver developers would not stay at the Linux kernel stable abis when there was a kernel mode one anyhow.

Basically where are my platform independent driver closed source makers?

Complain about lack of fast Stable Kernel API when they are at least showing signs of being willing to provide Linux with drivers.

Reply Parent Score: 1

earksiinni Member since:
2009-03-27

If you started with a clean sheet or paper, would you honestly end up with /usr/local/bin?


Just wanted to point out that GoboLinux uses /Programs. The real problem with FHS regarding binaries, however, is /lib and its variants. The idea of separating libraries from binaries via folders has merits but wreaks havoc with having a sane human-comprehensible directory structure. Sure, core Windows DLL's are separated into C:\Windows\System or C:\Windows\System32, but that's a far cry from the Linux way. Deleting the program folder in Program Files will pretty much delete the program (yeah yeah, not counting registry and all that stuff).

The real savior for directory simplicity is static binaries, which are feasible now thanks to cheap RAM and hard disk space. Unfortunately, most large projects don't support linking static bins anymore, including X.Org, WebKit, OOo, and Firefox, which I know from personal experience. X.Org can still be done with the defunct KDrive branch, which limps along without any modern acceleration. For office apps and web browsing, though, you're limited to AbiWord, Gnumeric, and eLinks (fun fact: eLinks uses Mozilla's js engine, so it's not actually that bad). Security updates are also a concern with static libs.

Two modern day static-only distros with the explicit aim of simplifying directory structure: stali (http://sta.li/) and Vorpo Linux (http://vorpolinux.sourceforge.net). The first hasn't gotten off the ground yet and the second has only released a boot disk. Give the second one time, though, it's developer is just saddled with writing papers for the time being ;-)

Reply Parent Score: 1

Icaria Member since:
2010-06-19

Don't forget /usr/bin, and /usr/local/bin, and /opt, and /sbin and /usr/sbin
...
If you started with a clean sheet or paper

From the paragraph you quoted:
Abbreviations and current usage aside

Like, good job reading 'n stuff.


I'm not talking about the basic ability to manipulate ACLs

From your previous post:
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.
I'll give you the benefit of the doubt and merely call that equivocal.

So widget incompatibility is an issue then?
Sure, I never said otherwise but lets compare, shall we?
font sizes go all over the place
fails to pick up font hinting settings, fails where the gtkrc defines more than one font (although it's rare that anyone does this)
I'd say there's a good order of magnitude difference, there. Again, you're attempting to use my criticisms to further your argument, throwing out pathetic false dilemmas, either out of an inability to comprehend that this is not a fucking debate, or out of plain ol' douchebaggery. Still not sure which.

Seriously, implying that people who use macs are homosexuals? Thats wholly inaccurate, and very stupid.
Le gasp, I used a common pejorative! Good thing I didn't call anyone a freetard-oops, I just implied that some people are literally retarded. Lord, have mercy.

Hasn't happened to me.
Then you haven't been looking. MS seem to have a great deal of affection for Workbench 1.0 and make a point of recreating it in every inconsistent detail. They'll be awfully disappointed to know that their efforts have been for nought.

I think apps using windows GUI APIs do seem more polished and consistent than apps using Linux GUIs, in my opinion, yes.
Not responding; just quoting for posterity.

How can the deck be stacked in my favour when Windows has all the problems and Linux doesn't?
'So where did you say you were, while you were murdering your wife?'

or those problems (which you have been so stridently arguing against) don't exist on Linux
Double negative, say what? And, "strident", oh my; such subtle rhetorical devices.

How can the deck be stacked in my favour when Windows has all the problems and Linux doesn't?

I mean, either there are serious user-visible issues with toolkit proliferation on Linux, which makes the deck stacked in Windows' favour because of its corporate-enforced 'somewhat consistent' UI APIs, or those problems (which you have been so stridently arguing against) don't exist on Linux which would mean there was no stacked deck.
Bullshit aside, my point remains, if only because it remains unaddressed: it's a lopsided comparison. Even working with the fallacious expectation that Gtk+/Qt4 widgets should integrate with one another, their efforts are reasonably impressive. Once you consider that these technologies are as alien to one another as cocoa and MFC, it only compounds the achievement.

I didn't try to pass any of your work off as my own. How do you figure that?
Repeatedly, rather than defend your own criticisms post-rebuttal, you've opted instead to merely substitute them for my own more tempered criticisms, while continuing to press the same conclusions. It's lazy, the relevance to your conclusions are tenuous and it's just not very good.

And if DKMS has nothing to do with this, why bring it up at all?
...because you mentioned having trouble with drivers, after updating your kernel? DKMS being the solution that evidentially eluded you, I mentioned it. You then, deliberately, or otherwise, mixed it up with the argument relating to the interoperability of desktop software stack.

People saying 'well <X> works for me, so shut up' doesn't mean the problem doesn't exist.
No, it just means that the problem doesn't exist for them. Desktop users simply don't have to deal with that shit, it's taken care of. Next.

The 'We must force people to open source their work and integrate it into the mainline kernel by severely inconveniencing them
...by forcing them to test against the latest kernel, rarely requiring more than trivial changes and testing. Never mind that this is all a non-argument, the moment that you expand the discussion to include the BSDs.

I guess so, are you really this aggressive, bigoted and rude?
Bigoted, strident, aggressive? Enough with the foreplay, baby; lets get dirty. Come on, get to the inevitable allusions to Naziism and lynchings and doing away with the decadent intellectual classes. Don't be a cocktease, go wild. Don't stop, don't stop, keep going. Call me a fascist pig, oh, that's it, baby. Now, finish me off with some pointless victimisation... oh... oh...
I guess when you disagree with me its perfectly justified but when I disagree with you its all gay, obtuse bullshit?
aaaaaaaaaaaah. I came.

Was it as good for you, as it was for me? ;)

I guess when you disagree with me its perfectly justified
It's not?
but when I disagree with you its all gay, obtuse bullshit?
Not all. Perhaps you could clear this up for me: are you in this for the INTARNET GLORY, do you honestly not understand what I am saying and am a bit lost, or are you just someone who neckbeards at the slightest criticism? I'm guessing it's some combination of the above, given your muddled responses and 'you're a bad, bad man' angle. I may be crude, rude and not terribly subtle but I'm a pretty nice guy and I didn't exactly open this exchange with 'you're wrong about everything and *nix doesn't have problems'.

Reply Parent Score: 0