I've finally finished reading the whole article thanks to longer build time for some of LFS packages.
While it's clear from the article that he's hardcore unix user and follower, I don't agree with one of the last paragraphs that Linux IS UNIX. Linux is UNIX like Operating System, it's a "clone" of the original UNIX, but it isn't UNIX and that doesn't mean it must follow *everything* UNIX did. Also, according to him, it is *prohibited* (well, maybe a harsh word) to use any modern technologies to implement something *someone else* might like/use/require if it's not implemented "the UNIX way". As Bruce said below, the "UNIX way" was rather the only way back then because of several limitations. On 02/04/2014 08:49 PM, Bruce Dubbs wrote: > 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: > Everything is more or less in place and I agree with you. I do have a comment or two below. > 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 believe that multi-seat that's being mentioned isn't the one you have in mind. Originally, UNIX and UNIX Like OS's are multi user operating systems, so in a way you can login into one system from several places as different or same users. In a way, that's what one would call "multi seat". So in the GUI era, an user could be logged to a desktop (use GUI, in general), while the other could be logged via SSH to the console and the third one could use the VNC to log in as a different user, for GUI. But only the first user has "physical" access to the hardware, meaning that he has access to display, audio card, web camera, microphone, what not. What systemd does in this case is properly manage such situations and calls it "multi seat management". It is important that other two users can't "read" any information from the web camera, display, audio card, microphone, etc, which first user has access to and uses it "in a way". When an user logs in via physical, the systemd (well, logind and it's rather optional feature) sets up a "seat" and gives the user access to the required device nodes given that they are not in use (but since modern machines only have one physical seat, it would be the only user that has access to such features). If an user logs via SSH or VNC or whatever that's not a "real console", logind won't grant such users permissions to use video card, audio device, cdrom, usb sticks, etc. I, for one, wouldn't want someone to access my cdrom device when he logs in remotely as a different user. > 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 > While it's true that systemd does a lot of things it shouldn't be doing, you can disable some of those features and use your own. Only required components that need to be running are systemd (/sbin/init), systemd-udevd and systemd-journald (the log daemon). But you can still use traditional syslog daemon if you prefer plain text logs, and prevent journald from writing to hard drive. systemd would still write to journald since they're integrated, but journald would forward everything to syslog daemon. I believe journald has been explained in the video linked above. You can't however disable some of the internal features, like "cron daemon" (which I don't even know how to use) or inetd replacement (socket activation) since they're part of systemd binary, but these won't give you any overhead, especially on modern systems. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
