> It did have a Load Byte and a Store Byte instruction, which allowed you to select the byte size.

Were these instructions atomic regarding interrupts? If not, then these look like shorthands for masking/shifting bit-fields out of words, leaving the word as the smallest atomically addressable unit.

They are atomic, indeed. The underlying implementation might have used masking and shifting, especially in bit-slice implementations like KS-10, but as far as operation of the computer was concerned they were atomic.

It becomes problematic for multiprocessor systems but you could probably build a communications fabric and memory model that works.

My fantasy CPU lets you write to the (say) 15 bits starting at the 43rd but of a 48 bit word which a real CPU would have to do a lot of work to implement but with the right kind of cache it is probably not so bad, it also has an instruction to read a UTF-8 character at a deep pointer and increment the pointer which a real system could satisfy out of the cache except when it can’t.

For PDP-10, because it operated only on word values, you can easily assume that every bus and memory operation passes a full 36 bit word every time.

In fact, recent-ish x86 CPUs have similar instructions, and as of Zen4 they are fast not just on Intel but also on AMD (previously they were microcoded as a bunch of shifts AFAIK with pretty lousy latency)

That's only the case if the author would want to upstream their changes. If they wanted to only fork ls then they would only be required to comply with the license, without assigning copyright over.

That may be the case but then why bother modifying ls when you can just write your own exactly as you want it?

The question is whether recursive submodule checkout happens after some integrity/signature validation or before. The RCE can be an issue in the latter case.

There would also have to be a compromise of the transport (i.e. a MITM of HTTPS or SSH) to use this in most practical scenarios.

It still weakens the security, otherwise why bother with integrity/signature checks if you trust the git remote?

There is still theoretically an edge if you just show the same frames statistically earlier to one player.

You can present the game state statistically earlier to the player with the higher refresh rate display.

Virtually all bugs have some cost. Security bugs tend to be more expensive than others, but it doesn't mean that all very expensive bugs are security bugs.

PNG already supports color profiles, but probably not HDR. I would say that the gamut argument in the article is misleading, you can already encode a wider gamut.

Not sure how HDR encoding works, but my impression is that you can set a nominal white point other than (1, 1, 1) in your specified colorspace. This is an extension, but orthogonal to specifying the colorspace itself and the gamut.

You are correct. I designed the article to be very approachable and understandable for the normal person. As such, I took some liberties like only showing HDR primaries and ignoring transfer function. I linked to Chris Lilley's post to give experts a more correct answer.

But wide color gamut was already possibly in PNG via ICC profiles (HDR was not). And those primaries I showed could have been used in a wide color image.

So the image is a bit misleading or red-flag-y to experts who know. But to the average person, I think it is as truthful as I can be without getting too deep in the weeds.

Rebase itself is also often used to work around UI issues of git log to present a "clean history".

Look up the passkey idiom.

Nice, but cumbersome with > 1 friend.

Don't do that in C++. Maybe unless if you are debugging. This can blow up in your face in unexpected ways.

You have critical section in the bonus section behind the pipe. Maybe shared state protected by that critical section could be your shared memory, like the state of the coins there.