Wait… Let me see if I understand this correctly… 1. Move fsck functionality into systemd 2. Have it generate opaque binary logs 3. If your filesystem is corrupted in a way that systems can’t repair, you can’t even read the logs of what systemd saw or did?
Yeah, that sounds like a very definite “bad thing”. Owen On Oct 21, 2014, at 10:17 AM, Israel G. Lugo <israel.l...@lugosys.com> wrote: > I was actually not aware of this. I've been told that systemd also > includes fsck's functionality (or is planning to?). That just seems > absurd to me. > > I didn't really have a strong opinion on either side of this yet. Seeing > the replies from other people here, though, and reading some more about > it, this seems to be a very bad idea. > > The binary logs for example worry me, especially corruption issues: > > http://www.reddit.com/r/linux/comments/1y6q0l/systemds_binary_logs_and_corruption/ > https://bbs.archlinux.org/viewtopic.php?id=169966 > > > > On 21-10-2014 14:40, valdis.kletni...@vt.edu wrote: >> On Tue, 21 Oct 2014 14:44:57 +0900, Randy Bush said: >>> systemd is insanity. one would have hoped that deb and others would >>> know better. sigh. >> It started as a replacement init system. I suspected it had jumped >> the shark when it sprouted an entirely new DHCP and NTP service. And this >> was confirmed when I saw this: >> >> "Leading up to this has been cursor rendering support, keyboard mapping >> support, screen renderer, DRM back-end, input interface, and dozens of other >> commits." >> >> http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ >> >> When your init system is worrying about cursor rendering, you have truly >> fallen victim to severe feature bloat. I guess Jamie Zawinski was right: >> "Every program attempts to expand until it can read mail." > >
