Distribution-friendly tactics in the desktop wars

By Jonathan Corbet
March 29, 2016

For many aspiring projects, getting accepted and shipped by popular distributions is an important step toward a long and successful life. But even large and established projects can struggle in this area. The distribution outreach program recently launched by the KDE project hosted a discussion making it clear that KDE cannot count on the support of distributions without supporting them in turn. If the participants are to be believed, KDE's second-place position in the desktop competition can at least partially be attributed to how the project works with distributors.

It all started when Eric Hameleers, a KDE packager for Slackware, posted a complaining blog entry. He ran into some trouble making KDE 5_16.03 work properly, and eventually got a message telling him to log in and run a loginctl command. What came next may not surprise too many readers: loginctl is a systemd command, and Slackware has no intention of moving over to systemd. So, Eric wrote in frustration, "WTF!!!! Slackware does not have a steenking systemd you crazy KDE developer."

Martin Graesslin responded on the outreach program mailing list, asking that distributors take their complaints, in a calmer tone of voice, to the project's mailing lists rather than to public blog posts. He pointed out that KDE does not require systemd; all it needs is something that can implement the appropriate D-Bus interface. ConsoleKit2 can fill that need as well as systemd's logind daemon. Beyond that, he said, the KDE project cannot be expected to have the resources to deal with systems that its developers are not using: "If your distro doesn't follow what 99% of all other distros do, don't expect we write code for it!" The project will happily accept patches to support such systems, but it won't write them itself.

At this point, openSUSE developer Richard Brown stepped in to point out what, he said, is perceived as an attitude problem on the part of the KDE developers. KDE is not seen as a core part of many distributions at all anymore, he said, so it is not in a position to make demands on those distributions. He advised the project to "change the mindset" and work on making it easier for distributions to integrate KDE. That includes listening to the complaints coming from distributors and providing more information to distributors about upcoming changes before those changes happen so that plans can be made.

As might be imagined, it didn't take long for GNOME to enter the discussion as an example of a different approach to distributions. Slackware developer Heinz Wiesinger was quick to claim that GNOME "has a history of making questionable choices" and is not really relevant to the discussion. But Richard disagreed, stating that GNOME's popularity gives the project the leeway to make questionable choices, while KDE lacks that. The trend for KDE, he said, is not positive:

We've seen this trend mirrored even within openSUSE. Even as KDE with the default option in our installer, over recent years we've transitioned from a strong 'majority KDE' distribution to one where KDE is now used by less than 50% of our userbase.

To be able to compete at this point, he said, "KDE has to be better, smarter, leaner". It has to be easier to package, should consider getting rid of second-tier or redundant applications, and needs to market itself better. "KDE needs to make it very easy for distributions to sell the premise, promise, and benefits of using KDE to their users."

KDE developer Thomas Pfeiffer wondered about what it was that makes GNOME more appealing to distributors. He acknowledged that the GNOME project has gained some credibility after the controversial 3.0 release by "constantly providing great releases". But, he said, one of the things that makes it easy to produce those great releases is that the GNOME developers don't really have to care about anything outside of the GNOME world. He was unsure that "easier to package" would be the tag line that would bring KDE back into the top tier, but he did agree that providing better information to distributors about which applications are best to ship would be useful. In another message he admitted that "even I as a core KDE contributor do not know what is or isn't currently maintained, or who maintains what within KDE."

In the end, Richard said, it comes down to trust. Distributions need to be able to trust a software project not to spring unpleasant surprises and to be supportable over the long term.

Even the great big change to GNOME 3 didn't come as a surprise, with clear plans laid out well in advance. GNOME work very hard to pro-actively communicate with Enterprise distributions about what they are doing, while simultaneously listening to their concerns and working to address them. It's quality was not perfect at release, but was acceptable. The initial GNOME 3 versions at least achieved what they set-out to achieve.

This kind of approach, he said, makes GNOME easy for enterprise distributions (among others) to deal with. It also helps those distributions pick up new GNOME releases with confidence, since they know what is coming and can expect it to work well. The KDE 4 experience was different, he said; it had no clear goals and the quality was not good. The Plasma 5 release looks, to distributions, like a similar experience. KDE's mission still "remains pretty much an unspoken mystery" and there's no way for distributors to easily cut through that mystery. The lack of clear goals also makes it harder to bring in developers (he worries that KDE is losing developers over time), and ongoing quality issues turn away both distributors and users. In the end, he said:

That is not a foundation upon which I think any Enterprise can put their faith into. Especially when you consider they are often thinking with a mindset of "can we support this for *years*?". There just isn't enough clear communication or quality technical execution in either the short-term or the long-term from KDE at the moment for that level of trust to exist.

These are some fairly strong words. But they came from a supportive developer at what is arguably the most KDE-friendly large distribution in existence, so they were taken seriously. Among other things, Thomas said that the project is indeed working on a statement of its vision, for both KDE as a whole and Plasma in particular.

In recent times, the KDE project has put some effort into making it easier for users to test upcoming releases. Things started with KDE Neon, which is an Ubuntu live image with a current KDE build installed; the Argon and Krypton releases will do the same thing with openSUSE Leap and Tumbleweed, respectively. But Richard warned against relying on users for early testing; instead, he said, KDE should be doing the sort of automated early testing that GNOME does. KDE (and openSUSE) developer Luca Beltrame pointed out that some of this infrastructure does exist — build.kde.org, for example — but it lacks the support to become a truly useful resource.

The discussion did not lead to any dramatic changes of direction on KDE's part, at least none that are visible now. But it may have planted some seeds within the project. Projects that aim for a high level of success, as KDE does, cannot expect to get by on technical quality alone — even if they don't go through a period characterized by quality problems. Like it or not, the resulting software must be sold, and, in the current world, selling to distributors in particular remains important. Someday, maybe, the efforts to circumvent distributors will see some success; for now, though, they remain the gatekeepers, and it is difficult for a project to succeed if it creates difficulties or worries for them.

to post comments

Distribution-friendly tactics in the desktop wars

Posted Mar 29, 2016 18:55 UTC (Tue) by arjan (subscriber, #36785) [Link] (6 responses)

There's a set of simple things projects can do the be more friendly (or unfriendly) to distributions... (speaking as someone who builds a distribution).

Good things
* Use a standard build/make system (autoconf, cmake, python setuptools, whatever, something that is pretty widely used)
* Clear license declaration (COPYING file)
* include unit tests (make test/make check); a distribution can and will use this this to verify they integrated the component correctly
* use pkg-config for dependencies
* regular releases, at least for bugfixes and security fixes (bonus points for having maintenance releases against latest stable in addition to more major releases, but rolling release is fine)
* Know what an "ABI break" is if you are providing a library
(Note: C++ makes it much harder to keep ABI, but it can be done, see the Qt folks)

Bad things
* Custom Makefile hackery that is not parallel build safe or ignores DESTDIR etc etc
* Unit tests that fail always on the official release
* No clear declaration of license
* Have "creative" ideas on where files go... when in doubt, please just follow the FHS.
* Not using the system CFLAGS, but thinking you know better
(expanding by adding things to the system CFLAGS is fine, but don't throw the distro provided flags away)
* Adding -Werror to CFLAGS.... newer versions of compilers add warnings, and -Werror will just require distros to patch -Werror away again

Distribution-friendly tactics in the desktop wars

Posted Mar 29, 2016 19:52 UTC (Tue) by josh (subscriber, #17465) [Link] (1 responses)

> * Adding -Werror to CFLAGS.... newer versions of compilers add warnings, and -Werror will just require distros to patch -Werror away again

In particular, if there are classes of warnings you want to keep out (and they're *not* the kind that tend to vary across compiler versions or optimization levels, like those for unused variables), add -Werror=specific-warning rather than -Werror. That way, if a compiler adds a new default warning, that won't break the build.

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 16:09 UTC (Wed) by admalledd (subscriber, #95347) [Link]

Or, if you use this and the compiler gets *smarter* about that warning and finds another few places it happens, that is nice as well. Happened on a small project we have internally here, new compiler on one of the build servers broke the build and we were happy it did! Well, not the developer who had to go fix it since it hadn't been touched in about five years...

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 6:43 UTC (Wed) by pabs (subscriber, #43278) [Link]

Another list of suggestions:

https://wiki.debian.org/UpstreamGuide

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 17:15 UTC (Wed) by flussence (guest, #85566) [Link]

As a Gentoo user who occasionally struggles to package distro-oblivious software, I can vouch for this list's accuracy.

If something needs patches and sed hacking of its build system just to compile at all, to run its tests — assuming an upstream provides that luxury — and to get it to run properly, it's a pretty likely indicator that either: a) every *other* distro also has to duplicate that effort and upstream is ignoring complaints about it, or b) nobody cares enough about the software (or its developers) to even complain any more.

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 18:21 UTC (Wed) by javispedro (guest, #83660) [Link]

I think that most of these do not really apply to KDE, since they mostly tend to center on cmake with the eventual autotools/qmake project.

I'd like to add a new one that in my (short) experience has been the most annoying one: huge, complex webs of dependencies. There's not much that can be done to avoid this, but really, it's still #1 predictor of time wasted packaging. Even an awful build system it's still just a few minutes of hacking, but having to do +50 libraries, python modules, ... just for one calculator program means a full wasted day.

Distribution-friendly tactics in the desktop wars

Posted Mar 31, 2016 7:45 UTC (Thu) by grawity (subscriber, #80596) [Link]

GNOME has a "Build API" for the first point.

Distribution-friendly tactics in the desktop wars

Posted Mar 29, 2016 20:56 UTC (Tue) by rknight (subscriber, #26792) [Link] (4 responses)

I had some difficulty following the discussion until I realized that the Robert mentioned in "In the end, Robert said, it comes down to trust." is actually Richard. You may want to fix that reference.

Distribution-friendly tactics in the desktop wars

Posted Mar 29, 2016 23:42 UTC (Tue) by rhekman (guest, #102114) [Link] (3 responses)

I struggled with the same. In fact, the distance between name mentions is a common (minor) complaint of mine with LWN articles. At first I just assumed I missed who "Robert" was, but got more confused when a ctrl-f didn't find a previous citation.

Maybe it's just my ADHD, but if Jonathan could tweak his writing style to use full names more frequently it would be much appreciated. LWN is consistently one of the most well written and researched Linux news outlets in my opinion. Maybe this bit of constructive criticism can make it even more so.

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 6:53 UTC (Wed) by dagsdfgsfhf (guest, #107852) [Link] (2 responses)

At risk of "piling on" I have to agree with both of you. I had to reread the meat of this article three times before I had a reasonably clear idea who was saying what and why they were saying it.

I was also forced to recursively reread the four previous paragraphs to figure out what distro is "arguably the most KDE-friendly large distribution in existence".

Distribution-friendly tactics in the desktop wars

Posted Apr 7, 2016 13:49 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

Given the comment elsewhere that Jon tends to refer to people by their first name, and Jake by their second, is there any chance that LWN could decide that it's good style to refer to someone by their *full* name the first time you mention them?

Various publications have that rule with abbreviations - that they must be expanded on first use - and with an international readership that makes a lot of sense (cf my confusing Obamacare with American Citizens Abroad a few stories back :-)

Cheers,
Wol

Distribution-friendly tactics in the desktop wars

Posted Apr 7, 2016 14:04 UTC (Thu) by jake (editor, #205) [Link]

> Given the comment elsewhere that Jon tends to refer to people by their first name,
> and Jake by their second, is there any chance that LWN could decide that it's good
> style to refer to someone by their *full* name the first time you mention them?

This we consistently do. It is only on second references where we differ.

jake

Distribution-friendly tactics in the desktop wars

Posted Mar 29, 2016 21:42 UTC (Tue) by ovitters (guest, #27950) [Link] (4 responses)

> He pointed out that KDE does not require systemd; all it needs is something that can implement the appropriate D-Bus interface.

That's pretty similar to the GNOME situation. Despite explaining this over and over, it's usually conveniently ignored.

> GNOME's popularity gives the project the leeway to make questionable choices

Someone else from KDE said that once better: More people on GNOME side are also working on more lower level/infrastructure parts. As a result it makes more sense to assume the lower level parts should be in a certain way. The rest is just announcing at least 6 months in advance what is going to happen.

e.g. GNOME Software in 2.22/September will also be able to handle GNOME shell extensions. Pretty cool, but GNOME software might not be packaged or not work properly (it could require some work on distribution side to ensure all the bits it depends on work properly). So I (have to.. didn't yet) announce that preferably 6 months in advance. This gives as much time as possible for distributions to thing about it, check if something needs to be done, fit it into their schedules, etc.

Regarding the title:
> Distribution-friendly tactics in the desktop wars

Developers and contributors of desktop environment usually are just ambivalent about other desktops because it is not in their interest area. But in case there's something which is better done across desktops, we work together. Desktop wars? Though things could be better, desktops work together. It's rather stupid to compete between free desktops while the amount of people using these desktops is tiny compared to the non-free ones.

KDE and GNOME release teams once had a talk to share how we do things; what worked and what did not. The way of working on KDE as well as GNOME significantly differed on some parts while both never gave a thought about doing it any other way. We both learned quite a bit from that and probably could do with a repeat.

> KDE's mission still "remains pretty much an unspoken mystery" and there's no way for distributors to easily cut through that mystery.

Sometimes just announce what you think of something. E.g. "this new stable version of this module? Yeah, it is not really stable and totally changed lots of things. Maybe hold off for at least a few months/next stable distribution release". Or ask for assistance. Software only stabilizes if more people use it and most people hate using live images and/or don't use it daily.

> KDE should be doing the sort of automated early testing that GNOME does.

Ideally you want your unstable stuff in everyone's unstable distribution channel. Way more testing! I usually dump everything into Mageia Cauldron. Unfortunately Mageia often has 6+ months freezes. During those times GNOME is IMO buggier (due to usage.. I suck at QA).

But aside from that: GNOME had a jhbuild type autobuilder for a long time. All those error messages were almost completely ignored. The current setup (ostree) makes the development way easier for developers. E.g. you can easily revert back to an earlier builds (of all the 200+ modules without eating up a lot of disk space). Colin Walters did some amazing work here. Keeping an auto builder running takes quite a bit of effort. E.g. upstream git is broken so revert to tarball or some specific git comment. Adding dependencies, etc. It's often seen as a sort of checkbox while it is actually more of an ongoing task.

There's various other bits: Ensure maintainers don't suddenly add new features in stable releases, etc. Lately we've lost a bit of focus IMO.

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 18:46 UTC (Wed) by louie (guest, #3285) [Link]

"I suck at QA"

Hah. ;)

GNOME without systemd

Posted Mar 31, 2016 12:10 UTC (Thu) by civodul (guest, #58311) [Link] (1 responses)

FWIW, in GuixSD (which doesn't use systemd) we extracted logind: https://github.com/wingo/elogind . See https://savannah.gnu.org/forum/forum.php?forum_id=8491 for details.

GNOME without systemd

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

There is also a consolekit fork by a XFCE dev that implements the logind dbus interface.

https://github.com/ConsoleKit2/ConsoleKit2

That still leaves the issue of doing continual catchup with the systemd/freedesktop devs as they shift things around. Like making upower basically a compatibility shim on top of logind, now expanded to handle laptop power management (and something similar is going on with udev, iirc).

The whole thing starts to take on the shape of Wine vs Microsoft, where one is constantly chasing the tail of the other.

Distribution-friendly tactics in the desktop wars

Posted Mar 31, 2016 17:27 UTC (Thu) by walters (subscriber, #7396) [Link]

To clarify a bit, the build system you're referring to is Gnome Continuous, whereas ostree is not a build system, it's a tool for transporting and managing content that can be used also as an implementation component for build systems, as GContinuous does. Other variants are xdg-app which implements a different build system on top of ostree, and rpm-ostree currently just reuses RPMs.

Distribution-friendly tactics in the desktop wars

Posted Mar 29, 2016 23:26 UTC (Tue) by ballombe (subscriber, #9523) [Link] (23 responses)

If a software displays messages saying to use some program, then it pretty much requires this program, whatever its developers opinion about the dependency.
Do not blame users for misconceptions induced by your software, fix it!

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 6:36 UTC (Wed) by mgraesslin (guest, #78959) [Link] (11 responses)

No really. I added that feature and no it's not like we depend on anything there. It's a fallback for the case that the lockscreen crashes constantly. This is something which is from the category "cannot ever happen", but happens for whatever reasons.

Now the lock screen integrates with logind to unlock the session. That works if logind is available and doesn't matter if it's not available.

What we did was pretty straight forward: hmm black screen doesn't help the user. Let's print "lock screen is broken", great doesn't help the user. But wait there is the logind integration, let's tell them also that they can use it to unlock.

So yes there is a bug on our side: we didn't consider how the non-systemd users would explode if they see this. We should have gone with "lock screen is broken, you have to hard reboot".

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 9:24 UTC (Wed) by ballombe (subscriber, #9523) [Link] (10 responses)

You could just have prefixed it with "If you use systemd then you can ..." and avoid misonceptions.

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 9:43 UTC (Wed) by niner (guest, #26151) [Link] (1 responses)

Arguably most users don't know that they are in fact using systemd while most users who don't use systemd do know. Why's that? Because right now the only major distros that don't use systemd are Slackware and Gentoo (in it's default installation). Both target rather advanced users who just tend to know more about their systems.

And indeed the fuss was not about a user being told to use loginctl and not finding it, it was about the user feeling rather strongly about systemd and taking offense at the assumption that he was using systemd.

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 20:18 UTC (Wed) by roblucid (guest, #48964) [Link]

Yes, a maintainer might check for existence of the systemd command, and vary the message to the reboot option when not present.

Our software gets stronger through collaboration on improvements, expecting upstream to know about your environment, doesn't make sense, nor does upstream not being open to feedback, from distro packagers.

What no-one needs is a hissy-fit!

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 10:02 UTC (Wed) by mgraesslin (guest, #78959) [Link] (7 responses)

Which means making the experience for everyone. It would be better to have a solution for each of the different ways to do it. But that needs people who don't use logind to step up and write the code. Otherwise it's not going to happen.

And to be completely honest: we did not even think about the possibility that logind is not provided. Sometimes when 99 % or even more are using technology A you forget that there is a technology B.

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 13:31 UTC (Wed) by Seegras (guest, #20463) [Link]

>Sometimes when 99 % or even more are using technology A you forget that there is a technology B.

Yes, this is called the Windows-User defense.

I got that from a developer last month, "I didn't even think a Linux user could run my (.NET)-program; so I hardcoded \ at the end of all paths.."

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 13:59 UTC (Wed) by johannbg (guest, #65743) [Link] (4 responses)

Supporting every downstream fragmentation as in whim and forks which exist out there due to philosophical, personal or political difference makes no sense ( especially fragmentation in the core/baseOS layer ) and does not work in real life for upstreams, it just keeps them busy chasing their own tail when trying to please everybody, wasting everybody's *contributed* time, resources and focus which could be spent on more practical things like fixing and enhancing their own application or application stack instead.

I failed to see why some upstream somehow feel they are compelled or obligated to do that.

Has the KDE community done any calculation how much contributed time it costs it's community supporting the existing fragmentation in the downstream ecosystem?

Arguably these days, desktop environments should be shipping and providing their end user base with their desktop from the ground up ( GnomeOS,KDEOS etc and associated app market ) where they have complete control over their product and receive feed back directly back to them from their end users ( as opposed to have that feedback proxied to them ), which in turn, will strengthen their own community, increase contribution directly upstream and will help shaping their project directly as it moves forward.

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 16:14 UTC (Wed) by jospoortvliet (guest, #33164) [Link] (2 responses)

While I don't black-and-white disagree, it's an argument for only supporting one distribution ;-)

Considering the silly arbitrary differences between distributions :(

Loving this example:
https://build.opensuse.org/package/view_file/isv:ownCloud...

# For beta and rc versions we use the ~ notation, as documented in
# http://en.opensuse.org/openSUSE:Package_naming_guidelines
# Some distro's (centos_6) don't allow ~ characters. There we follow the Fedora guidelines,
# which suggests massaging the buildrelease number.
# Otoh: for openSUSE, this technique is discouraged by the package naming guidelines.

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 17:06 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

That is annoying but isn't arbitrary. RHEL/CentOS 6 has an older RPM which doesn't support ~ character for versioning.

Distribution-friendly tactics in the desktop wars

Posted Mar 31, 2016 7:57 UTC (Thu) by pmatilai (subscriber, #15420) [Link]

Actually it does, for more than three years by now, see: https://bugzilla.redhat.com/show_bug.cgi?id=825087

At that time the Fedora buildsystem still ran on RHEL underneath and the tilde support was backported to make its usage possible in Fedora. Tilde on Fedora is still banned to this date but rpm in RHEL 6 does actually support it, yay...

Distribution-friendly tactics in the desktop wars

Posted Apr 12, 2016 8:19 UTC (Tue) by DeletedUser102083 ((unknown), #102083) [Link]

See my comment below. Let's make it happen.

Distribution-friendly tactics in the desktop wars

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

" And to be completely honest: we did not even think about the possibility that logind is not provided."

Then stop chasing the latest shiny!

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 7:18 UTC (Wed) by drag (guest, #31333) [Link] (10 responses)

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.

Distribution-friendly tactics in the desktop wars

Posted Mar 30, 2016 1:33 UTC (Wed) by rahvin (guest, #16953) [Link]

For all the early hatred of Gnome 3 I like it. I particularly like what Debian has done with it in Jessie.

Admittedly I haven't used KDE since the 4.0 debacle but one of the things I totally agree with the statement that no one knows where KDE is going. I've looked at the documents and websites and I couldn't tell you a thing about what they plan to do and where it's going in the future. Gnome is constantly telling people what they are planning. What is the overall design goal for KDE? Gnome seems to set clear design goals (even if they piss everyone off and then ignore all the complaints).

Fish and autobraces

Posted Mar 30, 2016 9:16 UTC (Wed) by rvfh (guest, #31018) [Link] (11 responses)

I am a _very_ long time KDE user, and I keep using it in a company that only knows 'Ubuntu' (even though users complain about Unity.) I have to say that I am running more and more fed up with features coming and going. The two features I used most are currently broken in Kubuntu, since 15.04 IIRC: fish (open a file via SSH from any KDE application) and autobraces (automatically add the closing bracket/quote when opening one, and in the old times also added brackets around selected text.)

As a developer who uses a small laptop to edit/build on remote servers, writing code in Kate, those two features were of course very important to me. Also, Kate only supports CTAGS. Over time, no support was added for CScope or Global, which I find a pity.

Oh I can hear the train coming of the 'if you want something implemented, do it yourself', except that I don't have time for this and will prefer just to switch to that editor that already has the features. And if I don't use Kate, then what do I need KDE for? Konsole? All my other apps are generic: Firefox, Thunderbird, Meld... The bugs are filed, I now use KDE 16.04 and it still is broken.

Fish and autobraces

Posted Mar 30, 2016 11:24 UTC (Wed) by halla (subscriber, #14185) [Link] (10 responses)

"I don't have time for this"

Well, that's the real problem. The real problem KDE is facing isn't that we don't release regularly and correctly, it isn't that we don't have CI, it isn't that we don't build on a good platform, or that we don't have an excellent desktop environment or a great set of applications. It isn't that we're not in touch with distributions, and it isn't that we don't know what we're working on.

It's that we've got too much code, and too many users who "don't have time for this" and not enough who put in some time. KDE has next to no sponsored developers: BlueSystems sponsors a few developers, Krita has one sponsored developer, and that's _it_. KDE has stayed much, much, much more dependent on volunteers than any other big free software project that is still active.

The only thing that resonated in the original article was "maybe we should stop releasing pieces of code that aren't maintained anymore." But that, of course will only lead to _you_ saying again " have to say that I am running more and more fed up with features coming and going".

So, what can we, as a very nearly 100% volunteer organization do to motivate people like you to volunteer some of their spare time to help maintain the features you depend on that you don't want to see go?

Fish and autobraces

Posted Mar 30, 2016 12:09 UTC (Wed) by rvfh (guest, #31018) [Link] (9 responses)

Thank you for your answer, and for the hard work you guys do on KDE. This being said, you seem to be missing my point here: the feature was there, it was working, and people were happy with it. Then it got broken. Twice.

At some point someone decided that it should not be a program feature anymore, but a much improved plugin. Too bad the plugin could not do what the feature used to.

And then again, some refactoring was done which AIUI forced all plugins to be re-written, but - bad luck! - the autobrace plugin was not lucky enough to be picked. Release 15.08 was targeted to have it back, but Kubuntu 16.04 uses release 15.12 and it's still not in the list (seems to need rewriting from scratch).

Now you tell me that you have too few people working on KDE? In this case, why do you keep rewriting things and breaking user features along the way? Why not stabilise things instead, so your users don't go from bad surprise to very bad surprise (KDE 4.0, Plasma 5) at each release?

Or you say you have too few testers? Does that mean nobody in KDE uses Kate (or should I say ktexteditor) to write code then, so they're not missing the autobrace feature?

Sorry to be so negative, but KDE changes very quickly, and sometimes I just wish it would calm down and let the dust settle a little.

improved vs. stable vs. motivation

Posted Mar 30, 2016 17:13 UTC (Wed) by tpo (subscriber, #25713) [Link] (3 responses)

> but KDE changes very quickly, and sometimes I just wish it would calm down and let the dust settle a little

I feel the same about pretty much everything software. I generally just want work to be done and that's pretty much it. And if the tools I use don't work then that sucks. The more the tools change, the more often I need to adapt, get other tools etc.

However maybe that's just a reflection of the evolution that happened over time in the open source space.

I remember in the "old days" when I'd spend maybe a third of my time reporting bugs, fixing stuff, sending patches etc. while using Linux. I no more do. Stuff more or less just works and works quite reliably. So there's no need to change anything any more. The only time that change comes along is when you need to upgrade.

So when stuff just works and people don't want it to change then how does the change - that will unevitably come along - come into existence? This is no more the old times when people would charge forward and change things. Or is it just me? There are expectations from software and distribution users, that the SW author or integrator will not break stuff.

And I suspect that "working" under such premises might not be so exciting any more. So maybe without us really noticing our open source world has slowly changed under our eyes from "we do it for free because we're motivated by how fun and exciting it is" to a more standard corporate world where you do stuff if and when you get a pay and use your non-work time for family or something else outside of open source?

So my open question is, do we as a open source community maybe need to reconsider our perspective? Should we start to expect to pay for the next stable and tested open source software release? Should we have different expectations towards projects and people that try to experiment, improve and invent new stuff and move it forward than towards "production quality" software?

The reason I am using Xfce is that it doesn't seem to be moving much and is stable and I am not aware that I'd really *need* any additional features out of it. In contrast it seems that both KDE and Gnome seem to be regularily colliding with the apparently contradictory expecations of "all shiny new and exciting" and "stable and upwards compatible".

improved vs. stable vs. motivation

Posted Mar 30, 2016 20:27 UTC (Wed) by roblucid (guest, #48964) [Link] (2 responses)

yes, it's like these "new looks" that get developed, that come & go in cycles and leave me, totally bemused, as quite often they're not as good as the old one.

I guess it's bike shedding.. ppl want to change somethign and aesthetics are the easiest to feel qualified for. :(

improved vs. stable vs. motivation

Posted Mar 30, 2016 22:34 UTC (Wed) by pflugstad (subscriber, #224) [Link] (1 responses)

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

improved vs. stable vs. motivation

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

Ironically coined as a response to Gnome devs ignoring bug reports because rewrites...

At this point in time i care little for what Gnome or KDE is up to, i go with XFCE. Or if they ever follow down the part of the other two, one of the box WMs.

Fish and autobraces

Posted Mar 31, 2016 2:12 UTC (Thu) by smoogen (subscriber, #97) [Link]

Welcome to computers

Code breaks because most of it is written to add a feature or fix something else. Most of the time, it breaks and the person goes to look at it and has no clue how it worked in the first place.. and they wrote it. You take out the new feature and the code still breaks.. only later you find out that it wasn't anything you did but because a new flag got enabled in a different library and it optimized the one feature that somehow had the code work in the first place.

Or it breaks, and no one notices it until it is shipped and then you get a flame fest of emails about how crappy a coder you must be because you can't get stupid XYZ to work. You already know you are a crappy coder because a) you didn't catch that XYZ wasnt working and you use it all the time you think.. and b) you go look at the code and have no clue how it worked in the first place again.

Or the guy who wrote the code left to do something else, and you went to adopt the code. You find that you have no idea why anything is doing anything because he used a completely different coding technique. You try to triage a bunch of bugs and just say screw it and rewrite the code from scratch. After 20-30 emails about how you didn't implement this or that feature you give up and hand the code to the next guy.

Finally, you got a new feature set to implement because people want a new window widget to work. [Oooh we need to have everything VR enabled.. can you make it work with Wayland-VR? or QT 6 has dropped 50 calls that the code used but it says you can now use these 44 other codes to replicate it. OK got that done.. what we have to ship it? I haven't tested ssh yet which was what I started on...]

This post sponsored by Everclear. Why code sober when you know that you will never understand the code tomorrow anyway.

Fish and autobraces

Posted Mar 31, 2016 10:34 UTC (Thu) by dhaumann (guest, #107972) [Link]

Hi rvfh,

as it seems, it was obviously a wrong decision to remove the autobracket feature in favor of the plugin.

However, the autobracket feature indeed is back in the "Editing" config page. You have to enable the option "[x] Enable automatic brackets".

This feature was added back in the bug report you are linking, and ideally, distributions should provide upgrades to the KDE Frameworks modules, which does not seem to be the case here.

You need a recent enough KTextEditor framwork 5.16, autobrackets should work as expected. You can check your frameworks version in Kate or KWrite through Help > About KWrite (or About Kate) > Version.

I hope this works for you as expected.

Fish and autobraces

Posted Apr 1, 2016 4:20 UTC (Fri) by marcH (subscriber, #57642) [Link] (2 responses)

> In this case, why do you keep rewriting things and breaking user features along the way? Why not stabilise things instead, so your users don't go from bad surprise to very bad surprise at each release?

Come on, we all know the answer: it would be way too boring.

What next; a full test suite with good coverage? Continuous integration running it and gating merges? Professional and up to date documentation? Stable ABIs?

Hey, why not the year of the Linux desktop while you're at it.

Open-source is not about users, it's about having fun coding and arguing!

In case someone missed it: https://www.jwz.org/doc/cadt.html

Fish and autobraces

Posted Apr 11, 2016 20:54 UTC (Mon) by morksigens (guest, #92681) [Link] (1 responses)

Welcome to software development. It's easy to complain about this if you aren't the one having to do the work.

Fish and autobraces

Posted Apr 11, 2016 21:59 UTC (Mon) by marcH (subscriber, #57642) [Link]

If you think software development is hard, come over to the side in charge of integrating, validating, delivering and maintaining actual _products_.

KDE for AR/VR

Posted Apr 12, 2016 8:00 UTC (Tue) by DeletedUser102083 ((unknown), #102083) [Link]

Give me the opportunity to sell you a KDE OS and you'll have your successor to Windows/Mac OS. This is exactly my Linux of containers strategy, to create a cross-platform unified distro that not only targets desktop but AR/VR as well. If you don't know what QML is or haven't tried Plasma, then listen right meow. You need to lookup Qt Quick and Kirigami UI. Did you know Plasma Mobile is a thing? Ubuntu Touch is using QML. Look at what Tizen is doing, and where SailfishOS left off.

Someone needs to put some funds into this. With Wayland, Vulkan, and the automated cross compilation of an optimal Linux distro stack to build and deploy inside containers—we can do this! Sorry to sound like a self-promoter, but help me crowdfund this please. I've put a lot of time into understanding how to make this happen, and we're seriously (like super cereal) close to kicking some Microsoft/Apple ass. Look at how many games have been ported to Linux already.

Canonical got $12m for Ubuntu Edge on Indiegogo. You like Krita? Let's get $10m and I'll make a KDE OS that is sexier and better than anything that exist today. Anyone want in?