Libdispatch is a burden to use for a server because of its book keeping overhead, and their history with kqueue makes it hard to convince someone to use it.
epoll isn’t very fast, kqueue is indeed much faster as a primitive.
MacOS’s implementation is an order of magnitude or more slower than (say) FreeBSD though, so its not a valid comparison that the syscall simply exists.
Another example of a syscall performing differently would be gettimeofday() in OpenBSD vs linux, its an extremely cheap operation in Linux but quite costly in OpenBSD despite being identical at the kernel boundary.
I am building something similar, with c++26 reflection. So any language can use c++ libs with only a few lines of boilerplate in a lifetime and memory safe way where possible. And where it’s not possible to infer the safe lifetime of an object i got a small .toml file which tells the lib how to safely use those functions.
This isn't true, often even in trivial cases. Auto-vectorization is actually quite fragile in 2026. The reason is that it's subject to (a) scalar float semantics (i.e. the resulting code must not produce different results from the scalar version), and (b) a number of opaque compiler heuristics that sometimes work out, sometimes don't.
For example, consider you want to compute the average of a list of floats. The compiler cannot autovectorize this, because float addition is not commutative. However, it's much faster to do component-wise addition in groups, then a horizontal sum at the end, and then divide. Whether it matters depends on your use case, and the compiler unfortunately can't read your mind, so it has to be conservative.
If you try writing SIMD by hand autovectorization can mess it up, eg if you have to write a scalar trailing loop then it might try to autovectorize it.
The autovectorizer afaik rarely emits optimizations for the different vector units to support + efficiently caches the CPUid check to happen once on program start. It’s a good baseline but the continuum (today) is scalar -> auto vectorized -> portable SIMD -> hand rolled explicit. That portable SIMD lets you bridge into hand rolled explicit ergonomically is a power auto-vectorization doesn’t have. Either the compiler does it or doesn’t but you have no way to even have a check that says “fail to build the program if this function isn’t vectorized”. This is important if you’re relying on that property and someone accidentally adds a data dependency and breaks the optimization without you realizing. Portable and explicit SIMD don’t have this problem by definition.
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.
Libdispatch is a burden to use for a server because of its book keeping overhead, and their history with kqueue makes it hard to convince someone to use it.
reply