Poettering: Revisiting how we put together Linux systems

Posted Sep 2, 2014 13:47 UTC (Tue) by javispedro (guest, #83660)
In reply to: Poettering: Revisiting how we put together Linux systems by torquay
Parent article: Poettering: Revisiting how we put together Linux systems

And then applications will want to use, say, Bluetooth, and then you realize library ABI/APIs is only 10% of the problem.

It extends much further. Simply put, the Cascade of Attention Deficit Teenagers problem prevents every other OSS project from ever committing to an specification. Gtk+ will change its library API. But then Bluez will change its D-Bus specification and all of your containers become useless (library API didn't change). Or Gtk+ decides not to break the ABI, but rather start rendering things in a slightly different way and your window manager breaks (e.g. client side decorations). Etc. Etc.

I just don't see how having a new massive abstraction layer is going to help. In fact, I don't even even see how even a universal abstraction layer is feasible. Efforts like have freedesktop.org have made the most progress (look, icons of Gnome applications now appear in KDE menus! tbh this had been unthinkable for me less than 10 years ago). But now they have been corrupted into furthering the agendas of some people with "visions" instead of trying to be a common ground of disparaging APIs.

Poettering: Revisiting how we put together Linux systems

Posted Sep 2, 2014 15:52 UTC (Tue) by raven667 (subscriber, #5198) [Link]

Most of this breakage you describe already exists in the current system, this proposal is about routing around the damage caused by lack of ABI discipline. You are right that the next battle is then moved to the IPC APIs such as D-Bus services like Bluez, and the proposal already touches on that, but this may be a smaller problem to get API discipline on IPC services than the entire set of shared libraries.

Poettering: Revisiting how we put together Linux systems

Posted Sep 2, 2014 22:33 UTC (Tue) by ovitters (guest, #27950) [Link] (3 responses)

> But now they have been corrupted into furthering the agendas of some
> people with "visions" instead of trying to be a common ground of
> disparaging APIs.

Can you give me any specifics?

For instance, GNOME makes use of logind due to ConsoleKit being deprecated. We actually still support ConsoleKit, though probably it's pretty buggy. The logind bits resulted in a clear specification and allowing even more things to be shared across different Desktop Environments.

We still have stuff like gnome-session. What is does is pretty similar across various Desktop Environments. It was proposed to make use of the infrastructure provided by systemd user sessions, though that's not fully ready yet. This would then allow various Desktop Environments to handle their session bits in the same way. AFAIK, this is something KDE, GNOME and Enlightenment appreciate.

Regarding Client Side Decorations: GNOME is working with other Desktop Environments as well as Window Managers. Suggest to read the bugreports that the KWin maintainer linked to. It's not so doom and gloom as he makes it out to be. Further, it's nice that he dislikes the idea of CSD, but in his Google+ post he sometimes goes too much into anti-CSD advocacy based more on feelings than anything happening. That just on Google+, in Bugzilla + mailing lists he's awesome (don't recall KWin maintainers name on the top of my head -- I assume everyone knows who I am talking about).

The D-Bus APIs changing is a real problem. I'd suggest not calling people names. Lennart wrote how to properly handle versioning in D-BUs interfaces. But yeah, just be an ass and say shit like "Cascade of Attention Deficit Teenagers problem", because that's how you'll get a friendly response from e.g. me (nope!).

> But now they have been corrupted

Get lost with calling me corrupted.

Poettering: Revisiting how we put together Linux systems

Posted Sep 3, 2014 14:24 UTC (Wed) by javispedro (guest, #83660) [Link] (2 responses)

> Can you give me any specifics?

When was the last XDG specification published? Most times I see the freedesktop.org domain referenced these days is because systemd is hosted there, for some reason.

In the meantime, the existing standards are being "deprecated" or ignored e.g. notification icons is at this point not supported by 2 out of the 3 largest X desktops. There's still no replacement even when these two desktops have their own version of "notification icons".

But I do not really want to argue about FDO's mission. I just used how quickly its standards are becoming useless to show how library APIs is only a small part of the problem. The bigger problem is the lack of commitment to standards (I'm not saying I'm not part of this problem, too). Ideally, good reason should be provided when dropping support for an existing and approved XDG or LSB standard. Not "it's just that we have a different vision for Linux". Without that, a generic abstraction layer is just infeasible.

> Regarding Client Side Decorations

I do not even dislike CSDs. But it's just yet another way in which _existing_ cross-desktop compatibility is being thrown down the drain for no good reason. I do not know about KDE but there are plenty other DEs out there some of which don't even use decorations at all.

And this compatibility change would not be fixed either by the proposal discussed in the article.

> say shit like "Cascade of Attention Deficit Teenagers problem"

That is not my quote. E.g.
http://blogs.gnome.org/tthurman/2009/07/02/cascade-of-att...

Poettering: Revisiting how we put together Linux systems

Posted Sep 3, 2014 17:07 UTC (Wed) by jwarnica (subscriber, #27492) [Link] (1 responses)

Its not Thurman's either, one needs to go to JWZ for the source:

http://www.jwz.org/doc/cadt.html

Poettering: Revisiting how we put together Linux systems

Posted Sep 3, 2014 22:46 UTC (Wed) by nix (subscriber, #2304) [Link]

... and attacking JWZ for using hyperbolic terminology is like attacking water for being wet. To JWZ, ranting is performance art.