It's not a matter of the init scripts. It's not that my apps are not compatible with systemd. Systemd is not compatible with my system.

Systemd depends on features which I can't give it in my environment. My environment is an unprivileged container. In this environment you CANNOT have use of prctl for security isolation (kinda sucks, yeah), you CANNOT have /dev as a tmpfs, and you CANNOT have access to the control groups at the kind of granularity. Systemd will not work without these features - I've tried. Were this a sysvinit system I'd just edit the init script to remove the bits I don't need. With systemd I need to recompile a binary and deal with the troubleshooting that results.

Now, these are based on my usage of CentOS 7 which is already 2 years old on top of the release delays. I'm sure newer versions make the situation better. But at this very moment systemd has made a VERY bad first impression (there's more, but I'm not going to go into that) and left me with no practical solution. All the other things like "binary logging" just make me even more irritated.

I keep saying it, systemd not an init system. KDE and GNOME should not depend on an init system. Why does the desktop care who's booted it up?

More specifically, systemd is Linux-only. The devs have explicitly stated that they are making good use of Linux-specific features. Fine, but if third party software becomes dependent on it then that implies they won't work on *BSD at all. Right? So now there's no Gnome or KDE on anything but Linux.

So really, choice is being taken away clear across the board. Either that or I'm missing something really big which implies systemd is not a strict dependency.

Busybox is also a pretty weak substitute for most of these applications. Reduced command-line options, fewer features, terse output, etc.

But on a system where memory is limited - even moreso than a Raspberry Pi, for example - this is an advantage. You could put busybox into an emergency recovery boot ramdisk and be able to work reasonable well. That's the objective - it's small and used in specific situations only. If you don't need it, good for you.

As someone already said most servers don't actually use busybox day to day. It's available in the event something goes wrong and you need it.

I contribute code and bug report and participate in the community (read: answer questions of novice users).

So I'll choose the community option because it makes me look best while being most vague.

Using the binary driver has been fine for me.

Not much more to say on the matter. ffmpeg + x264 make use of it nicely.

My own impressions of 5.0 haven't been too good. The lockscreen doesn't give you the unlock input (eg: PIN) without pushing a button to ask for it, the animations have been stepped up -- the kinds of animations you can't turn off from the Dev menu -- and it generally looks copmletely childish. That's not what I personally want.

If you're running 4.4 check out all the new Google apps from the store. That's what you're getting from Lollipop, but also with the launcher, etc. No. No no no. I uninstalled the gmail update as fast as I could.

This is the trend in tech - things become more colourful, flat and generally dumbed down. I don't mean dumbed down from a user knowledge point of view, I mean "UI designed in MS Paint" down.

In the embedded scenario the owner retains control. Frankly said owner should simply disallow embedding and let the embedder look like an idiot until they realize what they did.

https://bugs.freedesktop.org/s...

Indeed, I misremembered that. They don't say delete, they say the file gets rotated out immediately. And this bug report is famously linked as a demonstration of why systemd is hated for its developer attitude to the point that Lennart repsonded to it (today oddly enough). Corrupted files are not considered a bug and not getting fixed.

[Disclaimer: Yes I hate systemd and I proclaim that loudly. Everything below is my personal experience with systemd and why I hate it.]

If booting the machine up was all it did, then I probably wouldn't care. Most of my hate (I can't speak for the rest of the internet) comes from the fact that systemd does a lot more. It also tracks user logins using a mechanism (control groups) that isn't available in some container scenarios making systemd unusable in those environments (and by extension any distro mandating systemd). It does its own logging in binary which needs a tool to read the logs and if it gets corrupted then systemd's devs say "just delete the logs". Really?

But I think the best reason people hate it is because it makes other applications become dependent on it. GNOME is the most well known example but I've also seen that Centos7's Source RPMs have systemd-specific commands (macros?) making it hard to build them on other platforms. rsyslog doesn't listen on /dev/log because systemd is doing something with the socket now. You cannot start services without systemd being the one to do it.

This is the hate. systemd isn't just an init system, it becomes part of your daily life. I liken it to the MCP (Master Contrl Progam) from the first TRON movie. It's systemd's way or the highway.

Ordinarily I would agree, but systemd's "MCP-like" behaviour (TRON reference, I honestly believe that's a valid simile) means that uselessd has a chance of being a replacement for systemd packages of existing distributions. If I can put this in place of systemd on centos7 and have it boot in an unprivileged container (currnetly impossible with stock) then that's a win in my book.

You can't just switch systemd for openrc in an existing distribution without some major resistance. Believe me, I wish it could or I would just install openrc or upstart. That's the problem - systemd is claiming distributions and the list of alternatives is unnervingly small.

Here's a true story. I was in a CentOS 7 system via chroot and trying to troubleshoot some problems. If it were CentOS 6 I would just run "service rsyslog start" and have syslog running in the chroot so I can get the diagnostics I was expecting, but since systemd wasn't actually running I couldn't do that. I had to launch rsyslog directly by command-line, but then it didn't listen on /dev/log like it's supposed to and I had no logging. After all, it's systemd integrated now and gets its listen socket a different way. And this is just the most recent incident.

Systemd may be technically better than sysvinit but the latter is just shell scripts which are sufficiently independent of anything else and just work. Systemd takes over your machine and wants to get its hands into everything to the point that you can't even use it anymore without systemd. This is what we're worried about what will happen to X.Org and other software.

I guess I didn't explain that very well.

Libvirt provides its own container launcher under the name "lxc". As I understand it this software is developped and maintained with libvirt. This is different software from the standalone project known as "LXC" as linked in the article.

There's two projects named "lxc" - the one linked in the article ( https://linuxcontainers.org/ ) and one that's part of libvirt as a hypervisor driver. RHEL 7 includes the latter.

Now, time to download it and see how much has changed since the RC.

> [root@wang]# iptables -F

Suddenly your INPUT chain policy of DROP kills all traffic and your ssh session drops. (You do have a default policy of DROP, right?)

Seriously, don't do that on an unknown system.

(I post this because I've had vendors' support try to remedy problems by disabling the firewall. :/)