On Vi, 10 oct 14, 08:36:23, Joel Rees wrote: > > Some complexities you can encapsulate or hide, or expose in an > organized manner so that that are easier to deal with. Others, no. [big snip] The complexity argument can be used both ways: - the Unix way (do one thing and do it well) leads to many small tools that can be combined in different ways, where each tool has its own quirks, bugs, release schedules, etc. that only increase complexity - sysvinit (/bin/init) is indeed quite simple, but in practice it's own mechanisms (/etc/inittab) are only used to start sysv-rc (/etc/init.d/rc), which starts all other initscripts, poorly written (/etc/init.d/skeleton itself is known to have bugs) in a (poor) programming language (shell script) with many different implementations (bash, dash, etc.). The scrips are not even enough, they have to rely on additional tools like start-stop-daemon(8) with their own quirks and bugs. - each service/daemon is implemented in its own unique way, with different methods of running (quite often multiple ways, depending on start-up switches, like foreground, forking, etc.), reloading, logging, etc. - computers have gotten quite complex themselves with removable devices, complex network connectivity, etc. - multiple users on the same system (GNU/Linux is supposed to be a multiuser system, isn't it) with different backgrounds, level of technical understanding, expectations, etc. It feels to me like systemd (the project) is rather *trying* to reduce complexity, by providing: - a clear and simple way (unit files) to declare what a service needs and how it should be run and a clear and simple method for the daemon to notify when it is ready to provide its service if its authors choose to implement it - mechanisms to deal with badly behaved daemons as well as provide proper isolation (e.g. cgroups, tmp files handling, etc.) - mechanisms to deal with the complex interactions between daemons, devices, networks, etc. - a logging mechanism that can capture *all* output of a daemon (stdout, stderr, logging) - a unified way to manage users (as in humans) and their complex ways of interacting with the computer (different privileges, local, remote, etc.) - etc. Is systemd (the project) trying to do too much? Possibly. Would it be better if this was done in a modular design *done right*? Probably. Yet, none of the solutions so far has *really* caught on. daemontools, runit, s6, init-ng, etc. and even upstart were either never adopted on a large scale or eventually abandoned in favor of systemd. As far as I understand Linus Torvalds himself admits that a modular kernel design is better, yet he choose to make Linux monolithic. On the other hand Hurd is still not even in a releasable state. Could it be that a modular design for such complex tasks becomes too difficult to *do it right*? Is systemd going to change the GNU/Linux ecosystem? Definitely. Will this change be good or bad? Only time will tell, but I'm quite sure that even if the change will turn out to be bad it will *not* destroy GNU/Linux, but help it evolve in better ways. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt
Attachment:
signature.asc
Description: Digital signature