1. 9
  1.  

  2. 8

    It’s silly to assume Linux.

    There’s great options such as Netbsd rump kernels, to build unikernels on.

    1. 8

      It’s on tens of millions of machines, powers the clouds, and who knows how many smartphones. It makes sense to build on such momentum. In contrast, building risky projects on other projects with low popularity usually leads to the new project not going anywhere.

      1. 5

        At the end, marketing reasons, not technical ones.

        1. 8

          Partly marketing. The massive codebase, API, drivers, and Linux-compatible code are definitely technical reasons to build on it. Even vendors of separation kernels all did Linux VMs for such reasons.

          1. 11

            I think it is worthy to remember that a lot of unikernel stuff current in the wild is not Linux. Rumpkernel, mirage, and others are pursuing different approaches and they are being successful. Unikernels are very specialized and sometimes the things you listed as advantages are not where the focus of a given project it. It might be the case that mirage is more attractive to a project than some linux based solution.

            1. 5

              I think this point is under-appreciated. There are something like over 10 unikernel projects out there and almost every single research paper on them (which is not a small set) forks/tweaks existing projects into new ones.

              1. 4

                This kind of discussion is why I love this site. I’ve learned so much from the comments.

              2. 5

                they are being successful.

                I think this would be the main point of contention. The stuff I mentioned has massive uptake, reuse, contributions, and tooling. Unikernels themselves are barely a blip on the radar in comparison. The projects using them probably have nowhere near as much revenue and contributions as Linux-based products and projects. Successful seems a stretch unless they’re aiming for gradual progress in their tiny niche. It’s also possible I missed major developments while I was away from security research.

                This isn’t to discount any of their work. I like each project you mentioned. Anti’s work even happened with the system incentivizing him not to do it and griping at him for it. That’s an extra-respectable sacrifice. To further illustrate, if this was languages, this would be one group saying they were building their own platform gradually vs another saying it integrated with one or more of C/C++/.NET/Java/JavaScript’s runtime, libraries, and tooling. I’d see the latter getting more uptake for technical and marketing reasons even if there were painful consequences to that choice.

                All that said, I don’t know that I’d build a unikernel out of Linux. The Poly2 and OKL4 approaches of using pieces that help in isolating ways makes more sense if I was digging deep. OKL4 let you do native drivers/code, stuff in VM’s, and virtual drivers connecting to actual drivers in Linux VM’s. That last thing for drivers, syscalls, or apps is how I’d use Linux code on top of lightweight hardening for it. The unikernel or whatever could run beside it isolated somehow. IIRC, Poly2 folks were straight-up deleting code they didn’t need out of the OS. An eCOS-like, configurable fork of Linux that made that easy always seemed like a good idea.

                Too sleepy to say more. Just some random/organized thoughts on all that before I pass out. :)

                1. 2

                  Reading your first post again, I now get a better sense of what you call technical aspects.

                  So I stand corrected: then are not “more like economical then technical arguments”, but more akin to “technical arguments entangled with an economical factor”.

                  Related:

                  There are a few strong indicators that Linux is entering a new era and slowly but steady get more aspects of a microkernel

                  https://fosdem.org/2020/schedule/event/linux_kernel/

                  1. 4

                    “technical arguments entangled with an economical factor”.

                    You can say that. It works for unikernels a bit if you look at any startups taking VC money to make one happen.

                    Thanks for the link. I’ll check it out when I can.

                    1. 2

                      There are a few strong indicators that Linux is entering a new era and slowly but steady get more aspects of a microkernel

                      That talk did rub me the wrong way, for its vast ignorance of the state of the art.

                      They didn’t even seem to understand what a microkernel is nor what the point of the approach is, which is quite unacceptable past 1995, when the famed Microkernel Construction paper by Liedtke was published.

                      This is a trait I found to be very common among ignorant Linux fanbois, who mostly do believe that the so-called Tanenbaum-Torvalds Debate was somehow “won” by Linus. The reality of the situation is that, unfortunately, while technically competent in other areas, Linus himself is almost as out of touch with decades of microkernel advancement as the fanbois are.

                      1. 2

                        At some point, Linux taking over everything and anything hides smaller jewels around.

                        1. 2

                          Also in FOSDEM and much more interesting was this track.

                          I particularly enjoyed Gernot Heiser and Norman Feske’s talks.

                2. 3

                  Because a thing is everywhere does not mean it is good. Because it has a massive codebase does not mean it is good code.

                  1. 5

                    You’re talking abstractly instead of concretely about the specific project. It runs in everything from top-of-the-line smartphones to desktops to supercomputers. It must be good for something. The alternative(s) may be better in these use cases depending on what they’re trying to achieve, though. For instance, NetBSD’s codebase is supposedly designed to be very portable and easier to understand. Pieces of its code have been added to alternative OS’s before. I think QNX used its networking stack.

                    On the unikernel end, one person brought up NetBSD with several mentioning projects are building on other projects. This isn’t probably technical so much as the usual, social factors. In an interview, Anti just happened to be working on stuff for NetBSD, ran into problems, and built something that helped with those problems. Led to more interesting capabilities. Others built on what he already put out because folks often take the easy or obvious path. Others focused on leveraging a certain language building for theirs with that front and center. And so on.

                    The discussion we’re having is probably a different one than the unikernel authors had when each made their design decisions. ;)

                  2. 2

                    A massive driver and code base and support for everything under the sun feels more like “economical” than technical arguments. Also, a large part of that code base is written for POSIX rather than specifically Linux.

                    1. 9

                      Linux lacks stable driver APIs. That’s a strong argument against it.

                      1. 4

                        Linux has drivers, that is a strong argument for it. You don’t seem to like it very much I’ve noticed in earlier comments, I don’t really see why given that the thing is open and free and as such can be used as a source of inspiration at least, a source of code in the end for a myriad of applications. Nobody is forcing the use of Linux, if a BSD or one of those fancy verified systems I’ve seen you mention in earlier posts fits the bill those can be used as well. As long as the source is available for tinkering and the licence is amenable to that I’d say hallelujah and get hacking.

                        1. 4

                          The point of Unikernels is that you do not need that much drivers anyway, as most of the devices that will be available will be virtualised anyway. So the amount of existing drivers is not an argument. And as you will be working on the lowest level, lack of stable kernel API is a stronger argument than the amount of available drivers.

                          1. 1

                            Good point on virtualized hardware vs drivers.

                            So unikernels become about changing the API with the ecosystem from syscalls to generic virtualized driver interfaces (to wrap akin a libc wraps syscalls).

                            There is more work to do, more overhead to talk to neighbors (network, network everywhere, but also makes all IPC “network transparent”), but also not as much as if a whole kernel with the whole set of driver had to be written.

                            This depends on programming style also: do you use multiple small programs that get composed together (no, incompatible with unikernels), or big daemons that communicate with other big daemons (yes, compatible with unikernels)?

                            “You” is generic here, not particularly hauleth.

                            1. 1

                              Also, I do not think you can use an unikernel to act as a driver? Maybe though you can use an unikernel to be focused on hosting a driver for some hardware, then exporting a service (over the network? what else to communicate to an unikernel?) to the rest of the systems (thus not requiring the network).

                              This can also be achieved with a process though: for instance, plan9 mostly supports one type of filesystem: 9p, and for all other fs types, a daemon reads the /dev/… block device and export an 9p filesystem stream (let’s say an UNIX socket*) to mount as 9p.

                              • Plan 9 does not have UNIX sockets per-se
                              1. 2

                                Also, I do not think you can use an unikernel to act as a driver?

                                Refer to Netbsd’s RUMP kernels.

                                then exporting a service

                                You’ll find the more you advance in these thoughts, the closer you get to a pure microkernel multiserver design.

                                From my perspective, unikernels are the technical representation of realizing something is wrong with UNIX’s design then trying to reinvent the wheel, without doing the necessary prior research on what’s available out there.

                        2. 2

                          Now that gets technical and interesting! :)

                          Happy if you can hint me somewhere I can read about it, otherwise I’ll end-up facing it after some time…

                          1. 2

                            I don’t have any link at hand to some great article about the (bad, there’s also good) side effects Linux’s lack of driver APIs, but here’s some advantages of having driver APIs:

                            • As long as the driver API is still supported, the driver that works today will continue to work in the future. This is very visible on e.g. the BSDs, Illumos and Haiku (where BeOS drivers do work).
                            • As the interface between the driver and the operating system is clearly defined, which avoids families of bugs to do with misunderstandings there.
                            • This does also facilitate portability with other OSs, both by facilitating the porting to another API, or by a different OS providing the same APIs.
                            • And it does facilitate POLA and thus security, as with the right system design, the driver API can act as a barrier between the driver and the rest of the system, including hardware itself.

                            And a disadvantage that gets mentioned a lot is that having driver APIs supposedly facilitates closed drivers and removes the incentive for open ones. As BSDs have excellent hardware support, there’s much doubt about whether this is true, but it’s also possible that this is in some form facilitated by the popularity of Linux, which does not implement driver APIs.

                    2. 6

                      There are a lot of advantages to using a popular technology that have nothing to do with marketing.
                      Here is a partial list:

                      • Books, courses, and training are more readily available.
                      • Support is easier to obtain.
                      • Experts and consultants are easier to hire.
                      • It is less likely to disappear even if another technology replaces it.
                        COBOL, Fortran, IBM mainframes, MUMPS, OpenVMS, and XML are still available even though their popularity has declined.
                      1. -2

                        Die, XML, die! :P

                        1. 1

                          I downvoted myself on that one.

                3. 4

                  There’s another, more recent paper from this year’s EuroSys where the authors try to achieve something Unikernel-like using Linux configuration options. At some point you really have to wonder whether it’s still a Unikernel.