LWN: Comments on "Distribution-friendly tactics in the desktop wars"

Distribution-friendly tactics in the desktop wars

rahulsundaram — Tue, 12 Apr 2016 23:05:26 +0000

>that depends entirely on the graphics calls they make

Umm, that's what typically means here.

Distribution-friendly tactics in the desktop wars

dlang — Tue, 12 Apr 2016 22:16:15 +0000

> 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

rahulsundaram — Tue, 12 Apr 2016 21:00:25 +0000

> 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

dlang — Tue, 12 Apr 2016 20:55:18 +0000

> 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

hitmark — Tue, 12 Apr 2016 16:27:52 +0000

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

tao — Tue, 12 Apr 2016 12:33:47 +0000

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

DeletedUser102083 — Tue, 12 Apr 2016 08:19:17 +0000

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

KDE for AR/VR

DeletedUser102083 — Tue, 12 Apr 2016 08:00:21 +0000

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?

Distribution-friendly tactics in the desktop wars

hitmark — Tue, 12 Apr 2016 02:25:50 +0000

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.

Fish and autobraces

marcH — Mon, 11 Apr 2016 21:59:36 +0000

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

Fish and autobraces

morksigens — Mon, 11 Apr 2016 20:54:54 +0000

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

Distribution-friendly tactics in the desktop wars

tao — Mon, 11 Apr 2016 14:29:54 +0000

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

flussence — Sun, 10 Apr 2016 03:22:16 +0000

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.

improved vs. stable vs. motivation

hitmark — Thu, 07 Apr 2016 17:48:08 +0000

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.

Distribution-friendly tactics in the desktop wars

hitmark — Thu, 07 Apr 2016 17:44:21 +0000

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

Embrace, Extrend, Extinguish, anyone?

Distribution-friendly tactics in the desktop wars

hitmark — Thu, 07 Apr 2016 17:42:30 +0000

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

Then stop chasing the latest shiny!

GNOME without systemd

hitmark — Thu, 07 Apr 2016 17:36:47 +0000

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

jake — Thu, 07 Apr 2016 14:04:37 +0000

> 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

Wol — Thu, 07 Apr 2016 13:49:18 +0000

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

Fish and autobraces

marcH — Fri, 01 Apr 2016 04:20:04 +0000

> 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

Distribution-friendly tactics in the desktop wars

walters — Thu, 31 Mar 2016 17:27:39 +0000

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.

GNOME without systemd

civodul — Thu, 31 Mar 2016 12:10:29 +0000

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.

Fish and autobraces

dhaumann — Thu, 31 Mar 2016 10:34:06 +0000

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.

Distribution-friendly tactics in the desktop wars

pmatilai — Thu, 31 Mar 2016 07:57:40 +0000

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

grawity — Thu, 31 Mar 2016 07:45:54 +0000

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

Fish and autobraces

smoogen — Thu, 31 Mar 2016 02:12:23 +0000

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.

improved vs. stable vs. motivation

pflugstad — Wed, 30 Mar 2016 22:34:45 +0000

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

improved vs. stable vs. motivation

roblucid — Wed, 30 Mar 2016 20:27:33 +0000

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. :(

Distribution-friendly tactics in the desktop wars

roblucid — Wed, 30 Mar 2016 20:18:02 +0000

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

louie — Wed, 30 Mar 2016 18:46:27 +0000

"I suck at QA"

Hah. ;)

Distribution-friendly tactics in the desktop wars

javispedro — Wed, 30 Mar 2016 18:21:02 +0000

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

flussence — Wed, 30 Mar 2016 17:15:00 +0000

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.

improved vs. stable vs. motivation

tpo — Wed, 30 Mar 2016 17:13:34 +0000

> 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".

Distribution-friendly tactics in the desktop wars

rahulsundaram — Wed, 30 Mar 2016 17:06:27 +0000

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

jospoortvliet — Wed, 30 Mar 2016 16:14:12 +0000

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

admalledd — Wed, 30 Mar 2016 16:09:37 +0000

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

johannbg — Wed, 30 Mar 2016 13:59:46 +0000

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

Seegras — Wed, 30 Mar 2016 13:31:04 +0000

>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.."

Fish and autobraces

rvfh — Wed, 30 Mar 2016 12:09:00 +0000

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.

Fish and autobraces

halla — Wed, 30 Mar 2016 11:24:31 +0000

"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?