Mailinglist Archive: opensuse-factory (1578 mails)
| < Previous | Next > |
Re: [opensuse-factory] Runlevels in 12.1?
- From: Michal Kubeček <mkubecek@xxxxxxx>
- Date: Mon, 14 Nov 2011 08:19:14 +0100
- Message-id: <201111140819.14346.mkubecek@suse.cz>
On Monday 14 of November 2011, Brian K. White wrote:
I've read it. I read several articles about it. When you look through
the big words and phrases, there is nothing. Nothing else than (maybe) a
bit faster boot which is payed for by great complexity (leading to more
complicated configuration and diagnostic) and incompatibility with
third-party projects; some of them not developed primarily for Linux and
some not developed with Linux in mind at all; their developers are not
going to automatically accept the "the way you've been doing it until
now is wrong, rewrite your daemons not to be daemons".
Nice example of those phrases I mentioned above. What does this
"dynamic" really mean? On one hand, unnecessary complexity, complicated
configuration, difficulties with diagnostic. On the other hand, maybe
few seconds of boot time. On some computers, I boot once a day (twice if
there is a kernel update), on others every two weeks, on some every two
or three months. On none of them, few seconds of boot time matter.
Cars had issues but they had potential. This is in fact analogy of KDE4
- it was in very bad shape when it appeared but it was clear from the
beginning that it will be better than KDE3 one day (and I never said
KDE4 was bad as such - I ony criticized that it was made default too
early and that KDE3 was removed too early). With systemd, this is not
the case. It tries to solve an artificially overrated problem and does
more harm than good. Even if the problems with documentation and bugs
are solved one day, the rest is to stay. And these intrinsic problems
are enough to outweight the few seconds of boot time you get.
Michal Kubeček
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx
On 11/13/2011 5:12 PM, Michal Kubecek wrote:
I'm sure the systemd home page will provide a full summary of it's
goals.
I've read it. I read several articles about it. When you look through
the big words and phrases, there is nothing. Nothing else than (maybe) a
bit faster boot which is payed for by great complexity (leading to more
complicated configuration and diagnostic) and incompatibility with
third-party projects; some of them not developed primarily for Linux and
some not developed with Linux in mind at all; their developers are not
going to automatically accept the "the way you've been doing it until
now is wrong, rewrite your daemons not to be daemons".
Without even having looked at their home page I already know it makes
it possible to express lots more accurate and dynamic start/stop
dependencies and procedures for subsystems.
Nice example of those phrases I mentioned above. What does this
"dynamic" really mean? On one hand, unnecessary complexity, complicated
configuration, difficulties with diagnostic. On the other hand, maybe
few seconds of boot time. On some computers, I boot once a day (twice if
there is a kernel update), on others every two weeks, on some every two
or three months. On none of them, few seconds of boot time matter.
Don't be like what Ford said about what users want. If he had asked
people what they wanted they wouldn't have said motor cars, they'd
have said faster horses.
Cars had issues but they had potential. This is in fact analogy of KDE4
- it was in very bad shape when it appeared but it was clear from the
beginning that it will be better than KDE3 one day (and I never said
KDE4 was bad as such - I ony criticized that it was made default too
early and that KDE3 was removed too early). With systemd, this is not
the case. It tries to solve an artificially overrated problem and does
more harm than good. Even if the problems with documentation and bugs
are solved one day, the rest is to stay. And these intrinsic problems
are enough to outweight the few seconds of boot time you get.
Michal Kubeček
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx
| < Previous | Next > |