On Mon, 17 Feb 2014 21:52:55 +0400 Andrew Savchenko <birc...@gmail.com> wrote:
> On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote: > > On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann > > <volkerar...@googlemail.com> wrote: > > > Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: > > >> On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann > > >> <volkerar...@googlemail.com> wrote: > > >> [ snip ] > > >>> or it is an idiotic decision. Because features means complexity. > > >> Yeah, like the kernel. > > >> > > >>> Complexity means bugs. > > >> Bugs get reported, bugs get fixes. Life goes on. > > > > You didn't answered this, did you? > > Bugs are different. Bugs in the critical system components are > critical to the whole system. If Libreoffice or browser > segfaults, some data may be lost and inconvenience created, but the > system will continue to run. If PID 1 segfaults — everything is > lost, you have a kernel panic. That's why critical components should > be as simple and clean as possible. If it does, but does it? We have run it for ages without a segfault. > SysVinit code size is about 10 000 lines of code, OpenRC contains > about 13 000 lines, systemd — about 200 000 lines. That is an unfair comparison, be fair and consider PID 1's code size. > Even assuming systemd code is as mature as sysvinit or openrc (though > I doubt this) you can calculate probabilities of segfaults yourself > easily. Practical statistics are more reliable than theoretical probabilities. > > >> All of them are different tools providing one capability to > > >> systemd as a whole. So systemd is a collection of tools, where > > >> each one does one thing, and it does it well. > > >> > > >> By your definition, systemd perfectly follows "the unix way". > > >> > > > > > > no, it isn't. > > > > > > How are those binaries talk to each other? > > > > dbus, which is about to be integrated into the kernel with kdbus. > > And this is a very, very bad idea. Looks like you don't know matter at > all: to begin with kdbus protocol is NOT compatible dbus and special > converter daemon will be needed to enable dbus to talk to kdbus. That claims it to be a bad idea, but doesn't tell why; furthermore, no technical reasoning as to why it is incompatible is given. Do you know? > The whole kdbus technology is very questionable itself (and was > forcefully pushed by RH devs), anyway it is possible to disable this > stuff in kernel and guess what will be done on my systems. Similar claims again, without any weight; that is subjective opinion. > > > Looks broken. Broken by design. The worst form of broken. > > > > By your opinion, not others. > > That is not just an opinion. It is due to the lack of science and experience in your response. > And all that science was ignored during systemd architecture process > if there was any at all. For it to be claimed as "ignored", you need to know about the process; given that you don't even know its presence, such claim can't be made. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
