> Given how modern OSes still insist in using C derived languages at their bottom layer, instead of the Pascal and Modulas from the 90's.
On the other hand, the bottom layer is exposed to very little untrusted input nowadays, and the upper layers are mostly either using memory-safe programming languages, or languages with C++ with a ton of effective exploit mitigations (we owe much of that to PaX and grsecurity).
The days of Java, ActiveX and Flash browser exploits are long gone. Windows browser exploits have become so rare and complex that they're worth $1M+.
Still not ideal, but a lot better than it ever was.
> How those RPC alternatives keep re-inventing the validation schemas, performance optimization and code generation tooling of SOAP, CORBA and DCOM.
SOAP and DCOM were big balls of mud with myriad compatibility and security issues. CORBA was a designed-by-committee disaster.
It appears that we're finally close to getting this right with Protobufs, gRPC and Cuelang.
> Sandboxing is mostly a mobile OS thing, with devs clamouring against it on their desktops.
Desktop apps have mostly been replaced by web apps, which have excellent sandboxing and fine-grained permissions. The only native desktop apps I run nowadays are highly specialized (like an IDE). The days of having to download and run a zoo of random third party applications are mostly gone. ChromeOS exists.
> Many give up on open source, make use of SaaS, or switch to commercial because people leech their work and they need to pay bills.
This is true for end-user applications because yes, bills need to paid. Exceptions apply - well-funded open source projects like Krita and Blender have managed to not only keep up with commercial competition, but surpass them.
The rise of SaaS had the side effect of VC and corporate money funding a ton of open source libraries and infrastructure tooling, released under permissive licenses.
> Linux desktop is 1% of world market and keeps being plagued with audio, 3D drivers and lack of hardware acceleration for video decoding in browsers.
Last time I checked, it was ~3.5% if you include ChromeOS.
As long as you're careful to buy compatible hardware, audio, 3D, and hardware accelerated video decoding works just fine nowadays. I've been using a Linux desktop for more than ten years and I haven't had to mess with any hardware issues for the past four.
With ChromeOS and Crostini, you get a macOS-like experience where everything just works with zero fiddling and compatibility issues.
Mitigations that are Linux only and hardly effective, hence why Android is now going to require hardware pointer validation on Android 11.
Protobufs, gRPC are only a thing if one is on Google land and even then quite primitive tooling, versus what those other protocols offered.
Desktop apps are quite alive, specially on enterprise and domains like lifesciences laboratory automation, medical monitoring devices and plenty of other areas where a browser just doesn't cut it.
Krita and Blender are lucky to have good sponsors, a drop in the ocean of FOSS.
ChromeOS hardly counts as Linux, specially since not all devices are Crostini capable, and yes Steam hardware survey puts it at ruffly 1%.
I gave up on hunting for Linux hardware ages ago, Apple and Microsoft OSes and related hardware keep me happy when doing graphics programming.
> Mitigations that are Linux only and hardly effective, hence why Android is now going to require hardware pointer validation on Android 11.
What do you mean by Linux only? Modern mitigations are very effective at increasing cost of exploitation and the underlying concepts are platform-independent - Windows, macOS and iOS follow similar approaches with similar results. If anything, Linux (both the kernel, and various userlands) has been trailing behind.
Pointer authentication is just the logical next step, just like CPU features like SMEP and SMAP superseded software-only implementations like PaX KERNEXEC/UDEREF. And yes, even hardware pointer authentication can be bypassed if someone tries hard enough.
Without moving to a memory safe language, memory corruption exploits will always be possible (just more and more expensive), and I'd love to use an OS kernel written in Rust. It has been exhaustively proven that even the world's best engineering teams are incapable of consistently writing safe C/C++ code - any line of C code exposed to untrusted input is a liability.
But meanwhile, I'm happy that the industry is finally investing in mitigations that kill some classes of bugs, and raise the bar for others, rather than only hunting for and fixing individual bugs.
> Protobufs, gRPC are only a thing if one is on Google land and even then quite primitive tooling, versus what those other protocols offered.
The simplicity, even at the cost of expressivity, are one of the best parts of Protobuf and gRPC. The unbounded complexity and feature set of approaches like SOAP or CORBA is the reason why they've failed.
gRPC has seen a lot of adoption outside of the Google ecosystem.
We probably both agree that REST and JSON were a mistake.
> Desktop apps are quite alive, specially on enterprise and domains like lifesciences laboratory automation, medical monitoring devices and plenty of other areas where a browser just doesn't cut it.
Those are highly niche use cases, and the UI for many of these will eventually move to the web platform, too. Even my dentist's office, which used to run on an antique Win32 application, is now using a next-generation web application built by the same vendor, that supersedes the Windows application. Hosted on a local server, not the cloud.
Very few applications actually need low level hardware access, and sandboxing won't be a concern for these since they're typically the only thing running on the machine that's worth protecting to begin with.
> ChromeOS hardly counts as Linux, specially since not all devices are Crostini capable, and yes Steam hardware survey puts it at ruffly 1%.
Why wouldn't it count as Linux? It runs on the Linux kernel and with a slightly exotic, but fully open source userland. You can modify it and run it on your device (at the expense of boot integrity protection). ChromeOS shares a lot of code with other Linux distributions (like ModemManager, CUPS, the new Chrome renderer, a lot of work on upstreaming kernel driver improvements...).
Any recent ChromeOS device supports Crostini. If it doesn't, it's for reasons like "the CPU has no VT-x support", "this is a 32bit ARM CPU" or a potato CPU.
Steam hardware survey data is not representative.
> I gave up on hunting for Linux hardware ages ago, Apple and Microsoft OSes and related hardware keep me happy when doing graphics programming.
Agreed - graphics programming, especially the high performance kind, is best done on Windows. The tooling is just so much better. But for the kind of work I do - security research and systems engineering - GNU/Linux is perfect and hardware support is great.
> As you see, we have to agree to disagree.
Thank you for this pleasant and interesting discussion, even if we ended up disagreeing :)
lol on the "death of desktop apps" - browsers are just the modern version of VT220 terminals. They solve none of the problems of remote vs. local computing, performance issues around abstraction vs. running closer to the hardware natively, etc.
Everything old is new again.
Yes, you can shim stuff and run some things "offline", but there are many tasks for whom I would never want to relinquish total autonomy from the cloud.
It isn't going to happen. Both approaches have their pro's and con's - insinuating one is going to supplant the other is folly, despite people continuing to do it for multiple decades now.
> It isn't going to happen. Both approaches have their pro's and con's - insinuating one is going to supplant the other is folly, despite people continuing to do it for multiple decades now.
The "web app vs. native" line is already blurry now with Electron apps, and will get blurrier in the future as browser capabilities and performance improves. The browser is becoming an OS on its own - Chromium has already surpassed the Linux kernel in terms of complexity and lines of code.
I hate JavaScript and the surrounding ecosystem, but there's no denying that this appears to be the future of a majority of desktop applications (if it isn't already).
On the other hand, the bottom layer is exposed to very little untrusted input nowadays, and the upper layers are mostly either using memory-safe programming languages, or languages with C++ with a ton of effective exploit mitigations (we owe much of that to PaX and grsecurity).
The days of Java, ActiveX and Flash browser exploits are long gone. Windows browser exploits have become so rare and complex that they're worth $1M+.
Still not ideal, but a lot better than it ever was.
> How those RPC alternatives keep re-inventing the validation schemas, performance optimization and code generation tooling of SOAP, CORBA and DCOM.
SOAP and DCOM were big balls of mud with myriad compatibility and security issues. CORBA was a designed-by-committee disaster.
It appears that we're finally close to getting this right with Protobufs, gRPC and Cuelang.
> Sandboxing is mostly a mobile OS thing, with devs clamouring against it on their desktops.
Desktop apps have mostly been replaced by web apps, which have excellent sandboxing and fine-grained permissions. The only native desktop apps I run nowadays are highly specialized (like an IDE). The days of having to download and run a zoo of random third party applications are mostly gone. ChromeOS exists.
> Many give up on open source, make use of SaaS, or switch to commercial because people leech their work and they need to pay bills.
This is true for end-user applications because yes, bills need to paid. Exceptions apply - well-funded open source projects like Krita and Blender have managed to not only keep up with commercial competition, but surpass them.
The rise of SaaS had the side effect of VC and corporate money funding a ton of open source libraries and infrastructure tooling, released under permissive licenses.
> Linux desktop is 1% of world market and keeps being plagued with audio, 3D drivers and lack of hardware acceleration for video decoding in browsers.
Last time I checked, it was ~3.5% if you include ChromeOS.
As long as you're careful to buy compatible hardware, audio, 3D, and hardware accelerated video decoding works just fine nowadays. I've been using a Linux desktop for more than ten years and I haven't had to mess with any hardware issues for the past four.
With ChromeOS and Crostini, you get a macOS-like experience where everything just works with zero fiddling and compatibility issues.