Also, because they don't change gratuitously, once you learn their quirks, you can move on to other things without needing to worry about re-learning tons about the next update. Linux is a constantly moving target with lots of churn that users of computers really don't want or need.
But...
This article describes (at least in my opinion) an unusable and unstable machine.
Basic HDMI out and Ethernet aren't "optional" on machines I run. Frankly - I'd rather lose wifi/bluetooth than HDMI and Ethernet (not that bluetooth is working here either...).
So I guess my point is that
>that users of computers really don't want or need
seems very much like a personal opinion. I not only want churn if it's bringing online more hardware support - I find the lack of support here completely unsuited to my needs.
If this is what you mean by "clean"... then It feels a bit like keeping a boardgame in the shrink wrap - rather than getting it out, bending a few cards, and having a good time. At least to me (fully admit this is also just an opinion).
For instance, does "ifconfig" need to be replaced by "ip" in order to support new ethernet chips? Do you need all sorts of new invocations to systemd because a new generation of Intel graphics is supported? No.
It may be a personal opinion that people don't want or need churn, but what I mean is that when people want to use a system to get things done, learning new invocations for old commands is usually a distraction to getting those things done.
I don't really think I am.
I'm going to pick on your exact example: ip is replacing ifconfig because linux distros are moving to netlink as a replacement for ioctl. Why are they doing that? Hardware support - Particularly WNICs.
So did ifconfig need to be replaced? Strictly speaking, no - but if you want better hardware support - yes...
ifconfig could have been updated, but the problem is that you're adding complexity to the system somewhere, either by expanding the old interface, or by replacing it with a new one.
You can argue expansion would have been preferable to replacement, but I'm not totally convinced - they both have tradeoffs. Someone is paying the piper either way.
The only way to avoid that cost (churn in the existing tool, or churn in the introduction of a new tool) is by not supporting that hardware. Which is what BSD is doing...
ip replaced ifconfig NOT because of new hardware support. For one, ifconfig could, and has been, extended. Second, that wouldn't explain removing ifconfig. Third, other OSes, like the BSDs, have alternatives for additional functionality like wiconfig.
ip could exist alongside of ifconfig, if ifconfig were really a subset of ip. It's political. And if you're going to echo that, "oh, someone needs to sit around and spend all sorts of energy keeping ifconfig up to date", then remember that they clearly don't if you contend that ip is all about supporting new stuff.
In other words, there's nothing in what you're saying at all that would explain the need to remove ifconfig and break decades of common usage. That's unnecessary churn, in my opinion.
I will talk about Linux with my therapist when I see her next. I wonder if childhood trauma is the reason I'm a Linux sysadmin.
I see this opinion a lot, but what tangible benefits does that result in?
For me, this is a nice benefit because I can know that anything installed into /usr/local can be removed and won't break the basic system's functionality. This organizational structure I think is also just very sensible imo.
Note: I'm mostly a Linux user but I play around with FreeBSD a lot. I wish that by default my Arch machine organized things similarly, but ultimately it's minor enough for me that I haven't switched
I don't really see how it is relevant. First I don't see why would anyone want to randomly remove things. On my linux system everything that I compile or install by myself goes to /usr/local. Everything managed by packages goes to /usr, any thing that comes from a precompiled tarball is better installed in /opt. How is that different?
What I liked about freebsd when I was using it was the handbook that was fairly complete.
A simple example is if you run 'which vim'. If you have installed vim through pkg on FreeBSD it will show up in /usr/local/bin/vim. Whereas if you run 'which vim' on Ubuntu, it will show up in /usr/bin/vim -- but on Ubuntu Desktop (when I last used it) vim is preinstalled. You can't just look at the /usr directory on a Linux machine in most cases and know what was installed when you installed the machine.
I mean, try debloating an Ubuntu Desktop machine that's been used for a while and tell me if by looking at the /usr directory what was included in the install vs what you installed post-install.
A simple example is if you run 'which vim'. If you have installed vim through pkg on FreeBSD it will show up in /usr/local/bin/vim. Whereas if you run 'which vim' on Ubuntu, it will show up in /usr/bin/vim -- but on Ubuntu Desktop (when I last used it) vim is preinstalled. You can't just look at the /usr directory on a Linux machine in most cases and know what was installed when you installed the machine.