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.lugo@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_corru... https://bbs.archlinux.org/viewtopic.php?id=169966
On 21-10-2014 14:40, Valdis.Kletnieks@vt.edu wrote:
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
On Tue, 21 Oct 2014 14:44:57 +0900, Randy Bush said: 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."