Live data from Hacker News

SmartOS

docs.smartos.org

71–80 of 94 posts

Re: SmartOS

#71

great product. sadly dead! bought up by Samsung and now the briantrust has left to go work at a much cooler place

Not dead, still going strong under new ownership (MNX).

I did not know that! https://www.tritondatacenter.com/blog/a-new-chapter-begins-f...

Re: SmartOS

#72
post #68

Earlier quoted context omitted.

The reasoning can be simplified to two things. 1. Linux does not have the bhyve hypervisor ported 2. Maintaining a Linux distribution will require more effort and have more churn than illumos. Because Linux is just a kernel and users have to provide all of their own user space and system services there is a lot of opportunity for churn. Illumos is a traditional operating system that goes from the kernel to the system…

There's no churn in a graveyard, either. Debian's not much of a treadmill on stable; it's famous for it. The justifications for bhyve over kvm are similarly inscrutable; you can simply not build the code you don't want. Nobody's forcing you to use shadow paging. Comments like "reportedly iffy on AMD" are bizarre. What does "iffy" mean? This wasn't worth testing? Why should I, a potential customer, believe that these…

You may disagree with our rationale, but it is absolutely absurd to complain that that RFD 26[0] does not have "any meat." This is in fact dense technical content (10,000+ words!), for which I would expect a thorough read to take on the order of an hour. Not that I think you read it thoroughly: you skimmed to parts, perhaps -- but certainly glossed over aspects that are assuredly not your domain of expertise (or, to be fair, of interest to you): postmortem debuggability, service management, fault management, etc. These things don't matter to you, but they matter to us quite a bit -- and they are absolutely meaty topics.

Now, in your defense, an update on RFD 26 is likely merited: the document itself is five years old, and in the interim we built the whole thing, shipped to customers, are supporting it, etc. In short, we have learned a lot and it merits elucidating it. Of course, given the non-attention you gave to the document, it's unlikely you would read any update either, so let me give you the tl;dr: in addition to the motivation outlined in RFD 26, there are quite a few reasons -- meaty ones! -- that we didn't anticipate that give us even greater resolve in the decision that we made.

[0] https://rfd.shared.oxide.computer/rfd/0026

Re: SmartOS

#73

I am a huge fan of SmartOS. Back in the 2010s (around 2012), I was advocating its use in production at a small startup I worked. The SunOS kernel, ZFS, zero install, immutable core, convenient way to manage containers and VMs together - all of this looked great on paper, especially containers. In reality, I ended up running almost everything in VMs. The only thing worked well natively was nginx. MongoDB, Mysql, even…

You can get some of that with IncusOS ( https://linuxcontainers.org/incus-os/introduction/ ), which includes ZFS, immutability and manages both containers and VMs. I haven't used the OS yet, but have been enjoying Incus + Ubuntu.

Using incus heavily on Omarchy here and love it. I created a script to read yaml configs and create ephemeral incus containers with certain capabilities and certain directories mounted within. It's a wonderful experience for sandboxing Claude Code.

Re: SmartOS

#74
post #73

Earlier quoted context omitted.

You can get some of that with IncusOS ( https://linuxcontainers.org/incus-os/introduction/ ), which includes ZFS, immutability and manages both containers and VMs. I haven't used the OS yet, but have been enjoying Incus + Ubuntu.

Using incus heavily on Omarchy here and love it. I created a script to read yaml configs and create ephemeral incus containers with certain capabilities and certain directories mounted within. It's a wonderful experience for sandboxing Claude Code.

Interesting idea. How short lived are the containers?

Re: SmartOS

#75
post #68

Earlier quoted context omitted.

There's no churn in a graveyard, either. Debian's not much of a treadmill on stable; it's famous for it. The justifications for bhyve over kvm are similarly inscrutable; you can simply not build the code you don't want. Nobody's forcing you to use shadow paging. Comments like "reportedly iffy on AMD" are bizarre. What does "iffy" mean? This wasn't worth testing? Why should I, a potential customer, believe that these…

You may disagree with our rationale, but it is absolutely absurd to complain that that RFD 26[0] does not have "any meat." This is in fact dense technical content (10,000+ words!), for which I would expect a thorough read to take on the order of an hour. Not that I think you read it thoroughly: you skimmed to parts, perhaps -- but certainly glossed over aspects that are assuredly not your domain of expertise (or, to…

I did indeed read your document (twice, as I explicitly reported). I didn't address those parts because I found them better-supported. Instead, I addressed the parts I found confusing, and since your rebuttal here is just whining about what you think my behavior is, I continue to be mystified. That's okay; nobody expects you to explain yourself to me. If I thought it would help, I would suggest that perhaps a more effective defense would involve answering literally any of the questions I already asked. However, I don't appreciate accusations of bad faith based on your unwarranted assumptions about what I did or did not do and, bizarrely, what you imagine my motivations are. I'll just assume that the answers to the "why" questions I asked are rooted in similar wild-ass speculation.

Re: SmartOS

#76
I ran a fairly large SmartOS with project-fifo.net as the controller for a number of years . We also had the amusing time with Pluribus networks switching too. When they started they were also a Illumos based switchos . Bhyve on illumos came out of Pluribus and happened partly due to a number of FreeBSD users heckling the "SUN GODS" over why the official kvm port was a piece of shit .

In any case in the 6 years os smartos we never had any dataloss from failed disks, sure fifo and smartos had their warts but lx-zones works amazing well and i think we got Garrett D'Amore to go back to BSD land for some time . In the end we had to jump to VMWARE when Heinz gave up on fifo.

snarl/howl/chunter

https://project-fifo.net/ https://www.arista.com/en/support/pluribus-resources

Re: SmartOS

#77
post #75

Earlier quoted context omitted.

You may disagree with our rationale, but it is absolutely absurd to complain that that RFD 26[0] does not have "any meat." This is in fact dense technical content (10,000+ words!), for which I would expect a thorough read to take on the order of an hour. Not that I think you read it thoroughly: you skimmed to parts, perhaps -- but certainly glossed over aspects that are assuredly not your domain of expertise (or, to…

I did indeed read your document (twice, as I explicitly reported). I didn't address those parts because I found them better-supported. Instead, I addressed the parts I found confusing, and since your rebuttal here is just whining about what you think my behavior is, I continue to be mystified. That's okay; nobody expects you to explain yourself to me. If I thought it would help, I would suggest that perhaps a more ef…

...but your top post didn't ask any questions; certainly not ones that would justify a detailed answer.

It was several assertions, plus your admission of confusion. I mean, there are no stupid questions, but there wasn't even a question there, so I don't blame anyone for thinking you're communicating poorly.

Re: SmartOS

#78
post #68

Earlier quoted context omitted.

There's no churn in a graveyard, either. Debian's not much of a treadmill on stable; it's famous for it. The justifications for bhyve over kvm are similarly inscrutable; you can simply not build the code you don't want. Nobody's forcing you to use shadow paging. Comments like "reportedly iffy on AMD" are bizarre. What does "iffy" mean? This wasn't worth testing? Why should I, a potential customer, believe that these…

You may disagree with our rationale, but it is absolutely absurd to complain that that RFD 26[0] does not have "any meat." This is in fact dense technical content (10,000+ words!), for which I would expect a thorough read to take on the order of an hour. Not that I think you read it thoroughly: you skimmed to parts, perhaps -- but certainly glossed over aspects that are assuredly not your domain of expertise (or, to…

[deleted]

Re: SmartOS

#79
post #75

Earlier quoted context omitted.

You may disagree with our rationale, but it is absolutely absurd to complain that that RFD 26[0] does not have "any meat." This is in fact dense technical content (10,000+ words!), for which I would expect a thorough read to take on the order of an hour. Not that I think you read it thoroughly: you skimmed to parts, perhaps -- but certainly glossed over aspects that are assuredly not your domain of expertise (or, to…

I did indeed read your document (twice, as I explicitly reported). I didn't address those parts because I found them better-supported. Instead, I addressed the parts I found confusing, and since your rebuttal here is just whining about what you think my behavior is, I continue to be mystified. That's okay; nobody expects you to explain yourself to me. If I thought it would help, I would suggest that perhaps a more ef…

There is a reasonable explanation for the "foregone conclusion" flavour of the RFD that doesn't cast aspersions (quite as much as you are) on the authors:

It is simultaneously an assertion of the culturally determined preferences of a group of people steeped in Sun Microsystems engineering culture (and Joyent trauma?), and a clinical assessment of the technology. The key is that technology options are evaluated against values of that culture (hence the outcome seems predictable).

For example, if you value safety over performance, you'll prioritise the safety of the DTrace interpreter over "performance at all costs" JIT of eBPF. This and many other value judgements form the "meat" of the document.

The ultimate judge is the market. Does open firmware written in Rust result in higher CSAT? This is one of the many bets Oxide is making.

Frankly, I don't think Oxide would capture so much interest among technical folks if it was just the combination of bcantrill fandom + radically open engineering. The constant stream of non-conformist/NIH technology bets is why everyone is gripping their popcorn. I get to shout "Ooooooh, nooo! Tofino is a mistake!" into my podcast app, while I'm feeding the dog, and that makes my life just a little bit richer.

Re: SmartOS

#80
post #9
post #5

Earlier quoted context omitted.

It was acquired by Samsung, which is notoriously bad at open source. But the reason why it quietly faded into the background wasn't that. It was that Joyent's ex Sun people had an annoying elitism that made them not care about working with the community.

It was acquired again in 2022 by MNX [1]. [1] https://www.tritondatacenter.com/blog/a-new-chapter-begins-f...

Yeah, but at that point it had lost all the momentum it had, don't you think?
Post reply on HN