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.

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.

Sure, the regenerative braking probably reduces the wear on the brakes.

Point being, brake pads and rotors are normal replacement items. You should expect to replace them more than once in 12 years on a normal vehicle. I can wear down a set of pads in a weekend at the track. It depends a lot on how you drive.

I will agree that on the Tesla I test drove, I barely touched the brake pedal. The regen was turned up to maximum and that does a good job of slowing the car down if you are paying attention.

BMWs also tend to have static negative rear camber, and are RWD like the Tesla. But the wheels are smaller dia, which means the tires are more affordable.

I think over 12 years you will spend similar or more on Tesla model S brake and tire components as compared to an average BMW. I look forward to hearing from Model S owners 11 years from now...

Heck. At 12-years on a BMW, there are any number of wearbale parts that replacement may exceed car value (tires, brakes (you have to replace the rotors with the pads on a BMW), etc).

Not unless the car has been damaged.

BMWs have very high resale value. 12 year old BMWs are currently 2002 models. Very few model year 2002 BMWs can be found for under $5000 in _any_ condition.

In fact, if you do a quick search on autotrader.com for model year 2002 BMWs, you'll see that there are 1200 listings with an average asking price of $9700

I happen to be quite familiar with the running costs of old BMWs. The drive train of a BMW will easily last 12 years without substantial work. The exceptions would be the plastic cooling system components, and, on some models, premature VANOS failure. Sadly, on the newer N54 engines the HPFP is a disaster, but that is not the majority of used BMWs, and certainly not MY2002 cars.

Even paying dealer prices, to replace brakes, suspension rubber, tires, cooling system, etc, will not cost you $9000.

The brake rotors and pads are a few hundred dollars per corner, and you could replace them yourself in your own garage with a jack and hand tools.

FWIW, I really like Tesla. I look forward to a time when buying one of their cars makes sense for me.

However, your consideration of the repair costs of a 12 year old BMW is way off. Thus, my response.

Also, Brakes and Tires are functionally identical between a BMW and a Tesla, and, on the Model S, the Tesla replacement parts are probably more expensive (I haven't priced them to be certain), because the Tesla has very large low profile tires and very large brakes, especially compared to the "average" BMW (instead of their X5 trucks with big wheels, or their high performance M models with larger brakes)

So comparing a 12 year old BMW and a 12 year old Tesla, the wear and maintenance parts differences are the Tesla's battery vs. the BMW's conventional drivetrain. The latter requires coolant flushes, oil changes, transmission fluid changes, air filters, etc.

The one maintenance surprise that I learned about when chatting with a Tesla service technician was that on the model S, the A/C refrigerant is serviced regularly, because it is an integral component of the battery cooling system.

Never go full retard. X is not even remotely as important as init. For one thing, if X dies, who will restart it? And do we really want computers that explode when the GUI dies? I, for one, would like network services to terminate gracefully. The whole idea of TCP/IP networks, the dominant network used with Unix, is peer-to-peer. I may well run both services and clients on my machine. If X dies, the clients may die (if they're not text and running in screen) but the servers won't.

So the argument is that since the kernel is complex, we should add more complexity, or that more complexity won't matter? That's an ignorant, illogical argument.

Systemd still has to be more complicated so that it knows how to run these other processes, which wasn't even necessary. init was never meant to manage daemons. daemons were meant to manage themselves, or be run from inetd. If you want more complexity, inetd is the place to add it. And for handling daemons which don't adequately manage themselves, there's daemontools. There was simply no need whatsoever for this to happen.

It is bad, because PID1 is now responsible for a bunch of things which could have existed in any other daemon. And rather than roll the things which actually make sense in together, everything is getting rolled together. So now not only do we depend on a complex kernel, but we depend on a needlessly complex init system. There was no good reason to put all of this stuff into the same daemon.

Yes, yes I can. And I did.

Does nothing a script can't do

Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.

No. That is the virtue. They are simple. Simplicity is still a virtue.

Making PID1 more complex makes everything more fragile and opens up security holes.

NIH

This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.

Lifting which should not be done by PID 1. And PID 1 has to be more complex than it should be just to handle those external programs.

It does a lot of stuff the init system shouldn't do.

cgroups existed before systemd.

Up to the init script.

Already handled by several init systems.

We call it inetd.

That is ignorance at best, or perhaps a lie.

You have no idea about anything, that didn't stop you. I see why you didn't log in.

So to be clear, it's more awful to have 1 out of every 9 people have to pass two people if they want to use the bathroom than to have 2 out of every 6? Because that's typical economy seating plans are 3-3.