| 1 |
> From a technical point of view (the quality of the code and the time |
| 2 |
> it takes to fix bugs), I believe everyone (even Lennart's most fervent |
| 3 |
> detractors) will agree that systemd is a superb piece of software. The |
| 4 |
> problem is the philosophy behind it; if you agree with said |
| 5 |
> philosophy, systemd is great. Otherwise, is a new fangled beast which |
| 6 |
> goes against everything that UNIX stands for (whatever that means), "a |
| 7 |
> solution for a problem no one has", and "fixing something that wasn't |
| 8 |
> broken". |
| 9 |
> |
| 10 |
|
| 11 |
I won't start this up again, there is lots of info out there. LWN |
| 12 |
and this lists archives maybe reasonable for some for and against |
| 13 |
arguments. This post is as bad as Lennarts myth busting post which |
| 14 |
avoided all the real issues and skirted around the ones he did mention. |
| 15 |
|
| 16 |
The real drive behind systemd is enterprise cloud type computing for |
| 17 |
Red Hat. The rest is snake oil and much of the features already exist |
| 18 |
without systemd. With more snake oil of promises of faster boot up on a |
| 19 |
portion of the code which is already fast and gains you maybe two |
| 20 |
seconds. |
| 21 |
|
| 22 |
> 3. "is openrc just a dead project is that why?" |
| 23 |
> |
| 24 |
|
| 25 |
Not even close, systemd is one of the least used init systems. The |
| 26 |
question you should ask yourself is why would anyone talk about the fact |
| 27 |
they are using OpenRC. Having said that I do hate all the symlinking |
| 28 |
rubbish many linux (not OpenRC) uses but would bear it over systemds |
| 29 |
technical flaws. |
| 30 |
|
| 31 |
So there you have it complete contradictions which mean you should make |
| 32 |
up your own mind, even if it is easier for the more advanced arguments |
| 33 |
against it to be overlooked. |
| 34 |
|
| 35 |
> Is not dead; it has new releases and stuff. Just not many features are |
| 36 |
> implemented to it, and it has some pretty awkward bugs, some of them |
| 37 |
> years old, like not being able to start services in parallel. |
| 38 |
> |
| 39 |
|
| 40 |
There is arguably more weight to the argument of an init system that |
| 41 |
does parallel starting being a bug. |
| 42 |
|
| 43 |
What do you gain, speed? and complexity, what do you lose reliability |
| 44 |
and predictability. |
| 45 |
|
| 46 |
If you cause disk churn it *may* even be slower too such as windows |
| 47 |
tools that stage autostarts. |
| 48 |
|
| 49 |
Do one thing and do it well and you are more likely to make it into |
| 50 |
every Unix-like OS for good not so obvious reasons. |
| 51 |
|
| 52 |
I hope this doesn't start into another discusssion just know that there |
| 53 |
are many arguments badly represented by Canek to research if you want |
| 54 |
your answer. |
| 55 |
|
| 56 |
-- |
| 57 |
_______________________________________________________________________ |
| 58 |
|
| 59 |
'Write programs that do one thing and do it well. Write programs to work |
| 60 |
together. Write programs to handle text streams, because that is a |
| 61 |
universal interface' |
| 62 |
|
| 63 |
(Doug McIlroy) |
| 64 |
_______________________________________________________________________ |
Archives