18 Jun
2016
18 Jun
'16
1:43 p.m.
fre 2016-06-17 klockan 16:09 +0200 skrev Liam Proven:
GNOME's adoption of systemd helps a bit.
On 16 June 2016 at 22:09, Sean Conner <spc at
conman.org> wrote:
> It was thus said that the Great Liam Proven once stated:
>> It's a modern init. Most of panic is just headless running around. No,
>> it's not an old-fashioned simplistic Unix utility. Hey, newsflash,
>> neither is GNOME, neither is KDE. Neither is much of modern Unix.
>
> I'm not a fan of systemd, but it's not because SysV init is better, but
> because of the increasing scope of systemd.
>
What i don't like about systemd is:
the fud about how easy it is to write systemd unit files vs old shell
script init.d/ditos .
RH started in earnest to fix NFS for el7 but things still occasionally
go tits up (i have done a fair amount of work with centos7.)
NFS started to work well in Fedora 20/21.
Writing correct unit files for something as complicated as NFS and
especially if running in an split NFS3/NFS4 environment with
Kerberos-authenticated id mapping between server and client is NOT
simple.
Systemd doesn't ease the complexity of describing dependencies, and i
also have a suspicion that the systemd design wasn't enough well defined
for something else to happen (good and consistent design results in
better documentation) - so the users got to have to do a bit of
frustrating trial-and-error while writing their own unit files.
> Oh, and because of the say systemd works, it takes over cgroup management.
> The Linux kernel provides mechanism, not policy, but now, we have systemd
> forcing a cgroup policy on everything. Okay, perhaps systemd is the first
> program to actually *use* cgroups but if at some point in the future you
> want to play around with it, well ... sorry. systemd is in control there.
>
Which also affects something which i'm working with now namely cfengine,
cgroup's requires cfengine's performer cf-agent if it wan't to rerun
cf-serverd (the policy file server in cfengine, but cf-serverd has other
usage too) to start cf-serverd via systemctl enable/start.
THAT is my
problem with systemd. It's mandating a $#!?load of policy and
dependencies with largly undocumented APIs.
It is an odd move, I entirely agree. I am somewhat mystified that it
is thriving so much when it's relatively immature code, wildly
controversial and widely hated. Most mainstream distros have adopted
it. I don't get it. I also hear that it's not well-documented, that
they're adding a lot
of functionality of questionable relevance to its core function, that
there's little democratic decision making, etc. etc.
I am aware of the problems, or at least of some of them.
systemd-timesyncd is an example especially the assertion from the
systemd developers that SNTP is good enough for almost everyone except
(S)NTP servers.
It isn't good enough if the host is an virtual machine on esv4, that
really requires something which can handle clock drift in a sane way ie
ntpd.
Yes i'm aware of the CVEs regarding authentication keys in ntpd.
One functionality of questionable (or not so much) functionality is the
hails and whistles socket activation.
IN the cause of NFS it would require a new network protocol.
The CFengine developers has discussed using socket activation for
cf-serverd but it is really infeasible.
It would basically force them to maintain two completely different
cf-serverd implementations one for UNIX,systemd-less Linux and Windows
and one for systemd-ified Linux.
Systemd-style socket activation in new applications/servers is an
possibility if a hard dependency on systemd is ok.