UNIX design was so great that its authors did two other operating systems trying to make UNIX done right.

One of the few times I agree with Rob Pike,

> We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.

It's more like Windows! /duck

I will soon be releasing a distro that is free of systemd, wayland, dbus, and other troublesome software. It is built starting from LFS in 2019, and now consists of over 1,500 packages, cross compiling to x86-32/64, powerpc32/64, and others if I had hardware to test. It's built entirely from shell scripts which are clean, organized, and easy to read.

I need help to get the system ready for release in 60-90 days. In particular, I need a fast build system, as my current 12+ year old workstation is too slow. Alpha/beta testers are welcome too. Anyone who wants to help in some way or hear more details, please get in touch:

domain: killthe.net

user: dave

If the project is even split in different parts that you need to understand... already makes the point.

I need my systems to work. Not once in my career have I experienced a showstopping issue with systemd. I cannot say the same for sysV.

I think the *BSD are also good, at least from an educational standpoint, with their relative simplicity and low system requirements. Since there is a lot of integration making a from scratch distro might take less material, but it could be supplemented with more in depth/sysadmin exploration.

What a horrific thought.

> As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files.

However the reasoning they provide makes sense.. It's hard to build a Linux system with a desktop these days without Sysd.

  #!/sbin/openrc-run
  
  command="/usr/bin/rsync"
  command_args="--daemon ${RSYNC_OPTS}"
  pidfile="/var/run/${SVCNAME}.pid"
  
  depend() {
   use net
  }

Unlike SystemD if you need to make nontrivial decisions at service-status-management time, you have the option of putting your scripts or calls to other programs inline, rather than hoping that SystemD gives you the hooks you need in the places you need them and passes in the data you require. [1]

[0] And if 'rsyncd' was supervised with 'supervise-daemon', you wouldn't need to specify the location of the pidfile.

[1] As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does). As a less-trivial example, you can check for and warn the administrator about common service misconfigurations with the same mechanism that provides service startup and status information (as several services do).

For example, not all distros ship and use systemd-resolved by default, to choose from your list.

Design-wise, I think having users modify service on/off state *and* systemd itself modify those states is a terrible design, which leads to stuff turning back on when you turn it off, or things turning off despite you wanting them on, etc. (also mentioned higher up)

FWIW after making puteron I found dinit https://github.com/davmac314/dinit which has a very similar design, so presumably they hit similar issues.

But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup.

To give you concrete examples:

1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts.

2. Except that you can, but only if you use the /etc/fstab compat.

3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device.

4. Systemd has separate behaviors for network and local filesystems.

5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!!

6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching.

7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1.

I can go on for a looooong time.

Are you referring to the developer of Xlibre, who submitted multiple broken patches & kept breaking ABI compatibility for little to no reason[0]? Or someone else?

[0]: see discussion & linked issues in the announcement https://news.ycombinator.com/item?id=44199502

There is a difference of opinion. Freedesktop wants to "stabilize" X11. That does mean that they do not want to evolve Xorg. However, it does not mean that you cannot keep using it or that they are going to take it away. In fact, it is still being maintained and will be for a long time.

You can interpret the rejecting of patches and banning of developers as political. However others see the rejection and banning as protecting the stablity that is the goal.

If your goal is for Xorg to evolve and not to stabalize (fair), you may prefer Xlibre as a project.

Phoenix looks pretty cool too.

KDE Plasma and GNOME are trying to kill X11. Or, at least, they do not want to maintain support for it in their projecs. And COSMIC did not bother to add support for X11 at all. That will probably be the trend on desktop Linux.

Apple has had to invest reams of engineering effort in mitigating Mach’s performance and security issues in XNU; systemd dissatisfaction alone seems unlikely to shift the needle towards Hurd.

I'm not a systemD fan but SysV is not without its quirks and weirdness and foot guns

That's the point on which people differ. Even if we take as given that rc/svinit/runit/etc is not good enough (and I don't think that's been established), there are lots of directions you can go from there, with systemd just one of them.

In X11/Xorg's case, a common example would be environments built off different window managers, panels, launchers, etc. In theory nothing prevents Wayland to have something similar but in practice 17 years after its initial release, there isn't anything like that (or at least nothing that people do use).

At least in my mind, the Unix philosophy isn't some sort of dogma, just something to try and strive for and a base (like X11) that enables others to do that doesn't go against it from the perspective of the system as a whole.

Systemd and Xorg are very similar in many ways. I do not know how you hate Systemd and love Xorg unless your real problem is just change.

And, while I like Wayland, I think that liking the Wayland architecture should have you disliking Systemd. But that is just me.

I believe it's `systemctl list-unit-files` to see all the config that's executed, included by the distro, and then if you want to see the whole hierarchy `systemd-analyze dot | dot -Tpng -o stuff.png`

To me, seems much easier to understand what's actually going on, and one of the benefits of config as data rather than config as scripts.

https://github.com/openbsd/src/blob/master/etc/rc.d/watchdog...

It's not a perfect equivalence, of course, SystemD diverges more from other UNIXes than GNU does.