The original question I replied to stated they were thinking about IoT devices and embedded systems like routers. There tends to not be many officially supported distros for those kinds of markets, rendering everyone's discussion on distro support policies moot.

There is. 2.6.32 had around 6 years of support. Looks like 3.16 will be supported until 2020. Longer would be nice, sure, but 5-6 years for long term seems reasonable for a not-paying-for-it product.

If the password in question is required to login to the system in the first place, you have a chicken-and-egg problem. External devices like cellphones and post-its are the workaround, sure, but look which one people choose.

I'm running ZFS on Linux, so that's got me RAID and snapshots.

For "cloud" backup I have a remote system I also have access to running ZFS and use the "send/recv" feature to replicate incremental snapshots.

And finally, that remote system does the same thing in reverse, backing up to my home PC.

I've been using unix (ie. only Linux but we'll pretend that counts) for over 15 years now. Not quite the "old" you may think of but old enough.

I gave systemd a try. It actively fought me and I cannot accept that. It has too much of a "my way or the highway" mentality that you just can't fix without major C hacking and recompiling. If you don't like its way of doing things then too bad.

sysvinit scripts may be slower to boot and have fewer automatic/behinds-the-scenes features you want, but I can make any arbitrary change to them with minimal effort. I can run them with line-by-line tracing using "set -x" and find out exactly why it's hanging. I can rescue it with *any* install media even if it doesn't have systemd and '/etc/init.d/servicename start' will actually work.

systemd is fine for desktops run by people who think Firefox is the only app they really need to Surf The Net. sysvinit is designed for people who want control of their systems and want to be able to inspect what it's doing. And I'm sorry, I NEED the latter to do my job properly.

Remember back when IE 6 refused to die because corporations had ActiveX stuff that prevented upgrading? NPAPI has become like that as well. I can't upgrade because I have apps that run as Java applets and I'll lose them. I already can't use Chrome...

So, here's to vendors migrating away from Java and issuing updates I guess...

(And I find it ironic that Flash gets some kind of exception even though even Adobe wants it dead.)

It does require root if you want it to run a private port 80/443 service to do the authentication for you and/or to install the certificate into your apache config on your behalf. A nice feature for less capable users (ain't that a scary though)

But if you are using an existing web server and are okay with manual certificate installation/configuration and have a long command-line full of path overrides (eg. no using /etc for storing the generated certs) then it runs just fins as a normal user. I did it during the closed beta.

There's a few other little kinks to worry about like reloading apache on an updated certificate but I think you're capable of dealing with that.

I hate to reply to myself, but I realized a technical error or two. You can use /dev as tmpfs with extra effort, but if you read systemd's standpoint on containers they talk about dropping mknod support being discourage/unsupported. Unprivileged containers aren't allowed to use mknod so that's already out the window.

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.