Comment by npx | Hacker News Reader

Comment by npx | Hacker News Reader

Competition from Linux has become very stiff. For me, Kubuntu 19.10 delivers on all of the promises that OpenSolaris made back in the day. My laptop has two 1TB SSDs in a ZFS mirror. Docker works as you'd hope, creating a new ZFS dataset for each container. I have remarkably good hardware support, everything just works. I'd say that the user experience rivals or beats MacOS or Windows, although at this point I'd say it is largely just a matter of preference.

Linux still lacks the multitenant security guarantees of Solaris Zones but this isn't so bad. Hard multitenancy is a problem that only concerns a fairly small subset of people and even then, there are solutions. You can do hard multitenancy with Linux containers (namespaces/cgroups to be pedantic) if you start restricting the system call table. There is also Firecracker[1] which obviously isn't as efficient as Zones (because it uses VMs), but is proven in production and does provide additional security guarantees.

The technical advantages of Illumos are outweighed (or rivaled) at this point, in my opinion. When I show people things on my laptop, I always end up talking about the desktop cube in KDE or my neovim/tmux/zsh setup. Due to ZFS snapshots and the power of zfs send/recv, I expect this system installation to last for years to come. No more reinstalls, we're good, this operating system thing is covered.

1: https://github.com/firecracker-microvm/firecracker-container...

To get off into the weeds a bit... I've actually spent quite a bit of time using Illumos. The epicenter of The Suck begins, in my mind, with the effort involved in actually building the system.

GCC (and Clang) obviously didn't exist back in the day, so none of the Makefiles for the base system are written for a compiler that was released in the past 20 years. There is actually a wrapper that takes SunCC arguments and calls GCC... so that kinda works, right?

Okay, well, yes. It works. But then, it all kinda starts snowballing. There is a big investment in a debugger from the 1980s which can't unwind stacks without frame pointers. So... we have to emit frame pointers. Okay, that works. Because we care a lot about this, we'll also ensure that all function arguments promoted to registers are also copied to the stack so we can always look at them. Okay, fair enough.

Is this idiosyncratic enough for you yet? Okay, let's step it up a few notches and actually implement the Linux system call table on top of this. Wait, what? The struggle is real.

This is all technically brilliant in any number of ways, but I have things to do this week. All of the man years of effort spent on Linux and the surrounding ecosystem have actually solved a lot of real technical problems and solved them incredibly well.

Like any large scale project with a long history, we certainly have our share of eccentricities. We're working on moving the argument translation from cw (our "compiler wrapper") more directly into the Makefiles themselves.

I would note that both Studio and GCC are both older than 20 years if you're going by the date when they were first released; releases of both that we were using (Studio is no longer in use) were released more recently than 20 years ago. We currently recommend people use GCC 7.3 or 7.4 to build the OS, and those were released in the last two years.

The debugger I believe you're talking about is MDB[1], which is emphatically not from the 1980s. It was started as a project in the lead up to Solaris 7, as I understand, which was closer to 2000. GDB was first released in 1986, but I don't think either of these dates are a meaningful observation: they're both actively maintained debuggers with a different approach and a different focus.

There are lots of arguments for, and presumably against, the use of %rsp as a frame pointer. They're all trade-offs. The amd64 architecture is, at least, less register starved than 32-bit x86. Stack unwinding with correct use of the frame pointer is substantially less complex than using the unwinding information provided by DWARF sections. This helps a lot when making the stack() and ustack() DTrace routines available, as they need to unwind the stack in an extremely limited context in the kernel. Saving arguments to the stack (-msave-args) is another trade-off tilting the scale toward a better debugging experience, because yes, we do care a lot about that as a project.

At the end of the day, you should use whatever makes you happy and solves problems for you. Those of us who work on illumos, use it at home, or ship it in products, are doing so for just that reason.

[1]: https://en.wikipedia.org/wiki/Modular_Debugger

Reply on news.ycombinator.com