Quadra 660AV what's with the "PowerPC" label?

[Swift Griggs]

On Sat, 18 Jun 2016, Stefan Skoglund (lokal anv?ndare) wrote:
> 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 .

In most simple cases, their argument is that it's easier to write a unit 
file because you don't need to know shell script. However, as you point 
out, that all starts to fall apart when the unit files, which ARE 
basically the same format as Windows INI files (square bracket section 
header with key-value pairs following). That's because INI files aren't a 
Turing complete language and what you start seeing is edge cases where, 
even using unit files, you still need management scripts. So, that leaves 
you shaking your head asking why did Linux do all this crap in the first 
place, if most of their "benefits" start to disintegrate as soon as your 
init-need gets the least bit complicated.

> 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.

That's a great example, but only one that someone who digs in and 
discovers things at a low level will notice. Most of the loud voices on 
the pro-systemd side are people who don't interact with Linux at that 
level. They are just overjoyed that it boots 2 seconds quicker. Nevermind 
that ALL of the other alternative init systems boot faster than init. It's 
easy to do once you bootgraph everything (and init could easily be 
extended to do the same, and has been in some experimental cases).

> Systemd doesn't ease the complexity of describing dependencies,

As you know, you have to trace each unit-file's "wants" back to another 
unit file and keep going until you hit one without any dependencies. It's 
about the same turd hunt as looking at LSM tags (nothing lost, nothing 
gained). That's just my opinion based on working with both. As you say, it 
doesn't ease the process, nonetheless.

> 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.

I've heard that before from RHEL customers who were a bit shocked (and 
didn't know anything about the systemd controversy).

> > > 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.

Also, just for fun, my comment on cgroups is that they were just fine and 
working great well before systemd. Systemd forces everything to be 
potentially managed by cgroups (ie.. systemd is process ID 1). So, some 
would say this is better & easier. Me? I preferred the method of dorking 
with the cgconfig, cgcreate, cgset, and raw control interfaces where 
needed in /sys. That works great for /proc and the utilities that use it. 
I don't need systemd to mitigate this process for me (and I don't like 
it). Zero of the benefits of cgroups are tied directly to systemd (but 
boy, don't ask the systemd guys to admit that), nor do they need to be, 
nor is it impossible to put init under cgroups control (in fact it's quite 
easy). Putting an abstraction layer around something means that someone 
who's an "expert" now has to learn the abstraction layer AND the actual 
tool. Having now done both, I at least feel comfortable stating my 
position.

> 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.

Yep, so you end up having to bifurcate your unit files, write scripts, or 
some other "ugly" method (ugly in the eyes of systemd folks) that systemd 
didn't really factor into reality before rolling out.

> GNOME's adoption of systemd helps a bit.

They've adopted each other. I, for one, always hated GNOME anyway, (as 
Liam suspected). Birds of a feather sure flocked together in this case. 
However, that's a good thing. I like when things I dislike clump together. 
It makes them easier to avoid.

> 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.

Well, some of the freakout is over the fact that parts of NTP are some 
magical stuff and the maintainer is attempting to bow out. However, it 
doesn't detract from your very valid point.

> 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.

Well, it wouldn't surprise me if Lennart just plunged ahead and wrote a 
new protocol (as long as it only works on Linux and has plenty of suck). 
The guy isn't short on energy. I'll give him that.
 
> The CFengine developers has discussed using socket activation for 
> cf-serverd but it is really infeasible.

As you know, the method for socket activation is completely different from 
inetd/xinetd and as you point out, requires devs to maintain *both* now, 
if they want to be relevant outside of Linux.

> 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.

Great example. So, we end up with a significant portion of the open source 
software world being forced into a choice they never signed on for. Do 
they focus on Linux and thus use extra cycles to create unit files and 
other systemd cruft or do they stick with init scripts and get "left 
behind" by folks who claim there is no problem whatsoever with using init 
scripts with systemd (yeah, they work, but it drives the systemd guys 
crazy).
 
> Systemd-style socket activation in new applications/servers is an 
> possibility if a hard dependency on systemd is ok.

Yep. It just creates more work for folks wanting to write really open 
software. Now they have to include extra crap for Linux users or face the 
wrath of the Potteringites and possible exclusion from all the distros who 
drank the whole bottle of systemd koolaid. Of course, they can always 
maintain both bits, and waste time they could be putting into their core 
software, but hey, it's "progress" right? Yah, I'm sure they won't mind. 
:-<

-Swift