As with all open problems in computer science, we solved these back in the 80s.

I’ve used it a fair amount for memory mapped IO where the hardware defined bitfields. It is also useful when you have a data format with bitfields. I’d say it is also useful when your data does not respect byte boundaries, but the only time I’ve run into that involved the bit order being “backwards”, which means that I still had to bittwidle things back together.

From a performance perspective, a cache line is only 64 bytes. Space in registers, low level memory caches, and memory throughout are all limited as well.

You lost me at return oriented programming. Getting something working out of that is way more difficult than doing it out of vib coding. (Way more impressive though)

I’ve had a couple of issues like this:

• Wireless mouse has a flaky connection. Turns out the issue was the USB port it was plugged into (probably RF interference as other devices worked fine on that port)

• We had a couple of radio receivers in a server rack. The scale of the project had shrunk over the years, so what used to fill up 2 racks now only half filled them (mostly because of upgraded components becoming faster and smaller over the years). Another project needed needed some rackspace, so we reracked everything into a single rack. When we were done, we found that one of our receivers couldn’t get a signal, and another would lose it regularly. Checked over all of our connections and the antennas, but everything seemed normal. Turns out something in the other project was blasting out RF interference.

• We would occasionally need to manually move data on/off a server using a USB2.0 hard drive. This worked fine for years, until one day we had a server that would randomly disconnect from the drive a few seconds into the transfer. Tried different ports, same issue. The drive itself worked with all the others, so we decided the issue must be with the server. We swapped it out for a brand new one with plans to send the old one back for warranty repairs. Except the new one has the exact same issue. Both servers came from a newish batch from the OEM. Turns out that the earlier versions had a hardware “bug” where the USB ports would source more than the 500ma allowed by the spec. Since they fixed that, our drive would trigger the current limit during sustained use and temporarily depower the port. Solution: get a USB Y cable and power provider power from a wall block

• I had a mouse that would double click (or more) when you pushed the button. This was pretty obviously a hardware issue, but I figured I could just tell the computer to ignore double clicks that happened “too fast” and avoid needing a new mouse. In theory that should have worked, but the input stack on Linux turned out to be a giant web that I couldn’t figure out, so I ended up opening the mouse and soldering on a random capacitor I had lieing around.

• We had a laptop with a dead monitor that would mysteriously work at times. It turns out that most of the time, it was sitting on another laptop (of the same type). Those laptops had a magnet latch to hold them shut. It turns out that said magnet also was used as part of a “laptop closed” sensor that would disable the monitor, and the bottom laptop would trigger the sensor in the top one.

I think the image assumes that the viewer is familiar with merge sort, which is something you will learn in basically every undegraduate CS program, then never use.

To answer your first question, it helps to have something to compare it against. I think the most obvious way of sorting a list would be “insertion sort”, where you look through the unsorted list, find the smallest element, put that in the sorted list, then repeat for the second smallest element. If the list has N elements, this requires you to loop through it N times. Since every loop involves looking at N elements, this means you end up taking N * N time to sort the list.

With merge sort, the critical observation is that if you have 2 sublists that are sorted you know the smallest element is at the start of one of the two input lists, so you can skip the inner loop where you would search for the smallest element. The means that each layer in merge sort takes only about N operations. However, each layer halves the number of lists, so you only need about log_2(N) layers, so the entire sort can be done in around N * log(N) time.

Since NlogN is smaller then N^2, this makes merge sort theoretically better.

Because the thing people refer to when they say “linux” is not actually an operating system. It is a family of operating systems built by different groups that are built mostly the same way from mostly the same components (which, themselves are built by separate groups).