The Linux desktop space is a real mess at the moment, but KDE is the best of the bunch for general, modern computing.
The Linux desktop space is a real mess at the moment, but KDE is the best of the bunch for general, modern computing.
The artists in that community have some questionable taste (and I thought Keramik was ok, so yeah...) but, overall, the project has a very sane development approach.
I'm a post-3.5 refugee in WindowMaker (and sometimes ratpoison) land, but I honestly think KDE is a big, big deal. It still values customization and still tries to place the user in control of his device, unlike the ahem other guys who seem to be following in Apple's very questionable footsteps.
To their credit, though, Apple does at least think twice before pushing changes most of the time. Gnome's latest effort, with the client-side decorations, is maddening. Now every Gnome application has a thick titlebar that's also a toolbar, and every other application doesn't. They supposedly did that in order to save screen space - which could have just as well been done by reducing the thickness of that mammoth title bar Adwaita uses - but the effect seems to me to have been exactly opposite. Surely someone must have seen that the result is inconsistent on any system that runs a single application not included with Gnome -- say, for instance, Firefox! Or Chrome! Or Emacs! Or Thunderbird! Whatever.
I certainly understand that Gnome developers have a vision for their UI, but the uncommunicative way in which they impose it is pretty unpopular among users (like myself) who moved away from Windows or Mac OS a long, long time ago because they wanted more control over their operating system (well, that and no BSODs, which was a common occurrence at the time when I left Windows behind. Did you know Mac users didn't even have preemptive multitasking then? God I feel like a dinosaur now. Get off my lawn.)
The position of the window resizing buttons is entirely irrelevant when using keyboards shortcuts to control window layout is just much better.
> The position of the window resizing buttons is entirely irrelevant when using keyboards shortcuts to control window layout is just much better.
It's much better when you have your hands on the keyboard. When I have a hand on the mouse already, having to rely on the keyboard is annoying for the same reason why having to rely on the mouse is annoying when you have your hands on the keyboard.
If you really want to see where Gnome is going, please do check out Fedora 22. That really is the showcase for cutting edge Gnome (unfortunately, its not Ubuntu/Debian)
[1] https://extensions.gnome.org/extension/15/alternatetab/ [2] https://extensions.gnome.org/extension/937/laine/
[1] http://bahoom.com/hyperswitch
[2] http://superuser.com/questions/548146/change-command-tab-to-...
It is one of those It-Just-Works experiences.
Of course I've seen https://extensions.gnome.org/ , Gnome is almost unusable without it. But Gnome extensions aren't supported by the core development team. They can (and do!) break from one release to another.
The barrier for "customizing things" is pretty high, too. E.g. if I want to change my window decorations in KDE, I download a new set of decorations and change it. If I want to change my window decorations in Gnome, I have to install gnome-tweak-tool and that-program-that-removes-the-bloody-client-decorations-crap and now most (but not) all of my apps are going to use the decorations I want. With some glitches. That's not ok.
> If you really want to see where Gnome is going, please do check out Fedora 22. That really is the showcase for cutting edge Gnome (unfortunately, its not Ubuntu/Debian)
I don't need to check out Fedora 22, I can already compile Gnome from their public repos. The showcase for cutting edge Gnome isn't too impressive; it can be boiled down to "we really like tablets and you're going to like them too because two releases from now all our applications are going to look like they're running on a tablet."
Some day though I'll go back to straight DWM, my old love.
For better or for worse, they're also experimenting with a lot of new approaches to UI. Which is pretty much how innovation happens -- something that computer desktops could use since everyone else is, at this point, imitating either Mac OS or Windows 95. However, an opt-out solution for users who are happy to encourage innovation, but would rather not be the victim of failed experiments every other release would be nice...
Considering that regularly writing secure servers or browsers seems to be beyond our reach for the moment, I think it's a safe bet to say that writing a secure sandboxing system is even farther beyond our reach. I doubt there is as much to gain in terms of security as we may think.
> The permissions system in android has had a good effect on privacy since you can deny access to private data for individual apps, and if need be to not make it crash you can just feed it empty or random data.
I know that Xprivacy does that in a way that makes me seriously question its security ( if these guys are correct, at least: http://android.stackexchange.com/questions/59093/how-does-th... ). Not sure about PDroid and other solutions (my phone isn't supported by Cyanogen Mod). But it looks like a big pile of hacks over another big pile of hacks to me.
It is harder to breach two layers of security at the same time than one.
> I know that Xprivacy does that in a way that makes me seriously question its security ( if these guys are correct, at least: http://android.stackexchange.com/questions/59093/how-does-th.... ).
This is a vague argumentum ad hominem against a third party. I don't see relevance to my arguments.
> Not sure about PDroid and other solutions (my phone isn't supported by Cyanogen Mod). But it looks like a big pile of hacks over another big pile of hacks to me.
I don't see your point here in regards to this discussion.
I'm not questioning the advantages that sandboxing seems to have, in general. What I am questioning is the ability of the development team that couldn't fix Gnome panel for several years to write a secure sandboxing solution, even when relying on cgroups & co..
Either way, I'd much rather run sane applications that patch and pray that neither the application, nor the jail, have any really disastrous bugs.
> This is a vague argumentum ad hominem against a third party. I don't see relevance to my arguments.
Your argument about permissions and sandboxing on Android is that they help privacy because you can feed fake or empty data to the application. I never managed to do that on my phone (but didn't try that hard, either) so I thought I'd see if there was any progress in that field. Xprivacy was the first result that showed up.
The way it does that, apparently, is by extending /system/bin/app_process to load a JAR file on startup, thus attaching itself to every process and replacing any method in any class. Yeah, no thanks. I can't wait to have the first catastrophic exploit in the Xposed framework making every single process vulnerable.
I tried a couple of other solutions a while ago, but most of them ended up crashing or freezing applications.