Difference between revisions of "Regressions Of GNU\Linux"

From Steak Wiki
Jump to navigationJump to search
 
(62 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
Change is not always for the better. This page chronicles bullshit that has come down the Linux pipeline.
+
Change is not always for the better. This page chronicles bull*$&! 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.
+
== Debian ==
  
 
===Predictable Network Interface Names===
 
===Predictable Network Interface Names===
Line 14: Line 15:
 
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,
 
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.
 
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 ===
 
=== 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."
 
"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.
+
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 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.
 +
<small>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 1.2.3.4 -j DROP
 +
and
 +
"cmd" ip filter output ip daddr 1.2.3.4 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.
 +
</small>
 +
 
 +
With one fell swoop, thousands of iptables scripts and programs that use iptables were broken.
 +
<small>Note: technically iptables-legacy can be used. At least for now. Woe is the day support is removed for that.</small>
 +
 
 +
As an example, in 2020/10 This has bitten me with https://github.com/fail2ban/fail2ban/issues/2741
 +
 
 +
<pre>
 +
    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.
 +
</pre>
  
−
With one fell swoop, thousands of iptables scripts were made useless.
+
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 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.
+
ifconfig, is simpler to use, and easier to view (more symmetrical than ip addr) 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.
 +
 
 +
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 ===
 
=== /etc/resolv.conf depreciated ===
−
All you should need for DNS is a pointer 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.
+
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 ===
 +
<pre>
 +
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 <pkg-openssl-devel@lists.alioth.debian.org>
 +
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
 +
as:
 +
* 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 <pkg-openssl-devel@lists.alioth.debian.org>
 +
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
 +
 
 +
Homepage: https://www.openssl.org/
 +
Tags: implemented-in::c, interface::commandline, protocol::ssl, role::program, scope::utility, security::cryptography,
 +
      security::integrity, use::checking
 +
 
 +
</pre>
 +
 
 +
==Ubuntu==
  
 
=== Dropping Support for i386 ===
 
=== Dropping Support for i386 ===
−
Some distributions are dropping 32-bit support. With one fell swoop, hundreds of thousands of laptops made before 2006 and 2007 became less useful.
+
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):
 +
<pre>
 +
auto eth0
 +
iface eth0 inet static
 +
address 10.0.0.100
 +
netmask 255.255.255.0
 +
gateway 10.0.0.1
 +
</pre>
 +
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)
 +
<pre>
 +
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]
 +
</pre>
 +
Example direct from http://web.archive.org/web/20190905160853/https://help.ubuntu.com/lts/serverguide/network-configuration.html
 +
 
 +
===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:
 +
https://github.com/ifupdown-ng/ifupdown-ng/blob/master/doc/ADMIN-GUIDE.md
 +
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:
 +
<pre>
 +
auto eth0
 +
iface eth0
 +
    use dhcp
 +
auto eth1
 +
iface eth1
 +
    address 203.0.113.2/24
 +
    gateway 203.0.113.1
 +
</pre>
 +
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 netplan.io 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. Netplan.io 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 man 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 without-systemd.org
 +
 
 +
====Reboot fail====
 +
[[File:Systemd_Unable_To_Reboot.webm|thumb|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====
 +
<pre>
 +
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:~$
 +
</pre>
 +
And it will now take my machine 5-10 minutes to reboot.
 +
 
 +
====External Links====
 +
* [https://www.youtube.com/watch?v=RDKaFJmB254 LinuxCNC FAIL]: LinuxCNC broken because systemd can't do NTP right. In 2019/2020: Years after it is the default init...
 +
* [https://nosystemd.org Nosystemd.org]: 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).
 +
EDIT: Reboots are not required, so ignore the above. So far, at least.
 +
 
 +
==Misc==
 +
 
 +
=== Unix design fail: cases of flags ===
 +
suckless / http://harmful.cat-v.org/software/ 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. But 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.
 +
 
 +
https://unix.stackexchange.com/questions/154599/the-difference-between-r-and-r 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 ===
 +
[[File:Poor Icon Design.png|415px|thumb|right|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:
 +
https://www.gimp.org/release-notes/gimp-2.10.html
 +
 
 +
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 ===
 +
https://wiki.mozilla.org/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.
 +
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
 +
 
 +
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.
 +
 
 +
 
 +
quote
 +
<pre>
 +
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.
 +
</pre>
 +
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.
 +
 
 +
Shame.
 +
 
 +
Ref: https://www.cyberciti.biz/linux-news/heads-up-microsoft-repo-secretly-installed-on-all-raspberry-pis-linux-os/
  
 
{{GNU\Linux}}
 
{{GNU\Linux}}

Latest revision as of 14:11, 26 October 2024

Change is not always for the better. This page chronicles bull*$&! that has come down the Linux pipeline.

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


Debian

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 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. 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 1.2.3.4 -j DROP

and 

"cmd" ip filter output ip daddr 1.2.3.4 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 https://github.com/fail2ban/fail2ban/issues/2741 

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

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 <pkg-openssl-devel@lists.alioth.debian.org>
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
 as:
 * 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 <pkg-openssl-devel@lists.alioth.debian.org>
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

Homepage: https://www.openssl.org/
Tags: implemented-in::c, interface::commandline, protocol::ssl, role::program, scope::utility, security::cryptography,
      security::integrity, use::checking

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

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: https://github.com/ifupdown-ng/ifupdown-ng/blob/master/doc/ADMIN-GUIDE.md 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
    address 203.0.113.2/24
    gateway 203.0.113.1

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 netplan.io 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. Netplan.io 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 man 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 without-systemd.org

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

External Links

  • LinuxCNC FAIL: LinuxCNC broken because systemd can't do NTP right. In 2019/2020: Years after it is the default init...
  • Nosystemd.org: 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). EDIT: Reboots are not required, so ignore the above. So far, at least.

Misc

Unix design fail: cases of flags

suckless / http://harmful.cat-v.org/software/ 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. But 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.

https://unix.stackexchange.com/questions/154599/the-difference-between-r-and-r 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: https://www.gimp.org/release-notes/gimp-2.10.html

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

https://wiki.mozilla.org/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. 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

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.


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.

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.

Shame.

Ref: https://www.cyberciti.biz/linux-news/heads-up-microsoft-repo-secretly-installed-on-all-raspberry-pis-linux-os/

GNU\Linux
Programs
Other
Distributions
Politics
Retrieved from "http://steakwiki.com/index.php?title=Regressions_Of_GNU%5CLinux&oldid=1643"