Slashdot Mirror

This might be a relevant post from Kwin's main developer.

Let us take something equally ancient on the unix side, like the Xwindows. Is it on by default in linux? Does it suck as much as SMBv1 in terms of security?

Sucking as much is a loaded question. The reality is everything sucks differently. You can't bolt on security without making a mess. Security needs to be thought of from the beginning or the protocol needs to be replaced with something else. Here's a classic example from X: Not only can anything draw on the screen, it can also block other things from drawing on the screen. This has serious implications for something like a lock screen.

If something wasn't thought up when a protocol was created then adding it as a patch can potentially break the existing protocol irreparably. Hence, SMBv2 etc.

Ok sorry but you just lost the interest of 1billion people without finishing that first sentence. dir? what is that? The only time a Windows user types dir is when a scammer calls them up and offers to help "fix" their computer. The people who type dir are sys admins and power users. They aren't the ones that won't learn another OS, and chances are they already know multiple anyway.

Meh, there's always ChromeOS. I kind of wish more people would go to ChromeOS rather than Linux, because now we have Wayland, which locks stuff down "for your protection" like ChromeOS except it's security theater as you can still run arbitrary code which can modify the compositor for example, and boom, you have a keylogger. That's not Wayland's fault, but it's stupid to lock one door and hope someone else doesn't use the other door.

The problem is that in order for certain things to work, you have to extend the Wayland protocol and remove security features. A KDE developer explains the problem in his blog post. He does also say they'll address it in the future though.

Flatpak's Wayland security is passive, not active, it basically offloads the GUI sandboxing to the Wayland compositor and relies on the compositor to implement it. The problem is that the Wayland protocol leaves room for a compositor to expose this information to clients via a protocol extension though the core protocol defines no such channels.

If you use Flatpak with a hypothetical compositor that exposes surfaces and keypresses to clients via a protocol extension then Flatpak won't do much here. KWin exposes window placement and titles to clients via an extension and Flatpak doesn't stop that from happening.

Things like Subuser and Firejail implement active X11 sandboxing, they just Sandbox X11, whatever the server attempts to sandbox, they get in between the server and the client and decide what can be let through and what can't, no matter what protocol extensions the server implements.

No, Wayland fixes all of this. In fact, this is in part why Mir uses the exact same input library as wayland: libinput.

Responding to my own post because I realized that citation is need:
https://lwn.net/Articles/51737...
https://blog.martin-graesslin....

Yes, this seems to be problematic. The developers are aware of these (see this as well) but it'll take some time to fix the problems.

The worst thing in KDE 5 is that they are dropping the support for traditional tray icons.

http://blog.martin-graesslin.c...

KDE on wayland is not complete yet. There has been work for kwin, but one thing is sure: if you want to use it on wayland, you will need, as usual, systemd. Of course, the author points out that this does not imply you will also need to install a web server and a ntp daemon, and that the dependency is on the API not on the program itself, but then show me an alternative implementation i can use. You know, systemd brings nice new APIs and so on, but then I read about the next thing systemd broke. Its in the man page of the shutdown command that this should work.

This is relivant:

http://blog.martin-graesslin.c...

I can't add much to Martin's sage words, but basically the term doesn't have much meaning in and of itself. Its the tech equivilent of stamping a "Natural" label on a box. What does that mean? Almost anything.

The actual article where he says Plasma Next will not (at least initially) support Wayland is: http://blog.martin-graesslin.c...

Why do people go around saying stupid shit?

They don't read the kwin developer's blog?

I went digging after reading this article, here's the only thing I've found:

Mir in Kubuntu

Halfway down, he compares the two - it doesn't look like there's much concrete info about Mir though.

Summary: Philosophical differences in development style, server-allocated buffers vs. client-allocated buffers.

Umm, no.

While the reference implementation currently only supports client side decorations, that's probably more to do with the fact that it's at something closer to Alpha release state than anything else.

The Wayland specification allows either client side or server side decorations.
See this post for more details: http://blog.martin-graesslin.com/blog/2013/02/more-rational-approach-to-window-decorations/

This is a good explanation of the various, numerous, problems of client side decorations.

Too many comments forget Kwin. Which kind of shows nobody really uses KDE4, apparently, because it's a killer feature nobody knows about: It doesn't require GL and can enable and disable it on the fly without losing anything you are doing at the time. Even with automated rules!

KWin's Martin is making KWin leverage OpenGL ES 2.0 out of the box.

http://blog.martin-graesslin.com/blog/2012/09/splitting-up-kwins-opengl-compositor/

The result of this and other adjustments were that instead of gaining one additional backend for EGL we also got a new OpenGL 2/GLX backend and it turned into the default and OpenGL 1 into the legacy backend.

Now fast forward two years. In the meantime quite a lot has happened which I could not foresee when I started the OpenGL ES efforts. One happening is QtQuick 2 which will be used with Qt 5. KWin is already a heavy user of QtQuick 1 and of course we want to use QtQuick 2. But this will bring in a runtime dependency for OpenGL 2. So no matter whether we actually support OpenGL 1 or not, once we are using Qt 5, we will need OpenGL 2. This puts an end-of-life warning to our OpenGL 1 based legacy compositor.

...The change also nicely grouped all the OpenGL 1 code into one area which will be easier to remove once we decide that the End of Life is reached. Removing code is not as easy as one might expect and that is actually quite a project. To go to that direction I plan to introduce a new build option to build KWin without OpenGL 1 support, which is basically the same as the build option for OpenGL ES, but the existing build option could be used for actual differences between OpenGL 2 and OpenGL ES 2.0. And of course EGL needs to be uncoupled from the OpenGL ES build option – it is totally valid to compile the EGL backend for OpenGL.

To put it bluntly, KDE will be OpenGL ES 2.0 and up moving forward.

Like Martin, I'm worried about Client Side Decorations:

http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window-decorations/

I'm worried as I'm not sure they've done anything to address this. I'm certain I will not be touching it unless the window manager can be set to be the one drawing them.

I'll be honest, I was a little sceptical when I read about some of the design decisions in Wayland. In particular, the decision to move some of the window management to the application (in general, that means the toolkit, like Qt, GTK+, etc) makes me wince a bit, because it will lead to the hung-window-syndrome we know and love from MS Windows.

It causes more than that. This is a good read on the problems caused by CSD.

KWin requires OpenGL 3.x? Not bloody soon, if Graesslin is to be trusted.

Everyone should read that post and its comments. It demonstrates wonderfully why KDE 4 will never have a non-negligible userbase.

This conclusion matches the observation of the kwin developers who are brave enough to use GLSL for desktop effects
http://blog.martin-graesslin.com/blog/2010/09/driver-dilemma-in-kde-workspaces-4-5/

Without citations to back it up, the response of some open source devs was, IIRC: The KWin guys don't understand open source. They are meant to get in touch with the driver developers and help getting the bugs resolved, preferable send patches. The clutter developers i.e. sent patches to solve driver problems.

IIRC, the mentioned contribution from clutter devs to the graphics drivers were made by Red Hat employees, which heavily backs the gnome development. Red Hat has lots of money and eve more important expertise in house to tackle such problems. The KWin guys don't have these resources.

Open source gives the means to find, analyze and fix bugs, but its not mandatory. Saying so would mean that one has to know the code bases of every open source library used by his or her application. Thats ridiculous.

The firefox devs sure don't plan to get into linux graphics driver development and thats fine.

The real problem is that the driver teams don't have enough resources (money and developers) to get the job done. I'd be happy to vote with my feet and only buy graphics hardware with good open source drivers to encourage to hardware vendors to hire linux kernel developers. But right now I have to stick with nvidia since their drivers, though not open source and certainly have their own bugs, are the only sufficient choice for OpenGL (and OpenCL) on linux.

Wow, what a troll... you still did not explain anything at all.

What requires more memory? How is that even supposed to be possible at all considering that the very same software stack runs just fine on smartphones whose hardware specs are even lower than of netbooks?

How is supposedly to be technically possible at all that a non-compositing window manager (KWin 3.x) faster than the same window manager that is able to leverage the power of GPUs (KWin 4.x)? The consequence is that the CPU load is lower!
And KWin's main developer is improving KWin's performance even more: http://blog.martin-graesslin.com/blog/2010/10/optimization-in-kwin-4-6/

You could argue that KDE should drop deprecated stuff from the Platform libraries but in order for this to happen, a Platform 5.0 has to be made first! In this case demanding to "fix their code" on one hand and OTOH demanding to not think about 5.0 is a huge contradiction -- one only someone who's either a troll or a clueless person could demand.
And what you completely ignore is that KDE is actually working on further modularizing the Platform via profiles. This work is really happening and not some mind game for some hypothetical event in the future. Platform 4.5 already contains some groundwork.
In the end you may opt-in to use those compile-time profiles but KDE won't support them for their desktop releases because they'll break ABI stability on that platform and features will be sacrificed for them (those which are not needed on smartphones).
As for the desktop platform, KDE is reducing the number of dependencies there as well if those don't lead to binary incompatibility but this is (except a single item on the following list) already done: http://techbase.kde.org/Projects/Mobile/PlatformModifications
Completely dropping deprecated features, btw, only leads to lower disk space consumption and not necessarily lower RAM consumption because application developers are already free to not load those libraries into memory in the first place (IIRC Kontact 1.x and Konqueror are the last two applications that use KHTML by default and Kontact 2.0 is about to be released and Konqueror can use WebKit instead of KHTML -- distributions start to replace Konqueror with the WebKit-based Rekonq anyway...)
And who in the realm of desktop computing actually cares about those few MBs of RAM anyway? My low-end desktop PC has 768MB RAM. The fact alone that I prefer GNOME's nm-applet over KDE's Network Management Plasma applet causes my system to have ridiculous GNOME dependencies (like gvfs-gphoto2-volume-monitor) to be loaded into RAM and it doesn't even matter. 768MB RAM is more than enough to load both KDE's as well as GNOME's base libraries into memory without causing performance lags! Upgrade you PC to have more than 128MB RAM if you feel "bloat".

Whatever your PC's specs are, my point stands: Either you are clueless because you demand contradicting features and omit KDE's actual work. Or you are just a troll.

PS: Linux Journal's Readers' Choice Awards 2010 tie GNOME's and KDE's desktop environments at #1 which wonderfully shows that your claim about "core dev team and a few fanboys" is utterly wrong. As many like KDE's desktop as GNOME's desktop. All other desktops don't have a approval rating of more than 3%.
If your claims were true, LXDE or so would've been far ahead of KDE's desktop...

Whatever they do regarding this issue, I just want to implore the KDE devs to please focus on stability and performance improvements for the next few point releases, rather than adding any more new features.

http://blog.martin-graesslin.com/blog/2010/10/optimization-in-kwin-4-6/