Sabotage Linux on the “progress” of Linux

Since we agree with every word and punctuation in this article, we proudly republish it from the Sabotage Linux website:

When “progress” is backwards

Lately I see many developments in the linux FOSS world that sell themselves as progress, but are actually hugely annoying and counter-productive.

Counter-productive to a point where they actually cause major regressions, costs, and as in the case of GTK+3 ruin user experience and the possibility that we’ll ever enjoy “The year of the Linux desktop”.

Showcase 1: GTK+3

GTK+2 used to be the GUI toolkit for Linux desktop applications. It is highly customizable, reasonably lightweight and programmable from C, which means almost any scripting language can interface to it too.

Rather than improving the existing toolkit code in a backwards-compatible manner, its developers decided to introduce many breaking API changes which require a major porting effort to make an existing codebase compatible with the successor GTK+3, and keeping support for GTK+2 while supporting GTK+3 at the same time typically involves a lot of #ifdef clutter in the source base which not many developers are willing to maintain.

Additionally GTK+3 made away with a lot of user-customizable themeing options, effectively rendering useless most of the existing themes that took considerable developer effort for their creation. Here’s a list of issues users are complaining about.

Due to the effort required to port a GTK+2 application to use GTK+3, many finished GUI application projects will never be ported due to lack of manpower, lost interest of the main developer or his untimely demise. An example of such a program is the excellent audio editor sweep which has seen its last release in 2008. With Linux distros removing support for GTK+2, these apps are basically lost in the void of time.

The other option for distros is to keep both the (unmaintained) GTK+2 and GTK+3 in their repositories so GTK+2-only apps can still be used, however that causes the user of these apps to require basically the double amount of disk and RAM space as both toolkits need to live next to each other. Also this will only work as long as there are no breaking changes in the Glib library which both toolkits are built upon.

Even worse, due to the irritation the GTK+3 move caused to developers, many switched to QT4 or QT5, which requires use of C++, so a typical linux distro now has a mix of GTK+2, GTK+3, GTK+4, QT4 and QT5 applications, where each toolkit consumes considerable resources.

Microsoft (TM) knows better and sees backwards compatibility as the holy grail and underlying root cause of its success and market position. Any 25 year old Win32 GUI application from the Win95 era still works without issues on the latest Windows (TM) release. They even still support 16bit MS-DOS apps using some built-in emulator.

From MS’ perspective, the freedesktop.org decision makers played into their hands when they decided to make GTK+3 a completely different beast. Of course, we are taught to never believe in malice but in stupidity, so it is unthinkable that there was actually a real conspiracy and monetary compensations behind this move. Otherwise we would be conspiracy theorist nuts, right ?

Showcase 2: python3

Python is a hugely successful programming/scripting language used by probably millions of programmers.

Whereas python2 development has been very stable for many years, python3 changes at the blink of an eye. It’s not uncommon to find that after an update of python3 to the next release, existing code no longer works as expected.

Many developers such as myself prefer to use a stable development environment over one that is as volatile as python3.

With the decision to EOL python2 thousands of py2-based applications will experience the same fate as GTK+2 applications without maintainer: they will be rendered obsolete and disappear from the distro repositories. This may happen quicker than one would expect, as python by default provides bindings to the system’s OpenSSL library, which has a history of making backwards-incompatible changes. At the very least, once the web agrees on a new TLS standard, python2 will be rendered completely useless.

Porting python2 to python3 isn’t usually as involving as GTK+2 to GTK+3, but due to the dynamic nature of python the syntax checker can’t catch all code issues automatically so many issues will be experienced at runtime in cornercases, causing the ported application to throw a backtrace and stopping execution, which can have grave consequences.

Many companies have millions of line of code still in python2 and will have to produce quite some sweat and expenses to make it compatible to python3.

Showcase 3: ip vs ifconfig

Once one had learned his handful of ifconfig and route commands to configure a Linux’ box network connections, one could comfortably manage this aspect across all distros. Not any longer, someone had the glorious idea to declare ifconfig and friends obsolete and provide a new, more “powerful” tool to do its job: ip.

The command for bringing up a network device is now ip link set dev eth1 up vs the older ifconfig eth1 up. Does this really look like progress? Worst, the documentation of the tool is non-intuitive so one basically has to google for examples that show the translation from one command to the other.

The same critics apply to iw vs iwconfig.

Showcase 4: ethernet adapter renaming by systemd/udev

Latest systemd-based distros come up with network interface names such as enx78e7d1ea46da or vethb817d6a, instead of the traditional eth0. The interface names assigned by default on Ubuntu 20 are so long a regular human can’t even remember them, any configuration attempt requires one to copy/paste the name from ip a output. Yet almost every distro goes along with this Poettering/freedesktop.org-dictated nonsense.

Showcase 5: CMake, meson, and $BUILDSYSTEMOFTHEDAY

While the traditional buildsystem used on UNIX, autoconf, has its warts, it was designed in such a way that only the application developer required the full set of tools, whereas the consumer requires only a POSIX compatible shell environment and a make program.

More “modern” build systems like cmake and meson don’t give a damn about the dependencies a user has to install, in fact according to this, meson authors claimed it to be one of their goals to force users to have a bleeding edge version of python3 installed so it can be universally assumed as a given.

CMake is written in C++, consists of 70+ MB of extracted sources and requires an impressive amount of time to build from source. Built with debug information, it takes up 434 MB of my harddisk space as of version 3.9.3. It’s primary raison-d’etre is its support for the Microsoft (TM) Visual Studio (R) (TM) solution files, so Windows (TM) people can compile stuff from source with a few clicks.

The two of them have in common that they threw over board the well-known user interface to configure and make and invented their own NIH solution, which requires the user to learn yet another way to build his applications.

Both of these build systems seem to have either acquired a cult following just like systemd, or someone is paying trolls to show up on github with pull requests to replace GNU autoconf with either of those, for example 1 2 . Interestingly also, GNOME, which is tightly connected to freedesktop.org, has made it one of its goals to switch all components to meson. Their porting effort involves almost every key component in the Linux desktop stack, including cairo, pango, fontconfig, freetype, and dozens of others. What might be the agenda behind this effort?

Conclusion

We live in an era where in the FOSS world one constantly has to relearn things, switch to new, supposedly “better”, but more bloated solutions, and is generally left with the impression that someone is pulling the rug from below one’s feet. Many of the key changes in this area have been rammed through by a small set of decision makers, often closely related to Red Hat/Gnome/freedesktop.org. We’re buying this “progress” at a high cost, and one can’t avoid asking oneself whether there’s more to the story than meets the eye. Never forget, Red Hat and Microsoft (TM) are partners and might even have the same shareholders.

 

19 thoughts on “Sabotage Linux on the “progress” of Linux

  1. This civilization is dead in the water.
    We live the late days of (modern) Rome.
    The most castles and strongholds, of open source, are already fallen at the hands of the enemy.
    The same of course applies to most sides of the modern societies. Democracy is nowhere to be found.
    Creation is prohibited. Social life is absent.
    Useless and corrupted leaders, are just puppets of the Corporations.
    And what’s worst than that? Most citizens doesn’t even care. Lost on their precious ego-shelf, are not even have contact with the reality.

    To paraphrase the words of J.R.R.Tolkien: “Many precious golums, down their road (=to self destruction)”.

    O tempora, o mores. This is the time we live.
    As Homer said: “Some God blinded them, to destroy them”,
    It was called “Θεομηνία” (God’s Anger), who triggered, because of Ύβρις” (Swearing against God = Blasphemy).

    Blasphemy, because they turned against: 1) God, 2)Humanity and 3) Nature (Animals and Plants).

    In these blackened days, we have to continue struggling for what is Good and keep up the spirits.
    Just remember, that you’re never alone and that Good and Truth is always the winner at the end.
    The false impression that Evil takes over and triumphs, is just an illusion. Dark will never defeat Light.
    It’s just a trial.
    G.

    PS. you seem somewhat confused-irritated, by the unworthy-corrupted leaders.
    Never mind them. They after money and personal authority. They’re NOT worth your attention.
    The real value of open source and Democracy was always the people. And actually, not all of them. Just a fraction. The worthy ones. You and me and everyone else, who cares.

    Like

  2. Maybe the entire GNU/Linux universe should have forked at the first sign of Poettering?

    Like

  3. Also can be added :
    – pipewire ( pulseaudio, jackaudio )
    – dBus broker ( dbus )
    – nftables ( iptables )
    – pappl ( cups )

    to be continued …

    Like

  4. I would add, the latest GRUB version, to this list.
    You probably need GRUB Customizer, in order to handle it.
    The previous version, could perfectly be handle by hand.

    Like

  5. I just took their text from their site and transferred it here, I am not sure they are aware of this, unless they look at their web-stats or get link-pings.

    I wasn’t aware of Qt6 being out, just noticed it in arch. I don’t know if any sw has transferred dependencies from 5 to 6 yet or it is there for developers to test on.

    Like

  6. On which system are you on Giorgos? I doubt anyone has a newer version of Grub2 than arch -8, and Obarun’s is a slight modification -9 from arch to use different defaults such as ro instead of rw

    Unless arch has stood their ground and refused the bullshit. Maybe you are on Antix and debian has done some weird gnome crap to accomodate wayland’s complexities?

    Like

  7. Wayland is yet another disaster. It lacks support for remote operation, a possibility to switch temporarily to the unix shell, and support for legacy hardware.

    Like

  8. Isn’t this an easily-predicted result of extremism in licensing conflicting against the need for material support?
    If all you publish is clean code, there’s no need for maintenance which drives customers to support-based businesses.
    Neither fully-proprietary nor fully-freed extremes support a robust market.

    Would pulseaudio have found a foothold if ALSA (or even OSS before it) had been fully supported?
    Even today, where can a simple GUI sound-management front-end for them be found,
    or even “The Full Manual™” with all versions clearly and fully covered for all hardware?
    All a web-search provides is conflicting confusion.

    And then there’s proprietary pranks by hardware makers and vendors …

    Like

  9. A gui is something that takes clicks on buttons or active menu items and translate them into a single command line statement to be executed. The reverse is much harder to do. At least I don’t know of any or to be honest haven’t looked much, on how to control pulseaudio from a tui like alsamixer or by issuing simple (or complex) commands from a terminal. Is there one?

    For example to adjust volume I use this “clean” code gadget called alsa-tray (https://projects.flogisoft.com/alsa-tray). To make a gui or a panel plugin it would be straight forward, the task is just the graphical design complexity. I can also program keybinds to raise or lower the volume. But I am not much of digital audio/visual person. I prefer my music in analog world. I fell victim once of buying this gadget that supposedly took my guitar output and send it to usb for audio live or recording and it was an absolute waste as the delay was impossible to play with. Getting the amp-output and feeding it to the analog port for recording was much better.

    Management in enterprise level systems is not that objective and scientific. In a strict dictatorial hierarchy as a government organization or large corporation, the primary object of management is to pass the responsibility for all ills to someone else. To hire a sys-admin to design and maintain all servers with runit or s6 could possibly result in servers never needing any attention unless hw fails. But if this sys-admin fails to deliver someday, and things collapse, then the manager who hired him is responsible. This is where marketing plays a role in making “subjective decisions”. Since Dell or Hp are hired by the predominant amount of organizations and sell together with HW support an IBM/RedH server maintenance contract, everything will be systemd. If it fails it is not the IT management that failed but the vendor.

    This is how the cookie crumbles. In research labs where scientists depend on their own designed machines to deliver them with results so they can meet grant deadlines and publication/presentation/conference deadlines, the more they research their options the less likely it would be to run systemd. Connecting real time devices to some experiment that run on a biological clock and recording data for their research it would be unthought of to wait for systemd to be cleaning up its mess and restarting crap with little or no effective journaling/logging. Those guys whether they study comets or cell cultures, or chemical processes, or neural networks, or radioactive decay, couldn’t care less what RH has to deliver for upper level management confidence. They want FULL control of their machines and really want to know if there is a lag somewhere what is causing it.

    Their research assistants may run guis and games, while their boss is in another town presenting their work 🙂
    I have walked into a very high profile bio-reasearch-lab in such an occassion and they were all playing network-civilization on their SUN/SGI workstations. But when they went back to doing actual work, it was all terminals and tuis.

    Like

  10. A GUI (when properly designed) allows the user to focus on a task without the distraction of spelling, syntax or other non-task issues. (It need not be fancy or pretty.) This is usually done through abstraction, explanation, and presentation of choices.
    Some choices may be automated by use of detection of required criteria, such as type or model of a hardware element.

    Provision of an effective GUI often expands a market opportunity.

    The Linux kernel is a monolithic monstrosity of spaghetti-code that requires constant discipline.
    It would not have been adopted (at the time) if not for an unarguable speed advantage over modular (less-monolithic) code.
    Due at least in large part to (arguably unnecessary) variations in hardware, it has grown massive.
    (Some would suggest this expansion is not sustainable.)

    If pulseaudio (or systemd) likewise delivers some (real, or at least imagined-by-management) advantage, it will likewise replace prior designs and persist despite inconvenience – for those systems and situations where said advantage applies.

    For other situations, an alternative can prove more effective, and may eventually replace an inconvenient paradigm.

    Like

  11. pipewire (check Zenwalk slackware based distro) is a total replacement for pulseaudio.

    It is 2021, I am rereading the article above.

    I like it even better now than when I republished it. There is hope as long as there are voices of resistance and deviance around!

    Do not surrender peacefully!

    Like

  12. Pipewire?
    Is that the next incarnation of the pulseaudio/jack server-concept for not only audio/sound but also video “streams”?
    IF it’s carefully designed and bugs are avoided through discipline it may well be a Good Thing.
    Would it also be a paradigm shift?

    Like

  13. One of the reasons I turned to look at Zenwalk and did the installation was to see for myself what this pipewire goes, but caught up in the upgrade, the replacement of ck with elogind, and how it was abruptly plugged in everywhere in slackware, that I didn’t even pay attention to it. I just know it is in the repository and if I am not mistaken it doesn’t conflict with all pulse-crap. I think pavucontrol is functional with pipewire.
    I didn’t get mad enough to erase the installation, I just backed it up in an image and was going to restart a new one and not upgrade, just upgrade certain things and see how far I get without elogind or when the system finally breaks due to partial upgrading.

    LXDE and tools are pretty much finished developing, and I think that was mostly done before elogind/systemd was going around. To take something like pcmanfm and mandate that elogind runs or pcmanfm doesn’t is outright “sick”. I had to go back and check, I disabled ck and removed it. I tried to start pcmanfm (1.2.xxx) currently they have 1.3.xx in their repositories, and it didn’t even throw a warning or error of ck not running. So what alienbob says that this community pkgr did, transferring dependencies from ck to elo.. is bullshit. I am getting used to AlienBob’s speculative defenses and moving the goal posts around so he can win an argument.

    Like

  14. Btrfs is another trojan horse of a bunch of capitalist members of the Linux Frobnication.

    Like

  15. Pingback: “Lately I see many developments in the linux FOSS world that sell t… | Dr. Roy Schestowitz (罗伊)

  16. Pingback: Links 30/1/2021: Wine 6.1, LibreOffice New Generation | Techrights

  17. Pingback: Daniel Cantarín: Informatics, Progress, and Technocracy — Introduction | Techrights

If your comment is considered off-topic a new topic will be created with your comment to continue a different discussion. This community is based on open and free communication, meaning we must all respect all in minimizing the exercise of freedom to disrupt such communication. Feel free to post what you think but keep in mind the subject matter discussed. It is just as easy to start a new topic as it is to dilute the content of an existing discussion.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.