Live data from Hacker News

Helios: A distribution of Illumos powering the Oxide Rack

github.com

101–110 of 268 posts

Re: Helios: A distribution of Illumos powering the Oxide Rack

#102
post #89

Earlier quoted context omitted.

I'm excited to see how this compares to SmartOS. I'm pretty heavily invested in SmartOS in my personal infrastructure but its future, post-Joyent acquisition, has been worrying me. I really wish I did work for an org big enough to use Oxide's gear. Not having to futz around with bogus IBM PC AT-type compatibility edifice, janky BMCs and iDRACs, hardware RAID controllers, etc, would be so unbelievably nice.

I had been using SmartOS for a long time but finally had to bite the bullet and give up. I ended up deciding on Proxmox on a ZFS root and am quite happy with it.

the nice thing about the Proxmox + ZFS setup is that it works and is even recommended without using hardware raid controllers. Less headaches either way.

I recently wrote a guide [1] how to use proxmox with ZFS over iSCSI so you can use the snapshot features from a SAN

[1] https://blog.haschek.at/2023/zfs-over-iscsi-in-proxmox.html

Re: Helios: A distribution of Illumos powering the Oxide Rack

#103

Not that I'm not rooting for Oxide, but their product is still so niche and early stage that I can't imagine any actual businesses buying their stuff for a long time. They only just shipped their first rack to their first customer at the end of last summer and it's Idaho National Laboratory. State research institutions are basically the only entities positioned to gamble on this right now.

I work at a recently IPO'd tech company. Oxide was a strong consideration for us when evaluating on prem. The pitch lands among folks who still think "on prem.... ew".

Looks like a cloud like experience on your own hardware.

If only it were as cheap as dell...

Re: Helios: A distribution of Illumos powering the Oxide Rack

#104
post #99

Earlier quoted context omitted.

Quoting from an RFD co-authored by bcantrill and myself describing Oxide's policies around open source: > For any new Oxide-created software, the MPL 2.0 should generally be the license of choice. The exception to this should be any software that is a part of a larger ecosystem that has a prevailing license, in which case that prevailing license may be used. EDIT: I also am confused about why you are downvoted. Are t…

> [if Oxide-created software] is a part of a larger ecosystem that has a prevailing license, in which case that prevailing license may be used How does that work if the prevailing is BSD/MIT/ISC? You're saying that Oxide can then be licensed under BSD/MIT/ISC?

So I decided to cut off my quote but the next line has the answer:

> For example, Rust crates are generally dual-licensed as MIT/Apache 2.

We often produce components that we share with the broader open source world. For example, dropshot[1] is our in-house web framework, but we publish it as a standalone package. It is licensed under Apache-2.0 instead of MPL 2.0 because the norm in the Rust ecosystem is Apache and not MPL.

> You're saying that Oxide can then be licensed under BSD/MIT/ISC?

I am saying that we do not have one single license across the company. Some components are probably BSD/MIT/ISC licensed somewhere, and I guarantee that some third party dependencies we use are licensed under those licenses. That's different from "you could choose to take it under BSD," which I didn't mean to imply, sorry about that!

1: https://crates.io/crates/dropshot

Re: Helios: A distribution of Illumos powering the Oxide Rack

#105
post #74

Earlier quoted context omitted.

The main drawbacks to me are 1. No support for nested virtualization, so running a vm inside your vm is not available. This prevents use of projects such as kubevirt or firecracker on a Linux guest, and WSL2 on a Windows guest. 2. No GPU support If the base hypervisor was Linux, it would be way more capable for users it seems. I also wonder if internally Linux is used for development of the platform itself so they ca…

> I also wonder if internally Linux is used for development of the platform itself Developers at Oxide work on whatever platform they'd like, as long as they can do their work. I will say I am in the minority as a Windows user though, most are on some form of Unix. > so they can create "virtual" racks to dogfood the product without full blown physical racks. So one of the reasons why Rust is such an advantage for us…

Interesting thanks for the insight.

> I will say I am in the minority as a Windows user though, most are on some form of Unix.

Now i'm imagining Helios inside WSI - Windows Subsystem for illumos

Re: Helios: A distribution of Illumos powering the Oxide Rack

#106

What even is Oxide Computer? It makes no sense - it was publicized with all sorts of anti-blob, freedom, and posts about management engines and a sort of alternative to RaptorCS/IBM (which now has blobs again)... Yet most of that stuff is now buried/removed and Oxide Computer is just a hardware platform with unnecessary lock-in. For the bunker of the rich to be able to run their own mini-cloud? Sure. For anything els…

> Yet most of that stuff is now buried/removed Nothing has changed with regards to our anti-blob and pro-open source stances. I am not sure what you're referring to here. > with unnecessary lock-in. What lock-in are you referring to here? The way that things run on the rack is via virtual machines, you can run virtual machines on many providers. We even have a terraform provider so that you can use familiar tools ins…

I don't expect anyone to see my comments unless they're really looking since I've been shadow banned for many years now - so I appreciate your reply.

To be clearer regarding my questions:

- What happened to Project X (supposedly coreboot++ for latest AMD CPUs)? It seems dead, despite being more reported on than Oxide's attempts in working with AMD (to achieve the same outcomes, presumably - what's the difference?). Loads of well meaning people have approached this with virtue, innocence and skills; perhaps another approach is needed that fully respects the dynamic between the user, the chip manufacturers and the governments and banks they're in debt to.

- Does Oxide attempt to sandbox, completely remove or 'verify as benign' aspects like the PSP? For example, if someone could verify that the PSP cannot possibly be affected over the network, then peace of mind could be more affordable regarding things like supply chain attacks and bad actors with AMD/Intel/Apple management engine secrets.

Not referring to software lock-in, just hardware. And it isn't very nefarious like other hardware lock-in (serialization, see Rossmann Group). Just hardware on the rack-level: replacing oxide gear & upgrading oxide gear (not sure about repair, that could be easy). And if the offering were of a less blobby architecture, then many of us would be happy to pay a bit more for the hardware as a system. However, if the hardware platform is FOSS, then it won't be unnecessarily difficult to mix and match and integrate the Oxide gear with other DC-class gear.

Re: Helios: A distribution of Illumos powering the Oxide Rack

#107

Earlier quoted context omitted.

Quoting from an RFD co-authored by bcantrill and myself describing Oxide's policies around open source: > For any new Oxide-created software, the MPL 2.0 should generally be the license of choice. The exception to this should be any software that is a part of a larger ecosystem that has a prevailing license, in which case that prevailing license may be used. EDIT: I also am confused about why you are downvoted. Are t…

I had to look up RFD, and I like the idea! https://oxide.computer/blog/rfd-1-requests-for-discussion

Ah thanks! Yeah I should have mentioned this in my comment, thank you for adding the context.

By the way, you can browse public RFDs here: https://rfd.shared.oxide.computer/

I didn't include any links to any RFDs in my comments today because I have only been referencing non-public ones.

Re: Helios: A distribution of Illumos powering the Oxide Rack

#108

Earlier quoted context omitted.

Linux is a nightmare in the embedded/appliance space because one ends up just having platform engineers who spend their day fixing problems with the latest kernels, drivers, core libraries, etc, that the actual application depends on. Or one goes the route of 99% of the IoT/etc vendors, and never update the base OS and pray that there aren't any active exploits targeting it. This is why a lot of medium-sized companie…

CentOS wasn’t used in embedded systems.

Sure it was. So is RHEL.

Embedded isn't limited to devices equal or less powerful / expensive than the Raspberry Pi.

Re: Helios: A distribution of Illumos powering the Oxide Rack

#109

Earlier quoted context omitted.

> I also wonder if internally Linux is used for development of the platform itself Developers at Oxide work on whatever platform they'd like, as long as they can do their work. I will say I am in the minority as a Windows user though, most are on some form of Unix. > so they can create "virtual" racks to dogfood the product without full blown physical racks. So one of the reasons why Rust is such an advantage for us…

Interesting thanks for the insight. > I will say I am in the minority as a Windows user though, most are on some form of Unix. Now i'm imagining Helios inside WSI - Windows Subsystem for illumos

You're welcome. I will give you one more fun anecdote here: when I came to Oxide, nobody in my corner of the company was using Windows. And hubris and humility almost Just Worked: we had one build system issue that was using strings instead of the path APIs, but as soon as I fixed those, it all worked. bcantrill remarked that if you had gone back in time and told him long ago that some of his code would Just Work on Windows, he would have called you a liar, and it's one of the things that validates our decisions to go with Rust over C as the default language for development inside Oxide.

> Now i'm imagining Helios inside WSI - Windows Subsystem for illumos

That would be pretty funny, ha! IIRC something about simulated omicron doesn't work inside WSL, but since I don't work on it actively, I haven't bothered to try and patch that up. I think I tried one time, I don't remember specifically what the issue was, as I don't generally use WSL for development, so it's a bit foreign to me as well.

Re: Helios: A distribution of Illumos powering the Oxide Rack

#110

Earlier quoted context omitted.

It seems like the folks on HN tend to think the world runs on AWS (I'm not trying to say they don't have a huge market share), but many huge enterprises still run their own datacenters and buy ungodly amounts of hardware. The products that are on the market for an AWS-like experience on-prem are still fairly horrible. A lot of times the solutions are collaborations between vendors, which makes support a huge pain (fi…

OpenStack is pretty smooth sailing these days and I bet you it would be much cheaper to just get 3 FTEs for your OpenStack install than an Oxide rack

Where, exactly, are you getting these 3FTEs qualified to touch production OpenStack infra, for more than a year, where their aggregate cost is less than a rack of equipment?
Post reply on HN