Okay, let's hope the following doesn't whooosh over your head:

Yes, examples are worthless. A few comments up, I saw someone use systemd as an example for sticking with the UNIX philosophy. You really can't deny examples aren't worthless in the light of that, now, can you?

Apart from that, I'm still curious about your statement that

Because you seem to be massively underestimating the amount of "little devices with a CPU" in existance which couldn't even run a fragment of busybox, apart from not having a need for it in the first place.

Thanks for the explanation, I didn't know this is actually a thing. It sounds slightly^W insane, though, mostly because (as you note yourself) how much longer disk I/O tends to take compared with context switches, or the timeslots remaining at typical scheduling frequencies..

That theory (which is not a theory, btw, please try and find out what a theory is) only stems from the fact that what you said, when taken literally, is complete and utter nonsense.

Please try and find out what "monolithic" means.

Pot, meet kettle.

Oh, indeed. I wonder why I assumed I was replying to AC... Probably it was the combination of demonstrating poor knowledge of the matter at hand in a loud and smug way, missing the point and the general crappiness of your comment. In fact, you'd probably be better of posting anonymously.

PS: Please learn how to use grep(1)

I'm not sure I'm following. If we're non-POSIX, then what read(2) are we talking about? Also, that sizeof is by definition 1
 

Sure, although that assert is a no-op. It will never be wrong. If a no-op changes behavior of your program, then yes, it's either a compiler bug, or it's you having invoked undefined behaviour at some point and now the compiler doesn't need to hold on to its end of the deal anymore.
I've seen too many "obvious compiler bugs" turn out to be no compiler bugs at all, so I tend to be careful with my conclusion.
If that was indeed mid-late 90's MSVC++, then that makes it slightly easier to believe, yes ;)

Could you elaborate on what exactly is wrong with the C garbage collector?

It occasionally unticks itself.

FTFY

Yeah, I couldn't agree more. It's not identity theft, it's identity copyright infringement

Are you sure you understand why Duff's Device works? You can't do that with a "range" case, even if they would exist

You generally don't directly deal with the hardware in userspace; what language is used is entirely irrelevant.

How the hell can a language have "direct hardware access?". What's that even supposed to mean?

A thousand times this.

Eh, swallowed some quote tags there, sorry.

I don't know; I only used Linux here because the Android build system doesn't seem very portable. Not too familar with the implementation details of Linux' OOM killer.
Here's the log

The linker (gold) is responsible for the OOM-situation by having by far the largest amount of allocated memory, but it's the java compiler that actually triggers the OOM killer, causing gold to be killed. This somehow makes sense, but at the same time, meh. In my particular case, I'd have preferred the linking to succeed, at the cost of javac. But well, it's heuristic.

I have mixed feelings about the killing of processes; while I don't necessarily agree with the method, I can't argue with the results. Still, it'd be nice to try a SIGHUP and SIGTERM first.

Yeah. Actually in the logs i linked above, there's no indication of what signal was delivered; I think on the command line it gave something along the lines of ``terminated by signal 9''. I might have been mixing it up, with something else, too.
Then again thinking about it, the "more polite" signals are probably futile in a OOM situation.

I'd be happier if this statement wasn't followed by yet another blob of gibberish demonstrating that you're still in your old MO.

Unrelated?

Huh, facts?
It's so fundamentally flawed that the only way I see to "improve" systemd involves the rm(1) program. You see, the same thing you think about system V init.