Boycott systemd:

http://boycottsystemd.org/

I know things change, and you have to be adaptable. I can use systemd. I've already gotten familiar with it as a systems administrator.

But, IMO, it's an over-complicated piece of shit. The fact that it takes over my logging daemon and stores it as a binary only readable by journalctl irritates me more than I can explain.

F systemd. It is not the solution.

In fact, I have found no situation where SysV init scripts have not served their purpose perfectly.

I don't mind it all being bundled together. I do mind the lack of modularity. Best guess is setting that up is "too much trouble." If it had something along the lines of:

./configure <normal stuff> --with-system-logger --without-coredump-mgmt --with-alt-ipc= --without-network-ctl --use-posix-libc

etc. etc.

It wouldn't create nearly this much rage.

Every piece of systemd is easily duplicated by stand-alone packages which, in my opinion, makes it useless.

One of the key arguments has been service management and parallel daemon loading. If this was the chief arguments we could have enmass started using s6 and Runit which as init systems offer this feature set. Everything else could have been pushed back out to inet, ConsoleKit, eudev, etc. Runit and s6 are even POSIX compliant and fully support usage of sysvinit daemon start scripts if a run-file doesn't exist yet. They even can work with existing sysvinit scripts to further uncomplicate the boot process until Stage2 when they parallel load everything else in the service listing.

Yes it's over bloated and honestly, in my opinion, more effort into getting s6 and Runit pushed out should have been made, or even push perp for sysvinit more, but it's too over bloated and far too complicated to be really beneficial to the people it's aimed at which are the people who don't use Linux to begin with.

Binary logs that are readable only by Journald was a terrible idea. If you have a system failure and don't have a duplicate logging package to generate non-binary text logs and you have to enter via chroot, you're screwed because Journald can't be ran.

I disagree on the last part, and the reasons are listed in a previous mention. But I like your configure idea!

And I totally agree here:

Each person is going to feel differently about it, depending on their role. I can't imagine that programmers are going to like it, and sysadmins CERTAINLY don't like it because it is such a big change for such little gain. Its like retraining for no reason.

You can simply run journald from your live-system and use the --root= option of journalctl to attach to the log of the installed system.

Don't know what sysklogd or whatever can't be modified to use the gzip library or whatever before saving; If space is the concern.

Yes but you also have to have the host for the chroot able to use systemd tools also. I doubt many servers or users are going to have a dual-boot just for this purpose. There aren't too many live medias that offer systemd on optical media, if any. I think most still use BusyBox and mdev. I do know from when I was playing around with it, systemctl would not work under chroot period, and Journald needed systemctl running to work last I tried it.

To me binary logs are a waste. Text files are able to be read by any OS with any text editor from kwrite to Windows NotePad. Plus, exporting the log seemed very problematic also. I couldn't get it to work.

And yes, adding a gz, bz2, xz, or other compression technique to sysklogd wouldn't hurt, but having it also flush the old log and rewrite it upon reboot would be good too. Though then again, since when do text files get that unmanageable? You could even script it to run gzip at shutdown on the log file to export it before the system drive is remounted in RO mode.

I want to point out, as someone who does large scale systems management on Windows platforms... Stuff that is binary formatted is a pain. I understand that its unavoidable in some places. But, if you get a corrupt text stream, some of that can still be useful. If you get a corrupt binary file and you try to use the reader, you get really helpful stuff like:

The file format is invalid.

Windows Event Viewer is a pain to deal with as it is. Opening a sysklogd log is doable in anything like emacs, vi, nano, etc. text editors. Its nice, and ultimately better, to have simple tools able to do multiple things. I prefer text file logs to be honest. So much easier to deal with.

Interesting. I've often wondered when we would see a formal call for a boycott. However - what of the last resort to migrate to *BSD? Linux is GNU and BSD is not. What does Richard Stallman have to say about all of this?

Perhaps it is still important to keep (real) Linux alive through Debian et al. Recently (not sure when) the sysvinit package in Jessie changed to a metapackage whose description reads "This package is an essential metapackage which allows you to select from three available init systems in Debian (sysvinit, upstart, systemd) while ensuring that one of these is available on the system at all times." I fear this will go away before Jessie goes stable, but perhaps efforts (even if third-party) to keep this functionality could go a long way.

Also, who is going around Wikipedia changing all of the Linux schematics to have systemd as PID1? Usurping the operating system - and now a supposedly unbiased encyclopaedic description of it - this is getting way out of hand. The one figure on the cgroups page very explicitly implies that Linux != POSIX-compatible. A figure on the main Linux page ("Free and open-source-software display servers and UI toolkits.svg") seems to promote a VERY future-oriented, wish-list attempt at what looks like a different operating system than any distro in existence right now, with a convenient showcase of RedHat software. These people are SICK and it's time to organize and not just complain.

I've noticed it too, but Wikipedia often runs consistency checks and administrators do check for inconsistencies and will revert pages as needed.

Yes, it is time to issue a formal boycott, and it's time that other than my effort to get eudev going, we get someone to get a more viable UNIX init solution, other than SysV created and get formal scripts drafted and mass produced and started officially in LFS.

We have Runit as a better alternative, but Runit scripts are needed desperately. Runit's website already has all the information we need to get a proper hint drafted, but we seriously lack a generalized script set that can be used equally to the SysV and systemd bootscripts packages. To get an Runit script running, all you have to do is create a symlink between the script work folder and the service folder, but there's very few existing scripts as little attention was ever given to Runit.

We need someone who's proficient in init scripting to draft at least an equivalent Runit script set for all daemons, runlevels, and such to create a full fledged script set for Runit.

I picked Runit because Garret Pepe created this software to target all of UNIX, not just one branch of the tree. Runit runs on MacOSX, Solaris, BSD, Linux, and several other flavors though only a few can officially boot with Runit for now.

We all know full well that if a project can be made to work with LFS it can translate to any Linux distribution.

I think ArchLinux had scripts in their AUR repository, we could check it out.

You have to view the question from a different angle: What is the point of having a Linux From Scratch with systemd?

Systemd ist basically the "kernel" of Lennart Poetterings "Core OS" and the reference implementation of "Core OS" is Red Hat Enterprise Linux 7. So by building an OS based on systemd you end up with a more or less mediocre ripoff of RHEL7.

What is the point of doing that?

Exactly.

If LFS is still using sysvinit by default, and all they needed was udev, they should have researched, at least in my opinion, another low-level alternative init system and stuck with eudev. Going systemd was just overkill and unnecessary.

I've been meddling with Runit for several months now, and I can actually say Runit is a viable alternative and the scripts from ArchLinux gave a better insight into the init system.

The problem is now is getting the exact needed LFS-Runit-bootscripts that duplicate LFS-bootscripts and then reduplicate the BLFS bootscripts to match.

Exactly, LFS really should not have anything like a default IMO, using systemd as a default for anything defeats the purpose of LFS in the first place