Regressions Of GNU\Linux

From Steak Wiki
Jump to navigationJump to search

Change is not always for the better. This page chronicles bull*$&! that has come down the Linux pipeline.\_Evolution\_of\_a\_Programmer.html


Predictable Network Interface Names

Someone has controversially decided that it is better for systems to have obtuse and confusing ethernet and wireless interface abbreviations such as enp0s25 instead of eth0. Remember this makes things simpler, and easier for people (but who?).

In reality, most people get the shaft, and perhaps 10% (a small proportion) of users benefit. This raises the bar for entry level people to get started. Adding unnecessary complexity to Linux.

Apt instead of Apt-get

This is a tentative, based on whether they remove support for apt-get. If that is the end goal, then this will be a valid regression, until then, they live side by side. I don't need apt, when apt-get does the job. Needless changes. There must be something more important to do than this.

Debian 10: iptables has been replaced with nftables, after nearly 20 years

"Those are some great firewall rules you've configured there. It would be a shame if someone was to make them obsolete."

It started with Ipchains in 1998. In 2000, there was the last stable release of ipchains, which means if not by then, shortly after iptables took over. It's been 19, 19 years since then. Suddenly now, a new firewall is needed. Is this necessary for most people? That is the question.

From Wikipedia

A command to drop any packets with the destination IP address

iptables was:

iptables -A OUTPUT -d -j DROP

nftables now is:

nft add rule ip filter output ip daddr drop

More complex. Fail. EDIT: in hindsight, It's come to my attention that most common nft commands will have the format of "nft add rule" something something, so essentially, you are only memorizing everything after "nft add rule". That makes it a bit better, but still a hurdle, that average folks will have to get over. An initial look at the long string of nft commands is bound to cause people to lock up, and not be able to process anything further. Smoke and mirrors. Regardless, the accurate comparison is then:

"cmd" -A OUTPUT -d -j DROP


"cmd" ip filter output ip daddr drop

It's apparent that the firewall has tried to become more self describing, which can be a good thing. Perhaps a more self describing nature will elucidate people on the actual workings of the firewall better. That would be the ideal. I haven't used it yet enough to say.

With one fell swoop, thousands of iptables scripts and programs that use iptables were broken. Note: technically iptables-legacy can be used. At least for now. Woe is the day support is removed for that.

As an example, in 2020/10 This has bitten me with

    Fail2ban don't attempt to execute nft file. I tried to add full path to nft in config file. No luck...

 Please be aware that due to ipv6 support (see #1742) fail2ban executes actionstart on demand (by first ban, family dependent). So by design you'd not see nft called unless first ban occurs.

Existing fail2ban functionality (when fail2ban started, new table f2b-sshd or f2b-whatever was created. Now apparently it's not created until the first account is added to the banlist.) has been changed. This leads the admin to think fail2ban isn't working when the table doesn't exist. This results in lost time.

ifconfig replaced with ip

ifconfig, is simpler to use, and easier to view (more symmetrical than ip addr) for basic nic information, or setting an ip (ifconfig eth# netmask ip is unnecessary complexity for most use cases. This raises the bar for entry level people to get started. Adding unnecessary complexity to Linux.

ifconfig remains in /sbin/ifconfig, and requires root but the effort has been made to obsolete it. Don't change, what doesn't need to change.

/etc/resolv.conf depreciated

All you should need for DNS is a one line text file that points to a DNS server. Put that in /etc/resolv.conf. The simplicity of that is a threat to more obtuse OS, therefore there will be an effort to complicate it. This raises the bar for entry level people to get started. Adding unnecessary complexity to Linux.

Aptitude Descriptions

debian 8:

aptitude show openssl
Package: openssl
State: installed
Automatically installed: no
Version: 1.0.2k-1~bpo8+1
Priority: optional
Section: utils
Maintainer: Debian OpenSSL Team <>
Architecture: amd64
Uncompressed Size: 1,090 k
Depends: libc6 (>= 2.15), libssl1.0.0 (>= 1.0.2~beta3)
Suggests: ca-certificates
Description: Secure Sockets Layer toolkit - cryptographic utility
 This package is part of the OpenSSL project's implementation of the SSL and TLS cryptographic protocols for
 secure communication over the Internet.

 It contains the general-purpose command line binary /usr/bin/openssl, useful for cryptographic operations such
 * creating RSA, DH, and DSA key parameters;
 * creating X.509 certificates, CSRs, and CRLs;
 * calculating message digests;
 * encrypting and decrypting with ciphers;
 * testing SSL/TLS clients and servers;
 * handling S/MIME signed or encrypted mail.

debian 10:

aptitude show openssl
Package: openssl
Version: 1.1.1d-0+deb10u3
State: installed
Automatically installed: no
Multi-Arch: foreign
Priority: optional
Section: utils
Maintainer: Debian OpenSSL Team <>
Architecture: amd64
Uncompressed Size: 1,495 k
Depends: libc6 (>= 2.15), libssl1.1 (>= 1.1.1)
Suggests: ca-certificates
Description: Secure Sockets Layer toolkit - cryptographic utility

Tags: implemented-in::c, interface::commandline, protocol::ssl, role::program, scope::utility, security::cryptography,
      security::integrity, use::checking


Dropping Support for i386

Some distributions are dropping intel 32-bit support. With one fell swoop, hundreds of thousands of laptops and desktops made before 2006 and 2007 lost the ability to use modern OS. EDIT: this was taken back, temporarily. It stands, that some OS must support 32 bit i386, otherwise a lot of devices will be headed to landfills.

Setting up Networking has become more complicated

What was (/etc/networking/interfaces):

auto eth0
iface eth0 inet static

Example taken direct from For DNS, a one liner in /etc/resolv.conf will suffice.

Now is (w/

  version: 2
  renderer: networkd
          search: [mydomain, otherdomain]
          addresses: [,]

Example direct from

A better solution

A solution is:

  • whatever is used must be as simple, or simpler than before, as long as everything needed is included
  • aim to keep interfaces similar when possible, as familiarity will increase efficiency

Look what ifupdown-ng did: Their network interfaces is not more complex like netplan, but actually simpler. Yet it retains a lot of previous functionality, which means admins won't have to relearn everything. The new example:

auto eth0
iface eth0
    use dhcp
auto eth1
iface eth1

So here static is implied (which is either good or bad, depending on how you view it, and dhcp is explicitly mentioned. Yet the term inet has been dropped (what does that even mean?). To be honest it's mostly the same. A better comparison for what should've been would be like comparing openvpn to wireguard. There is a great leap. The latter is extremely simple, yet doesn't omit anything required. Configuration is kept at a minimum. It's a tool that gets out of your way and lets you create the VPN without worrying about how to use the tool itself. adds bulk and bloat that makes it a difficult tool to use. If only for its verbose config files. The more switches you have to change, the more complex the tool.

But is a new interfaces file even necessary? Is it change for the sake of change?

SystemD fail

Once upon a time there were many different GNULinux distributions. All of them had their own init system and kernel and programs. But that was too difficult for the gubermints to break into. So they devised a plan: "What if we made a single program that ran on every computer, so it would be easy for us to break in?". Thus the Intel ME was designed. Oh, and systemd too. They're basically the same idea. If every computer is the same, it makes the three letter agencies jobs easier.

That's one angle. For other angles, see

Reboot fail

A demonstration of Ubuntu and Systemd being unable to reboot the computer within a reasonable amount of time. It takes 5-10 minutes for reboot to occur. Keep in mind, that this init has been on this distribution for years now (from 16.04, so 2016-2020). Sysvinit does not have this problem, and reboots within 10-20 seconds. Note that this is a remote ssh session.

In Ubuntu 19.04, reboot can take upwards of 5-10 minutes to actually reboot the computer. Note that this occurs in only SystemD based distributions. A similar Debian (9 or 10) w/sysvinit reboots within 10-15 seconds.

I thought I would test systemd, so I installed Zoneminder on Ubuntu 19.04, and it demonstrates this problem. After witnessing the lifeforce of my computer being ripped out by this init, I threw the towel in and installed Devuan.

For the record, I also noticed the system to run noticeably slower. CCTV is a good benchmark for a server, as it involves a lot of CPU usage, unlike many file servers, or db servers.

Example Error when Trying to Reboot

user@host:~$ systemctl reboot
Error getting authority: Error initializing authority: Error sending credentials: Error sending message: Broken pipe (g-io-error-quark, 44)
Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Failed to reboot system via logind: Connection timed out
Failed to start Connection timed out
See system logs and 'systemctl status' for details.
It is possible to perform action directly, see discussion of --force --force in man:systemctl(1).

And it will now take my machine 5-10 minutes to reboot.

External Links

  • LinuxCNC FAIL: LinuxCNC broken because systemd can't do NTP right. In 2019/2020: Years after it is the default init...
  • More details on why this init is bad.

Udev requires reboots after Ubuntu 14

When I started using Linux distributions one of the things I noticed was how well updates were handled, compared to proprietary software. No forced reboots, no update screens that leave the user waiting. You can use your computer while it's updating. This statement ("Linux never needs to reboot when it updates") changed with udev requiring a reboot in Debian 8 or 9 occasionally (However, it's still extremely rare).


Unix design fail: cases of flags

suckless / has similar ideas, and here's another one: inconsistencies with case of flags for programs. between scp -r and chown -R there should be an unwritten standard where lower case is used for the most common operations. kind of like how there is an unwritten standard for commands to give help when you type command -h or --help. Nut there is none. Cases are all over the place. it's a mess. simple things.

Or perhaps all flags should be case insensitive. Is there any sane use case where you'd want to be able to use both -r and -R? It's just confusing.

If your program has 'that' many flags, that you have to go into both lower and upper case, then perhaps it's too complex. I mean, you can write words. There is the double hyphen. There should only be lower case flags. talks about this, but has no answer. It's just a big fucking mess. We are paying for it in pennies for eternity.

Too Many Icons

Too many icons are unsettling to the user. Less is more.

See picture on right.

GIMP 2.10 Icons and Theme Disaster

For reference see:

A light grey thread with colourful icons that transmit information quickly has been turned to a dark grey (read: hard to see) theme with a mass of all-looking-the-same grey icons that not only reinvent how you find the tool you wanted, it also fails to transmit information as effectively. If color tv is good, black and white is better?

I consider this software on watch. As of now you can revert to the legacy (they call it 'legacy' instead of classic. Interesting word choice. Legacy implies depreciation. Classic implies value) so its ok, for now. But if these all-looking-the-same monochrome icons become default, it will be a regression.

Mozilla Shuts Down IRC

Would you like some support for your mozilla? Just use your social media acct to login to our great matrix (whatever the hell that is) server.

Device Tree Bindings

ARM. Sounds like a good idea, except you need a different ISO for each single ARM CPU. Unlike the intel i386 which you can use one single ISO for ANY desktop/laptop.

ARM is fail. DTB is busy work, and fail.

This is one reason why Android is a failure.

It looks like unfortunately that RISCV will also follow this path.

EOMA68 devs have abandoned RISCV in favor of IBM's power CPU. Perhaps this is the right choice. RISCV may end up being not-worth-the-effort.


Many embedded systems use less fancy buses that don't support enumeration. This was true on PC up to the mid-1990s, before PCI overtook ISA. Most ARM systems, in particular, have buses that don't support enumeration. This is also the case with some embedded x86 systems that don't follow the PC architecture. Without enumeration, the operating system has to be told what devices are present and how to access them. The device tree is a standard format to represent this information.

The main reason PC buses support discovery is that they're designed to allow a modular architecture where devices can be added and removed, e.g. adding an extension card into a PC or connecting a cable on an external port. Embedded systems typically have a fixed set of devices¹, and an operating system that's pre-loaded by the manufacturer and doesn't get replaced, so enumeration is not necessary.

Well guess what - It's necessary now.

Raspberry Pi OS Sells Out Users to Proprietary Software via Telemetry

In 02/2021, Raspberry Pi OS (silently, and without warning) added an MS repo to APT, the package manager. Now each apt-get update will ping this demon corporation, letting them know that there is an RPI user at that IP address. The community is upset. The shills do damage control. Money corrupts.