Igor Živković wrote: > On 02/04/2014 06:54 PM, Armin K. wrote: >> On 02/04/2014 06:26 PM, Igor Živković wrote: >>> On 2014-02-04 18:18, Armin K. wrote: >>>> http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/webm-high/983_Why_Debian_should_or_should_not_make_systemd_the_default.webm >>>> >>>> >>>> Lennart managed to explain why/why not should Debian (but can be applied >>>> to many other distros) use systemd by default. He got some interesting >>>> points there. Since I noticed that some of you don't really understand >>>> what systemd really does except the binary logs, adding bloat and using >>>> D-Bus, it might be worth to watch. >>> >>> >>> http://wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd >>> >>> >> >> Looks interesting, I'll read it later. I did notice lot of UNIX word >> usage there, so it's natural that people who still "worship UNIX" are >> against systemd. > > Not really, people who worship Unix would probably pick one of *BSD. > It's more like that some people aren't happy about their systems slowly > being turned into the systemd monoculture.
I listened to the presentation and read the article. Let me say first that the profanity in the article detracted (for me) from what are really some valid points. This is my view: Unix/Linux has evolved. Many of the things we do today are due to hardware limitations in the past. /bin, /sbin, and /lib are there because of limits and expense of early disk drives. Programs like initd and xinitd are there because of the limited ram that was available. Today, an initrd often replaces the /bin, /sbin, and /lib structure. Both should have only one purpose: to mount /usr. The problem is that the initrd has been abused to do a lot of other tasks that can be initiated in user space. The important issue that most distributions face is that they need to be able to support a vast amount of hardware. Having a system with thousands of modules (literally) and having the boot process look through them slows down the boot process immensely. As was pointed out in the written article, the 'boot time' is often dominated by the BIOS and in hardware initialization. One question here that needs to be answered is "How do you define boot time?" If you define it from power on to a graphical login prompt, you will get vastly different results than if you define it from the time the kernel starts executing to a text login prompt. In LFS, we customize our kernel so we eliminate a lot of things a commercial distro does. In my experience, using sysv init, kernel start to a login prompt is about 8-10 seconds. In a virtual environment where no probing of real hardware is done, it's closer to two seconds. One of the main goals, indeed the primary goal, of LFS is to teach users how a system is put together and how things work together. The sysv scripts allow the user to see exactly what is happening and easily modify them if desired. In other words we give the user total control. systemd is, in many ways, like busybox. It aggregates many programs into one. This provides convenience for casual users, but dramatically reduces flexibility for users who would be interested in projects like LFS/BLFS. systemd offers some advantages for certain situations, but as I've said before, those advantages are useful for only a very few users. The talk addressed "multi-seat systems" repeatedly. How many of those are still around? Yes, they do exist, but in today's environment of cheap hardware, it seems to me to be a niche environment. My experience with such systems is pretty much limited to the last century. About the only one I've used recently is in a supercomputer environment and even those are adding web front ends. The certainly don't have GNOME or KDE desktops (at least for any of those I've used). I agree with the article criticizing systemd in that the init process does not need to control login, logging, udev, cron, and a host of other things. Yes, I do know that udev can be done independent of systemd, but they don't make that easy. I'd much rather have the ability to mix and match (or omit unneeded) programs than be tied into an ecosystem where I have no significant ability to exercise the control I want. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
