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.

1 members found this post helpful.

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.

2 members found this post helpful.

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

1 members found this post helpful.

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.

1 members found this post helpful.

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)?