Joker_vD

Another reason, which I think I wrote as an answer to the very Stack Overflow question mentioned in TFA, is because of data structure invariants and the function contracts.

    Public methods usually have a contract of "take the object in a consistent state, do
    something sensible, leave the object in a (possibly different) consistent state". Here,
    "consistent" may mean, for example, that the `Length` of a `List<T>` is no greater than
    its `Capacity` and that referencing the elements at indices from 0 to `Length-1` won't
    throw.

    But inside the object's methods, the object may be in an inconsistent state, so when
    you call one of your public methods, it may do a very wrong thing, because it wasn't
    written with such a possibility in mind. So if you plan to call your public methods from
    your other methods, make sure that their contract is "take the object in some state, do
    something sensible, leave the object in a (possibly different) (maybe inconsistent — but
    only if the initial state was inconsistent) state".

Well, the array indices are allowed to be any sorts of integers, and the standard is worded in such a way that such addition must work correctly without overflowing — provided, of course, that the array you're indexing into is large enough. So in practice, you're bounded by the width of size_t.

Oh, and did you know that the width of ptrdiff_t is not required to have any relation to the width of size_t? There is even an explicit provision in standard for the case when subtracting two pointers into the same very large array can't fit into ptrdiff_t:

    When two pointers are subtracted, both shall point to elements of the same array object, or one past
    the last element of the array object; the result is the difference of the subscripts of the two array
    elements. The size of the result is implementation-defined, and its type (a signed integer type) is
    ptrdiff_t defined in the <stddef.h> header. If the result is not representable in an object of that
    type, the behavior is undefined.

So yeah; you should try to work strictly with indices only, they're guaranteed to be correctly addible to pointers no matter the sizes of your arrays.

That's the price of innovation, I guess; before C invented its "for"-loop, other languages had their equivalents generally looking like this:

    FOR var = start [DOWN] TO end BY step DO ... END

No custom increment expressions, and "step" even usually was only allowed to be a constant (in which case, the language usually didn't have DOWN specifier and used the step's sign instead). Then Dennis Ritchie invented C, and ditched the traditional "do"-loop (Fortran started that construct with DO, so it was called DO loop; Algol used FOR instead, but most people preferred the Fortran's nomenclature... until C came to dominate, but that wouldn't happen for yet another 20 years) in favour of his invention because he felt that easily iterating through linked lists or strings was a much more pressing concern:

    for(p=head; p; p=p->next) { ... }

    for(s=str; *s; s++) { ... }

The downside, of course, is that now you can't straightforwardly write

   for size_t i = count - 1 downto 0 do
      ...
   end

"I see your particle physics paper (on sustainability of neutron-induced chain fission reaction in uranium), how does this affect the world politics???"

Turns out, it affected the global politics tremendously.

I just want "a" to make the same sound it makes in literally every other spelling system, including Cyrillic and Greek, not "ey" or "eh". Seriously, that's one of the most stable phonemes, how did it turn into "ey" in English?

> any process that calls `setsid` is responsible for ensuring that signals are being propagated.

Well, again, the process that calls setsid(2) ceases to receive the signals from its previous process group, so there is nothing for it to propagate. The only way this propagation can work is with cooperation from the parent process of the setsid-calling process: it will need to manually pass the group-wide signals to its setsid-calling child — which it can't reliably do for two obvious reasons.

> By limiting its usage to the period between fork and exec, so that the process calling setsid knows that the parent process is propagating signals to it.

Wait. Are you implying a scheme where the process A, that wants to do setsid(2), forks itself, and it's this child process B that does setsid(2) and all future actual work, while process A merely lives in a "while(1) { sig = sigwait(); signal(pidB, sig); }" loop forever? This almost works but doesn't survive SIGSTOP/SIGCONT/etc. and, of course, you can't propagate SIGKILL. And SIGKILL-propagation is arguably one of the main attraction of the process groups — you send SIGKILL to the process group (or a container, for that matter), and all of it dies with no further work on your part.

> I'd say that any process that calls `setsid` is responsible for ensuring signal propagation across the pgid.

How?! After a process calls setsid(2), it becomes a leader of a new process group so it stops receiving signals from its former process group!

> But that would have been nice to actually have nestable job management.

Yes, it would be. Just imagine: a simple, straightforward way to group a bunch of processes (and their potential children, inescapably), signal them all at once, wait for them all at once, etc. Instead, we at best ended up with docker compose and k8s. And they kinda do solve that problem, no question about that but it's just so incredibly heavyweight...

This advice comes from threads on Linux being second-class citizens. As TFA itself states, there are some syscalls that really should only be made in a single-threaded process which is frankly insane... but that's the legacy of starting with the processes-only model and patching it years later to have threads as well.

UNIX job management is fundamentally broken already in that it simply can't be properly nested, even with PID namespaces. If the "container’s process [is the] part of my shell’s foreground process group", then it can not, literally can not, job manage its children.

Well, yes, the humanism seems to be on a long decline, that's true, "dogs are inherently better than people" etc.

Okay, so let's not do the human trials. Just be content with the modelling (which is known to be imprecise especially where it matters most), and just approve the drug. What would that even solve? Instead of 6 volunteers getting injured, all the customers/patients who bought and took the drug would get harmed.

There is always human trial — the whole history/timeline of people taking a particular medicine is effectively a decades-long human trial. That's actually the only way we learn about long-term side effects, see paracetamol for instance. All you're proposing is we remove a smaller, controlled pre-trial before releasing the medicine into the wilder population. Sorry, but that won't solve anything except for your feeling of moral indignation.

> Debian isn't really trying to lead the charge on making it possible to install arbitrary apps. In fact they're mildly hostile to the idea.

I, for one, welcome our Debian overlords, taking care of stupid users such as myself to protect them from both "arbitrary" applications and from non-obsolete versions of non-arbitrary applications.

And yes-yes, this curated walled-off garden is fine, unlike all others walled-off gardens, because its maintained by "the community" (of Debian maintainers, that is).

A regular remainder that brutalism, despite what many people think, was originally invented in the UK.

It is the future, and has been the future for almost 40 years already! I bet that's what the hoverboards will use inside their microcontrollers — gotta drive those portable fusion reactors reliably!