Maybe so, but it's clear from what happened at Penn State that they just don't want the label. There's way too much tendency to turn a blind eye.

And it's also never been perfectly true, otherwise nobody anywhere ever would have had their system broken by package upgrades.

The main issue is no one wants to fight the court battle.

But frankly, this has all been kind of irrelevant anyway - you can distribute source packages, let the client do a compile on install, and ignore the entire affair.

He said explanation, not a transcript of the signals you receive from the CIA in your fillings.

What unnecessary code? I'm genuinely curious what you think is completely dispensable as a system service at the init system level.

I mean we need something to launch processes, something to resolve dependencies of processes (init.d has insserv and the LSB headers), networking, disk mounting, time synchronization, authenticating and user session management (else how do your sysadmins log on from central administered sources?). We need process monitoring, logging, we'd like to have cgroups for security. We need some sort of time-based job scheduler.

Which one of these things are you going to drop? Which things are completely inseparable from systemd?

The biggest problem with the Kindle is it's very easy to forget you need to charge it "sometimes".

If there was ever a device that would benefit for long range wireless charging, even at just a trickle, it'd be the Kindle.

It also tends to be that people who forego cellphones still choose to utilize everyone else's. At some point that's a violation of the social contract - you're making yourself uncontactable, but taking advantage of that utility surrounding everyone else. Moreover, you're also starting to demand people adhere to your schedule on your terms: see complaining that people won't kowtow to your contact hours.

Money doesn't talk as much as people think, and the return rate on dollars to candidates elected for SuperPACs remains poor. It only works when the messaging goes unchallenged.

Really? Because my immediate reaction was to laugh out loud at the naivete. Companies care about bottom lines. They don't care about security, as amply demonstrated by banks which can have vulnerabilities pointed out to them, and then try to criminally prosecute the guy who tells them, and don't fix the problem.

This has happened over and over right here on Slashdot.

So, unlike FreeBSD then, which is all managed under one giant repository for development purposes despite representing many individual applications?

You know...exactly like systemd (~70ish utilities managed under 1 repository).

How the hell do you think changing PID 1 is supposed to be phased?

It is literally the first process which runs on Linux. Please explain "phased change" when something that fundamental is being altered. You might as well say "I'm outraged we had to get kernel 3.x all at once! It should've been a phased upgrade...."

Actually you only need a correct answer for 1 program: the one running on the firmware of the robot. At which point the question is simply "over the input space, can the program provide outputs which end human lives?"

Of course depending how you define that, you can take this right into crazy town - plenty of cellphones have ended human lives over the possible input space.

This is class political strategy BS: "look at how much drama we're causing! Something is clearly wrong!"

It's why most successful projects have benevolent dictators: because it shuts down most of the political strategems people translate to democracies of any sort.

I don't know, maybe my point was spelled out in the immediately following sentences which you didn't read?

Because you just went on to prove the entire point I was making by talking all about extra network protocols and daemons all created to make networked syslog reliable while you're in the middle of complaining about using a separate daemon to make journald network exportable.

At this point, I have no idea what you think the problem is other then "oh my god journald is new and scary". Because you've been explaining in excruciating detail exactly why you wouldn't use the raw logging protocol of a local system to actually communicate over a network because networks aren't reliable.

In which case, we return to the original issue: what exactly is the problem with using a special purpose daemon for exporting logs over the network? You know, the aforementioned separation of concerns which in any other thread on systemd is apparently the only thing people can talk about?

23.23.142.124

Did a digit go missing? Get flipped? Maybe it meant to say 231.23.142.124

It's redundant in the sense that it's useless. Not redundant in the sense that it's robust.