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

On Sat, 18 Jun 2016, Stefan Skoglund (lokal anv?ndare) wrote: 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. 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). 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. I've heard that before from RHEL customers who were a bit shocked (and didn't know anything about the systemd controversy). 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. 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. 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. 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. 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. 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. 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). 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