omnios-build VS nixpkgs

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.

I don't think so. The article is probably intended for the Nix community, so the author doesn't need to convince HN that something is going on. If as an outsider you are interested then you need to look into it yourself, the community has no obligation to make their internal conflicts legible to the outside world.

As an outsider myself, it certainly looks like something is going on as more than 20 Nixpkg maintainers left in a week: https://github.com/NixOS/nixpkgs/issues?q=label%3A%228.has%3...

https://github.com/NixOS/nixpkgs/commits?author=neon-sunset

I see two signers in the top 6 displayed on https://github.com/NixOS/nixpkgs/graphs/contributors

For a single file script, nix can make the package management quite easy: https://github.com/NixOS/nixpkgs/blob/master/doc/languages-f...

For example,

```

Yes, Nix doesn't actually ensure that the builds are deterministic. In fact it works just fine if they aren't. There are packages in nixpkgs that aren't reproducible: https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aiss...

I'm not familiar with Bazel, but Nix in it's current form wouldn't have solved this attack. First of all, the standard mkDerivation function calls the same configure; make; make install process that made this attack possible. Nixpkgs regularly pulls in external resources (fetchUrl and friends) that are equally vulnerable to a poisoned release tarball. Checkout the comment on the current xz entry in nixpkgs https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/comp...

NixOS uses a monorepo and I think everyone's love it.

I love being able to easily grep through all the packages source code and there's regularly PRs that harmonizes conventions across many packages.

Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing.

https://github.com/NixOS/nixpkgs

In this specific case, nix uses fetchFromGitHub to download the source archive, which are generated by GitHub for the specified revision[1]. Arch seems to just download the tarball from the releases page[2].

[1]: https://github.com/NixOS/nixpkgs/blob/3c2fdd0a4e6396fc310a6e...

[2]: https://gitlab.archlinux.org/archlinux/packaging/packages/ib...