Regressions Of GNU\Linux

Change is not always for the better. This page chronicles bullshit that has come down the Linux pipeline.

http://web.archive.org/web/http://www.ariel.com.au/jokes/The\_Evolution\_of\_a\_Programmer.html

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.

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? Doubtful. Again, a small minority will benefit. Most will get the shaft. Imagine if you couldn't buy a certain tool at the store. Say, hand saws are no longer sold. You now are forced to buy an electric jigsaw. Is this necessary? Can't we have both? Who thought changing a fundamental part of the software was a good idea? They could not had good intentions, if only for how much work they will force admins to do, with any update. Another good reason to abort Debian. Systemd is the first.

From Wikipedia https://en.m.wikipedia.org/wiki/Nftables

A command to drop any packets with the destination IP address 1.2.3.4:

iptables was:

iptables -A OUTPUT -d 1.2.3.4 -j DROP

nftables now is:

nft add rule ip filter output ip daddr 1.2.3.4 drop

More complex. Fail.

With one fell swoop, thousands of iptables scripts and knowledge were made useless. Imagine if you were no longer allowed to play baseball. Now instead, you had to learn baseketball.

ifconfig replaced with ip

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

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

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 of bullshit. https://forums.sifive.com/t/will-riscv-avoid-the-linux-mainlining-mess-that-arm-had/1615

https://unix.stackexchange.com/questions/399619/why-do-embedded-systems-need-device-tree-while-pcs-dont

https://github.com/riscv/riscv-device-tree-doc

quote

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.

Ubuntu

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.

Setting up Networking has become more complicated

What was (/etc/networking/interfaces):

auto eth0
iface eth0 inet static
address 10.0.0.100
netmask 255.255.255.0
gateway 10.0.0.1

Example taken direct from http://web.archive.org/web/20150916101112/https://help.ubuntu.com/lts/serverguide/network-configuration.html For DNS, a one liner in /etc/resolv.conf will suffice.

Now is (w/netplan.io)

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      addresses:
        - 10.10.10.2/24
      gateway4: 10.10.10.1
      nameservers:
          search: [mydomain, otherdomain]
          addresses: [10.10.10.1, 1.1.1.1]

Example direct from http://web.archive.org/web/20190905160853/https://help.ubuntu.com/lts/serverguide/network-configuration.html

GNU\Linux has and is being obfuscated.

SystemD FAIL

A plot to make linux worse, which was brought into all the major distributions in suspicious ways. It deserves its own section.

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 (2020). Sysvinit does not have this problem, and reboots within 10-20 seconds.

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.

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 reboot.target: Connection timed out
See system logs and 'systemctl status reboot.target' for details.
It is possible to perform action directly, see discussion of --force --force in man:systemctl(1).
user@host:~$

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