>A new OS isn’t compelling for users.
I'm a user (and in particular a Linux user) and a new OS which has Chromium ported to it is compelling to me because I expect that Linux will never evolve to be secure enough.
I'm a user (and in particular a Linux user) and a new OS which has Chromium ported to it is compelling to me because I expect that Linux will never evolve to be secure enough.
And none of these things require Linux (the kernel) to change all that much. Hell, Android has decent security by running all apps with different user IDs and restricting the parts of the filesystem it can access.
Obviously your default Linux desktop install doesn't work like this, but some motivated individuals could do it, if they wanted. Writing an entire new OS is hardly necessary. Google just wanted something it could control, when it comes to Fuchsia. And they're the last company that I would trust to build an OS that doesn't end up being user-hostile.
Functional programming, micro kernels, RISC (or, depending on the decade, CISC), cryptocurrency, etc.
Superficially, that claim sounds reasonable, but I'd have a hard time substantiating it. There is exactly one secure microkernel ready for production use today, and zero secure monolithic kernels. There's not even a "here's how one could secure a monolithic kernel in principle" whitepaper.
I'd be interested to hear your definition of "secure", and why OpenBSD doesn't qualify.
Although professional security people are also rather bad at this and like to eg stack multiple cool-looking mitigations even if they break each other. (https://siguza.github.io/PAN/)
(Qubes, OTOH, is interesting; I see it as one possible path to the future)
Would you? Linux is, in fact, quite modular, and perfectly happy to not load things until asked to (often as a result of hardware being discovered or plugged in).
Sandboxing is a much better approach to security than the Unix permissions model, which is nearly obsolete.
Sure the problem cannot escape the sandbox, but in the end i'm more concerned with my data in the sandbox.
Both Mac and Windows just dump a whole bunch of libraries into the install directory.
I think on Flatpak you can update the base platform package and have the applications use that automatically, so there's that.
So it's either AppImage/Flatpak/etc or it's building a package per distro.
That's an incredibly low bar. They're a bad model because the Unix API surface is huge and underspecified; there are a zillion different ways apps could potentially interact with each other. Some of them are giant security holes. Some of them are vital to some obscure corner of app functionality. Most of them are both.
So when you download a game your threat model isn't that it might want to mess with the kernel, but that it's going to steal all your data from your browser cache. Dealing with that requires some sort of sandboxing.
Huh? No-one is advocating using user accounts for security.
> So when you download a game your threat model isn't that it might want to mess with the kernel, but that it's going to steal all your data from your browser cache.
Why do you think this contradicts anything I said? And what mechanism do you think it's going to use to do that? Maybe not syscalls in the narrow sense, but certainly via one of the "zillion different ways apps could potentially interact with each other".
> Dealing with that requires some sort of sandboxing.
Is this the "something must be done" fallacy? "We need some kind of sandbox, snap/flatpak are some kind of sandbox, therefore we need snap/flatpak".