Comment by Analemma_ | Hacker News Reader

Comment by Analemma_ | Hacker News Reader

Good? I have gripes about systemd, but this is not one of them. Indeed, cleaning up the multi-decade Gordian knot of distro-specific crappy Sysvinit scripts was the entire point, as they made clear right from the beginning. If systemd compromised a little on that in the early years, that was probably just to get a foot in the door.

> These dependencies are predictably wrong in any number of cases, because they've never been really used before.

Then fix them. Isn't that considered good software engineering in all other contexts? At least where I work, you're not allowed to merge until all the unit tests are green, and if someone writes a new unit test that reveals your component was broken all along, you fix it.

The comparison to security is not valid at all. I was on the side of pragmatism and the letter-writers, and against the Guardian and the purists, on the recent WhatsApp fracas, which you'd think would pit me against systemd here, but the analogy is flawed. We have to be pragmatic about security because it involves the choices of uninformed and uninterested users, and we have to maximize their security given that they frequently make bad choices and we have little hope of making that better. systemd is exposing problems that were created by developers and can be fixed by developers.

If I have code that is:

  executeStep1();
  //Step 2 requires step 3 to be run first
  executeStep2();
  executeStep3();

I don't expect my compiler to go ahead and run step 3 first. Systemd is choosing code comments over code organization. The tests are green, until we run them under a compiler than prefers comments over procedural organization.

The fact that they are syntactically formatted as comments is irrelevant. There is a spec, and that spec is respected by many tools besides systemd, including insserv (which was used for parallel boot on Debian for quite a while before systemd became default).

Because shell scripts are such a terrible format for init scripts, they were standardized as comments to the shell. But they are not comments simply for human use.

An analogy is the type-checking syntax in Python 2, which couldn't pick up a syntax change like Python 3 does. They're formatted like comments. They're not arbitrary strings for amusement, and a type checker is entirely right to complain if the appropriately-formatted comments are invalid. If you want to express things for humans, you're welcome to use normal unstructured comments.

I don't mean to advocate for systemd's approach, but they are not the first compiler to give meaning to information in comments.

For example, there exists a Javascript compiler that puts static type annotations in the comments: https://github.com/google/closure-compiler/wiki/Annotating-J...

For static analysis and linting in C information gets held in comments as well.

Unfortunatley, about the only thing everyone can agree on is:

  /* fallthrough */

For when you intentionally don't put a break in a case statement.

Because init scripts are being used in such a strange and non-rigorous way (configuration and operation combined in single files, with execution order implied by the name of each file), I don't think it's fair to draw such a direct parallel to the more formal languages used today for programming.

> I don't expect my compiler to go ahead and run step 3 first.

You would be surprised[0]. In low level code (in some cases) you'll need memory barriers[1] to ensure the proper order of instructions execution.

Even in higher level code your compiler's optimization algorithm may decide that it's faster to execute step 3 first if it thinks the result would be the same.

[0] https://en.wikipedia.org/wiki/Out-of-order_execution

[1] http://irl.cs.ucla.edu/~yingdi/web/paperreading/whymb.2010.0...

Out-of-order execution always has the same answer that would occur from a single threaded perspective. There's no "thinks the result would be the same" about it - the result is the same.

You get into trouble when you:

1) assuming ordering to external peripherals (e.g., memory mapped I/O)

2) assuming stores/loads are happening in a specific order (e.g., other threads either pre-empt or are simultaneously running) causing data races

Your response makes it sound like a compiler could reorder functions like:

  x=5;
  x=add(x,5);
  x=multiply(x,10);
  printf("%d", x);

and you could expect to get either 100 or 55 as an answer if you didn't use fences. That's not true. The answer will always be right (100) no matter what OOO, speculative execution, etc happen.

If you read my post carefully the "thinks the result would be the same" was about compiler optimization case, not processors' out-of-order execution.

Take this example:

    a = 5;
    b = sqrt(44);
    return a * b;

If the optimizer is sure (and strict aliasing[0] also helps to be sure in many other not so obvious cases) that the sqrt function is not using the a variable then it can swap lines 1 and 2 in the generated machine code, and the result will be the same.

In your example changing lines 2 and 3 will alter the result naturally so the optimizer won't touch it.

[0] http://dbp-consulting.com/tutorials/StrictAliasing.html

I thought the headers were interpreted by sysvinit as well, as they were intentionally part of the design. Am I mistaken?

System 5 rc (rc, not init, note) didn't have such a concept. Even the original van Smoorenburg clone of rc didn't have this.

The LSB headers came along some years later. They are one of two different header styles that systemd's conversion tool understands, in addition to supporting the case where there are no headers at all. There are multiple extensions to van Smoorenburg rc. The LSB headers are just one such extension, understood by toolsets on some operating systems and not others.

* http://unix.stackexchange.com/a/233581/5132

Reply on news.ycombinator.com