[175455] in North American Network Operators' Group
Re: Linux: concerns over systemd adoption and Debian's decision to
daemon@ATHENA.MIT.EDU (George Herbert)
Wed Oct 22 13:35:31 2014
X-Original-To: nanog@nanog.org
From: George Herbert <george.herbert@gmail.com>
In-Reply-To: <CAD-DQxRg_2Fvr5vFGHjrXnTLy0+cgXLci=uC-YGHdXypJGk9TA@mail.gmail.com>
Date: Wed, 22 Oct 2014 10:35:22 -0700
To: Jeffrey Ollie <jeff@ocjtech.us>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On Oct 22, 2014, at 9:30 AM, Jeffrey Ollie <jeff@ocjtech.us> wrote:
>=20
> 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 t=
hrough five or more generational shifts in enterprise OS, plus diversions to=
Mach, Plan 9, MacOS, etc. Change is normal. =20
B) Systemd and the Solaris SMF that it conceptually followed have a number o=
f technical flaws, ranging from obscure interfaces (sometimes requiring sour=
ce code to understand) to lack of human readable configs to (at least with S=
MF, and as far as I can tell systemd) a lack of ability to even print/dump o=
ut the current dependencies and ordering tree.
C) In both systemd and SMF a tremendous unpreparedness of training and docum=
entation accompanied rollout. These were not reasonably enterprise ready at=
launch, or now.
D) The architectural case that the services adopted in systemd over time bel=
ong 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 dist=
ance that operator feedback in the community and to Sun regarding SMF flaws w=
as somehow missed in systemd's development as they did the same wrong things=
.
A change this big deserves architectural clarity and justification. We get s=
nide comments about change being good and core developers Linus evidently f=
eels are unsafe.
George William Herbert
Sent from my iPhone=
