I have been working with developing systems that boot with Linux for a number of years on a multitude of distributions and I never saw a problem with the tools or the process. Purely the lack of standards. It seems stubborn at the least to propose an opaque software solution when a simple standards organization for how to structure the init system is all that is required. Why not write high level code to manage standardized scripts rather than replace them with binary darkness. The only reason we have desktop Linux is due to the flexibility of the Unix architecture, seems silly to abandon that now. The pure fact of it is that developers hate messing with text because its unpredictable and prone to bugs. However with standards and possibly a decent meta format (I look towards YML, XML, JSON) that can be consumed and produced with scripts there should be no issues. The final fact is that bash itself is a dirty language that developers hate and system administrators love. Its a gross blend of programming functionality mixed with command line awareness and its unpredictable, especially at the code generation level. Its also too sensitive to text formatting and line endings. In conclusion, we will continue to deploy our scripts to a number of Linux distributions and have came to the conclusion that it is simply cheaper to have a human deal with the actual deployment of the system rather than write host of deployment code to cover every system. End users know how to use their system and we rely on that. Finally, why not focus on creating and maintaining collaborative unbiased standards rather than parading egos and hurting communities. On Tue, Oct 21, 2014 at 1:55 PM, Owen DeLong <owen@delong.com> wrote:
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:
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
http://www.reddit.com/r/linux/comments/1y6q0l/systemds_binary_logs_and_corru... 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."
-- eSited LLC (701) 390-9638