amirmc

History is always written by the victors. What does the western world think of colonisation, wars etc?

It's still early days for most people to make deep comparisons.

I'd say the best thing is to actually try a few of them out. MirageOS has tutorials and I'm sure some of the others do too. I doubt enough people (outside the teams themselves) have had a chance to build useful things with each approach.

Folks interested in this should also check out MirageOS (http://openmirage.org -- I'm a contributor).

There's also a good series of unikernel articles that give more background. http://www.linux.com/news/enterprise/cloud-computing/821243-...

> "You don't need to stick ads IN the app to monetise it."

Exactly. I'm always surprised when people think it's the ads themselves that matter. It's the behavioural data and profiling that's valuable. With that information, you can place targeted ads elsewhere.

I'm sure most users still don't realise that WhatsApp is an FB product now.

How far should we take that maxim? It implies that no one should ever attempt this, but that leads to nothing new (unless you are first recognised as a crypto guru -- but how could you become one?).

I think it's worth drawing a distinction between the algos/maths and attempts at implementations. Otherwise we wouldn't have things like OCaml-TLS and others.

http://openmirage.org/blog/introducing-ocaml-tls

I think the GP was pointing out that it was effective. Sometimes validity (or even reasonableness) has nothing to do with it (cf. influence of special interest groups in politics).

They were not ideas. They were working versions.

At some point you have to put your ideas/implementation/whatever out into the open (you might even have to advertise its existence). At that point, anyone better resourced than you can probably just mimic your work.

What alternative does anyone really have?

I find your comment quite odd. It's like saying people don't need email anymore -- which is ridiculous. So as long as people are using email, there will be the need for groups of them to coordinate over email. Mailing lists are one answer.

And what on earth does 'organic growth' of mailing lists even mean in this context?

Had you been commenting about mailman specifically, then I guess I could see your point (it's one product in this space) -- generalising to all mailing lists ever seems absurd.

You describe those options as though they are at opposite ends of the same spectrum. I'd say they're somewhat orthogonal.

Be careful what you mean by 'mostly'. Though there may be many small outfits that use it for this particular features, there are others that use it very differently (and at completely different scales). Examples such as Facebook, Jane Street and Esper come to mind. There are likely many other companies who have less of a web-presence too (cf defence industries, as mentioned in the slide deck).

Given what you've described, I think you might be interested to look further at Irmin [1]. It's not quite ready for prime-time but certainly stable enough to kick the tires.

Regarding commercial uptake, the nice thing about the library approach is that companies get to pick and choose the components they want (without even going 'full Unikernel'). For example, I'm aware of the cohttp library having commercial users. The real issue is legacy code but I mostly sidestep that when I write (but we're well aware of it).

Interesting that you mention MirageOS in containers. I don't see any reason the two can't be compatible but it would good to hear more about what you'd like to achieve (or how you'd expect it to be in terms of workflow).

[1] http://openmirage.org/blog/introducing-irmin (I think it's time we put together an overview page with all the links).

Documentation often gets cited as the main 'semi-techncal' thing to do for an open-source project.

However, I disagree with the point that moribund projects could be revitalised this way. If the people writing the code have little interest in explaining to other people like themselves how to use it then IMHO writing additional text for less involved people is not going to be very impactful.

Your second point about myopic docs is spot on, though. A human-readable summary can be invaluable but it involves getting your head around what already exists first -- that requires some will from the developers in the first place.

What about all the over-hyping that goes on? Or outright false/misleading advertising? Sometimes you only find out you're an 'early adopter' when the product's in your hands.

Even early adopters expect the products they use to do the thing advertised. I don't believe there are many paying customers who'd be happy with, say, a lighting system that only works half the time.

The main difference from my perspective is that the bar for 'Minimal' and 'Viable' in hardware is much higher than for software.

> "Is there a need for someone like me in any open source projects and if so, how do I contribute?"

This is an excellent question. I doubt that anyone is going to turn you away but there are some things you should probably consider. I'm drawing this from my experience with MirageOS [1] and OCaml-related projects I've been involved with.

1. Why are you doing this?

After you've figured out what you care about you should still ask yourself why. Is it CV points? New experiences? Specific project goal? To stretch yourself? Accolades?

If you can be upfront with yourself about what you're hoping to get from contributing then it makes it a little easier to frame what it is that you can offer. As I said above, no-one's going to deny a new contributor but having a flaky contributor is also frustrating. Most projects won't have any kind of 'onboarding' process so knowing why you want to do this at all will help you create your own.

In my case, I can see how a new method of building software (with unikernels) could be transformational. I also want to know that I'm helping to promote the creation of better software for distributed systems. There's a specific use-case I want to be able to highlight too (see point 2).

2. What do you actually care about?

This matters more than you might think. If you're only peripherally interested in a project it'll be difficult to remain motivated, especially if you already have a full-time job. This is more than buying into a project's wider goals (assuming it even has any stated goals) but more about what would actually drive you to continue contributing. It's somewhat related to the above point but a little more specific.

Do you like writing docs? How about blog posts or giving talks? Or doing tests? Triaging bugs? Helping users with issues? Organising stuff (community/devs)? Small project or a large one? Move fast or be considered?

Can you match any of these up with gaps you see in the project?

From my point of view, I want to work towards distributed systems that empower users [2] and I can see how parts of the project can get me there [3]. I wanted to write more (personally), I care about good organisational practices/structures/communication and onboarding new people. Those are the things I tend to think about and it's led to me coordinating fortnightly calls, curating a set of Pioneer Projects and writing a lot more.

3. How will you build credibility?

Since you're not contributing code, it's almost inevitable that you'll end up in bike-shed territory (though even code has plenty of bike-shedding). Everyone has an opinion so why would anyone listen to yours?

I think this is why 'documentation' (inc tutorials) gets touted as the first, semi-technical way to get involved with a project. It's rarely threatening to the existing team and provides immediate value. Many of the other things you mention in your list provide long-term value but they need to welcomed. Again, no-one will state that they don't need these things but that doesn't mean that any offering will be accepted. If you're willing to believe that customers can't always articulate what they really want, then the same applies to any open-source project :)

I don't have a pithy answer for this. I think it just takes consistent behaviour over time. Be reasonable and try and back up any claims but don't be afraid to stand firm.

4. Just start!

All of the above points may seem cautionary but it's best to just get involved. Open source projects can be pretty awesome and there's nowhere else where I've been able to be as transparent about what I'm working on. There's probably a useful blog post in this comment so I may write my thoughts up properly some day (as opposed to this brain dump).

[1] http://openmirage.org

[2] http://nymote.org/blog/2013/introducing-nymote/

[3] http://amirchaudhry.com/brewing-miso-to-serve-nymote/

Personally, I'm not a huge fan of the Unikernel vs Docker natrative but it feels inevitable given how the Docker crowd claimed the 'death of the hypervisor' in their early days. These two tools could probably play quite nicely together.

With that mini-rant out of the way, the really interesting thing will be examining the differences between Unikernel approaches. So far, there hasn't been scope to do that as it's been more about rasing awareness of the space in general.

And a share of gross revenue, at that. I'm sure all these definitions are written in the studio's favour. Apparently, Stan Lee never got anything for his creations either (and Spiderman grossed $800M+).

https://en.wikipedia.org/wiki/Hollywood_accounting

> "But in any real Xen deployment I'm aware of, Linux is running in dom0 anyway."

It's still separated from the the domUs via the hypervisor. So an exploit in one place isn't easy to escalate into a breach of the whole system. This is a security benefit.

From the rest of your comment, I get the impression that you care more for speed/convenience (even the post you link to is about speed). That's a perfectly reasonable position and the examples you provide are perfectly valid for different threat models (i.e. running your own trusted code on your own trusted server). Deployments to the cloud (or large scale teams) do need to consider different threat models.

As avsm points out in a sibling comment, you can target numerous back-ends with MirageOS -- meaning that you can compose a system that suits your particular needs.

Edit: the comment I replied to has been deleted. It referred to legacy code and linked to OSv. I'll leave this comment here anyway.

-----

The nice thing with multiple Unikernel approaches is that you get to choose your trade-offs. MirageOS takes a clean-slate approach and generally concerns itself with safety and security. OSv allows you to work with legacy code, and Rump Kernels help to break up the existing stacks. There are also others that have a preference for speed etc. Depending on the task at hand, you could choose whichever suits your needs/problem-domain.

The upfront cost you refer to only comes from having to port legacy code. However, building new services this way doesn't carry that cost (apart from potentially learning a new language -- but I hope people see that as a useful skill, regardless).

So with a whole bunch of additional optimisations (not out-of-the-box) you can get an order of magnitude improvement. Unikernels are at least another two orders of magnitude faster than that (~300ms), without any optimisations.

Upcoming paper: http://anil.recoil.org/papers/2015-nsdi-jitsu.pdf

The projects themselves have progressed since this article and MirageOS is doing pretty well [1]. There was also a recent HN discussion on an experiment to create (and run) one VM per URL, which was built via MirageOS [2].

Although there are many applications of the unikernel approach, a longer term goal that I'm particularly keen to work towards is the idea of distributed personal clouds. Enabling people to run their own infrastructure, without becoming sysadmins, would be pretty cool [3]. Of course, there are other ways to achieve this but unikernels offer certain benefits.

[1] http://openmirage.org (I'm involved with the project).

[2] https://news.ycombinator.com/item?id=9263146

[3] http://nymote.org/blog/2015/brewing-miso-to-serve-nymote/

> "I don't think there are many companies who have the depth of info security knowledge that Github can draw upon."

I recall at least two vulnerabilities that GitHub was exposed to. The mass-assignment one from Rails (which they didn't fix until after they were the poster-child for it), and the cross-site one, which prompted them to use github.io.

I suspect their security teams are better now but you're still taking it on faith. By using 3rd-party services, you are increasing your exposure, not diminishing it. Someone who wants to attack you specifically will do so regardless.

A large part of your blog post seems to be premised on the difference between incoming cash and outgoing cash. That only works as long as the people you're paying will accept net-30 (or have it imposed on them) -- Amazon was a great example of this but their suppliers also got wise to it.

In the current scenario, all those instacarts, eat24s, etc are also looking to get paid first, so this advantage should evaporate (leaving only those which are systemic -- ie banks, processors, etc).

Thanks. In hindsight that should have been an obvious place for me to look.

> "What is too heavyweight is a VM image of a conventional operating system distribution with all of the baggage that it brings."

Indeed. I didn't realise that Docker/Container folks had ever said VMs were too heavyweight. Is this linked anywhere?

> "Would these fine-grained unikernels also run well on KVM, VMware ESXi, Hyper-V, or bhyve (FreeBSD's new VMM)?"

We've been asked this before and for KVM at least, it just boils down to someone suitably motivated to write the boot and VirtIO code [1, 2]. If anyone's interested in this, we'd love to hear about it [3]!

[1] http://lists.xenproject.org/archives/html/mirageos-devel/201...

[2] http://lists.xenproject.org/archives/html/mirageos-devel/201...

[3] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageo...

The fun thing about this is that you can try it out locally and apparently it took (about) an afternoon to put together (most of the work is in rewriting URLs).

This kind of fast experimentation is going to lead to some really cool things happening with unikernels.

If you can hook in FB data then you might be able to figure out so much more about the users/visitors (what's more likely to work for a given visitor).

I'm impressed by the product/service but I'm so jaded about 'being gamed' that I'm always cynical when I buy online.

This is quite frustrating. There's a lesson here in keeping mirrors of projects in multiple places. That things can be 'disappeared' from GitHub is because not enough people do this anymore.

Why? Because you find it unfathomable that people would do this? Do you also believe that people never fall for 419 scams?

http://en.wikipedia.org/wiki/419_scams

What you've stated is exactly why they can can be subverted. Pretty much every influence, sales, negotiation book will cover these mechanisms. None of this is new.

If you want the short version, read the 6 principles that Cialdini reduced them to.

http://en.wikipedia.org/wiki/Robert_Cialdini#6_key_principle...

> "Observing this, and portraying it as something new and abusable is just silly."

Err... no, it is not silly. Techniques like these are routinely used to separate people from their money -- and in the digital age to get people to share ever more information about themselves. Being aware that this is a 'thing' means you can come up with counter-techniques to cope with it. Or just let yourself be manipulated (I guess that should be counted as an option).

Also worth looking at the list of cognitive biases as they're commonly exploited too.

https://en.wikipedia.org/wiki/List_of_cognitive_biases