On Fri, Jan 13, 2012 at 11:07 AM, Zachary Kotlarek <z...@kotlarek.com> wrote: > > On Jan 13, 2012, at 8:27 AM, Matt Burgess wrote: > >> I like the idea behind systemd, inasmuch as they are trying to speed >> booting up by using dependencies to allow scripts to run in parallel >> rather than Sysvinit's serial boot ordering. > > > Parallelization and the related speed is one of the talking points, and for > some people that's important, but IMHO it's not the reason we, as system > builders and admins, should care. > > Systemd provides a number of other benefits including: > > 1. All daemons are first-class citizens that get monitoring and re-launching. > Sysvinit theoretically provides monitoring, but since it doesn't provide an > easy way to enable/disable services in practice most people only launch > really vital, never-down services with it. And with the use of cgroups to > capture processes systemd provides much better monitoring that sysvinit or > even many purpose-built tools (e.g. it can track even through a double-fork). > > 2. There is no need to manually order the launch of daemons. Just specify the > service(s) they require, if any, and let the system figure it out for you. > Also no need for huge, mostly redundant symlink directories to tell your boot > scripts what to do. > > 3. Unlimited number of named configuration sets, and snapshots. It's not > necessary to wedge your usage into 5 numbered configuration sets, or to > provide instructions on how to switch between them; just identify what should > run in a given target, either explicitly or relative to another target. > > 4. Useful disk and boot-time events and handlers. For example, systemd > provides a useful way to deal with encrypted mounts that might be necessary > for certain services, but that require human interaction to mount (or that > might need a manual fsck or the like). It will block only the affected > service(s) (with an interruptible sleep), monitor for the mount to become > available, and immediately unblock the service when the mount becomes > available. > > 5. Avoids use of the shell. Sometimes it's necessary to use a shell to setup > a process, but frequently it's not, and there's a lot over overhead involved > if all you really need to do is exec a binary and keep track of it's > process(es). > > 6. Socket services. Back in the day we had inetd, which allowed you to listen > for connections without actually running all the different deamons. systemd > provides the same concept, but for UNIX sockets and D-Bus connections. So > rarely-used services can launch on demand rather than at boot (think > printing, for example). There are also parallelization/dependency > implications to this concept; you need not make service A depend on service B > if service A only needs to access service B's socket -- you can freely launch > A and when it attempts to access B's socket systemd will queue that request > until B is available (starting B if necessary). > > -- > > That being said, I think it's prudent to wait until systemd itself is stable > and at least somewhat widely used; the concept of systemd or a similar > sysvinit replaces seems inevitable to me, but I agree that it's not yet clear > that systemd, in its current incarnation, will be that replacement. > > Also if we wait until it's in wider use it will not be necessary to write all > our own startup config for LFS/BLFS daemons, which would be handy. It's also > likely that, at least within a distro (and hopefully across them) there will > be some naming standards that make systemd configs fairly interchangeable, > and it would be nice to adopt those. > > Zach
So it would pull in libxml2 or expat, and dbus. I could live with that. I prefer not seeing the same libraries in LFS as BLFS though... systemd, The more I read about it, the more I want to try it. Especially if it is using the newer kernel features available to it. And it would be nice if our init system was built to match other distro's. (ex:/ when it comes to sysvinit, software on the computer could not interact with sysvinit to determine it's status or setup bootscripts across different distributions). It sounds like it might have enough adaptation that it could be considered a viable replacement. It also has developers willing to work with distributors to ensure it does what they require. The fact it's mentioned on freedesktop.org is also a + in my books. Still a bit hesitant to throw my support behind it without actually having tried it, but things sound good. -- Nathan Coulson (conathan) ------ Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
