Rust in Illumos

This article really comes at some of the crux of packaging pains for many languages. The "distro ships the software" idea is something so many modern language toolkits are pretty far away from (and, as someone constantly burned by Debian packaging choices, something I'm pretty happy with as well). But without a good answer, there's going to be frustration.

When distros are charging themselves with things like security, shared libraries do become a bit load bearing. And for users, the idea that you update some lib once instead of "number of software vendor" times is tempting! But as a software developer, I really really enjoy how I can ship a thing with exactly a certain set of versions, so it's almost an anti-feature to have a distro swap out functionality out from under me.

Of course there can be balances and degrees to this. But a part of me feels like the general trend of software packaging is leaning towards "you bundle one thing at a time", away from "you have a system running N things", and in that model I don't know where distro packagers are (at least for server software).

> The development model of illumos is different from Linux and thus there are no Rust drivers in upstream illumos yet. But that is to be expected for new things. In our model, we take the time to mature new tech in a fork, and for rust, the Oxide fork has taken that role. In there, we have several drivers for the Oxide Networking stack that are in rust. Based on that some experience could be gained.

Soft forks are also good, but doesn't illumos have a stable driver ABI, such that you could just make your drivers completely independently? I thought that was how it had ex. Nvidia drivers ( https://docs.openindiana.org/dev/graphics-stack/#nvidia )

> The Debian approach of putting everything into one system and only having one version of each dependency is not feasible for a huge international community of people that develop together but never meet.

I find this to be overbroad and incorrect in the larger case.

I want one version that has been reasonably tested for everything but the parts I'm developing or working with. Having just one version for everyone generally means it's probably going to work, and maybe even has been tested.

For my own stuff, I am happy to manage the dependencies myself, but moving away from the debian approach harms the system in general.

> Missing support for shared libraries

Well, rust does support shared libraries. Call things by their name: what distros want is for all libraries to have a stable ABI. And I guess some sort of segmentation that the source of one library doesn't bleed into the binary output of another, and I think the latter part is even more tricky than ABI stability. Generics are monomorphized in downstream crates (aren't C++ templates the same?), so I think you'd either have to ban generic functions and inlining from library APIs or do dependent-tree rebuilds anyway.

> for one would love to have people help me with the new Installer[0] and with the package Forge[1]

Those repos really need some basic high-level information about what they are and how they work, the Forge doesn't even have a README.

[0] https://github.com/Toasterson/illumos-installer

[1] https://github.com/toasterson/forge

> The development model of illumos is different from Linux and thus there are no Rust drivers in upstream illumos yet. But that is to be expected for new things. In our model, we take the time to mature new tech in a fork, and for rust, the Oxide fork has taken that role.

This is silly. Virtually all illumos development is done by Oxide. There is no other upstream to speak of.

As far as I am concerned, illumos is Oxide.

Also, it's illumos, in lower case.