This is 100% false. It's easy to configure Linux itself to only occupy 1 or 2 cores (one real + the hyper-thread for that real core), and then pin your own application threads to the other cores where no other code will run. This setup has identical application performance (other than not having those two Linux cores) to having no OS at all. 100% predictable, ZERO jitter application code (including user-space networking).
Except…you can still SSH in to your "no OS" Linux box, you have a file system, can run cron jobs, git, gdb, WireGuard, etc. So it's much, much better in practice and what actual high-performance network developers actually do.
Essentially no one has run a literal "no OS" box for at least a decade; everyone who is running on normal hardware does what I just described with Linux because the cost is dirt cheap and it's way too convenient.
As to "run of the mill software dev" this is not a snarky comment, this is just reality.
Most devs have absolutely no idea how to configure Linux at all, other than to make their application work. Not to mention configure for real time operation.
So I stand by my comment that comes from over two decades of experience in the field.
Hacker News is a site that values intellectual curiosity, not snark: you should have replied with an explanation of what you are actually doing to get that kind of thing out of the Linux kernel. What value is your experience in the field to this community if you refuse to share it with others? In this case my analogy is even stronger because you could argue that explaining imaginary numbers to a third grader may be difficult, but "I set CONFIG_whatever to this value and set the kernel to never schedule my application off this core" is exactly the kind of response that would be expected in this context.
Downvoting reasonable posts that do not fit somebody's point of view without providing any constructive explanations is of course way better.
It is my understanding that the other real time linux attempts ended up in similar territory, good but not sub 5 microsecond good.
Garbage collection gets a bad rep from garbage collectors that are tuned for throughput rather than latency, but there is no lower limit to latency for garbage collection and there are GCs out there that prove it (like Azul). If you can afford dynamic memory allocation, you can afford garbage collection. And if you can't afford it, you can just preallocate and turn off the garbage collector.