Le dimanche 14 juillet 2013 à 20:19 +0100, Kevin Chadwick a écrit : > I certainly wouldn't run systemd on any of our systems including > production systems or products and in fact could never run it on some > of our embedded products because it is simply too resource hungry.
If you have requirements that are so low that the systemd memory footprint is a problem, you should probably switch away from Linux and definitely switch away from Debian. We do not practically support systems with less than 256 MiB of memory. > It is a far better and prove more workable and less problematic default > for corner case and controversial features (almost all of systemd can be > put under that category) that increase complexity and the number of > lines of code to be optionally installable such as monit, redundant > systems and carp or nagios for user access uptime than to make users > work backwards. What you do not understand is that systemd dramatically *reduces* complexity. > p.s. I haven't the time to talk about or even recollect a 20th of the > problems that systemd poses which should be enough for anyone to say > hang on, what is this mess, it is obviously not optimal or very > close to suitable for all as any init system should and always > has rightly been. “We’ve been doing things this way for 30 years, and it never was a problem!” You know, I hear this sentence a lot. People who don’t want to migrate from rsh to ssh despite the reduced user-level complexity. People who don’t want to automate deployment because they already have a huge stack of buggy scripts that often works. And now people who want to stick with buggy shell scripts instead of migrating to a much simpler, declarative mechanism. Change resistance is normal. There is a cost to any change, and questioning it is fine. But if we never actually did any change, we would be stuck with Multics. > P.s. whenever I hear someone talk about Linux and Modern it is simply > proving to show that commenter's inexperience. Only idiots *require* > cgroups or parallelisation the latter being only required/beneficial > when the fastest bootup is required, which is almost never the case else > bioses wouldn't conduct post tests or memory checks. Systemd was not written to reduce boot time. It was written to handle the boot process *correctly*. Reducing the boot time is a nice side-effect for teenagers, but it was never the point. Cgroups are not used to improve the boot time - and I’m pretty sure they actually delay the boot process. They are used to put each daemon and each user session in a container that can be throughly cleaned up when needed, which is a giant step forwards in terms of reliability. Parallelisation is not something new in systemd: we already have it in Debian with insserv. And just like with insserv (which uses declarative fields too, see how that makes things better), it is just a side-effect of having done things more correctly. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1373877164.2461.703.camel@pi0307572
