gsliepen

Ah, the venerable disk defragmenter! I ran it once, and it was slowly progressing. 97%, 98%, 99%, almost done now I thought! 100%, 101%, 102%, uh oh, that can't be good... but maybe it was just a rounding error in the calculation of the percentage? I stopped it at 110%, but the damage was already done, all the sectors shuffled so much the filesystem was effectively unreadable.

You can indeed, but it would change the code from the article drastically: you have to get rid of the mutex, the discriminant becomes an atomic variable, and you need barriers between access to the discriminant and to the value the source is holding. Performance-wise I don't think it will show a drastic improvement, the main benefit would be the size of the source.

> The wait_for method is why we have a condition variable at all. If it weren’t for that guy, we could have used std::atomic‘s wait and notify_all methods.

No, the std::mutex is the reason you have a condition variable. Never mix std::atomic with std::mutex-and-friends, you are very likely introducing race conditions that way.

I've worked with piezo actuators to align optical elements. They have great resolution, but they suffer from non-linearity, non-repeatability and a lot of hysteresis. Making motion accurate then becomes a problem of having encoders that can measure the position of your device with the required accuracy.

Are segments really more flexible? I wrote some 8086 assembly back in the day, and they are a pain in the ass to work with. Code that spans segments has exactly the same problems bank switched systems have. I think the main benefit of segments is that only the CPU needs to worry about the segments, whereas with (most if not all?) bank switched systems, the whole computer sees banks being switched, which is a problem for DMA.

It's also not like you are stuck with a full OS when you are running Linux. You can remove features from the kernel you don't need, and you can configure a bare-bones busybox to be your userspace, or just run your application directly as the init process.

But that's not what's happening here. If anything, it's driving the e-ink display less. The main risk is that grays are not well-defined. Given a pulse train to get a certain gray level, that gray level might change over time due to aging of the e-ink panel, or it might change directly with temperature or other environmental factors.

Another issue I heard, but I don't know enough about the physics of e-ink to know if this is correct, is that if you are at a gray level, the white and black particles are mixed and might exchange charge, thereby causing some particles to not move correctly anymore.

Even weirder: when the router forwards the packet from the host to the Internet, it already sees both the source IPv6 and MAC address, so it could store them.

Maybe there are some weird situations where a host that just got its own IP address starts proxying for a third node that wants return packets to asymmetrically bypass the host?

I think the solution is to really give the user control over when something is pasted and into which application. So if you press ctrl-V, it shouldn't pass that on to an application that then gets to poll the clipboard, instead the OS or window manager should send the contents of the clipboard to the application the moment ctrl-V is hit.

> Intent matters a great deal,

The road to hell is paved with good intentions.

For FPGAs in general: When latency is important. Even a $1 MCU has a huge amount of compute power nowadays, and they can simulate many things, but if you need to deterministically react within 1 microsecond to what happens on a pin, and your MCU doesn't already have a hardware peripheral that does exactly what you want, you're probably going to need an FPGA.

Some recent advances, like the Raspberry Pi Pico's PIO units, have made it possible to do things that MCU's couldn't do before, like emulating a ROM chip. But there are limits to what the PIOs can do.

If it comes to pure computation and not latency, you need some very specific use case before an FPGA becomes better than a regular CPU. Most likely when it involves massive parallelism and custom caches and interconnects. Although nowadays NPUs are starting to fill that niche.

For tiny boards in particular: getting experience and having fun.

The Swedes managed it.

> Everything being static inline makes it hostile to these older systems which have limited RAM.

Compilers can un-inline as well. In fact, since every function is defined in the header file, the static inline annotation means very little, it's more of a hint; the functions that were not marked static inline can be inlined just as well by the compiler.

We'll see how much people like it once the cheap subscriptions end and the actual cost of LLMs (+ profit margin) is asked of them. Although I'm suspecting that eventually, machines that are good enough to run reasonably useful models will become cheap enought that most developers will have those, but that might be some years from now.

Debian is run by volunteers, and I think Debian Developers would not like it if they would have to pay to work on it, thus there will be some aversion to (at least frontier) LLMs.