Kügler: Plasma’s road ahead [LWN.net]

Kügler: Plasma’s road ahead

Posted Oct 20, 2016 15:48 UTC (Thu) by blujay (guest, #39961)
Parent article: Kügler: Plasma’s road ahead

There is no such thing as stability in this brave new KADT world. Every time we almost crest the bucket, the crabs of backwards-incompatible major library releases and reimplementation parties pull us back in. We will never have anything that just works for years at a time without regressions and disappearing functionality, because software that works is boring, and that mythical goal of elegance is always /almost/ within reach…

Our only hope is to abandon such software and use “old” software, like Emacs. Even though it continues to improve (25.1 just came out!), it also /just works/, and major functionality doesn’t simply disappear when you upgrade it, with vague promises of returning someday (right before the next major transition, when it will disappear again).

On the bright side, I installed TDE on my laptop and netbook, and it works great and looks great. I can store my config files in git and sync them, and all my settings magically work on the other computers without having to reconfigure everything on each system. Upgrades come in and features don’t disappear. I even put my money where my mouth is and donated to the Trinity project, because they are taking stability seriously: only improvements, no regressions, no disappearing features. This is software I can depend on. And it uses far less memory as well.

Still using KDE4 on my desktop, but I don’t see myself moving to (KDE|Plasma|whatever)5, aka KFlatUI. Why would I, when features I depend on are simply missing?

It’s tragic how many man-years have been wasted reimplementing the wheels in DE projects, and there’s no end in sight. Yeah, yeah, volunteers, free-time, blah, blah–you’d think volunteers would want their work to last more than a couple of years before being thrown into the bitbucket. If you just want a toy programming project to mess around on, there are a million choices besides rewriting software that people depend on.

The greatest problem facing the FOSS community today is lack of stewardship. Fundamentally important projects like these need to be recognized as commons, like community gardens that benefit everyone who uses them, and those who work on them should recognize their roles as stewards, as gardeners whose job is to keep the place clean and keep the plants healthy–not rip out the plants and paths every couple of years and say, “Well, this new kind of concrete came out, so we wanted to change all the paths. Did you file a bug about that missing path? We’re working on it…”

to post comments

Kügler: Plasma’s road ahead

Posted Oct 21, 2016 6:07 UTC (Fri) by krake (guest, #55996) [Link] (8 responses)

> Yeah, yeah, volunteers, free-time, blah, blah–you’d think volunteers would want their work to last more than a couple of years before being thrown into the bitbucket

I think you are confusing the product with single versions of a product.

The people developing Emacs are likely proud that it has been in use for decades and is still being used, but it doesn't decrease their accomplishment if nobody is using Emacs 1.0 anymore.

They are likely more happy if people throw an old version into the bitbucket and move to a more recent one than keep using the ancient one. Maybe that older version is not even maintained anymore.

Kügler: Plasma’s road ahead

Posted Oct 23, 2016 17:44 UTC (Sun) by h2 (guest, #27965) [Link] (7 responses)

Your reaction is interesting, and quite revealing. Anyone who understood incremental development would understand the example of emacs is not given to suggest that we would be using version 1 and thus preserving the original programmer's contributions.

When you do incremental development, code is preserved, modified, refactored, but what it is not, is tossed out the window. The example of emacs, like any well developed long term project, was a good counter example to the current preference to dump all existing stability and functionality at every major version update.

I suspect this comes down to how one personally develops, since I maintain projects that have been going on now for more than 10 years, at no time did I dump the codebase and redo them, that would be such a pain, instead, I just keep modifying them, sometimes I do big refactors, which essentially wraps the existing logic in new containers, but what those refactors NEVER do is lose functionality. They simply improve code maintainability and flexibility.

This apparently explains why I can still get work programming, I assume this ability has some commercial value, I certainly know it has extreme value to me on the work I volunteer on. One of my libraries has a standing guarantee to users to NEVER break their existing code, for newer versions to always be drop in replacements, merely with expanded functionality. Sometimes this takes some thought and foresight, but honestly, it doesn't take that much, from what I can see, all that is really required is to care about this part of the programming experience, and to use it to determine other decisions one has to make along the way.

I know I'm not the only one out there to do this, since so many great free software projects do this, and do it well, year after year, and the longer I use free software, the more I begin to appreciate the fundamental discipline this type of development demands. I also understand how easy it is to not do it this way, and then walk away, or move on to the next project, leaving the old code, as you say, to rot and fade away, useless to future generations.

Kügler: Plasma’s road ahead

Posted Oct 24, 2016 9:26 UTC (Mon) by vasvir (subscriber, #92389) [Link] (5 responses)

Yes __you__ are doing the refactoring to __your__ (old) code.

If it isn't your code you are not attached to it emotionally. I am not saying that a full rewrite is the correct or even the recommended solution but...

If you are young and you want to help with open source why to bust your head to understand somebody else code in order to modernize it? I mean upgrade libraries, dependencies or refactor it?

I don't agree with it but I can see the point of view of somebody (maybe yang?) that wouldn't touch somebody else's code without being paid.

Apparently in DE projects people come and go and there is not enough incentive for newcomers to work in somebody else half way project. Not when they can start their own half way project that does a (konqueror vs dolphin?) similar things.

In KDE some examples of useful programs (that are not part of the KDE releases) are K9copy and I am not sure about K3b, amarok. Are they properly ported to the new infrastructure?

Kügler: Plasma’s road ahead

Posted Oct 25, 2016 20:18 UTC (Tue) by Wol (subscriber, #4433) [Link]

> In KDE some examples of useful programs (that are not part of the KDE releases) are K9copy and I am not sure about K3b, amarok. Are they properly ported to the new infrastructure?

:-)

Which is why I now use Clementine. "Amarok for KDE 3" rolled forward to KDE4, not the mess that was the KDE4 rewrite.

Cheers,
Wol

Kügler: Plasma’s road ahead

Posted Oct 28, 2016 3:18 UTC (Fri) by h2 (guest, #27965) [Link] (3 responses)

<<< If it isn't your code you are not attached to it emotionally. I am not saying that a full rewrite is the correct or even the recommended solution but...

It's odd how far/low we're falling in this arena when it comes to the two biggest free desktops, gnome/kde. I believe it was Paul Graham who noted that great code generally comes from redoing existing logic, and that rewrites tend to toss out the baby with the bathwater, that is, all the existing logic that was created to solve issues is removed, and you start fresh, which means you have to fix all the same things again, basically, and things just don't work anymore, until they are fixed. In other words, the kde 3>4.x cycle, then the kde 4>5.x cycle, or the gnome 2>3.x cycle, etc. Horrible waste of finite free software developer hours/days/weeks/years.

I have one program whose code I really dislike because it's a royal pain to work on, but the entire thing is basically logical handling of bad data, very very bad data, so while someone could rewrite it, they'd literally have to do so line by line to not lose all the fixes. That was in fact also a rewrite of an older version of the logic. Not mine. That rewrite lost exactly zero features in the process, just improved overall flexibility and feature support.

Personally I view this problem more as a failure to do good architecture, not at all a question of working on someone else's code or not. The linux kernel is filled with 'someone else's code', and seems to roll along fine without major rewrites version to version. Libreoffice, the same, openbsd, freebsd, apache, the same. These are all old projects that are not rewritten routinely, and that basically keep working over many years time. All with very large code bases. Now and then I assume they are cleaned up, modernized, and of course, there are regressions etc, but in general, the goal is to not do that. Particularly not with user facing stuff like libreoffice.

It's in my opinion hugely disrespectful of the finite man hours available in major free software projects to just blow it all up and have the entire desktop be unusable for a year or more, but I'm starting to believe that certain projects simply are not well run, and don't enforce good coding rules, and don't have good solid architecture that you can work with for a long time, and therefore have to blow it all up fairly routinely, at great loss to users and the overall free desktop experience. One of the, if not actually __the__ reason the linux free desktop has failed to make any significant inroads on the non free desktop market, constant desktop desktop breakages and failures. Lack of reasonably coherent and stable desktop apis for even the simplest things really damage the ecosystem, always have, always will, until you see patches added to patches with things like flatpack/snap etc, which are the proverbial one more standard to fix the flood of standards, none of which would have been an issue with a stable desktop api, which appears to be something that's become taboo to discuss anymore. See for example gnome/gtk refusing to lock down their api until the very end of the 3.x cycle, which is the exact opposite of how it should work, a strong sign of significant lacks in the design/architecture area of the gnome/gtk project. Even the simplest thing, templating, is too hard for them to lock down, so sub releases in gtk 3.x break those apis, making life suck for people who were using the gtk toolkit for their software, but nobody at redhat seems to consider this a valid issue since that's not invented there.

It's actually kind of funny to watch desktops try to do bad copies of OSX, all the while totally failing to grasp that what apple users love fanatically about their desktops is the fact very strict rules are applied to interface changes, and stuff doesn't just change and break all the time. I know apple has really bad internal programming etc, have to deal with those bugs too often, but the intent is to provide a consistent user experience, which is a point the desktops that seem to want to copy the superficial look/feel of osx seem to totally miss, completely, and utterly.

So no, I don't buy that line at all, this is far more about failing to implement much stricter handling of changes, better initial architecture, etc.

I've started realizing that the longer I use free desktops and software, the less interested I am in watching projects break themselves, so now I tend to just walk away, even when I was very heavily involved in supporting them, as was the case with kde, at a certain point it's just obvious to me the things aren't well run, if they were, stuff wouldn't be failing on major version changes.

There's two kinds of rewrites I'd say, the good kind, where the code improves, but the features don't degrade, and the bad kind, where everything is broken for years as people struggle to try to restore features that were removed. Or of course, the gnome way, which appears to just remove any complicated feature that requires skill to handle, until you can commit a new version with only 14k of changed lines. About what one reasonably skilled coder can do in 6 months more or less, give or take.

But the problem is, you really need to be careful designing these things to begin with. My guess is if you started with kde 1 or 2, then started modularizing it, refactoring, abstracting away a bit from the toolkit specific version, you might actually end up with something worth moving forwards with, always with an eye on speed, performance, and eye candy treated as what it is, eye candy, that should never dictate anything central in the desktop.

Kügler: Plasma’s road ahead

Posted Oct 28, 2016 21:31 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

> what apple users love fanatically about their desktops is the fact very strict rules are applied to interface changes, and stuff doesn't just change and break all the time

Ha! You don't work much with Apple stuff do you? Every Xcode update is nightmare until we find out what they broke next and work to deal with it. People are fanatic, I think, because Apple hands them an experience that Apple has hand-crafted to their own ideas of how things should work, bugger to those who disagree. Plus, they had that whole skeuomorphism thing going on for a while that just magically disappeared once someone got moved around internally back off the UI stuff.

Granted, I see Apple more from the "I have stuff which needs to work there" rather than the "I use it" category, but things change all the time from the default scroll direction (who knows how long the option will exist), breaking extensions to the OS all the time (apparently 10.12 broke the key remapper apps…again). Other than that, my interactions with OS X UI stuff is minimal (it's more iTerm2 and the occasional Firefox window really), so I can't say much beyond that.

Kügler: Plasma’s road ahead

Posted Oct 28, 2016 21:54 UTC (Fri) by pizza (subscriber, #46) [Link]

> Plus, they had that whole skeuomorphism thing going on for a while that just magically disappeared once someone got moved around internally back off the UI stuff.

This bears repeating -- Apple's UI guidelines were quite strict, but only for everyone else. They broke their own rules whenever it suited them, which was all the time.

> breaking extensions to the OS all the time

10.12 was unusual in that it was the first release since 10.4 that *didn't* break Gutenprint in some way.

Kügler: Plasma’s road ahead

Posted Oct 29, 2016 7:24 UTC (Sat) by peter-b (guest, #66996) [Link]

>> what apple users love fanatically about their desktops is the fact very strict rules are applied to interface changes, and stuff doesn't just change and break all the time

> Every Xcode update is nightmare until we find out what they broke next and work to deal with it.

Oh boy, Apple platforms are ridiculously costly to support for us at LiveCode. Every Xcode update and new SDK brings some backwards-incompatible breakage that sometimes takes us dozens of man-days to figure out. The release notes are useless, the "documentation" is pretty but contains nothing of any value, and (of course) there's no source code. We pay Apple $$$$$ a year for the dubious privilege of being permitted to build and distribute software for MacOS and iOS and seem to get nothing to show for it. I thought I'd never say it, but developing for Windows is a so much easier in comparison. Interestingly, the one platform that is super easy to support and with which we never seem to have any problems is Android.

Kügler: Plasma’s road ahead

Posted Oct 26, 2016 20:34 UTC (Wed) by krake (guest, #55996) [Link]

> Anyone who understood incremental development would understand the example of emacs is not given to suggest that we would be using version 1

I used Emacs as this was the example given in the previous poster's comment.

The comment suggested that "volunteers would want their work to last more than a couple of years" was a contradiction to delivering newer versions of the software.

I simply clarified that if this were the case, that this would apply to even the given example and was thus not very likely.

Plasma has already passed "a couple of years", some of KDE's softwares have been in use for more than a decade.