Hacker News Reader

Comment by troad | Hacker News Reader

I get frustrated when people misstate the Unix philosophy.

The Unix philosophy is about function, not form. Say you have a tool to send something over a network. In 1993, that tool can get by being quite simple. In 2024, that same tool now needs to be more complex, just to do the same 'one job' and to 'do it well'.

It's a consistent insistence that the 'single job' be defined today just as it was in 1980 that results in Linux requiring hundreds of packages to be even remotely usable. Oh, you want Wi-Fi? Well, that's not really the job of the networking stack, the job of the networking stack is to connect PDP-11s together...

View on HN

There is systemd the init and there is systemd the project.

I counted no less then 64 related executables related to systemd on my system.

Accusing systemd of "not doing one thing and doing it well" is like accusing the GNU project of not following the Unix philosophy.

You think systemd-resolvd does its job well? :p

Actually, yes.

It is currently the only linux resolver stub, that supports link specific upstream resolvers. In the terms that user would understand, your split-horizon DNS works correctly over your VPN.

> Oh, you want Wi-Fi? Well, that's not really the job of the networking stack, the job of the networking stack is to connect PDP-11s together...

WiFi absolutely should be a separate component; the unix philosophy is an excellent defense against servers in a datacenter trying to install a WiFi stack.

wifi happens to be a separate component; wpa_supplicant or iwl are separate user space tools that network management tools call into; on the kernel side, the drivers and their stack are separate modules.

Yes, as it should be; while we might quibble about the exact details, I think the Linux-world network stack(s) do a good job of separating components cleanly while still giving users a good experience (if you just install Debian on your laptop, you don't need don't need to know or care how many packages it takes to make networking work, it just does).

  The Unix philosophy is about function, not form. Say you have a tool to send
  something over a network. In 1993, that tool can get by being quite simple.
  In 2024, that same tool now needs to be more complex, just to do the same
  'one job' and to 'do it well'.

Even by that standard scope remains a problem with systemd, it makes emacs look svelte. It's absorbed big pieces like time management and logging that ought not be part of a purported init system.

A core part of the Unix philosophy is being able to pipe standard streams between processes, files, sockets, etc, as the user sees fit.

Systemd, particularly journald, violates this severely by snarfing any stream you want to send to /var/log or wherever and locking it in a binary database somewhere, that you have to use journalctl to access.

I have no problem with journald as an idea, but the audacity that it knows better than the user what to do with stdout/stderr is insane, and 100% anti-Unix.

> In 1993, that tool can get by being quite simple. In 2024, that same tool now needs to be more complex, just to do the same 'one job' and to 'do it well'.

1993's sendmail is more complex than qmail. The latter uses a modular system, where each subtool does its job well, rather than sendmail's monolith design.

The single major flaw with systemd...

Linux was(is?) the system. Shell scripts could configure the system, reasonably well. Systemd meant it was no longer possible to simply fix a linux distro that had it...a massive recompile and intricate understanding of many low level systems was needed.

No, you shouldn't need to know about PDP-11s to fix your buggy wifi, neither should you need to know a massive binary subsystem to configure your wifi either...

So as far as doing its "one job", it did/does it fairly poorly, even today. It is a lot more standard and it does get points from me in that respect, but it fails at being a configurable system completely.

I've fixed a lot of problems on a lot of systems and never needed to recompile systemd. The majority of them I've fixed by editing text files.

What kinds of problems are you hitting where you need to recompile systemd?

I could simply trace shell scripts with some file io, or echo statements. Now there are systems using python, even better I can set breakpoints and modify, no need to recompile.

Configuring the system with textfiles only works if the system anticipated all your needs, and to anticipate all needs is not only complex but error prone.

Systemd unit files can exec shell scripts…

There have been times where I needed to do something that wasn’t available in the unit file syntax, so I just do it in a shell script and ExecStart that.

I suppose, can you arbitrarily replace portions of systemd with scripts, though?

If so, perhaps it is less of a problem than it used to be.

It still doesn't fit every need but it's better if it can get out of the way when told to.

I don't think systemd is meant to be fixed or modified, unless you are actually contributing to the upstream systemd project and have accepted that it will be a time consuming project.

It seems to be made for, and works well for, a modern ephemeral infrastructure workflow.

Build stuff to work with an unmodified distro, wipe it and reinstall if it goes wrong.

Reply on news.ycombinator.com