Also the case of 'learning that someone did updates directly on AWS console instead of terraform and losing 0.5 or more days cleaning up the resulting mess'
Correct, most of Linux user land targets API stability, not ABI stability. Windows targets ABI stability because applications are typically distributed as binary blobs. Most applications on Linux are open-source and built per each distro, so it’s a non-issue, just recompile.
This doesn’t work for proprietary software that’s distributed as blobs and rarely updated, like say, video games. But that’s a minority of stuff on Linux. But not on windows.
Realistically, on Linux applications target specific API versions of frameworks. Like Qt 6, or GTK 3, or whatever. Then everything is compiled or dynamically linked at a per-distro level. The ABI compat can bite specifically when distros enforce strict dynamic linking. But then containerization technologies come in.
And there is a difference between API and ABI stability. For example, adding SSO to std::string in C++ broke ABI, not API. If you recompile it’s fine, everything works. If you don’t then it doesn’t.
Dead wrong. Win32 (externally) only seems stable, but internally it changes between Windows releases. Win7 syscalls are completely different from Win11 syscalls, meaning if I want to release a binary _without relying_ on Win32 I need to provide full syscall mappings _for each and every Windows version_. This doesn't happen on Linux.
That's literally the definition of it being stable. Programs written against an interface keep working despite the implementation changing. The Linux kernel also constantly changes internally but programs written against syscalls keep working, so it is stable; that fact doesn't stop being a fact just because I dislike perf_event_open(2) or whatever. This is all very basic and easy to understand.
There is sadly no hdmi CEC support on Most GPUs for pcs. So when you want your tv to turn on and off with your pc it is only possible with the tv being reachable from your pc via ip.
I believe LG doesn’t advertise such an api via Bluetooth
HDMI breakout and a esp32 module flashed with esphome is another option. The tv most likely doesn’t care that the port that sent on/off command is not the same port the video signal is coming from..
For responsiveness that’s what you want, context switches add quite a lot of jitter and perceived slowness’s, making your app feel slow despite running at 120 fps.
Depends a lot on the memory pressure. If you can be fairly certain the data is (or will be) resident in memory, mmap is basically unbeatable. If you can't (because the data is larger than RAM or there's other stuff competing for RAM), mmap can have gnarly system-wide performance implications[1].
In my case: its a PROT_READ, MAP_PRIVAT map and i cannot get a SIGBUS since i tell the kernel to handle it all for me, thanks to liburing, instead i get a short send in that case.
To be more precise: i use that map to send assets out directly to clients from a zip file.
Its a new web server i am building and its the fastest way i could find out.
Just switching from epoll to liburing made the server ~45% faster too, its ridiculous. It can serve 10 gigabyte per second with a single thread, or around 10 million responses per second with h2 and 32 multiplexed requests.
I had to write a new http load generator for that since i couldn't find one which could generate enough load to saturate my server or be fast enough to withstand it.
??? The only configuration that will allow disk reads at 10 GB/s is if you're using PCIe 5.0. PCIe 4.0 or lower, and SATA will not drop out long before that.
He's very clearly hauling data straight from the page cache.
to not let the bytes i forward enter userspace, i serve from the page cache for the asset path, directly from a zip file.
i open the file, mmap it, close it and tell io_uring_prep_send which bytes from the mapping to send, this also saves me from a possible SIGBUS cause the access to the mmap happen inside the kernel, and when a SIGBUS would happen in userspace the kernel just reports a shorter send in cqe->res
The Linux-specific MADV_POPULATE_READ is much more reliable than MADV_WILLNEED if you want to implement read-ahead for a memory-mapped file.
In my opinion, the POSIX advices specified for madvise are useless or even dangerous.
On Linux, for precise control of memory-mapped files one should use only these 4 Linux-specific advices: MADV_COLD, MADV_PAGEOUT, MADV_POPULATE_READ & MADV_POPULATE_WRITE.
These should be used within io_uring, so that they will be executed asynchronously.
These have a well-documented meaning and using them carefully should be sufficient to reach optimum performance with mmap.
It is still a shame that the city which called itself Zuse-City does not try harder to keep it. I know how hard their financing situation is first hand but the ZCOM as a place and education institute was more worth then they understood.
You don’t have to do any significant work within the signal handler itself. In fact, the signal handler can literally be empty. What matters is that as long as SA_RESTART is not set, after the signal handler runs, the interrupted syscall fails with errno set to EINTR. Then the code that did the syscall can check whether a cancellation occurred (and retry the syscall if not).
Disclaimer: I haven’t looked at Zig’s implementation; I’m only going off how the Unix APIs work.
reply