Hacker News new | ask | show | jobs
by zb10948 859 days ago
That's serveral conjectures on your part. Give me metrics about the minority and then back up the fact that most of those people never wrote a sysinit or rc script by hand.

Like it or not Systemd breaks the Unix way and for a certain amount of people (I am not pretending to have a measuring stick) the dogma and philosophy are much more important than perceived ease of use or features.

2 comments

All the major distros, especially server distros, run systemd. That is proof enough that NOT running systemd is a niche and unsupported configuration in any half-serious setup.

A conjecture is not automatically wrong. The point of a conjecture is to challenge someone else to prove it wrong. You'd have a hard time showing proof that systemd is niche.

And honestly, it does not break UNIX, let's be serious now. A haphazard bunch of shell scripts is not much better than a monolithic binary, and UNIX does not give a damn either way.

I do not care about dogma and philosophy, I am an engineer with software to run and deadlines to meet.

> I am an engineer with software to run and deadlines to meet.

Sure, but UNIX, with its minimalist philosophy, was - luckily for us! - not created under that slogan. With respect to quality, this slogan has always been the one driving its decrease that we see all around us today.

UNIX was created by engineers to run software, not as a philosophical device.

Sorry to say, yours is a terrible excuse. I respect that you might not like systemd, no software is perfect and systemd has many flaws, but the "think of the UNIX philosophy" is righteous nonsense that I cannot take seriously.

The real world is not black-and-white, with or against us. One of the most beloved UNIX tools, Emacs, is as far removed from the minimalist philosophy that some have decided to be UNIX's crowning achievement. It is not. Linux and UNIX have not won because we're all into minimalism, or dogmatic zealotry.

To be fair, "Unix philosophy" was originated by said engineers themselves.

https://en.wikipedia.org/wiki/Unix_philosophy

Speaking of emacs, it was created outside Unix, to be later reincarnated by Stallman as part of his "GNU's Not Unix" project.

> A haphazard bunch of shell scripts is not much better than a monolithic binary

If know shell scripts you can read and adapt the former. You can keep the state in vcs without needing a compile artifact or a compiler.

How much work is it to add a bespoke feature to systemd?

It's a tradeoff for sure, but let's not pretend simplicity has no benefits.

And knowledge of Cron transfers to the bsds.

Why would I care about "breaking the Unix way"?
Because people who probably have never used Unix said it's superior.
I don't care about a 50 year old technology philosophy. Times have changed.

Cloud computing and the prevalence of highly distributed systems have completely changed how software is deployed, scaled, and managed. These environments often rely on complex orchestration which can stretch the boundaries of the UNIX philosophy towards systems that are more about interactions between distributed components than about simple, single-purpose tools.

I don't see how it's relevant. An orchestration tool can also follow the Unix way by not implementing too much functionality and relying on the small tools for subtasks.
And do you know what systemd is? A project that produces multiple orthogonal executables that share a syntax paradigm and communicate over standardized IPC mechanisms.

I think the only valid-ish argument these Unix philosophy discussions boil down to "why didn't they use purely text based interfaces". Well because they are inefficent and hard to debug and reason with. Making things text only doesn't make them more understandable but they make sure the programs waste energy and development time in meaningless parsing code that is full of security issues.

You have a point concerning the text files. (Although I would be really interested to see an example where efficiency of text files is insufficient on modern hardware.)

However "multiple orthogonal multiple orthogonal executables" is just a strawman: their interfaces are unstable and non-straightforward, aand communicate over standardized IPC mechanismsnd one can't reliably replace one of them with an alternative. It's technically true but in practice not. This effectively makes it a huge, inflexible, not-easily-verifiable blob with wide permissions and, potentially, many bugs.

> and communicate over standardized IPC mechanisms

I've never seen that anyone could replace one systemd component with an alternative implementation. Did you?

Why? For old time’s sake?
See the Wiki link above.
Right. Why would one care about principles.
They’re not my principles, and I spent the first 15 years of my career administering real capital U UNIX systems.
Do you care about my principles too? Mine don't involve a Unix philosophy.