That's an abysmal idea (pun intended).
Besides, llvm vs systemd is not Apples to Oranges (after all those are both fruit and foods). It's Apples to TV remotes.
Besides, llvm vs systemd is not Apples to Oranges (after all those are both fruit and foods). It's Apples to TV remotes.
Inspite of that, ANYTHING is better than systemd.
edit: Having something like LLVM as a first class daemon, compared to something like systemd is not even comparable. It's like... evolution. systemd is like taking corporate backwash and trying to clean a pristine pond.
Not really. It's a great replacement for the mess of init scripts and ad-hoc solutions in traditional unix, and it was an informed decision after many years of deliberations for most distros to adopt it.
Besides this is zero content.
>Having something like LLVM as a first class daemon, compared to something like systemd is not even comparable. It's like... evolution. systemd is like taking corporate backwash and trying to clean a pristine pond.
You keep using this word LLVM. I'm not sure it means what you think it means.
Systemd is not a compiler, it's a system for managing system services and processes.
LLVM is just a set backend libraries for writing compilers, and a collection of some compilers implemented with them.
"Having something like LLVM as a first class daemon" is close to being content free as a statement, especially when that's something's role will be to replace systemd. It's not even wrong, it's meaningless.
In the only way the sentence makes sense "LLVM as a deamon", would be a always-running compiler/server that you pass your programs to it, instead of invoking LLVM as a command line app.
There was no mess of init scripts. The only mess introduced was through poor integration practices through the introduction of corporate induced timelines and requirements, who then introduced an even worse solution.
I really doubt that run-once startup scripts would benefit from JITing, though. And memory overhead might be a non-starter.