So because you've chosen to live where your meager skills won't permit you to make a good living, you're complaining? how's about you go someplace where you can get paid? You're whining about how your state handled obamacare, but that's your state. If it didn't come out the way you wanted, you share the blame. Next time, involve yourself in the politics. Now, everything is over for you but the weeping.

Bull shit. ERs turn away emergency patients all the time, then they drive them from hospital to hospital until they die. Since I live in bumfuck, if that happens here, I'll almost certainly be dead.

My hardware worked okay with their 4.3 release (ASUS EEE 701 4G here) but went into bootloop with 4.4-rc1. The 4.3 release was shit, mind you, but it did boot. You just had to do shit like hit the power button to wake up the lock screen. 4.0.something was the last Android-x86 release I tried which didn't asplode constantly once I got it working.

I'll keep trying every new release, but so far the only usable thing they've kicked out was obsoleted almost immediately.

Sure. So now I get an additional log daemon which doesn't feed logs back upstream. Explain how this is simplifying my system.

They claim they're moving things, not removing them. If done well this will help KDE immensely because current prefs dialogs treat trivial and significant settings as equally important by barfing them all up together into a big dialog.

Odd, so does a syslog. And you can still use tools to read it. Indexed files could be built from it if you had that much logging done. And since systemd has no option to output the ascii log in realtime, you have to use the tools. If you want to use the body of existing tools which do things with normal log files, you'll now need a FUSE filesystem to treat the binary logs like real logs, or you'll simply be out of date as you read the ascii logs from journald.

android-x86 is a bit of a dog's breakfast. They only kick out a release image every now and again, everything never works, lots of crashes. The latest 4.4 image is way less stable than the last 4.0 image they put out, and they stopped building nightlies and so did everyone else. It's really quite useless and always has been, because they never actually finish a release. Google kicks out a new version, they say "Ooh, shiny!" and they move on before they actually get the system working reliably or properly. Then you get to deal with all the apps that won't work right on x86 on top of that. It makes far more sense at this point to go ahead and run the emulator.

Well, maybe. Or maybe it just demands a higher standard of living, one which cannot be supported without more oppression.

too true. I like the servers with chat filters, which bring a level of amusement to the situation when the chat scrolls with tales of bananasing female dogs and so on

You have fallen into my trap: So then why did it have to be part of systemd at all? Why couldn't it just be improvements to one of the existing syslog daemons? Answer, NIH.

It's an ASCII pipeline any time that it's feasibly and meaningfully human-comprehensible; that is part of the Unix way. Any other time the format varies broadly, and has been all sorts of things including BDB — which has all the same problems as binary log formats ala systemd. Since the user-perceivable output of javascript in a browser is XML, you reasonably could use STDIO in a very normally Unix-y way.

None of which requires that logging be moved into PID 1. Instead, all you need is the ability to support a new log format in some syslogd. Unless you were some kind of moron, you'd design the new program to be able to log to both text and binary formats at the same time so that you could enjoy the benefits of both formats. Systemd may or may not do this, I don't care; there's no reason whatsoever why logging should not be a separate daemon.

cgroups is a kernel feature. It doesn't stop working because whatever process you're using for cgroup management dies. The process comes back, reads the state from /sys/fs/cgroup, and resumes doing whatever kind of management you wanted. If PID2 only manages cgroups, and cgroups' state is maintained in the kernel (which is is) then it doesn't particularly matter if the daemon craters, so long as you can restart it. But absent many requests for cgroup management, it may not actually even need to be long-running.

The only reason that we even need a daemon for cgroup management is that we're making inadequate use of capabilities. When a user (or script) runs a tool which creates cgroups via a mount, they should not need to use any tool for privilege elevation because they should have the right to manipulate one or more cgroups in one or more approved ways — which can consist of a couple of lines in a file which is sourced by init scripts. In systems with init scripts of any complexity, all of which source external files, no changes need appear in them whatsoever.

Even with a[n old, slow] HDD it only takes about a minute to boot my Ubuntu PC, and that's with a stupid-long POST to deal with the second ATA controller's stupid-long POST added to the base machine's stupid-long POST.

With that said, I am not against improvements to boot speed. I simply question the need for a replacement for PID 1.

I live on a paved road and I'm several miles (at least three) away from fiber. Literally the only company with fiber into my county is AT&T, and as you likely know, they are bastards of the first degree.