On Wed, Oct 22, 2014 at 12:35 PM, George Herbert <george.herbert@gmail.com> wrote:
On Oct 22, 2014, at 9:30 AM, Jeffrey Ollie <jeff@ocjtech.us> wrote:
The people that like systemd (like myself) have wisely learned that the people that hate systemd, hate it mostly because it's different from what came before and don't want to change. There's no way to argue rationally with that.
I think you are monumentally misreading the situation.
A) Change is the constant in IT. Staying relevant and employable has put me through five or more generational shifts in enterprise OS, plus diversions to Mach, Plan 9, MacOS, etc. Change is normal.
I agree with you about change, but there are a number of people that vocally resist any kind of change, no matter what. There's little that can change their mind other than time. It's a useful skill to be able to recognize these people and not to let them get you down.
B) Systemd and the Solaris SMF that it conceptually followed have a number of technical flaws, ranging from obscure interfaces (sometimes requiring source code to understand) to lack of human readable configs to (at least with SMF, and as far as I can tell systemd) a lack of ability to even print/dump out the current dependencies and ordering tree.
I have no experience with Solaris SMF so I can't comment on it specifically, but in my opinion systemd: 1) has excellent documentation, especially when you compare it to other open source documentation. 2) What's more readable than .ini files? They even avoided the temptation to use XML. I can't tell you how much time I've wasted reading shell script spaghetti trying to figure out exactly how a service is started up. Services implemented in Java and Ruby seem to be especially bad at that. 3) systemctl list-dependencies, although since service start-up in systemd is highly dynamic it's difficult to predict what order services will start up.
C) In both systemd and SMF a tremendous unpreparedness of training and documentation accompanied rollout. These were not reasonably enterprise ready at launch, or now.
In 2010/2011 when systemd was first being integrated into Fedora (and I believe SuSE) I would have agreed with you. However this is four years later and I couldn't disagree with you more. More to the point, Red Hat disagrees with you, given that they have put their money where their mouth is and integrated systemd into RHEL7.
D) The architectural case that the services adopted in systemd over time belong there or are safe there is not proven, and not that I see well argued or documented. Conglomerated services are at least to be eyed skeptically.
I did not closely follow systemd's development but it is evident from a distance that operator feedback in the community and to Sun regarding SMF flaws was somehow missed in systemd's development as they did the same wrong things.
A change this big deserves architectural clarity and justification.
I don't follow systemd development closely either, but Lennart Poettering, Kay Sievers, et. al. have made extraordinary attempts to communicating about systemd. They've appeared at numerous conferences and given talks about systemd, written blog posts, documentation, etc. I don't know what else they can do other than to be invited over to everyone's home for tea and a systemd discussion.
We get snide comments about change being good and core developers Linus evidently feels are unsafe.
We also get snide comments about change being bad. As for Linus, other than the fact that he has an extraordinary amount of influence over what goes into the kernel, I've learned to take his comments on other matters with a very large grain of salt. I have a lot of respect for the guy, but his attitude and behavior towards other people is appalling. What's really surprising about some of Linus' comments WRT to systemd is that one of systemd's main goals is to make it easier to use some of the advanced functionality of the Linux kernel that were little used or ignored before. -- Jeff Ollie