And of course there are also tons of huge Windows software that come with all sorts of their own dependencies.

Edit: I think I somewhat misread your comment and progval is more spot on. On Linux you usually install software with a package manager that resolves dependencies and only installs the unsatisfied dependencies resulting in small install size for many cases while on Windows that is not really a thing and installers just package all the dependencies they cannot expect to be present and the portable version just does the same.

Versus Linux where you have Gnome vs. KDE vs. Other and there's less emphasis on backwards compatibility and more on minimalism, so they need to package a lot more dependencies (potentially).

If you only install Gnome Flatpaks they end up smaller since they can share a bunch of components.

Personally i vastly prefer AppImages to flatpaks (in fact i do not use flatpaks at all, i'd rather build the program from source - or not use it if the build process is too convoluted - instead).

[0] https://appimage.org/

Thanks all for the explanations, much appreciated, I thought I was missing something. I really should have known though, Ive been using portable apps for over 20 years on windows and remember.net apps not being considered portable way back when, which are now considered portable since the run time is on all modern windows.

(This has also made an otherwise nice music player[3] unusable to me other than by dragging and dropping individual files from the file manager, as all of my music lives in git-annex, and accesses through git-annex symlinks are indistinguishable from sandbox escape attempts. On one hand, understandable; on the other, again, the software is effectively useless because of this.)

[1] https://wiki.archlinux.org/title/XDG_Desktop_Portal

[2] https://wiki.c2.com/?PowerBox

[3] https://apps.gnome.org/Amberol

https://news.ycombinator.com/newsguidelines.html

Oh wait...

In the Python world, something wants numpy>=2.5.13, another wants numpy<=2.5.12, yet Python has still not come up with a way to just do "import numpy==2.5.13" and have it pluck exactly that version and import it.

In the C++ world, I've seen code that spits out syntax errors if you use a newer version of gcc, others that spit out syntax errors if you use an older version of gcc, apt-get overwrites the shared library you depended on with a newer version, lots of other issues. Install CUDA 11.2, it tries to uninstall CUDA 11.1, never mind that you had something linked to it, and that everything else in that ecosystem disobeys semantics and doesn't work with later minor revisions.

It's such a shitshow that it fully makes sense to bundle all your dependencies if you want to ship something that "just works".

For your customer, storage is cheaper than employee time wasted getting something to work.

For instance, the Switch - and I don't know where in the stack this limitation lies - won't even let you run multiple programs that use the network. You can't, say, download a new game while playing another one that happens to have online connectivity - even if you aren't using it!

On a computer, we want to be able to run dozens of programs at the same time, freely and seamlessly; we want them to be able to interoperate: share data, resources, libraries, you name it; we want support for a vast array of hardware and peripherals. And on and on.

A Switch, fundamentally, is a device that plays games. Simpler requirements leads to simpler software.

The problem with it is that it's a lot of work (just getting secure boot to work is a massive pain in itself) and there are a lot of drivers you need to manually disable or settings to manually toggle to get a Switch equivalent system. The Switch includes only code paths necessary for the Switch, so anything that looks like a USB webcam should be completely useless. Bluetooth/WiFi chipset drivers are necessary, but of course you only need the BLOBs for the specific hardware you're using.

Part of Nintendo's security strategy is the inability to get binary code onto the system that wasn't signed by Nintendo. You can replicate this relatively easily (basic GPG/etc. signature checks + marking externally accessible mount points as non-executable + only allowing execution of those mounts/copies from those mounts after full signature verification). Also add some kind of fTPM-based encryption mechanism to make sure your device storage can't be altered. You then need to figure out some method of signing all the software any user of your OS could possibly need to execute, but if you're an OEM that shouldn't be impossible.

Once you've locked down the system enough, you can start enforcing whatever sandboxing you need on top of whatever UI you prefer so your games can't be hacked. Flatpak/Snap/Docker all provide APIs for this already.

The tooling is all there, but there's no incentive for anyone to actually make it work. Some hardware OEMs do a pretty good job (Samsung's Tizen, for instance) but anything with a freely accessible debug interface or development interface is often quickly hacked. Most of the Linux user base want to use the same OS on their laptop and desktop and have all of their components work, and would also like the ability to run their own programs. To accomplish that, you have to give up a lot of security layers.

I doubt Nintendo's kernel is that secure, but without access to the source code and without a way to attack it, exploiting it is much harder. Add to that the tendency of Nintendo to sue, harass, and intimidate people trying to get code execution on their devices, and they end up with hardware that looks pretty secure from the outside.

Android and ChromeOS are also pretty solid operating systems in terms of general security, but their dependence on supporting a range of (vendor) drivers makes them vulnerable. Still, escalating from webkit to root on Android is quite the challenge, you'll need a few extra exploits for that, and those will probably only work on specific phones running specific software.

For what it's worth, you can get a pretty solid system by installing an immutable OS (Silverblue style) without root privileges. That still has some security mechansism disabled for usability purposes, but it's a solid basis for an easily updateable, low-security-risk OS when installed correctly.

I don't think that's particularly hard if you only include support for one set of hardware and a single API/ABI for applications. Notably, no general-purpose OS does either of these things and people would probably not be pleased if one tried.