The chat messages are full of nasty, hateful language. It seems to me that the user experience varies greatly from one server to another.
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
Logging isn't done by or in PID1.
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 a toy.
Which is fine though. Plenty of people spend plenty of money on "toys" to make this a viable product. $1000 for a 3D printer which is really just a toy isn't all that bad. The XBox One was $500 when it came out. By the time you get a second controller and a few games, you're probably getting close to $800. And the XBox One, or PS4, or any other console is really just a toy. You can't even run your own code on them. You can pretty much just play games. The new iPhone just came out and it's $650 for the cheapest one. And while there are some business uses of an iPhone, the vast majority of people I know with an iPhone use them solely for personal use and could do just as well with a $200 phone (or less).
Personally, I can't see the point in owning a 3D printer. The number of objects that I'd want to print out is quite small. It would make much more sense for me to go down to Home Depot and pay them to print out my parts on a $10,000 printer (assuming such a service existed), because I'd probably get better results and it would cost me less and take me less time. It's the same reason I don't own a photo printer. I can get a much better job done much faster by just taking my memory card into Walmart. If I feel like getting some really high quality prints, I can take them to a better photo place and get them printed better. But there's no way that I would have the money to afford that level of quality for my own personal use.
They think it's about limiting yourself to pipelines, but it's not. It's about writing simple robust programs that interact through a common, relatively high level interface, such as a pipeline. But that interface doesn't have to be a pipeline. It could be HTTP Requests and Responses.
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.
Sometimes new stuff is actually much better than then old stuff. I was skeptical about binary logs until I actually tried it. The advantages of a indexed journal is overwhelmingly positive. "journalctl" is an extremely powerful logfilter exactly because of the indexed and structured logs.
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.
If PID2 is responsible for critical features like eg. cgroups which affects all running processes, including PID1, then it won't make a difference.
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
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.
Arithmetic is being able to count up to twenty without taking off your shoes. -- Mickey Mouse