Why is everything so complicated now?
 

Background to the rant: Yesterday morning I booted into AntiX to do my weekly update. After completing this, I decided to take advantage of my early morning "free download period" to download the packages that I would need to start my new LFS build. It seemed sensible to transfer them from Antix's ~/Downloads to LFS's /sources directory before logging off and shutting down. And I found I couldn't do it!

Tried to do it in the file manager and was told I had to be root. Yet /etc/fstab said that all my guest partitions were user-mountable! Tried to do it several different ways with mount and got told either that the disk didn't exist or that it wasn't in fstab. So then I checked the entries in /dev/disk/by-label one by one and found that the partition had a different UUID from the one listed in fstab. And then I realised what had happened. Like most people I clear partitions by reformatting them with mkfs and a new filesystem means a new UUID.

Rant begins
All Debian distros use UUIDs in the fstab created by the installer. I believe other distro families do this too.
a) This is ugly and confusing. You can't really see what gets mounted where. AntiX at least provides comment lines with the correct partition device above each active line, but the need to do that at all proves my point. The contents of a major file like fstab should be self-explanatory.
b) It is very difficult to use the mount command with such long partition IDs. And you can't use the mountpoints instead because, idiotically, they take the form /media/UUID. Cut-and-paste is the only thing that works.
c) Partitions are seldom deleted but often repurposed, especially in a multiboot machine. The quickest way to repurpose a partition is to reformat it. Did the Debian developers not realise that, compared with device names, UUIDs are ephemeral and can easily get out of date? Again fstab is too important a file to be made so fragile.
d) Most drives are gpt now so if ID strings are really needed (and I'm told that they are necessary in server machines), the installer should at least check for this and use GUIDs where available and not UUIDs.


Thank God Slackware is still sane!

You youngsters .... :p

As in most inane decisions made by distros (think sudo) UUID was mandated by Ubuntu when the support for SATA was rolled out for PATA disks. They figured their users were too stupid to be able to handle the nomenclature change from /dev/hda to /dev/sda
And they had the audacity to suggest it needed to be done because device names might change between after boot. Bunkum !!!

You never have to use UUID (maybe partition UUID rarely) - sometimes it can be handy tho'. Also tab completion works fine on the mount command. I never use GUI file managers for anything important.

What did they think udev rules were there for? Decoration?
Well, I for one would rather not have to completely re-edit the fstab file created by the installer. That's more or less what I am complaining about here. They keep saying they want to make Linux easier and they're actually making it harder and more confusing.
Oops! I never thought of that.
I don't often use them either; I much prefer command line. In Slackware I don't even have a file manager. But since AntiX does have one, I thought that using the file manager's automount capacity and just dragging files across would be faster. Bah!

Think of the positive :) - using the file manager in antiX alerted you to fixing fstab

User can label partitions (via gparted for example) and set them in fstab and you are right -it is complicated (which is why we provide a script to 'simplify' it through comments)

Here's mine

Why not just use their /dev/sd? in fstab - it still works fine, especially for internal disks - UUID can come into their own when using/removing multiple external disks... ;)

There's an important structural point here. If you have multiple Linux systems on one drive, they should be completely independent of each other, island universes. The only points of contact should be conceptual links that you yourself choose to make: for example, I have a common data partition that is mounted in the same place on all my systems and that works because I set my UID to be the same for all of them. If I want to make one system's root partition available within another system, I can do that, but I make sure that this doesn't conflict with any future plans I might have for that partition. Using a device name ensures that; a UUID or an e2label does not.

If root partitions are automatically shared around in fstab files, the integrity of one system becomes dependent on what happens to another. fstab in effect becomes merely a snapshot of the systems at the time of installation and its accuracy is almost bound to degrade over time. How is it that devs don't see this?

@anticapitalista Thanks for making it clear where those comment lines came from. Without them, I might have been threshing about even more. But that isn't a solution. In fact if a partition acquires a new UUID, the comment line can cause further complications. When I tried to mount the target partition by device name, I was told that it was not in the table, because it was there only in a comment. And when I tried by the UUID as listed, I was told there was no such disk.

I thought the preference for using UUID was because if you had multiple disks, there was no guarantee that /dev/sda didn't become /dev/sdb the next time the system booted.

Yes to the post immediately above. That has bitten me more than once. The device node changes if you plug the SATA cable into a different port on the mobo.

And anyway, you can use volume labels.

How often does the average user play musical disks with their motherboard? Distros like Debian and the Ubuntus try to be all things to everyone and you end up with things like this. Then, software wants to not have to do all the heavy lifting and you end up with Avahi as a requirement for a printer. Users want things done automagically, then you end up with Systemd, as in sudo systemctl jobctl system.world.universe.mindofgod dog::wash.start(). Finally, people get tired of something that's worked fine since the 1980's, decide to reinvent the wheel, and you end up with Wayland. My curent process list from ps aux is 306 lines long. That's why everything is so complicated.

Actually my buddy had a haswell hp business desktop that I slackified for him. It had a proprietary mobo (non standard shape), powersupply (weird connectors, non standard form factor), and only one extra sata port. When I put an extra drive in, it was a dice roll which drive was going to be sda and which sdb (every time) even though no one was touching cables or config. I did have to use blkid /uuid scheme to make it fit for recipient (who was not willing to learn to tinker with it to fix it himself). HP's theory about corporate customer hardware seems to be same as systemd philosophy about software: idiot proof the box with respect to a customer who is only going to do unimaginative expected things with it , but so inflexibly that it also impedes intelligent people trying to innovate ways to do more with their system.

Yes, of course I can if I completely rewrite my fstab. But if I decide to do that, I might as well do it with device names. The point I'm making is that most distros and most users rely on the installer to create their fstab and it shouldn't create one that is dependent on the future management and use of partitions that have not been declared as relevant.

I'm really sorry, for me it looks like the best way to solve it is what we have right now, at least I don't know anything better. As said, things become more and more complicated over time, so the solutions become more and more difficult.
By the way, if I remember well using systemd this good old fstab can be eliminated completely. In the future. But it is another story.

+1 from me.

When I trouble-shooted a Linux VM that had a cyclic reboot (admin mistake), I saw that after 20-30 reboots it came up to maintenance mode - with sda and sdb swapped!

Others have reported a disk swap after an OS upgrade.

And RedHat recommends to use either UUID or LABEL.
If you dislike the UUIDs then go for LABELs!

I also worked with Solaris. Solaris uses /dev/ path that is symlinked to a /devices/ path that is from the physical structure, a HW path and/or a UUID. You need a special "reconfiguation reboot" to reconstruct it (and then risk a disk swap).

Well, all I can say is, since starting using Linux (1999), I've been using /dev/sd? since the renaming from /dev/hd?, without any issues. :)

(I do use UUID on some installs, so not averse to it, just think it isn't needed in most cases.)

This thread is not about what I should use to create a good working fstab. There are several good memorable options available for sysadmins to identify partitions: device names, filesystem labels and, for GPT disks, partition labels. GUID and UUID strings are ugly and unmemorable imho but if you want to use them in your own handwritten or hand-edited fstab, go ahead. What I am complaining about here is the traditional automatic fstab generation at installation, which used to give you a stable and reliable setup but no longer does so. Newbies rely on these files to just work. They used to do so and now they don't because installers are writing in partition identifiers that are liable to change without notice.

There are at least two ways in which this could be fixed.

1) Don't include in the installer-provided fstab any hard drive partitions that the user hasn't named as part of this installation. Just make entries for the internal partitions like root, swap, and home plus some standard entries for hot-pluggable devices. If users want to make any other partitions available, they can do so for themselves.

2) If you do want to include partitions that are outside of the current installation, don't use filesystem-dependent identifiers for them that are liable to change without notice. Use device names for an mbr disk, partition names or GUIDs for a gpt disk.

Is that too much to ask?

Back in the old days when IDE drives were still the norm, I simply used /dev/hda, /dev/hdb etc, since the system was always going to assign /dev/hda to the master drive on the primary IDE port, and /dev/hdb to the slave drive on the primary IDE port.

When SATA came along, drives can be on any SATA port. Things are less guaranteed, whether it be because of port swapping, bios changes, buggy firmware etc... It's rare drives will get assigned different designations without making any changes, but it has happened to me.

How large is the auto-generated fstab file? It's easy to see what UUIDs belong to what drive.

+1. I have one uuid for a usb disk so it's always on the same mount point.

I think it works already that way, installers do not care about all your disks/partitions, but the OS you want to install. Or probably I misunderstood something? (how is it related to your initial post?)
This is an extremely hard question. There are a huge amount of different filesystems/partitions, storage devices available, including ram, disk, nfs, samba, raid, lvm, virtual disks, cards, ....., there is no need to have either mbr or gpt. Exactly this unique id is [meant to be] used to identify them, if any.
But if it is not suitable for you use labels or whatever else you find useful.

I am talking specifically about AntiX, but I don't know if what this installer does is universal in Debian distros these days or if it is a special AntiX wrinkle. And I know even less about other non-Debian installers.

The partition assignment dialogue in AntiX is actually very impressive. It shows all the partitions it has found and you label the ones you want to use for root, swap, efi or any other standard purpose (for example as a /var partition) in this installation. Logically therefore these should be the only partitions to go into the fstab. But what AntiX does is to add in the remaining partitions to be mounted user-mode in the /media tree, like removable devices. And it uses filesystem-dependent IDs for them rather than partition-dependent ones.

I'm sure this is someone's idea of user-friendliness but it makes the installed system hostage to changes that may take place elsewhere on the drive, which imho are none of AntiX's business. Maybe some people who use other distros would care to report whether their installer programs do this. If so, my first rant stands: this is the kind of creeping complexification I would rather do without.

I won't report hazel, since we share similar views and distros. What irritates me is things being automagically mounted in places like /media/user/other/directories/UUID/. :(. Why mount it at all if you're going to hide it so well?

But that's the whole point, isn't it. Those weird mountpoints are not intended to be seen and used by human beings but by udisks/udevil. You just click on a folder in your file manager and the appropriate disk gets mounted behind the scenes. The general view these days is that what is actually going on in the system must be kept hidden so as not to frighten the poor silly users. Until it goes wrong and then you have the devil of a job finding out what actually happened.

Exactly. Which is why neither of us are going there. I don't go for systems operated on point & click. Point & click is a good way of selecting 'one of many' options, but very poor otherwise.

Besides, with me going from Accounts to grease monkey on motorbikes, to Electronics R&D Genius, my whole career orientation is against that sort of thing. And let me guess - udevil requires Systemd?

Not on AntiX, it doesn't! AntiX is just as hostile to systemd as Devuan or Slackware. Although it mostly uses Debian repositories it has a "non-systemd" repository of its own, where it stores systemd-free versions of programs like cups. It uses sysvinit to boot and eudev to manage hardware. I suspect that they also use elogind to stand in for the systemd dependencies in application packages.

Thinks have ALWAYS been complex and complicated, but we were once too ignorant to KNOW that!

I use the tools to give things names, and mount using the names. That way the UUID can change, but the name I GIVE IT identifies the item properly.

Exceptions: mdadm does its own non-UUID naming. LVM simplifies one end while making the other end more complex, but it is a complex that is under my CONTROL! I REALLY like control!

That isn't so. I started using Linux around the turn of the century and I was amazed at how easy it was to understand the basic structure of the system and how it worked. It has grown hugely more complicated over the years, easier to use perhaps but much harder to understand.
If you use an e2label, then I think that goes in the superblock along with the UUID, so the label would disappear if you remade the filesystem. But I agree that labels are at least a lot easier to recognise than UUIDs.
Exactly. That's partly what I'm complaining about in this thread.

Yes, control is good. And control over simple is better than unnecessary complications. I earned a living fixing (hardware) stuff too complicated for the ordinary mortal. But linux is in danger of losing that simplicity. It's great to be able to configure files and fix stuff, instead of imploring apt or systemd to fix it for you.

I have Antix, on my laptop. I mean to get to know it better. I have Devuan to replace Debian on this box as a spare distro. I have the iso on a usb drive, I just haven't run it yet.

I'm not really for or against systemd. When Debian switched, I held back any of the upgrades to systemd. When I bought a new laptop, I installed Debian, and let it pull in the minimal default dependencies. In my daily usage, I really didn't notice much difference between sys-v and systemd.

I don't really have a lot on my system that's automatic. My fstab includes the root filesystem and /tmp on tmpfs. Any additional drives I manually mount.

Why not just remove or comment out the unwanted entries in fstab?


Oh, and what does udevil do? I don't have it on my system.

antiX does not use elogind or any of its libraries at all (unlike Devuan and Slackware).
We also have a runit init version available and an init-diversity development release which includes 4 init systems on the live iso (sysvinit, runit, s6 and s6-66).

Is there documentation on what/how you change the packages that currently depend on libsystemd0/libelogind0 in order to make them not do so?

No there isn't.

There is, as Hazel mentioned, an antiX nosystemd repo (with source files) for those that want to see what we do. eg Here is a link to our stable/Debian bookworm nosystemd packages.

This is going off-topic though - hope Hazel doesn't mind.


http://repo.antixlinux.com/bookworm/pool/nosystemd/

SYSTEMD adds complexity that is not needed. One can live without it. You should not have to work harder to do without it, but here we are.

X.Org has gotten so complex and the code has so MANY traps that it is difficult to maintain. The Desktop team brought up Wayland, and it addresses that issue. Both of these are only needed if you want a GUI desktop and the complexity that comes with it.

I do not install a GUI on my server systems and prefer to run them using the SYSV-INIT init-0 version. (But RUNIT would work as well, or a couple of the other more UNIX like init-0s.) Without a GUI a good CURSES menu system and SCREEN or TMUX come in handy.

Anti-X without SystemD is a solid option. Devuan is good. FreeBSD is not bad. There are others, and you can find them with a little looking. (Oh! Hello there Void, did you miss me?)

The thing is, if you want it simple you need to seek out the distributions and maintainers working their butts off to keep it simple in the face of all the pressure to make it more complex! BUT, you also have to take responsibility for administrating your own system! If you remake a file system or partition KNOWING that this will change the label and UUID, then you need to clean that up before you shut it down! What you did is not the normal automated "stuff" that regular users are expected to do. Most users never run into the issue. You did because you are better than they are, and did something they would not know to do. (So congratulations? Or something?) The good news is, you KNOW how to fix that.

For my day-to-day work I do. But I need to have an up-to-date AntiX system to hand because I have a friend who uses it and is not very computer-savvy. She depends on me to troubleshoot for her if anything goes wrong. I have AntiX-19 on my laptop (Littleboy) but that is now so old that I can't even get AntiX-21 to install on it, let alone run. So I put it on Bigboy. And it's a good thing I did, because it was the AntiX installer that told me my old hard drive was about to fail.
I think it is almost reflex to clean up anything that you know will no longer work after a change in the same system. But would you automatically check the system files in every other system on your drive? I never did that before because I never needed to. And it never occurred to me before that having UUIDs in fstab in a multiple-system setup could lead to this sort of problem. I just thought they were ugly and unnecessary. Now I think they're conceptually wrong. And I think I'm going to convert that fstab file into one that uses simple device names and mounts everything on files of the type /mnt/distroname. Just like I have in Slackware and LFS. I don't know if all the AntiX-specific desktop gewgaws will work with that setup but I think it's worth trying. I don't want to go any greyer than I am already!

I agree that device names don't always work in machines with multiple drives (though it surely ought to be possible to fix that with a udev rule). But most modern machines use gpt-formatted drives, so why not use GUIDs for alien systems if you must put them automatically into fstab?

Yes, but partlabels don't (which are available on gpt partitioned disks). That said, I don't think it's much of an ask to give something a label when you format it, and if reformatting a partition while wanting to keep its existing label is something you do often enough for it to be an issue, then it would be trivial to write a "reformat" script/function to read the label and reuse it on the format command.

UUIDS are unwieldy and I avoid their use, and I share Business Kids aversion to the stupidly long auto generated directory paths that things get mounted on (which is likely why I still use old-school autofs/automount for removable media).

No reason you can't still Linux like it's 1999! You just have to turn your back on the big desktop environments. :D

+1 on that. But you can do so without everything we hated: ISA buses; Telling lies about hard disks and memory location; OSS; PCMCIA; nutty laptop BIOS requiring kernel 'quirks'? 16 hardware interrupts; Installing a system today, and getting Xfree86 finally booting reliably 2 days later, etc. etc. Multiplying or dividing back to get every spec to feed into you Modeline?

We also had some awful hardware back then. Doesn't anyone remember the Via MPV3 "Hardware fault?" The "Creative Soundblasters" that everyone thought were great? The only great thing was actually the windows driver. The SiS 6326 Video card that could only install linux in text mode? The infamous Via Southbridges with many & varied novel hardware flaws?

OK, done. Here's what it looks like now:
Of course I've also added the mountpoints I need. And I've saved the old version just in case.

Interesting quote from Arch Wiki:

I think that "systemd" simply came about due to the need to work more easily within centrally managed computer networks. For example, if you are a corporation which has 5,000 or more "desktop computers" that you are responsible for, efficient management becomes a genuine problem. If "every subsystem does its own thing, in its own way," then this becomes "a spider-web of individual things that you have to attend to." So, one key goal of the project was to make the situation more "manageable."

For example, under Microsoft Windows®, it is possible to centrally-manage [thousands of ...] computers, partly because everything in that world now uses a single source of information: "the Registry." This was not always the case: at one time, everyone used "C:\WINDOWS\[...].INI" files. Gradually, Microsoft persuaded everyone to change. Now, they determined "what 'the Registry' actually was." It became an abstraction – a database: the requesting program doesn't actually know (or care ...) where the key-value comes from. There is also a centrally-manageable and consistent concept of "services," with an also-centrally-manageable "permissions" structure. To a big corporation, this matters a great deal.

On "your own individual computer," this of course is not an issue. And, there, you are entirely free to do as you like. But, I think, this is why the project was started and pursued. And, for many corporate users, it is justifiably important. Linux, when "in a crowd," needs to be able to "play nicely with others."

I'm sure this is true. But only a small minority of Linux distros are commonly used by the server market. There is no need for all the other distros to go down this rabbit hole.

I remember that early (pre-Fedora) Red Hat installers asked you whether you wanted a home installation, workstation or server. The workstation option included build tools, and the server option had all the daemons but I don't think it had a GUI. We need something like that for the few "office" distros and more simplicity for the others.

Gradually, operating-system manufacturers began to abandon these "different editions." It's just too complicated to sort out.

Also, I suspect that the majority of their users "neither know nor care" whether their systems are still using "init." As long as it works – which it does.

Likewise, "LVM." You may never use it – until one day maybe you need it. Meanwhile, it costs you nothing for it to be available.

As a home user.... I can't see where I will ever use it. No need for the overhead, so don't install. KISS. EXT4 (or whatever comes next ext5?) is all I will ever need. LVM just makes life a bit more complicated when used.

That I agree with. As a long time user of Linux, I don't even care... As long as it works... And so far systemd has worked well.

for the masses it is not visible, yes. The only things which are really measurable: [execution] time and the required resources. As long as we have more than enough we don't care at all.

RE: systemd. Those of us who do serious system administration care. We are mostly professional, and will work with whatever we mush, but systemd is a hot mess of points of failure and complexity for the sake of complexity to no great advantage. Two golden rules of all engineers (and all Sysadmins) are: #1 keep it simple stupid! Simple has less to break and is easier to troubleshoot and fix. #2 IF it ain't broke, don't fix it. systemd is a solution in search of a problem, and it has never found one. We have at lest 5 better solutions that are less complex, work VERY well, and are easier to maintain.

RE: LVM. Have you ever had a system using EXT4 with /boot in its own file system and run out of space? Without LVM that means downtime and it is complex to fix. WITH LVM it is a bit less complex, but you can fix it without downtime. IF you allow a bit of downtime with the LVM technique it is still faster and easier than without.
Now if you have everything in one big partition (generally TERRIBLE for server use, but fine for a home PC or laptop) you never worry about such things. IF you use ZFS or BTRFS that is already managed in a different way (subvolumes are cool!).

Thing is, for a professional who manages legacy machine, modern database servers, performant clusters of certain kinds, massive storage arrays (but without ZFS), or some other applications common in technology and business but not in the common home LVM is a lifesaver. IF you work for Microsoft then SystemD makes perfect sense. IF you are a normal home user you just want your magic box to do "the stuff" and not complain.

I need to know a bit about how all this stuff works and how to make it sing and dance. If you do not, then just enjoy the music.
Different viewpoints, equally valid, not equally accurate.

That may be true... But for us users/non-OS programmers as long as gcc runs, the printer works, network starts and runs, libreOffice starts, 24x7 access, etc..., we are golden :) . As you say, it is all about perspective of how the systems are used.

Nope. And because my systems can be down for days if necessary (say waiting for a new drive to come from TimBuckToo), not a concern if ever happens. May just re-install the OS (time for a clean install), and lay the data back down as needed (good backups).

You'll be grateful for LVM when you (finally ...) run out of space on your "primary hard drive." (In "cloud VM" environments, of course this happens much sooner.) Very simply and easily, you can just "add more space," expand your filesystem to manage it, and "keep right on going." You will also appreciate it when your (non-SSD) drive "begins to make ominous clicking noises." All that I can say is, when I'm working with other operating systems, "I miss it." It's well-thought-out, it's clean, it's pragmatic, and it works. Beautifully.

this looks like the usual blame war.

SYSTEMD adds complexity that is not needed.
LVM adds complexity that is not needed.
Wayland adds complexity that is not needed.
You'll be grateful for LVM.
You'll be grateful for Wayland.
You'll be grateful for SYSTEMD.

You'll be grateful for <add your religion here>.
<add some other religion here> adds complexity that is not needed.

Yes
No
Better
Too complicated.
Simple, easy.

Do you have a bullshit generator?

Why is everything so complicated now (this is the initial question)?

In a way I think you're both right.

I hate to say it, but I am persuaded given that both LVM and Systemd have their place. I think Wayland in development is a separate case, and let's see where it goes.

The trouble is, LVM and Systemd belong in enterprise - that's their place. Now I would understand them on an enterprise distro, but I find them a bit much on a distro for home users. LVM I can leave off, but Systemd is in danger of assimilating things.

Then, of course, the Government hackers of many countries will start on it and it could well end up being seen as a cancer. If some governments have guys in Systemd like they had in xz, watch out.

BTW, I also feel if a larger percentage of the community could be persuaded by reasonable arguments, the linux community might be a better & more progressive place.

I don't know if you'd be "grateful" for systemd – but I've been grateful for LVM many times. ("Cloud" installations seem to always need to have more storage added, and this way you can do it without downtime.)

Other than that – "your Linux system works." It does things for you, however it does it. You usually don't care "exactly how." And that is really the point. If you do care, "respond as you see fit." This world is chock-full of "distros" to choose from, including: "Linux From Scratch (LFS)." You can get your hands as dirty as you care to.

Heck, I came through windows to get where I am. Systemd has to succeed where selinux (remember that?) failed. I have a natural dislike & distrust of any program that wants to take over my pc or it's apps.

Besides rpm based distros, I did LFS, & ran it for a year or two. It's a good exercise for newbies, but a PITA in need of a package manager. I did HLFS (= Hardened LFS, R.I.P. 2005) & Kevux before I promoted myself to Slackware. Now I want a .deb based distro as a spare, purely for the repository. I'm about to install Devuan where Debian was on this box. I can install things like Kicad, Freecad, or FPGA suites, etc. with more dependencies than you can shake a stick at rather painlessly there.

None of my 'installations' are in the cloud.... I'd never ever do that here at home and certainly don't see a use case for it, -- even at work. I will not run applications located in the cloud (like editors/spreadsheets/etc.), or put personal stuff in cloud storage. That just complicates things and encourages lock in too (which Google/M$/Apple/etc. really like and encourage in name of convenience).... Back to KISS and all things local and bare-metal as far as one can be without dockers, sandboxes, etc.

Well, the original question was due to the OP recreating a partition that then had a new UUID. Since the UUID had changed it was not recognized by anything that had the old UUID. I see that as a sysadmin issue, not a complication, but I understand his viewpoint.

The UUID became the identifier because of UDEV which could (and often would) change the device path on every boot (so today your first physical hard drive is /dev/sda, while yesterday it was /dev/sdb and the second disk was sda). UDEV made dynamic device detection easier and faster, making things appear less complicated for the end user. I like using labels better, but UUID was an attempt to make things more dependable and easier for the end user.

So, things are so complicated because we keep trying to make things WORK as if simple for people who want to not deal with the complexity.

I can get that. That is okay, as long as it really does make it simpler or easier to use. So to me UDEV makes sense. UUIDs make sense, although I prefer a different solution. LVM makes sense as soon as you assume that you might have to make storage changes that it makes easier, just as it makes sense to avoid it if you do not. (I know of no distribution that forces LVM on the user on installation, but I do not use ALL of them only a bunch.)

SystemD does not make anything easier, or more simple: I do not understand how it is justified. What problem does it solve that is not more elegantly solved by something less complex? I am willing to consider any argument justifying it, but I have yet to encounter one that makes sense.

-------------------
I am reminded of code refining in the old days.
STAGE 1: analyzing the problem, data flow, and desired solution characteristics. No real code.
STAGE 2: design a code outline that would provide the solution. No real code.
STAGE 3: code or pseudocode the solution in the most simple, clear way. Most likely not elegant, not efficient, but it works. Kinda. Bad solution. (Bubble sort?)
STAGE 4: add error checking, data verification, cross checking, event management and complicates things MASSIVELY. Solution is totally inelegant, but works and avoids major problems. (COMPLEXITY and bad solution!)
STAGE 5: refines the solution, combines code elements (generalizes objects and both generalizes and optimizes methods?) and returns a simple, smaller, more consistent, and more easily maintained solution. (This is the first case of verified good code that should ever be in production: alas if you show stage 4 to management it will go into production and you are doomed!)
STAGE 6: maintenance and modifications for changing environment (data, features, changed requirements) Done well it loops between fix and refine coming back to stage five again. Done poorly it returns to stage four and creates such a hot mess that it is cheaper and easier to just rewrite the whole thing. (Looking at YOU X.Org)

We have a lot that has become very simple and elegant and looks to be in STAGE 5 - optimal. It is simple, dependable, easy to maintain, easy to use, and elegant.

Alas, we have some things that have changed and not yet been refined to an elegant, simple, correct, and trouble-free solution. Those need attention, and team attention is FAR better than one motivated individual because refining to elegant is HARD WORK and benefits by extra eyes and brains on the code.

And we have a VERY few things that were never intended to be refined, where complexity IS the point, and elegant would be at cross purposes to the goals. I HATE those. Those violate the UNIX philosophy, and not in a way that makes sense to me. I fear SystemD might be one. Feel free to nominate others, perhaps we can get them refined and improved or eliminated from environments where that complexity is unjustified.