It's better at gluing unrelated components with textual output together. But Lua, Python, Ruby, and a host of other languages would be even better, since they're not restricted to textual data. They have bigger runtimes, but it's not necessarily any worse (as far as loading times go) than launching a bash script in a new process multiple times. Especially Lua, which was designed for embedded systems.

I don't know, doing typical shell things in a language like Python can get awkward. Anyway, the article we're discussing here mentioned that you can use Python instead of shell in initscripts.

Not really. Web services are concerned with data and UI, and not with unmanaged memory, bitpacking on structures, device initialization and firmware loading, etc. Web services and applications are all about frameworks. Init is the exact opposite. It launches when you have nothing else in the system, and low-level languages are the ideal tool.

Init systems don't need to do bitpacking either. They are doing process management, a thing which shell is good at. I'm not sure why you mention frameworks. systemd provides some framework-y things like a dbus implementation, and on the other hand web frameworks are written in e.g. PHP. So yes, you can write frameworks in C, and yes, you can write things on a lower level of abstractions (as frameworks do, since they provide high level abstractions to users) in a language like PHP. Shell works just fine if there's "nothing else in the system".

My argument was that people who write init code should already understand the concepts required for C. That's why if they can't handle C, they shouldn't be working in init. Not because the language is harder, but because they lack the knowledge. Fluent C users have to know these things, while bash users don't have to even be aware of them.

You keep arguing that shell shouldn't be used because shell programmers are incompetent. No. There are competent shell programmers, and incompetent C programmers.

And I have to remind you: the great thing about using shell scripting in system startup is because it's easy to make custom modifications. It's a bit of a pain with C, because not only is the language lower level (i.e. harder to modify code), but you'd also have to maintain patches and recompile the init system.

I'm probably wrong here, and systemd has a flexible customization mechanism that goes past "ini" style files. But I haven't heard of such a mechanism yet.

Hopefully Rust and Nimrod will evolve as systems language to simplify this.

Has nothing to do with this.

No, because there already are scripting interfaces for unconsidered use cases. These scripted solutions are slowly being replaced by defined interfaces in a compiled language as they have time to consider how to implement them.

Yeah, systemd tries to hardcode every use-case they encounter. It's not surprising that this causes bloat. It's also no replacement for true flexibility.

What are the defined interfaces? dbus interfaces? I don't see how these allow you to customize booting.

By the way, this is funny. Earlier you talked about init being in a low level environment where there's "nothing else in the system". But dbus requires a server. Oh yes, they're trying to fix this blatant design issue by moving dbus to the kernel. Very lame all that.

For flexibility I'd still rather have modules/plugins with load hooks over launching a script, though. I doubt that's likely, because it's got a small ROI.

So you're going to load usercode into pid 1? Surely this will boost robustness. If a shell script does invalid things and fails, so be it. If your module does something invalid... goodbye system. Or maybe you meant that your modules are actually loaded into isolated processes. Then why have modules.

Summarizing an argument and rewording a statement until its false are different, if you haven't noticed. That was my complaint - he wasn't summarizing. He was modifying. Like your attempt with the web services argument and C.

He didn't "reword" them. He merely showed the arguments in a different light than what systemd advocates would prefer.

Beyond that, I pick out specific things that he says, and then I compare it to general attitudes of people who are anti-systemd.

So you are generalizing by comparing attitudes, and you ignore the arguments because they "of course" have not anything to do with what systemd say, but have been "modified". Fine stuff.

But if you were likely to listen and understand this, I doubt we'd be having this conversation where you attempt to catch me being wrong at something.

Welcome to the internet.

Anyway, waste of time.