<p>We are happy to announce the <a href="https://github.com/unigornel/unigornel">unigornel project</a> to the Go and unikernel community.</p>
<p>Unigornel is a clean-slate approach to unikernels for the Go programming language. It is built on Xen's Mini-OS and a fork of Go. Our goal is to build a library operating system predominantly written in Go, much like the MirageOS project.</p>
<p>The project is still in the development phase. Only basic hello world examples work. A network stack is in progress. It is already possible to build a unikernel that replies to ping echo requests. Currently the memory management system is the most lacking subsystem.</p>
<p>This project was part of a semester-long university project and we would now like to make it available to the general public. We welcome all contributions, remarks or questions.</p>
<p>To build your first unikernel, read <a href="https://unigornel.org/doku.php?id=getting_started">Getting Started</a>!</p>
<hr/>**评论：**<br/><br/>bboozzoo: <pre><p>Interesting. Can you share the reasons for choosing Mini-OS over rumpkernel?</p></pre>hverr: <pre><p>Our goal is to create a highly specialized unikernel system. We aim to write as much as possible in Go. So we started with a very minimal operating system which was easy to understand and customize. Since rumpkernels are based on the full NetBSD kernel, it was not a very good fit for our objectives.</p>
<p>There are no other arguments for our approach. It's just the approach we took, and it certainly has its downsides. We don't claim it's more efficient or secure than the rumpkernel alternative, though it could be. It is however, more specialized, one of the characteristics of unikernels.</p></pre>bboozzoo: <pre><p>Fair enough. Nevertheless, interesting project, wish I had equally interesting projects back at the technical university I went to.</p></pre>koffiezet: <pre><p>Cool!</p></pre>taylorchu: <pre><p>Do you mind sharing the top N things about what you learn from building a kernel with go?</p></pre>hverr: <pre><p>Sure, I'll give you my personal top 3.</p>
<ul>
<li>Inner workings of the Go compiler and runtime (especially the C interface and the memory subsystem)</li>
<li>Lots of operating system concepts: virtual memory, scheduling, segmentation, TLS, ...</li>
<li>Small amount of hypervisor stuff: Mini-OS was already fairly complete in abstracting the communications with the hypervisor. It is still important to know what is happening behind the scenes when you issue a hypercall, but we barely had to interact directly with Xen ourselves.</li>
</ul>
<p>The whole process we've been through is <a href="https://unigornel.org/doku.php?id=presentations" rel="nofollow">quite well documented</a> and it shows nearly all steps we had to take to build the system.</p></pre>beertocode: <pre><p>The basic idea seems very appealing, but to be honest, I'm very unfamiliar with unikernels. What is the difference between unigornel and unik (<a href="https://github.com/emc-advanced-dev/unik" rel="nofollow">https://github.com/emc-advanced-dev/unik</a>)?</p></pre>hverr: <pre><p>I am unfamiliar with the unik platform, but as far as I can tell unik is some sort of Docker alternative for unikernels. It will use an external unikernel compiler to compile unikernels and manage them.</p>
<p>Currently, unik uses Defer Panic's gorump to build Go unikernels. Gorump is based on rumprun which combines the NetBSD kernel and modules to provide classic operating system services (scheduler, memory management, networking).</p>
<p>We have opted for a different approach, similar to that of the MirageOS project. Our aim is to build highly specialized unikernels, starting from a very minimal operating system. Unigornel could be incorporated into unik as an alternative unikernel compiler for Go.</p></pre>matiasbaruch: <pre><p>So cool!</p></pre>HectorJ: <pre><p>Seriously curious: what would you answer to <a href="https://www.joyent.com/blog/unikernels-are-unfit-for-production" rel="nofollow">https://www.joyent.com/blog/unikernels-are-unfit-for-production</a> ?</p></pre>hverr: <pre><p>Some of the points that are made in the article have some value, but I think the issues presented require a far more nuanced approach than the author takes. If you'd like me to elaborate on a specific topic please ask.</p>
<p>His main concern, that debugging unikernels in production environments is impossible or at least very difficult, is probably justified. I don't have any experience with unikernels in production. However, I don't see any reason why this problem (if it is indeed present) won't get solved in the future.</p></pre>HectorJ: <pre><p>Yeah, the debugging part seemed to be the best argument.</p>
<p>Though with good logging, metrics, profiling, and perhaps Delve-remote-debugging-enabled instances, this can be somewhat mitigated.</p>
<p>For performances, I'm thinking the only way to truly know is to benchmark on a case-by-case basis.</p>
<p>For security: he's basically saying it is not a silver bullet. Sure, but reducing the attack surface still sound like it should help.</p>
<p>For size: he seems to say that unikernel can be done badly and end-up bigger that some lean OS like Linux Alpine. Sure, everything can be done wrong, to be compared on a case-by-case basis again.</p>
<p>For porting/compatibility: </p>
<blockquote>
<p>hope everything you need is in OCaml!</p>
</blockquote>
<p>That seems stupid, unikernel are designed for single apps, which most of the time are written in one language. (BTW, I'm guessing Unigornel does not play nice with cgo, does it?)</p>
<p>So not much questions actually, it's just that your post made me discover unikernels (thanks) and I wanted the opinion of someone who already used them.</p></pre>hverr: <pre><p>Exactly.</p>
<blockquote>
<p>BTW, I'm guessing Unigornel does not play nice with cgo, does it?</p>
</blockquote>
<p>It's certainly possible to write some parts of your application in C or an other language, and integrate them with cgo. However, we don't provide a POSIX-like environment, so the possibilities are very limited.</p></pre>TotesMessenger: <pre><p>I'm a bot, <em>bleep</em>, <em>bloop</em>. Someone has linked to this thread from another place on reddit:</p>
<ul>
<li>[<a href="/r/unikernel" rel="nofollow">/r/unikernel</a>] <a href="https://np.reddit.com/r/UniKernel/comments/4oyuau/unigornel_cleanslate_unikernels_for_go/" rel="nofollow">Unigornel: Clean-slate unikernels for Go</a></li>
</ul>
<p><a href="#footer" rel="nofollow"></a><em><sup>If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads.</sup> <sup>(<a href="/r/TotesMessenger" rel="nofollow">Info</a></sup> <sup>/</sup> <sup><a href="/message/compose?to=/r/TotesMessenger" rel="nofollow">Contact</a>)</sup></em></p>
<p><a href="#bot" rel="nofollow"></a></p></pre>ptman: <pre><p>There's also <a href="https://github.com/deferpanic/gorump" rel="nofollow">gorump</a></p></pre>
