That's not good, but their command structure will still have learned the LOAC, right?

The parts of the command structure, Inspectors General and attorneys in the Judge Advocate General's office, that are supposed to enforce that have been gutted.[1] Secretary Hegseth said that the removals were necessary because he didn't want them to pose any "roadblocks to orders that are given by a commander in chief."

[1] https://www.military.com/daily-news/2025/02/24/people-are-ve...

Anchorage is closer to Nuuk than to Minneapolis by air... Just saying.

just popping in to say that it is 15° F in Nuuk right now and 1° F in Minneapolis. Currently 26° F in Anchorage. Minneapolis is often colder than the Alaskan Metro areas with Fairbanks being an exception.

Almost as close, sorry.

As far as i can tell they have trouble with sustained satisfaction of multiple constraints, and asm has more of that than higher level languages. (An old Boss once said his record for bug density was in asm: he'd written 3 bugs in a single opcode)

I agree with this. Just the need to keep track of stack, flags and ad-hoc register allocations is something I’ve found they really struggle with. I think this may be why it does so much better at porting from one architecture to another - but even then I’ve seen it have problems with e.g. m68k assembly, where the rules for which moves affect flags are different from, say, x86.

Until you've used an oscilloscopes to debug your buggy kprintf, you haven't lived.

LOL in my 4th year Advanced Operating Systems Concepts course we wrote a toy x86 OS from scratch. We obviously didn't have to make our own hardware, but uhhhh I definitely added a bunch of printfs inside QEMU to dump out CPU states when we couldn't figure out the chain of events that led to hard faults.

On the other side... have also definitely used a pair of LEDs to try to debug an RTOS on a microcontroller with no JTAG access...

"couldn't figure out the chain of events that led to hard faults..."

Tales from the terminal/dark side/h4x0r pro in da house!

First thing to do is get a working UART.

First thing to do is get a GPIO pin or two to toggle. Plenty of debug patterns that one can blink out.

As they say, a coprocessor is a box that turns your cpu-bound problem into an i/o-bound problem.

Ca. 1200, hydraulics: https://news.ycombinator.com/item?id=42482805

Love hydraulics and they’re so much better with electro-mechanical controls now :)

I'd guess a continuous flow variation on https://en.wikipedia.org/wiki/Heron%27s_fountain

Running in the woods supports TFA: 180 steps per minute * 16 possible locations per step = 12 bits per second; maybe there are fewer or more possible footfall spots but no matter what it's more than 1 bit per second and less than 100. (and way less than 1e9)

Also, ivanbakel's answer was good ; the llm one was long and unfocused.

Algol 68 was certainly too much language for the tiny machines of 1970, but on a 2020 box it might be fairly decent.

There is a modern implementation if you feel like checking it out firsthand

https://jmvdveer.home.xs4all.nl/en.algol-68-genie.html

Not really, I did an implementation in the late 70s, ran on a mainframe of the time (1MHz 6Mb). The language itself is not much more than modern C in scope - and in fact many ideas that were new in 68 are expected in modern languages

The big problem was that the spec was essentially unreadable.

6MB was quite an amount back then.

Yup, we bought 1.5Mb of core for our B6700 for over a million dollars (I think we only had 3Mb on the machine I was working on)