Hacker News Reader

Comment by codetrotter | Hacker News Reader

Solaris was ahead of its time. They had Zones, which was a container technology, years ago. Likewise, FreeBSD way ahead with Jails. Only later did Docker on Linux come into existence and then containerization exploded in popularity.

View on HN

In the early 2000s I rented a managed VPS based on FreeBSD jails. This was nice because you were root in your jail while the distribution was managed for you (security updates in particular), and you could still override any system files you wanted via the union file system. It was like the best of both worlds between a managed Unix account and a VPS where you can do anything you want as root.

AND you are running bare metal, without the virtualization layer overhead, which is quite nice especially in the early 2000s :)

My first project as a junior was to deploy Solaris Zones to replace a bunch of old SPARC machines. It's such a great tech and was a fun project.

Well, Docker did a few things differently then these older approaches. First, the one-process-per-container mantra, second the layered file system and build process and third, the "wireing together" of multiple containers via exposed ports. Zones and Jails were more like LXC and were mostly used as a "lightweight virtual machine".

Linux had a few different containerisation technologies before Docker blew up. But even they felt like a step backwards from Jails and Zones.

Personally I think its more fair to say that Linux was behind the times because containerisation and virtualisation were common concepts in UNIXes long before they became Linux staples.

While Solaris was/is one of my favourite UNIXes, back in 1999, HP-UX already had HP Vaults, which keeps being forgotten when Solaris Zones are pointed out.

We all try to do our best to forget HP-UX. I worked on it at Bristol-Myers Squibb in 1999 and hated every minute of it.

How much was HP-UX, and how much was the job itself?

40 60

I've said it before, and I'll never stop saying it.

Zones were awful.

Solaris had all of these great ideas, but the OS was an absolute pain in the ass to admin. And I say that from both sides of the SWAN firewall.

My only Solaris experience is using SmartOS. I find Zones there to be fairly easy to deal with. Is this just because SmartOS is papering-over the awfulness?

And ZFS, and DTrace.

Crossbow as well.

And STMF.

I highly recommend this talk, talking about Jails and Zones. Jails was first, but Zones took a lot of lessens from it and went further.

https://www.youtube.com/watch?v=hgN8pCMLI2U

Rereading the zones paper now makes me cringe, but I was in my 20s, what can I say. I think the argument we made that holds up is that this was designed to be a technology for server consolidation, and the opening section sets some context about how primitive things were in Sun's enterprise customer base at the time.

I have a lot of admiration for what Docker dared to do-- to really think differently about the problem in a way which changed application deployment for everyone.

Also I can tell you at the time that we were not especially concerned about HP or IBM's solutions in this space; nor did we face those container solutions competitively in any sales situation that I can recall. This tech was fielded in the wake of the dot-com blowout-- and customers had huge estates of servers often at comically low utilization. So this was a good opportunity for Sun to say "We are aligned with your desire to get maximum value out of the hardware you already have."

It's a blast to see this come up from time to time on HN, thanks.

> Rereading the zones paper now makes me cringe, but I was in my 20s, what can I say.

Still a nice paper!

> to really think differently about the problem in a way which changed application deployment for everyone.

Could that also have been done with Zones? In terms of the developer experience?

Seems to me Docker just thought about the develop-and-deploy pipeline differently.

I had done the packaging work (like what Docker has done) as part of experiments with Belenix. I used puppet and rpm5 (that I had ported to Belenix) to ensure idempotency, and used ZFS snapshots for the layers. Unfortunately, life happened and I did not take the work live.

Interesting, never heard of BeleniX. Funny how live turns sometimes. Docker was open-sourced because a PAAS company almost went bust and exploded.

Yes, technology wise, I think it could have been done; once I left Sun/Oracle I stopped paying attention, so I can't speak to what else was done later.

Please take some pride in your work. I ended up DTracing Zones and I find your ideas to be excellent.

Historically, HP-UX 10 Vaults might have been there first.

probably lynn wheeler will tell you cp/67 was there first: https://www.garlic.com/~lynn/2003d.html#72

CP-67 was a hypervisor, a different model altogether to the chroot/jails/zones/linux namespace evolution, the sidequest of HP Vaults and various workload partitioning schemes on systems like AIX, or the grand-daddy of chroot line, Plan 9 namespace system.

yes, i agree, except that doesn't chroot predate plan9 by almost a decade?

Thank you, somehow I missed the part of the history! Yes indeed, chroot() starts in 1979 patches ontop of V7 kernel. Plan9 namespaces probably evolved from there as Research Unix V8 was BSD based.

thanks! i didn't have any idea 8th edition was bsd-based

Certainly, I was only focusing on the UNIX side of the history.

understandable!

From what I have read, it was nowhere near as comprehensive and integrated. I only read about them once, so I don't really know.

I would say it was easy enough for traditional UNIX admins.

We used it for our HP-UX customers in telecoms, using our CRM software stack, based on Apache/Tcl/C.

Solaris is still ahead of its time on many things. I wish it were worth porting eBPF to Solaris.

Still the only Unix where SMB works.

> I wish it were worth porting eBPF to Solaris.

What on Earth for? Solaris has DTrace.

cgroups came only three years after zones, not a huge difference.

Reply on news.ycombinator.com