31–40 of 189 posts
One giant program to rule them all was never the Unix way. System's monolithic architecture will be its downfall. Rather than stabilize I predict that systemd will get more and more complicated and eventualy fall due to unwieldy maintenance problems at which point someone will come up with a better more modular system.
Earlier quoted context omitted.
I am not against them considering the end users. But getting pushed around by "end-user" (please read desktop-user) focus is way too unacceptable behavior, especially for a community like Debian. edit: added clarification for end-user.
> getting pushed around by end-user focus is way too unacceptable behavior why?
Earlier quoted context omitted.
I am not against them considering the end users. But getting pushed around by "end-user" (please read desktop-user) focus is way too unacceptable behavior, especially for a community like Debian. edit: added clarification for end-user.
> getting pushed around by end-user focus is way too unacceptable behavior why?
One giant program to rule them all was never the Unix way. System's monolithic architecture will be its downfall. Rather than stabilize I predict that systemd will get more and more complicated and eventualy fall due to unwieldy maintenance problems at which point someone will come up with a better more modular system.
People seem to ignore the kernel for some reason, but it is literally one giant program to rule them all, and it works very well. There have been many efforts to modularize it and move most of the complexity into independent units, and none have particularly worked out.
No point in discussing systemd anymore quite frankly, it won, doubt that it's good it did, doubt the methods by which it won - I do both - but it won. Many of the major distributions are not really following the Unix philosophy anymore, heck, some stopped quite a long time ago to do so. I run sever operating systems because I like to have the control, the minimalism, the elegance, the security. By trying to be more o…
And if you look at the things you care about when running a daemon process -- sessions, controlling terminals, reliable restarts (without killing the wrong process), logging, starting dependencies in the right order, dropping privileges reliably etc. -- none of those things are good ideas that work well together. You can clearly see that things like double-forking and detaching from controlling terminals and syslog were all bolted on later, because the original system didn't work well, and the hacks don't work well either.
I run servers, and I'm excited about systemd because it makes all these things actually work. The Unix philosophy gave me tools that do one thing and kinda sorta do them okay, if you're lucky. systemd does multiple things, and it does them all well. Back when we ran FreeBSD, we had hard-coded sleeps to wait for the network and NFS to come up before we continued with boot, and we had regular problems with being too aggressive with those sorts of hacks and having machines that would get stuck before launching sshd. That is straight-up not a problem with systemd.
One giant program to rule them all was never the Unix way. System's monolithic architecture will be its downfall. Rather than stabilize I predict that systemd will get more and more complicated and eventualy fall due to unwieldy maintenance problems at which point someone will come up with a better more modular system.
It's ironic that one of the design goals (or was that just the marketing blurb) of systemd was "modularity".
Init should be just this: http://git.suckless.org/sinit/tree/sinit.c , systemd incorparates too much funcitonality IMO, I cant get used to it. Well, but its a free world, I have even written a Go init, some guy did Rust based, and upstart is still being used by Ubuntu 14.04, I like choices, and happy to see this alternative as well.
1. If the only thing you needed from init was to reap reparented zombie processes and manage to not die, why have init at all? Why not tell the kernel to skip reparenting processes (and just reap them internally if their parent is dead) and not treat pid 1 as special, allowing it to exit? That's less userspace code and less kernel code. 2. Speaking of kernel code, have you looked at how much stuff is going on in the…
ps -eLf | grep '\['
ps -eLf | grep '\[' | grep root
Nice, but from the users' standpoint it would've been better if they had worked with Debian rather than rolling out their own distro.
The problem sort of is that (the rest of) Debian wouldn't work with them on this.
Problem is systemd helps you booting fast and this is important both in the cloud (where every minute is a billed), and in telecom (where you have a stringent SLA to cover).
I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. I love bash, I love nitpicking about how to use bash along with the other bash nazis in #bash@freenode. But I would never put myself through sysvinit again. I thoroughly enjoy using distros like CentOS 7, Fedora 23, RHEL7. They're a joy to manage and work with, in part thanks to Systemd. I never want to debug, troubleshoot, or even look a…