Linked by Thom Holwerda on Mon 18th Oct 2010 21:54 UTC
Permalink for comment 445727
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
More News »
Sponsored Links



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?
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.
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.
So theres no problem?
Oh yeah, there is a problem, isn't there.
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.