Don't be so obstinate. To sue someone, as it is commonly used, is independent of the presumed outcome. The very filing of a suit places possibly undue burden on the defendant.

This assumes that there are no sidechannel attacks against this storage, and that it's protected against power fluctuations. IOW: A very professional professional with a $1E6+ budget would probably be able to do something more with it than just stare at it with dismay :)

That's only true given an assumption of there being no JTAG chain on an iPhone - I seriously doubt that. This gives you debug access to all the chips, and all you need to do is to pull the case apart and cradle the phone in a very modest bed of nails. This is sufficient to dump the flash, but not encryption keys. Unless there's a backdoor in the chip that carries the key - one can't be sure without reverse-engineering the relevant chip.

For all I know, Apple could have sneaked in JTAG access even through the lightning interface, so an encrypted dump of the flash could be done using a specialized JTAG-over-lightning bridge, without opening the phone.

I think that such adaptations go even on a much shorter timescale. I don't eat between breakfast and dinner, and it used to be that I had a sugar low around 1-2pm. Right now it's the opposite: if I eat anything during the work hours, I get sleepy because there's an insulin low that starts after noon or so. And I did actually sample the insulin levels at hourly intervals for a month to make sure I'm not imagining things. These days, going out for an occasional lunch with coworkers is a surefire way to waste the rest of the day, falling asleep at the keyboard.

The best day for me is to get a bit of lactose from coffee with milk in the morning, not have anything else to eat, drink water, and then have a nice dinner. If I'm planning to do any work at night, the dinner must be under 1200 kcal.

And that's why, in 2000 years or so, the evolutionary processes will likely fix it. Of course we'll be all in a big doodoo if, for whatever reason, we'd be faced with going back to a hunter-gatherer lifestyle - not only due to population crash, but also due to a then-maladaptation to circumstances that wouldn't exist anymore.

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.

So it closed last year, but you only just noticed and posted an article? It doesn't seem like it's going to be missed very much, if the corpse can decompose and start to smell before someone sends the police to check on aunt Mozlabs.

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.

Ada was quite painful before widescreen monitors became the norm...

"a lot of Genetically Modified foods show tumor acceleration in rats and infertility in three generations" Um, no, Just no. Stop it.

There's no easy way to avoid "making" of your own glucose -- it's simply the digestion of carbohydrates that you eat. If you're not living on a carbohydrate-free diet, there's glucose absorbed in your small intestine, continuously, and it has nothing to do with whether you eat sugary snacks or not. If you eat anything with flour in it, you're absorbing glucose in the gut :)

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.

Evolutionarily, there are quite good reasons for that. Fruits are seasonal.