illumos day 2014: The Dream is Alive! Running Linux containers on an illumos kernel

I really enjoyed this talk[1] by Bryan Cantrill, part of which is about what it took to emulate Linux's syscalls from within SmartOS. It's lengthy, but enjoyable. One of the applications that they tried to port directly to before the emulation layer was htop, and he has a good rant about what that took because of its use of /proc and how that made porting it very difficult. Given that, I'm sure this wasn't easy. Kudos! [1] [VIDEO]

Video of this talk. [VIDEO] Though it is from 2014, it is interesting on comparison between linux and smartos(solaris). There is also a recent, shorter video [LINK]

Not sure what in the announcement you are referring to. The only thing it says about Docker is that it has brought move visibility to OS-virtualization. But, Joyent is infact working on docker support for SmartOS. They have revived an old Solaris feature called LX-branded zones that allows running linux binaries directly in SmartOS. Bryan Cantrill gave a talk on it at SurgeConf this year: video: [VIDEO] slides: [LINK]

Assuming the last question is earnest: while I think "amateur" is a tad strong, I do think that Linux suffers enormously from NIH; it remains the first system (or first Unix system, anyway) for many of its contributors, who seem to know no other way -- and this shows up all over the system.[1] In terms of how this has changed over time: if anything, it used to be much, much worse. For example, Linus' attitude on kernel debugging circa 2000[2] is not merely amateurish, and not merely irresponsible, but actively dangerous. While his attitudes have soften over the years, there still remain striking differences of engineering principle between Linux and other systems -- of which systemd is merely (in my opinion) one particularly egregious manifestation. [1] [VIDEO] [2] [LINK]

We have put (and are putting) a bunch of work into LX branded zones[1], and are at the point that they are working on an incredibly broad class of apps (64-bit and with on-the-metal performance). A concrete case in point: we recently ran the (amazing!) hundred language quine relay[2] in an LX branded 64-bit Ubuntu 14.04 zone on SmartOS.[3] As for ZFS support and Docker, it will be via sdc-docker[4], our (emerging) end-point for the Docker Remote API. The progress there has been swift and everything is being done in the open; expect to see something in production from us in this first calendar quarter. [1] [VIDEO] [2] [LINK] [3] [LINK] [4] [LINK]

Of course you can get more specific - for example, the Solaris kernel/libc combination is so tightly coupled that it is described as a "welded unit" [VIDEO] OpenBSD solved the Year 2038 problem by incompatibly changing the kernel and libc ABI in lockstep, which broke every single existing binary application using time_t - how's that for tight coupling... [LINK]

Funny you should mention that one in particular -- from our (SmartOS's) epoll(5) man page: While a best effort has been made to mimic the Linux semantics, there are some semantics that are too peculiar or ill-conceived to merit accommodation. In particular, the Linux epoll facility will -- by design -- continue to generate events for closed file descriptors where/when the underlying file description remains open. For example, if one were to fork(2) and subsequently close an actively epoll'd file descriptor in the parent, any events generated in the child on the implicitly duplicated file descriptor will continue to be delivered to the parent -- despite the fact that the parent itself no longer has any notion of the file description! This epoll facility refuses to honor these semantics; closing the EPOLL_CTL_ADD'd file descriptor will always result in no further events being generated for that event description. So while we do aspire to be bug-compatible, we're not about to compromise our principles over it. More details (or some of them, anyway) can be found in the talk on LX-branded zones that I gave at illumos Day at Surge 2014.[1][2] [1] [LINK] [2] [VIDEO]

I don't understand. If bcantrill's description of VDSOs (buried in this presentation: [VIDEO] ) is accurate, then they're just a way to make certain syscalls faster, when syscalls are already fast enough.