On 16.02.2014 20:50, Canek Peláez Valdés wrote:
[ ... ]
It's because they are cons only if you agree with systemd's view of the world.
I do.
Isn't there too many "if you believe" and "if you agree"? A church of
systemd? ;)
I wonder why all systemd's fancy stuff hasn't yet been integrated into
any existing init system, because of theoretical impossibility or just
practical uselessness?
Actually why not do the daemon management, logging, cron etc in the
Linux kernel itself? It's obvious, and we even have a perfect example of
kernel-integrated graphics around -- `guess the OS name`. It also has
much in common with systemd; "Believe us it's the best OS", "Believe us
it provides loads of features", "Agree with having binary logs" etc.
A competent approach for choosing software for a task is answering the
questions:
1. Is the software standards-compliant?
2. Does the software have an alternative compatible implementation?
3. Is the software developed to achieve a certain, concrete goal?
4. Does the software achieve the goal?
5. Does the software achieve the goal "gracefully"?
6. Does the software have a clear perspective and view what it will be like?
7. Is the software developed and maintained by a reliable company or group?
AFAICT, with systemd there's by far one "yes". The other answers are
dubious if just plain "no".
I'd personally share Alan McKinnon's POV: there's no real reason to
switch to systemd since the present init systems serve pretty well and
the benefit, if any, isn't worth the adaptation threshold.
But why then is Linux drifting to systemd? The answer is simple: money.
Time is money. You have to support two init systems -> twice the time,
twice the money. Sooner or later, a sum of money will outweigh the
users' opinion. To be a realist, one has to admit that in near future
90% of new distro versions will be systemd-based. Unless some green soxx
emerge and take over Red Hat...
--
Best wishes,
Yuri K. Shatroff
