Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SmartOS

docs.smartos.org

Post reply on HN
Print view View original

61–70 of 94 posts

Re: SmartOS

#61

Post by ptribble »

jeffbee wrote: post #16
nZac wrote: post #3

> SmartOS is a "live OS", it is always booted via PXE, ISO, or USB Key and runs entirely from memory, allowing the local disks to be used entirely for hosting virtual machines without wasting disks for the root OS. Does anyone know if something like this is possible with Proxmox? I've got three servers I'm thinking of setting up as a small cluster and would like to boot them from a single image instead of manually se…

It depends on what "this" you meant, but in general the ways of netbooting an OS are many and varied. You'd have to declare what kind of root device you ultimately want, such as root on iSCSI. Personally, I feel that "smartOS does not support booting from a local block device like a normal, sane operating system" might be a drawback and is a peculiar thing to brag about.

SmartOS can, of course, boot from a local zfs pool, but it treats it logically as just another source for the bootable image. See the piadm(8) command.

Re: SmartOS

#63

Post by eduction »

znpy wrote: post #38
fsflover wrote: post #35

See also: Qubes OS, which is a desktop OS based on virtualization, https://qubes-os.org

This looks OT? judging by https://doc.qubes-os.org/en/latest/_images/qubes-trust-level... it looks very linux-centered.

No it's a very similar idea, just on workstations instead of servers. Qubes is built around "do everything in VMs" as SmartOS is "do everything in zones."

It's just a usage detail that Qubes may have a slightly higher percentage of linux containers vs smartos - at this point both are probably mostly linux containers on both OSes in terms of usage. (Qubes can also do Windows vms and they amped up support for this in the latest release, while smartOS has native zones and i believe you can do freebsd and maybe others on bhyve.)

Differences are many, including that Qubes has no concept of a "native" VM (dom0 is just a thin fedora wrapper around Xen) and that the global zone in SmartOS is significantly beefier than dom0 in Qubes, since Qubes offloads networking and usb io and bluetooth and sound to independent service qubes (VMs). And their development has been entirely separate. But they are spiritually siblings. I think it's an inspired comparison.

Re: SmartOS

#64

Post by gertrunde »

ptribble wrote: post #62
calvinmorrison wrote: post #30

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).

Nice to hear it's not dead, as the website and github repos do give that impression.

I'll have to give it a spin.

Re: SmartOS

#65

Post by gigatexal »

gr4vityWall wrote: post #57
re-lre-l wrote: post #24

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…

These days, you're indeed better off using Illumos/SmartOS to run GNU/Linux zones/VMs, rather than native applications, from what I hear.

If you’re just going to run things in VMs then QubesOS one might as well

Re: SmartOS

#66

Post by fennec-posix »

Glad to see SunOS/Solaris still alive in some form in the Open Source space. Had heard of Illumos and OpenIndiana, but didn't know about SmartOS. It's definitely won me over with the NetBSD pkgsrc package manager... Very nice.

Re: SmartOS

#67

Post by ironhaven »

stonogo wrote: post #52
tylerhillery wrote: post #46

Earlier quoted context omitted.

Oxide uses Helios, their own illumos-based distro: https://github.com/oxidecomputer/helios They’ve written up their reasoning in this RFD: https://rfd.shared.oxide.computer/rfd/0026#_comparison_illum...

After reading that document twice, I'm still not sure why they based it on Illumos. I strongly suspect it's just down to the personal preference of the founders, which is a perfectly valid reason. This document very much reads like "here are the pieces we will use, let's work our way back to why"

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 systemd layer. Illumos is also very stable at this point so most of the churn is managed up front

The choice is between porting a handful of apps to illumos or jumping on to the Debian treadmill while pioneering a new to Linux hypervisor. Would Linux have enabled a faster development cycle or just a easier MVP?

Re: SmartOS

#68

Post by stonogo »

ironhaven wrote: post #67
stonogo wrote: post #52

Earlier quoted context omitted.

After reading that document twice, I'm still not sure why they based it on Illumos. I strongly suspect it's just down to the personal preference of the founders, which is a perfectly valid reason. This document very much reads like "here are the pieces we will use, let's work our way back to why"

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 people are better at this than the established companies who have been producing nearly-identical products for twenty years? At the domain of development they're discussing why bother using an x86_64 processor from a manufacturer who does not bother to push code into the kernel you've chosen?

Again, it's their company, and if they (as I suspect) chose these tools because they're familiar, that's a totally supportable position. I just can't understand why we get handwaving and assurances instead of any meat.

Re: SmartOS

#69

Post by abrookewood »

re-lre-l wrote: post #24

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.
Post reply on HN