omnios-build VS genode

key features at OmniOS Community Edition

OS Challenge: Try out an Illumos (OpenSolaris) image in a VM (there are Solaris kernel options available in Proxmox). If you want something fun, install OmniOS and create a Linux zone on it. So cool to run Linux on Solaris. https://omnios.org/

While UTM is much better at resource usage, it's not perfect. Virtualbox seems to emulate more of a system instead of passing it through to the hypervisor and so is better for running more unusual OSes. I have two VMs there running Illumos which I have yet to figure out how to boot in UTM. A problem that I think is related to UTM's greater use of the hypervisor is that you can't suspend and resume VMs that use it instead of being emulated, so I've still got a few VMs hanging around in Virtualbox which spend most of their time suspended. Finally, what stops me from using UTM at work is that you can't use it as a Vagrant provider. This is incredibly annoying, as the lack of a decent virtualization application makes the otherwise very nice M1 Macs nothing more than pretty toys. I expect that this glaring lack will be fixed within the next couple of years.

Can anyone recommend a good place to start learning OmniOS? Coming from Debain world. Other than the documentation on omnios.org, I only found a few blog posts here and there...

OpenIndiana is pretty neat. It has quite a few cool features like Zones, DTrace and Crossbow. ZFS is another big feature but you have already said that you don't really care about that. Hardware support is kinda lacking, but improving. Also it's rolling release so if you're like me and don't like that, OmniOS might be a better option; it's another illumos based OS.

seL4 foundation members[0] are using it.

There's Genode[1], which supports it among other kernels, offering a fancy desktop environment.

However, efforts like this driver framework do help. There's also Makatea[2], an effort to implement a stronger Qubes-like system based on seL4.

0. https://sel4.systems/Foundation/Membership/

1. https://genode.org/

2. https://trustworthy.systems/projects/makatea/

> While this is true from a certain perspective, machine code creates a system which must grand access to many things to become usable. A shared file system is a good example of this. Some software could easily echo a line into you .profile that tries to launch a key-logger, and this works in many cases.

That's common, but it's certainly not a requirement to run native code. For example, we've done a pretty good job at retroactively fixing that while preserving backwards compatibility with containers (I can, and have run normal official Firefox binaries inside a docker container with zero access to my real home directory) or sandboxes like flatpak (bubblewrap). If you want to run real native binaries but don't have to preserve backwards compatibility, then it gets easy; genode ( https://genode.org/ ) does a lovely job of truly practicing only giving programs what access you want to give them.

> The expectation of software existing as opaque files creates a huge amount of work for the OS in verifying the exact behaviour of the software as it runs (and in ways which can often be circumvented), rather than a source-based approach in which malware is never allowed to touch the processor.

I think you're overoptimistic regarding what you can do with the source code short of manual (human) auditing. I mean, sure there are things you can scan for to try and catch bad behavior, but in the case of actual malice I wouldn't trust automatic code analysis to protect me.

>> I'm typing this on a nice comfy GNU/Linux box where the only blobs are some firmware

> So you suffer the worst of both worlds then. You've had to download and compile the source yourself, but as the software is designed around being distributed as blobs, so you enjoy none of the benefits that might come from source distribution.

I have no idea why you think either of those things? Depending on the distro I certainly can compile from source on my own box (ex. Gentoo, NixOS), but I can also use precompiled binaries (ex. Debian, NixOS) while still having it be trivial to go find the exact source that went in to the binary package I downloaded (this has gotten even stronger with Reproducibility efforts meaning that I can even verify the exact source and build config that created a specific binary). The actual application software and OS are available as Open Source code that can be audited, with binaries available as a convenience, and the only remaining blobs (unwelcome but impractical to fix so far) are firmware blobs with relatively constrained roles (and on machines with an IOMMU we can even enforce what access they have, which is a nice mitigation).

Genode[1] is slowly approaching the point at which I can use it as a daily driver. I hope it makes it before Windows 10 goes away. It will be nice to never have to work about viruses, or spyware, etc., any more. It'll be like a trip back to the free spirited days of DOS and write protected floppy boot disks.

[1] https://genode.org/

I'd dig into genode[1], which is a capability based operating system. You'll likely see an upsurge in interest in capability based systems in the next decade.

[1] https://genode.org/

Yet another exploit that just wouldn't work on a well-designed system, such as Genode[0].

0. https://genode.org/

Have you looked at Genode? I don't think it's usable day-to-day yet but the concepts seem interesting.

Maybe you should go into details a bit more what you are planning and why. There are (and have been) several approaches here. The most prominent might be Genode (https://www.reddit.com/r/genode, https://genode.org) and joining forces there might be a better approach than starting another project that will get lost in the details and complexity eventually.