SoylentNews is people
SoylentNews
from the it's-already-perfect-is-not-the-right-answer dept.
We all know about Microsoft's latest OS, so I won't rehash. A lot of us intensely dislike it, to put it politely. Those of us who can, use other operating systems. This is Soylent, so let's focus on the one that is the most important to us: Linux.
I have been using Windows as my OS since right after Atari times. A few years ago I bought an ARM (ARMHF/ARMv7) netbook and put Lubuntu on it. I had problems with my first Linux experience, mainly in the area of installing software: missing packages in Synaptic, small dependency hells, installing a package at a time by hand, some broken stuff. I put it down mainly to the architecture I have been using, which can't be supported as well as x86-64.
Now, we all know that no software is perfect, and neither is Linux, even though it is now my main OS. We support it in spirit and financially, but there is always room for improvement.
So, the question is: What are your problems with Linux and how can we fix them? How do we better it? Maybe it's filesystems, maybe it's the famous/infamous systemd. Let's have at it.
(Score: 3, Insightful) by Marand on Thursday February 23 2017, @05:24AM
One of the things which has been a benefit is systemd. Most of the arguments against it are nonsense. The declarative file format is much easier to read and write than shell scripts since it requires less wheel reinventing. shell scripts can be convoluted and obfuscated, systemd often has a simple declaration which would require many lines of shell script dealing with PIDs and so on.
You've repeated this a few times here, so I wanted to correct this misconception about the sysv-style init. I'm probably wasting my time writing this, since you already like systemd and likely won't care, but it's an anti-sysv argument that keeps coming up and it's just wrong. Despite what you and others seem to think, init scripts do not have to be in sh, or be scripts at all. It's not an inherent requirement of sysv init and should not be used as an argument for the abandonment of it.
Bourne-style shell scripts are what distros generally use, but it's not a requirement of the init system. At its simplest, all that's required is a program that accepts command line arguments of "stop" and "start", and can be anything that does those two things. If you want to get fancy, you can make it follow the LSB init script requirements and also accept "restart" "force-reload" and "status". There is one LSB requirement that makes it appear that you need shell scripts: LSB inits currently require a very specific type of comment block that documents dependency information that can be used by fancier inits that can do parallel booting. The expected comment block's lines start with "### BEGIN INIT INFO", end with "### END INIT INFO", and contain "# key: value" lines in between, and was chosen because # is a sh comment, so it's understandable that someone might assume sh is the only option to comply, but that's not the case.
All that is really needed is to have a multi-line text block inside your "init script" that can be parsed. I've made init scripts in Scheme by doing something like this, for example:
(define init-block "
### BEGIN INIT INFO
# Provides: foo
# Description: Foo
### END INIT INFO
")
Never used the init-block symbol for anything in the script itself, it was just there for the benefit of the parser. It seems to just do something like use the "strings" command to pull out the strings, so you can even do this with binary files! Out of curiosity I tested by writing a simple init script in C, putting a multi-line string in the file that contained the init info block. It parsed it just fine.
---
At this point, you might be thinking this doesn't address your argument that systemd's unit files are declarative and that's superior to having to write programs, regardless of the language. That's the thing, though: since it respects the #!/path/to/interpreter shebang format for text files (scripts), there's no reason you can't use a declarative parser with sysv-style init. You could make an interpreter that reads a systemd-esque unit file and write all your unit files in the same declarative language, just with a shebang and some LSB init headers at the top. All the boilerplate start/stop/etc. code could be handled by the interpreter itself, removing the "wheel reinventing" for inits that fit within the declarative unit file use-case.
Advantages to this approach would be that you could easily fall back to normal init scripts if you need to do something that's beyond the scope of your declarative interpreter, you wouldn't have to keep tacking on new features to support every possible use case because you have the scripting as a fallback, it would be a lot easier to implement than rewriting everything, and you still have a tiny, battle-tested init that does very little and has a small attack surface.
The declarative format argument is a red herring that has been used by the systemd folks to convince people that are ignorant of how init works that they need systemd to get rid of shell scripts, but that's never been the case. If that were the goal it could have been done a lot easier with a custom interpreter.