and Germany. And the Netherlands. And a tonne of other countries where Socialism works just fine thank you very much. What _doesn't_ work is mixing American Style right-wing Reagan-Thatcher politics in. See the UK's collapsing economy for that, or wealth inequality in the U.S. that's gone back to pre-Black Tuesday leves.

Also, there's this little think called progress. I'm too lazy to google for the Robert Reich infographic that show that productivity is up 80% since 1979 but wages are only up 8% (and that proves wages stopped growing in America in 1979). Forget all that. We're rapidly automating away just about every job. Even _China_ is replacing workers with robots. When robots are cheaper than Chinese slave labor you know you have a problem.

So, when we don't need people to work 20 hours a week let alone the 50 they're doing now (you can google the /. article on that one too) what the _heck_ do we do with 'em all. The world _doesn't_ need ditch diggers....

If you start with PHP, even Brainfuck looks fun and refreshing. Jesus pal, talk about damning a language with faint praise.

Another attempt by a vendor to try to lock in software development and make cross platform development incredibly difficult by introducing a new language.

Fuck, I do tire of the sociopathic tendencies of corporations.

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.

Indeed. And quite often even dead FOSS projects can be cannibalized. The difference between dead open source and dead closed source projects is that the bones of one sit in an open pit that anyone can pick at, and the other sits in a concrete bunker twenty miles underground.

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.

Please try to keep up.

1. Standards change.

So is the wankery of your comment.

Basically everything is doable at 10Mbps. It's an acceptable minimum standard. We'd all like to see more, but at least they're setting the bar someplace livable.

Yes, my argument was that altering the init scripts would have solved most of what systemd solved. Thanks for confirming that.

The scripts are unified by maintainers. I've already made the proposal that you could actually interpret unit files as init scripts, with the right parser which basically stripped out the sections in brackets, dumped the rest of the content of the file into a series of variables by sourcing it, and then running a unified init script. This would work just fine for any daemons which are long-running, without any complex work. All you'd need is a hashbang at the top of the unit file.

Congratulations, you just hammered home the point that you don't understand Unix, while simultaneously proving that you don't understand sysvinit. Using fancy scripts with the original sysvinit is still using the original sysvinit. You are witnessing the awesome power of the Unix philosophy. Because sysvinit is small, simple, and completely modular, the scripts could be extended to provide functionality which sysvinit didn't try to claim for itself. Instead of moving more functionality into PID1, the functionality can be implemented at the script level.

You failed to understand the Unix way. It's not to have one piece of software. That's the systemd way. It's to have many pieces of interoperable software which can be combined to perform complex tasks, and reconfigured to perform other complex tasks. So we have cron and at (which are often merged) and we have udev and inetd. And each of these things does one simple thing. It's not unusual to want to start processes in multiple ways, that is in fact common to all modern operating systems. You can start them from the command line, you can schedule them, you can start them from the GUI. Is that a problem for you?

And you still do. Only now, they're all managed by one process which, if it craters, will not just cause them all to fail, but which will cause a panic. Great idea!

That's getting harder to do as people depend on it. I may finally have to go back to BSD.

Well then, I sit corrected on this one point. And finally, we have found something for systemd to do. I propose that we stop using it as init, strip out all the shit better done with a script, and use just that part. Perhaps it can be reworked into a replacement for daemontools. That would make a lot more sense than eating up all these daemons which work fine on their own.

Surface Pro 3.

the real capitalists are global. They benefit from us competing with cheaper labor. Marx predicted this but all anyone can remember about him is that a few dictators used his books for rhetoric.

As for Adam Smith, he actually as against this sort of naked capitalism. He wrote at a time of small merchant artisans. He didn't see the industrial revolution coming and if he had probably wouldn't have written the books he did. These days he's like Marx: all anybody remembers about him is what fits in with what they want.