The user land API/ABI is stable to a fault in Linux. The kernel API/ABI is unstable.
Companies are cheap. They hired web devs then tasked them with building a desktop application rather then hiring people to write native apps. They had a hammer and used it to fix every problem they had.
macOS is just as affected by electron apps as a Linux is.
Electron is horrible, but it does bring apps to many an OS once Chromium is ported.
Open protocols or open APIs from the company would fix the non-native app problem.
The user land API/ABI is stable to a fault in Linux. The kernel API/ABI is unstable
It’s the other way around. The kernel API stable to a fault, the kernel ABI isn’t. If your application only relies on the kernel API you won’t have many compatibility issues. If you rely on userland stuff such as C++ stdlib, GTK, QT, Python, … Good luck.
I wasn’t clear and that seems to have cause some confusion. I was talking about the Linux kernel itself, and only the Linux kernel.
There are two sides to the Linux kernel: internal exposed to drivers and such, external syscalls exposed to the public. That’s what I was talking about.
All bets are off with 3rd party software. That’s just a general problem in software development. It’s not specific to Linux, and it’s why vendoring libraries is recommended.
This is why all the 3rd party software is frozen at a point-in-time with fixes backported in distros like Debian or RHEL. It fixes the problems of devs being mercurial. The distro is the SDK. It creates a stable base, and it works rather well.
Unfortunately, most software relies on libc and a compiler. Both of which can be problems, and both of which are external to the Linux kernel. There’s not much which relies on only kernel syscalls.
Further, if you get code into the kernel, anyone who breaks it needs to fix it. So it seems to me it’s only a problem if you’re trying to do something like maintain a proprietary driver without putting it into the kernel? Or something to that effect?
Basically. Out-of-tree drivers are annoying without an LTS kernel.
There are also out-of-tree drivers which don’t get mainlined for one reason or another even though they are FOSS. OpenZFS has this problem, and now so does bcachefs.
Edit: I bought this one for 180 in another site just a few months ago. It now costs as much what I paid for RAM, CPU + MOBO. Dodged a bullet not waiting for the black Friday “deals”
The user land API/ABI is stable to a fault in Linux. The kernel API/ABI is unstable.
Companies are cheap. They hired web devs then tasked them with building a desktop application rather then hiring people to write native apps. They had a hammer and used it to fix every problem they had.
macOS is just as affected by electron apps as a Linux is.
Electron is horrible, but it does bring apps to many an OS once Chromium is ported.
Open protocols or open APIs from the company would fix the non-native app problem.
It’s the other way around. The kernel API stable to a fault, the kernel ABI isn’t. If your application only relies on the kernel API you won’t have many compatibility issues. If you rely on userland stuff such as C++ stdlib, GTK, QT, Python, … Good luck.
I wasn’t clear and that seems to have cause some confusion. I was talking about the Linux kernel itself, and only the Linux kernel.
There are two sides to the Linux kernel: internal exposed to drivers and such, external syscalls exposed to the public. That’s what I was talking about.
All bets are off with 3rd party software. That’s just a general problem in software development. It’s not specific to Linux, and it’s why vendoring libraries is recommended.
This is why all the 3rd party software is frozen at a point-in-time with fixes backported in distros like Debian or RHEL. It fixes the problems of devs being mercurial. The distro is the SDK. It creates a stable base, and it works rather well.
Unfortunately, most software relies on libc and a compiler. Both of which can be problems, and both of which are external to the Linux kernel. There’s not much which relies on only kernel syscalls.
Further, if you get code into the kernel, anyone who breaks it needs to fix it. So it seems to me it’s only a problem if you’re trying to do something like maintain a proprietary driver without putting it into the kernel? Or something to that effect?
Basically. Out-of-tree drivers are annoying without an LTS kernel.
There are also out-of-tree drivers which don’t get mainlined for one reason or another even though they are FOSS. OpenZFS has this problem, and now so does bcachefs.
But the Electron Apps are resource intensive, namely RAM.
Well, RAM is dirt cheap anyways. /S
Edit: I bought this one for 180 in another site just a few months ago. It now costs as much what I paid for RAM, CPU + MOBO. Dodged a bullet not waiting for the black Friday “deals”