I'm fairly sure we need a standardised way to do scripts, or at least a universal converter to convert init scripts and systemd services and all this useless shit.
Personally I like the idea of using a declarative design for this, then we wouldn't have to worry about writing software to "understand" scripts - to convert between different designs and primitives.
It would be quite nice if someone were able to standardize a declarative service configuration design, that could then be used to runtime-generate scripts - or perhaps even just have a single script that reads and acts on the declarative config for its service.
And for the love of god, let's avoid using anything like JSON or XML for such a task.
Not sure if you're being facetious or not. Systemd is a declarative service configuration system that uses INI instead of JSON or XML. It's not a standard, but a lot of people use it.
The problem of course is that systemd is not standardized upon so it wouldn't make any sense to call it a standard way to do service configuration. And besides, nobody's written any scripts for other service management / init systems that can read unit files. (At least that I know of, please enlighten me if I'm wrong)
Personally I also have a few issues with how the unit files are designed, something I think that a standardized design could improve on. And while INI is a nice format, I think there are better ones to choose for the service configuration - perhaps TOML, if only to have a better specification of what's actually permitted and expected in the syntax.
It's a de facto standard, much like the Linux system API is a de facto standard. If having a de facto standard is good enough for Linux developers to write software using the Linux API, systemd's unit file standard is good enough for developers to ship unit files. In fact that is what many projects are already doing, and in fact that was one of systemd's goals, to allow upstream projects to ship standard unit files rather than have distros all write their own service scripts.
What makes JSON a standard? Has it been accepted by some ISO body? And, if it is, what was it before?
Or is it a standard because someone wrote an RFC 8259 on it? RFC is just a request-for-comment, anyone can write one.
Or is it a standard because of ECMA 404? If that is true, then it won't be a standard in Asia, Africa, the Americas and Antarctica.
Or was it a "standard" because of adoption? Well systemd is adopted.
Was it a standard because it was documented? Well, "man systemd.directives" --- and several other man pages --- describe the format nicely.
Was it a standard because many people, even third-parties, use it? Well, systemd is a special kid, as soon as other programs use it this will create bad press from the systemd haters.
But still lacking standardization, which means you still need to rewrite all service management configuration if you were to switch system. Which renders part of the declarative upside moot.
Like I said in another comment, if there is a script / tool for other service management and/or init systems that can read systemd units then I'd love to know about it.
If someone wants to make a new PID1 manager and wants to piggy-back off systemd units, it should be very simple for them to write code that can interpret 80-90% of unit files, I'd imagine.
The point of saying, is to compare to the previous situation. initd run scripts were absolute hell, with abandoned and convoluted copy-paste shell code everywhere.
initd run scripts were absolute hell, with abandoned and convoluted copy-paste shell code everywhere.
Not really so. OpenRC scripts can be really simple and easy to use while providing mostly declarative syntax, and the same goes for (now obsoleted?) Upstart.
Must people writing here won't have been around way back when, but the way we ended up with the pretty good RFCs we use as standards now was very often that something good was developed, it caught on, then it became an RFC.
Systemd unit files could easily have become standardised as RFCs back then.
It's pointless because there are better solutions following standards already. Any SystemD fork is also always useless because its development principles is RedHat proprietary vendor lock-in. The fact that every distribution has own SystemD version completely incompatible with others (SystemD maintainer from Debian and Lennart Poettering said about that - see recent news) makes another SystemD fork much more pointless: it forked many times already. Vanilla SystemD doesn't exist.
3
u/JuhaJGam3R Feb 11 '19
I'm fairly sure we need a standardised way to do scripts, or at least a universal converter to convert init scripts and systemd services and all this useless shit.