Recent discussion:

Real-time Linux is officially part of the kernel (arstechnica.com) | 500 points | 139 comments | 10 days ago | https://news.ycombinator.com/item?id=41594862

That article claims that without NO_HZ Linux wouldn’t be running in datacenters. Um, no. Many hyperscalers still haven’t enabled it! Stopped reading there.

Are there any good books or other resources yet on realtime programming on Linux?

I Dunno. "The main aim of the PREEMPT_RT patch is to minimize the amount of kernel code that is non-preemptible", that's nice and all, but there are still no guarantees, which (in some interpretation of "real time") a RTOS is all about. For some applications the effort might suffice, but others will insist on those guarantees. For music recordings, I (perhaps naively) would expect a decent audio card with its own processor and (RT) firmware would yield better results.

The Raspberry Pi Foundation does not do a good upstream support. It is not very bad, but also not good. They should start adding support for their new chips in the upstream projects before they get into the market, like Intel does it for example. They could add support for some new IP cores, without reveling when and how it will be used later. When the product comes out the only add small patches linking the code together like device tree files.

It would also be good if they would release all the closed source firmware files needed for their devices under a redistributable license in the linux-firmware repository. For some time it was not allowed to redistribute the binary wifi firmware needed for the Raspberry Pi devices. This is needed for Linux distributions to package the binaries.

I hope they do this only because of lack of resources and not intentionally to lock people into their Linux distribution.

Virtually nobody uses mainline Linux on Raspberry Pis, so not sure why would it be so surprising.

If I went and checked commits, I’m sure there are a lot of business critical IOT/controller type processes that now rely on Raspberry and therefore engineers backing support out the gate

Isn't intel SRIOV getting mainlined with Xe driver in 6.12 or am I mistaken?

Yeah, went through a whole journey getting this to work on a NixOS guest with a Proxmox host recently.

You reminded me to write up the process, and publish a flake for NixOS users who want the kernel.

Unfortunately migrating real-time stuff to Linux _doesn't_ necessarily reduce costs or simplify real-time development needs. I've been doing embedded development for 5+ years at a few companies and doing embedded Linux is still a slog. I prefer a good MCU running Nim or other modern language. Heck there's even MicroPython nowadays.

Especially for anything that needs to "just run" for multiple years. Linux means you must deal of the distro or something like Yocto or Buildroot. Both of which have major pain points.

I think there's still a wide range of devices for which a bare-metal or smaller RTOS approach is still more cost-effective. Anything that's simple enough it doesn't need networking, a filesystem, or a display, for example. Especially considering bare-metal embedded work seems to pay less than development on linux. But yes, embedded linux can address a huge part of the market and RT expands that a lot (though, of course, most people for whom that is a good option are already using it, it was a well-supported patchset for a long time)

its what a kernels supposed to do. also cryptocurrency scams are not that novel in my experience, they're usually pretty derivative and low-effort

Stability is more about not introducing new bugs than reducing the number of bugs in total. i.e. if a system is working well enough for you now, because you can work around or are unaffected by the bugs that currently exist, and your requirements don't change, it will continue to work for you in the future, because they are much less likely to disrupt your setup with new bugs or even just changes that require your intervention. Debian is great for that 'throw some infrastructure on a box and leave it chugging away for years' kind of situation, and conversely terrible for the 'actively developing a new product' situation.

> Reminded that Debian-family is outdated linux that uses the marketing 'stable' which has 0 relations to the number of bugs.

Correct: It is stable, which is to say that things that work today will work tomorrow and the system does its best to stay out of your way. It doesn't, say, expect you to jump major versions every 6 months like other distros you might name.

> I thought we were trapped with Windows 11 and 'Linux'(meaning Debian-family).

I mean, yeah, the family of Linux distros alone is huge; conflating "Linux" and "Debian-family" is a significant mistake.

> No, turns out that is outdated linux and Modern linux is amazing.

And less-bleeding-edge Linux is also amazing. Unless you need the new stuff, moving at a slightly more sedate pace is perfectly fine. Which way the tradeoffs go depends on you and your usecases; some people want all the new shiny features right right now and benefit from riding the bleeding edge (like Debian Sid, Arch, or yes Fedora), and some people want to set things up and then not have to think about that machine for another few years (funny enough, I'd actually prefer that Debian supported each release for an even longer time, but that takes resources the project doesn't have). Bashing either approach is myopic.

I don't think I've ever had a Debian install crash. When they say stable, they mean stable.

Yeah, I have been saying this for years now. Debian and Ubuntu type distros starts doing custom patches and cherry picks changes into 3 year old software, just to keep it chugging along. Sounds like insanity to me. Just upgrade so you are not 3-4 years behind, and by keeping the number of custom patching lower, have a simpler time fixing bugs.

Fedora and Ubuntu release at the same frequency...