A Glimpse at the Linux Desktop of the Future 759
hisham writes "Every now and then we see articles pointing out "what's wrong with Linux on the desktop." This one gives a nice overview not only of the problems we all know, but also where to look for solutions (app dirs, smarter filesystems) and what's out there (projects trying to change the face of Linux, like Klik, Zero Install and GoboLinux). Still, it usually boils down to things that Mac OS X already has or that are/were touted for inclusion on MS Longhorn. Fortunately, the major desktops stopped playing catch and are focusing on forward-looking Linux projects, like KDE Plasma and Gnome Beagle. Interesting times ahead."
one click (Score:2, Informative)
Linux is ready for the desktop,*especially* for grandma, it just needs to be preinstalled and sold like that in the big retail shops. And frankly, with hard drive sizes like there are now, getting a computer with dozens/hundreds of apps preinstalled and available in the GUI menu tree would tend to negate any reason for grandma to even go looking for more apps. And people who actually have a need for more exotic apps usually have the wherewithal to go find them and install them, on any platform.
Re:Dear Linux (Score:1, Informative)
X-windows allowed me to make modlines for very odd displays with very unusual resolutions..
I have yet to hear why that can't be done for this specific one..
Re:Dear Linux (Score:3, Informative)
Already posted on Linux Today (Score:3, Informative)
FYI, this article has already been ripped to shreds in the comments at Linux Today:
here [linuxtoday.com]
Re:Two stories (Score:3, Informative)
That's been my experience up until quite recently too.
However I got a new laptop for my wife recently, so I thought I'd have a go with ubuntu. Ubuntu was a dream to install, and everything just worked with two small exceptions (suspend and xv) which is pretty good for a brand new laptop.
I was extremely impressed when I plugged my Crucial USB memory stick in, and it just appeared (by magic) on the backdrop.
I believe linux has now caught up in that area!
I don't normally notice this sort of thing though, since I only really use x-windows so I can fit more rxvt & emacs on the screen ;-)
the best of all worlds (Score:3, Informative)
Re:Two stories (Score:3, Informative)
Comment removed (Score:4, Informative)
Re:Dear Linux (Score:2, Informative)
OS/X - why just yesterday I tried to get you to work with my Athlon 64 PC and
Re:Mac OS X didn't work this morning (Score:3, Informative)
Re:I used to care about the "Linux Desktop" (Score:3, Informative)
Actually, Qt does offer a compromise. They offer expensive licenses, which raise the barrier for entry considerably. Basically, two classes of people can develop for KDE:
Ironically, GNOME is an official GNU project, while KDE isn't.
Re:Desktop icons (Score:1, Informative)
Re:Seamless Vs Extensibility (Score:3, Informative)
It's seldom commented because there is no such thing. The interoperability features that KDE provides are way more advanced than UNIX pipes.
Case in point: DCOP [wikipedia.org]. Using the console DCOP client, or the DCOP APIs you can control almost every KDE program from your scripts. For example, if you want to pop up the K menu at the mouse cursor, just call `dcop kicker kicker popupKMenu 0`. Want to switch to the next virtual desktop using your script? No problem: `dcop kwin KWinInterface nextDesktop`.
I don't really understand what your point is. AFAIK (correct me if I'm wrong) there is nothing stopping you from using DCOP calls from a GNOME or XFCE application. If you are interacting with application X from your script, your script naturally depends on X. It doesn't matter if you use DCOP, D-BUS [wikipedia.org] or pipes to do that.
Re:Dear Linux (Score:2, Informative)
Look at it the other way round: Athlon 64 doesn't work with OS/X, Pentium doesn't work with OS/X, iSeries doesn't work with OS/X, Amiga doesn't work with OS/X, Sparc doesn't
Glad the "douches" could perceive the slight tinge of sarcasm and get to the (informative) point of my remarks.
Does that make any more sense?
Nothing sadder than those who complain when the moderators don't accord with their predjudices!
Re:Desktop icons (Score:5, Informative)
It tends to help to read the entire article before commenting. Don't worry, though. You're in good company. A large vocal user base has been misinterpreting my ideas since they've been posted. I'm working on a followup blog to see if I can hammer a few of these misunderstanding out.
Mods? How about a few points so that this correction will appear on par with parent post?
Re:Change the people, not the software... (Score:2, Informative)
Providing an easier interface (an abstraction layer) over the existing tools does not take anything away from the power users. They can always choose to ignore the interface and use the underpinnings directly. For example, I can drive a car but I have no idea of what's going on under the hood. I still have the need to drive the car and every right to do so. Likewise a car mechanic needs and has every right to use a computer. If a person does not have a degree in computer science, that does not mean that he is dumb.
Higher levels of abstraction don't mean decreased efficiency. If they would, we'd still be writing all the software in assembly.
SymphonyOS??? (Score:4, Informative)
Re:Dear Linux (Score:3, Informative)
I followed the instructions which I found here: http://www.help2go.com/postt14349.html [help2go.com]
Hope this is useful to someone.
Re:self-installing applications is a bad idea (Score:2, Informative)
Autopackage allows one to install a package without a root password, so it must install it in the home directory, thereby avoiding any conflict with existing files. I'm not aware of any mechanism that rpm or yum has to automatically detect 'tampering' of already-installed files (such as through a worm or virus). I'm not aware of any measures autopackage takes to ensure that a package is not a virus or spyware, but in theory they could have developers register in a 'trusted packages' list that autopackage would ping each time a user tried to install a package. Then if the package isn't from a 'trusted source' than a dialogue would pop up to warn the user of potential danger associated with installing this package. Then of course, there is the probelm of statically linked libraries. There does seem to be a potential security issue with that, and it would be more of a hassle for the user to update all his apps to plug a security hole. Then again, autopackage could hold a database with a list of all installed libraries across all installed apps, and then one could download a
You can double click a rpm file and have it install itself, but it requires the root password to do so, and it doesn't handle dependencies like autopackage does.
Really, the three major advantages that autopackage has are cross-platform compatiblity with other distros, the resolution of dependencies without being required to go to yum or Synaptic, and faster distribution of software among different distros (one doesn't have to wait for their repos to be updated with the package, one can just go to the developer's web site and install it from their
Re:Linux desktop of the now!!! (Score:2, Informative)
At the moment I'm merging everything with wine, but in a week or so there should be lots of testing to do...
drop me an email at oliver_stieber@yahoo.co.uk and I'll let you know when enough works been merged into wine that many games should be playable.
Sofar the Directx 9 playable games include:
Halflife 2.
Rolercoster tycoon 3
Teenage mutant ninja turtles
Colin Macea rally 2004
Kohan 2
Axis and Allies
The increadables
Warhammer 40k
Evil Genius
Pirates
Robots
Settlers heritage of the king.