Development quotes of the week [LWN.net]

On the other hand, this story about GtkPod is just one of many similar stories. Real problems have been solved in open source software, and computing historians, vintage computer enthusiasts, researchers etc. can still benefit from that software long into the future. Throwing out all this stuff in the name of "progress", could be misguided. I'm especially sad when I see the glee which people have expressed when ditching libraries like Qt4 from the archive. Some software will not be ported on to Qt5 (or Gtk3, Qt6, Gtk4, Qt7, etc., in perpetuity). Such software might be all of: unmaintained, "finished", and useful for some purpose (however niche), all at the same time.

— Jonathan Dowland

All good stories need at least a villain so I have arbitrarily chosen copper thieves as the villains of the story that set in motion what youtube-dl is today.

— Ricardo García (Thanks to Paul Wise)

to post comments

Development quotes of the week

Posted Nov 12, 2020 9:34 UTC (Thu) by k3ninho (subscriber, #50375) [Link]

>I'm especially sad when I see the glee which people have expressed when ditching libraries like Qt4 from the archive. Some software will not be ported on to Qt5 (or Gtk3, Qt6, Gtk4, Qt7, etc., in perpetuity).

Another example that 'throwing out all this stuff in the name of "progress" [is] misguided' today [1] from xscreensaver's maintainer (Lisp Machines Hacker/Netscaper/nightclub and arts space owner) Jamie Zawinski:

>Dear Lazyweb, I am told that the Linux folks have been "improving" things again, and by "improving" I mean "deleting 25 year old APIs without providing a compatibility layer." Specifically:
>I'm told that some distros have stopped shipping gdk-pixbuf-xlib.
>I'm also told that libglade is on the chopping block, and that there is a migration tool, and also that said migration tool does not work.
>It would be great if someone were to send me a patch that makes xscreensaver still compile and run properly in the face of these pointless, unnecessary changes.
>I have no interest -- in fact, less than no interest, a *positive disinterest* -- in figuring this out, so I'm not going to. I haven't thought about GTK since the 90s and I'd like to keep it that way.
>To whoever does this, the xscreensaver users thank you, and my inbox thanks you.

K3n.

1: https://www.jwz.org/blog/2020/11/xscreensaver-vs-cadt/

Development quotes of the week

Posted Nov 12, 2020 18:10 UTC (Thu) by lisandropm (subscriber, #69317) [Link] (5 responses)

I've replied in Jonathan's blog but it will need moderation. tl;dr:

> I'm especially sad when I see the glee which people have expressed when ditching libraries like Qt4 from the archive.

I'm probably one (if not the most visible) of them. But it's not just about progress: it's also about acknowledging the fact that "software life cycle" includes... well, death. Or pushing us maintainers to become the upstreams of a huge codebase.

Development quotes of the week

Posted Nov 12, 2020 20:07 UTC (Thu) by Wol (subscriber, #4433) [Link] (4 responses)

The problem is that (a) us oldsters get fed up of seeing the young people re-invent the wheel, and (b) I feel this especially in that I have to keep on re-training the even older oldsters, who often have learning problems due to their advanced years ...

Cheers,
Wol

Development quotes of the week

Posted Nov 12, 2020 21:53 UTC (Thu) by halla (subscriber, #14185) [Link] (3 responses)

Of course, this development quote wasn't about "youngsters reinventing the wheel", but "oldsters not maintaining their ancient projects for ancient hardware" and "vague, non-specified people who probably don't exist not spending effort packaging out-of-date libraries".

None of it is about "youngsters". None of it makes any of Jamie Zawinski's rants applicable; none of it is about reinventing the wheel.

It's about abandoned projects no longer following the growth and progress of the dependencies they depend on, that growth, especially in the case of Qt, being actually managed by the people who were working on those libraries twenty years ago.

If you take a good, hard look, what's going to shock you is not how "youngsters" are taking over by "reinventing the wheel" but how libraries like Qt, or platforms like KDE, are still largely developed by the same "oldsters" who were involved twenty years ago.

Development quotes of the week

Posted Nov 13, 2020 11:13 UTC (Fri) by k3ninho (subscriber, #50375) [Link] (2 responses)

> None of it makes any of Jamie Zawinski's rants applicable
In case it's unclear -- and with humble respect -- I raised JWZ and xscreensaver to get attention and hopefully have someone help out.

I understand time is limited and there are so many hours in the day to make and maintain our computer systems. The code exists so that we can run the machines we use like we tend gardens, putting the suites where we want them to go, but tending gardens includes weeding and cleaning up.

I appreciate (in its technical sense) the nuances of keeping and culling unused code. Old code in legacy systems ossifies organisations around their legacy systems*. 'Vendoring in' stuff still goes by a rule of thumb I read here at lwn.net: fewer than a million lines and it's worth caching code you rely on in your own source code trees. And culling unusued libraries is a useful lifecycle act to free up time and mental attention to the things that benefit more people, with the caveat that the older code exists somewhere in a historical archive if system-archaeology needs to recover it and use it anew.

*: the long-term consequence of Conway's Law

K3n.

Development quotes of the week

Posted Nov 13, 2020 15:16 UTC (Fri) by lisandropm (subscriber, #69317) [Link]

> I understand time is limited and there are so many hours in the day to make and maintain our computer systems. The code exists so that we can run the machines we use like we tend gardens, putting the suites where we want them to go, but tending gardens includes weeding and cleaning up.

I really **love** this analogy.

Development quotes of the week

Posted Nov 17, 2020 20:22 UTC (Tue) by nix (subscriber, #2304) [Link]

Relevant patch (Cc:ed from JWZ's thread):

https://github.com/oracle/solaris-userland/blob/cae02421c...

Development quotes of the week

Posted Nov 13, 2020 6:19 UTC (Fri) by pabs (subscriber, #43278) [Link]

Luckily GtkPod will be available from the Debian snapshot archive for the foreseeable future.

https://snapshot.debian.org/

Development quotes of the week

Posted Nov 19, 2020 11:59 UTC (Thu) by davidgerard (guest, #100304) [Link] (1 responses)

I keep finding that the most reliable way to run old free software is the Win32 version under Wine.

It's a stupid amount of work - working out what libs you need, software archaeology to dig them up - to run old free software. My albatross is an ancient Slash dump that I need to somehow bring up Slash 2.2.6 - old Perl with a pile of outdated dependencies - to try to extract the posts to WordPress from ... it's been in the to-do pile for several years, and occasionally I bother pushing it forward another step.

In the future, there will be a standard binary format that is stable through the decades! And it'll be WIn32 under Wine.

Development quotes of the week

Posted Nov 19, 2020 12:00 UTC (Thu) by davidgerard (guest, #100304) [Link]

(I should note that Ubuntu recently proposed removing the 32-bit libs that Wine needed to do win32 on AMD64, so not even that's so safe.)

Development quotes of the week

Posted Nov 25, 2020 9:50 UTC (Wed) by Vipketsh (guest, #134480) [Link] (2 responses)

What irks me about this "progress" is that these libraries basically do the same thing for 20+ years during which time they went through numerous incompatible changes to their API. Surely a reasonable API would can be found in a few tries and with decades of experience ? Yet these things "progress" but essentially always keep doing the same thing.

I was developing a some GUI around the time when gtk3 started being widely available and had to port stuff from gtk2 to gtk3. All in all the port wasn't /so/ hard, but the changes to the API and the reasoning behind them was dump and, even though the devs I'm sure didn't think like this, were essentially stuff just to make churn in downstream projects.

The example I still remember is that there was an API to retrieve the size of a window. In gtk2 you passed the object (window) and a pointer to a 'size' structure with width and height members. In gtk3 this was changed to a pair of functions: one to retrieve the width and the other the height. It's the exact same thing, only different. To make matters more annoying the rationale for the change was that "structures in API is bad practice". So, I have to fix all my code based on someone else's theory. Not very enjoyable.

In summary the gtk devs decided to preemptively and definitely break all applications to avoid a potential break in the future. How is this "progress" or even reasonable ?

Development quotes of the week

Posted Nov 25, 2020 12:11 UTC (Wed) by pabs (subscriber, #43278) [Link] (1 responses)

Part of the problem is that other parts of the ecosystem change and the toolkit has to adapt too. On the hardware side, fast GPUs, HiDPI screens, touchscreens, VR/AR, various input gadgets and form factors. On the human side, more people using the software for more things means extra accessibility needs, more font rendering features, more flexible translation systems, better streamlined UX and adapting to the UX trends in other computing ecosystems. On the software side, a larger variety of software with a wider variety of use cases and a wider variety of widget needs. On the development side, folks discovered that certain types of APIs lead to mistakes in application code, so they redesigned the APIs to prevent those things from reoccurring.

Development quotes of the week

Posted Nov 25, 2020 14:31 UTC (Wed) by Vipketsh (guest, #134480) [Link]

I understand things change and thus the underlying libraries need to change too. For some reason there those projects which can, for the most part, add modern features without breaking old applications, while others have to break stuff. Linux is a prime example -- applications statically linked decades ago still run today. X had a time when it was actively developed, new features where added, and all of its user facing interfaces continued to support older applications. I just don't understand why that has to be so different today.

Mind you, I very much agree with the sentiment that "structures in API is bad practice" and various other bad practices -- if you are designing an API from scratch. It's completely different however if the API already exists and has thousands of users. In this case the "possible mistakes" have to be weighed against the cost of change. Especially the example I gave. The "error prone" API was in place for years with apparently no issue, so clearly it wasn't such a big and immediate problem to fix.