If you want LTS, target Windows. I have stuff I wrote on NT4 that still runs today. Linux and macos can't get near that.
And then there's what you allude to: A stable Windows environment that will, in most cases, run ancient code mostly fine assuming they were written to specs of the time or it's a very important piece of code (eg: Simcity).
Linux does not have a stable userland ABI/API, it's very common for binaries built for one distro version to not work in another distro version due to changes in system libraries (curl, ssh, libc are common ones), there's usually ways to work around these but it's a mess that shouldn't be left to the user.
The solution the Linux commmunity has come up with to solve this problem is containers, such as Flatpak (for desktop apps) and Docker (server apps).
Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statical...)
Your link is about glibc, not libc in general. For example musl is perfectly fine to link statically to.
Python’s “manylinux” binary target is a good example on how to do that. We’re currently targeting “manylinux2014”, which is a decent middle ground.
I don't think that is correct. Do you have an example? Linus is adament that "[they] do not break userspace".
> it's very common for binaries built for one distro version to not work in another distro version due to changes in system libraries (curl, ssh, libc are common ones), there's usually ways to work around these but it's a mess that shouldn't be left to the user.
But that would be the same thing on windows. If you dynamically link your executable to an old version of libcurl and run your executable on a windows with a newer version containing a breaking change, you'll be in trouble, whatever your OS.
> The solution the Linux commmunity has come up with to solve this problem is containers, such as Flatpak (for desktop apps) and Docker (server apps).
Flatpak and Docker solves many other problems than kernel API. Actually, it does not solve this problem at all if you think about it because these technologies do not insulate you from the kernel (contrary to a VM).
> Statically linking libc is heavily discouraged (https://stackoverflow.com/questions/57476533/why-is-statical...)
Statically linking glibc. You can perfectly statically link with any other libc. You can even code without a libc (see zig).
I think you interpreted Linus wrong. When he says "we do not break userspace" he is talking about the Kernel APIs that are exposed to the Userland.
Userland APIs would be stuff like glibc, which has a terrible track record in regards to API breakage.
I think I correctly interpreted Linus when he talked about the kernel API/ABI facing the user (developer of application).
A lot of trouble you are going to get maintaining builds are due to poor tooling, not linux.
But we are getting into semantics here. At the end of the day, I think that if you are careful with what you are doing and think a little before choosing your tools and writing code, you should get very good mileage out of your linux binaries.
I don't know enough about windows to comment on its stability but I very much doubt I could just slide my original Quake CD or 3DS max 4 install into Windows 10. But I might be wrong!
Most of the time I can run a program from the 1990s on Windows 11 just fine, you can't say the same for Linux.
The only incompatibility in Windows that happens frequently is if you try to run a program written for a newer Windows version in an older version. That will likely fail because forwards compatiblity isn't a priority. But with regards to backwards compatiblity, Microsoft goes to herculean efforts to make sure Windows programs written several decades ago will work today.
Windows programs ship with all their necessary libraries and/or link against the Microsoft c++ resist packages and you can have many different versions installed. Your MSI installer has to install the libcurl.3.dll instead of it being shared with other programs.
Docker and Flatpak fix the userland part the kernel part is already stable by "definition". Stuff may still break overtime but no more than it does on MacOS and Window. It's not broken by design anymore.
Win32 API is much larger than Linux kernel API and is stable so there is quite large chance that a couple decades old software still works without recompiling or updating libraries. It has its issues with many parts of it being completely horrifying to use, but the stability is something that Microsoft has done well.
Windows has very variable support timeline for its releases, and, going forward, Microsoft only looking to cut down on support times, not increase them. So, even if it worked for you during NT era, it's not going to work for people writing for Windows 10 or whatever the present day version is.
Not to mention that Windows is just not a player in many major computer markets, so not even an option for someone who eg. wants to provide storage solutions or HPC and many others.
edit: Hah, good work, siblings!
this is probably machines that handle special hardware.. like MRI, ECG, or monitor for vitals like pulse, blood pressure, blood oxygenation or other stuff like that..
Those machines need to be certified as a whole package and this include the computer that will control it.. and once you certify you cannot make changes to the package without having to certify again..
So you certify the machine with that software on it.. that specific kernel version, that specific libc version and so on.. if you change anything you need to get a new certification..
and now those machines are no longer air gapped because hospitals want to be able to remote monitor the patients vitals from a central nurse station..
Oh you are so naive... You probably wish it worked like that, but in practice it doesn't.
The certification process is completely broken today. First of all, it allows proprietary software / hardware to go through this process (which is the majority of applicants by far). Typically, FDA or similar will ask for company's own research that establishes that the software works with absolutely no way of verifying that it does. They, as well, have no way of ensuring that whatever version was used to produce the research results is the one that's being installed on the hardware shipped to the hospital / patient. Companies producing software routinely patch their software if they discover problems after initial release and don't hesitate to claim that it was approved.
In short, the problem MS created for medical / hospital equipment is that by trying to ensure they control the software, they made the hospital staff incapable of using the software to their own benefit. Hospital research today is archaic in its practices compared to virtually any other field because of how it relies on Microsoft products. Usually, it's a bunch of people manually filling Excel spreadsheets and doing a lot of other things that would've been trivial to automate by hand.
Hospital / medical equipment is not validated well by various bodies established to do that (eg. FDA or similar European bodies) because the technology is proprietary and validation, essentially, relies on companies submitting their internal research results to get the equipment approved.
PACS and similar systems are designed and implemented by companies who don't understand how hospitals work, and aren't interested in learning that -- the typical enterprise model inspired and encouraged by the use of MS products, where deals are made between high-ranking managers w/o any attention to the actual needs of the personnel who are supposed to use the software. And this is again, because MS conditioned hospitals not to use open-source software, which also resulted in no internal talent / expertise growth. So, doctors in external clinics and even inside the hospital, even though connected by their computerized system, don't know how to use it well, or, sometimes systems lack important functionality.
By bribing their way into medical system, MS committed the largest crime in its history, much larger than anything it's been taken to courts for. Countless lives have been lost or severely impacted because of MS profiteering. But nobody really talks about it because these numbers are hard to count. It would be very hard to sue them for this as this is too broad and hard to get concrete evidence of... but if you had ever interacted with the hospital computer systems from the inside, you'd see this plain as day.
There are really 2 things you need to avoid: Context switching, and tripping over the internals of the kernel. By forcing the multimedia timer to 1khz, you can address the latter. You should still try to run your time-sensitive code on a dedicated thread and never yield to the OS, even if yielding is made less costly. Keeping the cache hot all the way thru is way more important. If the kernel doesn't have an opportunity to make a decision about your priority, you don't have to worry about a thing. Hold onto the thread of execution and never let go. Async/await is your enemy. Poll everything.
For me, the biggest win is in the development experience. Building this stuff on Windows is like cheating compared to being forced to target an obscure RTOS linux distribution up-front. Even then, if I build my RT product in something like .NET6+, it is plausible I could compile the exact same code for a more power efficient platform after completing initial development on windows. The only code that would be platform-specific are any "hacks" like one-time mm_timer calls.