Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 7:18 UTC (Wed) by drag (guest, #31333)
In reply to: Distribution-friendly tactics in the desktop wars by ballombe
Parent article: Distribution-friendly tactics in the desktop wars

Well... It is important to realize that the purpose of a OS is to make it easier to write and develop applications.

So requiring high-level software that works in the majority of cases to take on the burden of maintaining support (and the resulting increase in complexity and bugs that goes along with it) in order to support a minority of cases is really a anti-pattern.

Unless the app dev wants to do something stupid or dangerous to the OS environment then it's the job of the OS to make it as easy as possible for them to serve their users in the best possible way.

The functionality provided by logind and similar software is valuable. It makes sense. If it was superfluous or frivolous functionality then it makes sense to protest it, but it's not.

Another way to look at it is this: If KDE is forced to conform to a particular distribution then the burden of that choice (increased lines of codes, bug count, maintenance. etc) will be born by every KDE user everywhere and it's on the shoulders of KDE developers to maintain it. Does it make sense that for the sake of Slackware (and other non-systemd distros) every KDE install from OpenSuse, Debian, Fedora, etc has to pay a price?

Then what about Gnome? What about LXQT? Every environment for every LInux OS will pay the price for Slackware's imposition. (not trying to pick on Slackware here. It's just the example in the article)

It's a snow balling maintenance burden for the sake of 'choice'.

If, on the other hand, non-systemd distros work together (possibly with the BSDs as well) to provide a good way to support the APIs and functionality that desktop environments are depending on then they are the only ones that bare the burden of their choices. Also they gain compatibility and a higher degree of 'future proofing' as Linux distributions diverge further as systemd and 'linux plumbing' continues to evolve.

Also this may help keep the systemd devs honest by helping to shape the APIs and making sure that implementation-specific decisions don't negatively impoact functionality that high level software wants and/or depends on.

Distribution-friendly tactics in the desktop wars

Posted Apr 7, 2016 17:44 UTC (Thu) by hitmark (guest, #34609) [Link] (9 responses)

" The functionality provided by logind and similar software is valuable."

Embrace, Extrend, Extinguish, anyone?

Distribution-friendly tactics in the desktop wars

Posted Apr 10, 2016 3:22 UTC (Sun) by flussence (guest, #85566) [Link] (8 responses)

I get the implications there, but I'd suggest a new catchphrase for RedHat... maybe “FOSS, Force, and Forget”.

There's no garbage collector for projects that get ejected from the “ooh shiny” rewrite treadmill; they accumulate like radioactive waste as dependencies of other code. If you're lucky the new shiny will be backwards-compatible ad infinitum, or even coexist side-by-side with the old stinky, and you only suffer the standard costs that a total rewrite from scratch always inflicts.

But sometimes you get unlucky and RedHat decides You Will Use ude^Wsystemd-udevd now, not HAL, and all those DRMed movies you bought online no longer work. (What, people *used* our old stinky library? How dare they! systemd-udevd has always been a critical part of every distro's boot, how else are they going to load bus1.ko when it's needed by PID1?)

To drag this tangent back in a more topical direction: I predict that Qt4-libQt3support.so will outlive $kde5¹-kdelibs4support on most distros.

¹ -- shorthand for whatever KDE3+2 currently identifies as.

Distribution-friendly tactics in the desktop wars

Posted Apr 11, 2016 14:29 UTC (Mon) by tao (subscriber, #17563) [Link] (7 responses)

Yes, because staying with HAL would've been so much better, because it was such an excellent piece of software, completely without issues.

Face it, sometimes it takes multiple iterations to come upon a good solution.

systemd (combined with udev), by the looks of it, is that good solution.

Distribution-friendly tactics in the desktop wars

Posted Apr 12, 2016 2:25 UTC (Tue) by hitmark (guest, #34609) [Link] (6 responses)

Iterations are not really the problem, the interface churn on the other hand...

Note that at the kernel level, there is a whole lot of fretting about getting the interface right. Because Torvalds will hold everyone to maintaining that interface once it had been ntroduced to the world.

By contrast, logind didn't carry over the consolekit interface. Instead the consolekit2 devs are busy chasing the logind tail by trying to maintain interface compatibility.

This while at its most basic level, X11 still behaves at it did when released. If you wrote a straight xlib back then, it would likely still work today.

Distribution-friendly tactics in the desktop wars

Posted Apr 12, 2016 12:33 UTC (Tue) by tao (subscriber, #17563) [Link] (5 responses)

Wayland isn't X compatible though (though there will be an X-server on top of Wayland, just as people write consolekit2 on top of logind). Sometimes you have to tear down and start anew if the foundation just isn't solid enough any more.

Distribution-friendly tactics in the desktop wars

Posted Apr 12, 2016 16:27 UTC (Tue) by hitmark (guest, #34609) [Link]

Well for one thing Wayland is pretty much just a protocol, and X can use it instead of a GPU driver, thus effectively operating as a compositor.

And consolekit2 is not on top of anything. It is a fork of the consolekit code that tries to offer an alternative implementation of the logind dbus interface alongside the consolekit interface.

Distribution-friendly tactics in the desktop wars

Posted Apr 12, 2016 20:55 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

> Wayland isn't X compatible though

but will this really matter if everyone runs an X server on top of Wayland so that they can continue to run apps that don't choose to lock themselves to Wayland?

Distribution-friendly tactics in the desktop wars

Posted Apr 12, 2016 21:00 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

> but will this really matter if everyone runs an X server on top of Wayland so that they can continue to run apps that don't choose to lock themselves to Wayland?

Applications themselves typically don't care about whether they are running or top of X or Wayland or XWayland.

Distribution-friendly tactics in the desktop wars

Posted Apr 12, 2016 22:16 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

> Applications themselves typically don't care about whether they are running or top of X or Wayland or XWayland.

that depends entirely on the graphics calls they make. If they use some library that abstracts it away, then they may not care (unless they were statically linked with the X version of the library), but if they use something that doesn't jump on the fad to re-write all graphics stuff, it very definitely cares.

Distribution-friendly tactics in the desktop wars

Posted Apr 12, 2016 23:05 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

>that depends entirely on the graphics calls they make

Umm, that's what typically means here.