No troll here. Just someone who apparently is a lot more likely to write that paper one day than you are. If you think I'm talking gibberish, it's because the argument is over your head. Had you been more polite about it, I might be more polite here.

Actually, systemd keeps all of that complexity and more, it just sweeps it under the rug and makes it into a single point of failure.

Also, unless the daemon decides it wants to give up all portability and lock itself into systemd, it has to implement all of that code anyway and ignore systemd. Or worse, it can add yet another compatibility shim and accommodate systemd as well.

Of course, a SIMPLE utility could do that job on a case by case basis and be usable by systemd or sysvinit or openrc, etc etc. It could also be portable to *BSD and OSX (unlike systemd). Systemd's 'design' reminds me of Robin Williams talking about God getting incredibly stoned and creating the platypus.

As a bonus, that approach wouldn't screw up a simple thing like fstab.

Meanwhile, where are these experts and those amazing code reviews?

More likely you can't answer the question.

And so I claimed that it actually is a good language to use, not just there by inertia.

In what way is Jit going to run faster than a binary pre-compiled after careful (and automated) profiling and tuning? JIT's advantage is in cases where the end user can't do a custom compile.

No, it's just a healthy understanding of the KISS principle. There is a virtue to something too simple to screw up.

You seemed to feel that inertia was a big factor.

No JIT will be as fast as compiling once in advance for exactly the hardware it will run on. Especially given the chance to do time (and correctness) trials with various optimizations first. Interestingly, JIT and scripted languages make a lot more sense for small to medium clusters, particularly if they would see idle time anyway. In those, the pressure to get value from every cycle tends to be a bit lower such that saving development time and debugging effort may be worth it.

Pull your head out of the sand. The system did not come up far enough to do what you suggest even though it was clearly capable of it (since it did when sysvinit was in place).

What special treatment? Are you now claiming it is somehow going the extra mile for an ISP to actually do the bare minimum they already promised to do?

If you want to live like a nomad chasing ISPs, beat my guest, but there's probably an answer that will be much better for our society.

Since the report was that it was NOT possible to edit fstab with vim, however far it actually came up was not enough.

You don't get to just ignore the parts of the report you don't like and call the user an idiot.

No. It should at least come up far enough to diagnose and fix. Did you miss the part about not coming up far enough to edit fstab?

Easily done. Given the lack of dependencies on sysvinit, it just drops right in. Feel free!

FORTRAN is an excellent language for that sort of thing even though the standards people seem hell bent on screwing that up lately.

C is great for many things but it's too easy to have bugs that crash it in hard to diagnose ways. Interpreted languages have their place too, but not when absolutely maximum performance is a requirement.

It's probably more like 20 years, we've been pushing against a wall for a while now.

Given everything they have done, how can you even imagine they would hesitate to do that?

Bad people do bad things. Doubly so when the 'person' is of the legally incorporated multi-national variety.

The better argument against GP is the almost purely ad-hominem attack.