First, I apologize for top posting, but I don't have any part of the message I can reply to, so I'll start here.
Now, people need to distinguish two things: systemd itself is a name of an umbrella project hosting many tools/daemons that manage the system (not just bootup and shutdown) and at the same time systemd (the binary /sbin/init points to) is just an executable designed to do what it should do, while doing other things that are also necessary for doing things "the right way". While those things may not be useful to some people, they will be useful to others. There's no way you can make everyone happy, sorry. So when people say "systemd has ..." they most of the time mean about the umbrella project, not about the /sbin/init. It would be the same as saying that Xorg has an xclock. Xorg is a big project, xclock is a subproject. The only difference is that Xorg has everything modular, while systemd keeps everything in one repo (like Xorg used to do in the past). Now, every time I see systemd threads, I see these 3 mentioned: "There's no big difference in boot time when using systemd and sysvinit" The boot time is irrelevant. That wasn't the goal when systemd was made. systemd can be slower in some cases, depending on what you do. Boot time decrease is just a side effect of "things done right" (whatever that may be). "It uses binary logs" Yes it does, it's as good as it's bad idea, see below why. "It does not follow UNIX Philosophy" Anyone who works with modern software will notice that nothing today follows that. Even X.org (the thing everyone has installed) does more than one thing, doesnt't use text streams (the X server is a(n) (terrible) IPC), etc. The technology and software have evolved so much that UNIX Philosophy is silly nowadays. Even the modern text editor (and I am not speaking of VIM and alike) does more than one thing today, but still in defense you could say that it "handles text (but does many more things in process of doing that)", but in the same way you could say for systemd is that "it manages your system (system and session manager as the upstream claims)". Speaking about anything modern that should follow the UNIX Philosophy is just silly today. > 30 years in software development is like 1000 years in real world. It evolves rapidly. On 09/09/2014 09:41 AM, Mattias Schlenker wrote: > > Am 09.09.2014 um 06:31 schrieb Bruce Dubbs: >> >>> >>> The other day I was trying to understand how updatedb was scheduled to >>> run on my Arch install, as there was no entry in cron. It turns out >>> it's "scheduled" via systemd: "When mlocate is installed, a script is >>> automatically scheduled to run daily via systemd" [1]. Really? >>> Systemd is also a cron replacement too now? >>> Yeah, it does. It has more or less everything required to manage a (modern) Linux system. >>> [1] https://wiki.archlinux.org/index.php/locate >> >> and a dhcp client and a login client and a syslog client ... >> dhcp server is there for assigning network addresses in containers that systemd also can manage (why? I have no idea and I can't say I really like it doing that, but it's not done in PID1 so I don't really care). I do like the idea of networkd, it really beats all the implementations all the distros have for low level networking management, ie Debian's ifupdown, Archlinux's netctl, whatever the Fedora/RH/SuSE use (ifcfg)? Not to mention that dhcp client library (not an actual executable) was contributed by Intel and it being a library makes it possible to bring up the network in matter of miliseconds and not having to deal with hell of managing forked process of a dhcp client such as dhclient. All the recent work was about using systemd in containers and having stateless systems for fast deployments in enterprise if I recall correctly. I don't really know what syslog client might be, but I suspect it's about syslog _daemon_. Yeah, journald is required for systemd (as a matter of fact, systemd (/sbin/init), udevd and journald are the only components that can't be disabled, everything else can), and one could agree that having logs stored in binary format might be a bad idea for several reasons, but there are also few good reasons why it's a good idea. Ie, it logs *everything* in one place, so you don't have to go through several log files and search for the thing you were looking. Another thing is that all entries have a proper time stamp, and being in binary format, you can manipulate them any way you want. Ie, recently I had an issue where GPU driver was causing my machine to hang, but I wasn't aware of that. I could just look at the logs starting from a specific time (and ending at a specific time, from a specific service, etc) to find out that GPU driver was hanging and I had to deal with newer kernel(s). I don't think this is possible even with grep/less/cat other than having to look yourself at that. Also, last time I checked, kernel messages (dmesg) weren't properly timestamped, so you had to guess when something happened in case you leave your machine for some time and find out that something undesired has happened. That may have been changed though, it has been a long time since I used any other system log daemon implementation. And if you don't like it (you still can't disable it) you can install your favorite system log daemon and let journald forward messages to them. The only thing that may be anoying is having to run 2 daemons, but journald is not something that you'd even notice that's running, much like any system log implementation. >> You can disable them or ignore them, but you can't remove them if you >> are using systemd for other things. >> > > ...and a replacement for ntp client and server. I guess at some point it > will also include a IPP printing daemon and other daemons as well. > It's just SNTP client, not a server. It's mainly there for synchronizing network time in containers and servers that don't need the ntp server capabilities. Still optional. If you get some time, you can see what Debian is doing about systemd nowadays along with some explanations about what each (well, some of) component(s) do(es). http://ftp.acc.umu.se/pub/debian-meetings/2014/debconf14/webm/A_glimpse_into_a_systemd_future.webm -- Note: My last name is not Krejzi.
signature.asc
Description: OpenPGP digital signature
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
