amirmc

There are also more links/resources on the OCaml website.

http://ocaml.org/learn/books.html

That was wonderful. Thank you for sharing.

> "ISDS exist because national courts are not always unbiased, and may unduly favour the host nation."

As opposed to favouring ... what, exactly?

I found a list at http://fbinfer.com/docs/infer-bug-types.html

More OCaml code coming out of FB. Can add this to the list, which includes, Hack, Flow and Pfff [1].

The kinds of bugs it finds are listed at: http://fbinfer.com/docs/infer-bug-types.html

It's interesting to see how building tools with languages like OCaml can reduce bugs for teams, without them having to change the language itself. I do wonder what things would be like if such languages we're used directly more widely.

[1] http://ocaml.org/learn/companies.html

On point 4, I'd wonder that it's because the author is British. There's a whole nervousness about referring to anyone using race as a differentiator (lest you be considered racist?). To the point where someone will describe someone else by imaginative means even when 'the black guy with glasses' would actually be the most succinct way.

Off-topic but have you come across Irmin? It seems like something you might be interested in.

https://mirage.io/blog/introducing-irmin

For those who are interested in following the discussion that the maintainers/devs are having, you'll find it starting at:

http://lists.ocaml.org/pipermail/platform/2015-June/000595.h...

I've recently become really interested in things around the periphery of secure systems keys etc.

For example in this scenario, what happens if one of key-holders dies? Presumably the remaining are enough for a quorum, but say something bad happens at a conference that many of them are at? It makes me think of why the President and Vice-president aren't in the same place at the same time.

In this case, I expect it would be possible to start again and select a new group of keyholders but what downstream effects would that have? In any case, I'm looking forward to seeing this progress.

(Incidentally, one of the contributors is also an author of the OCaml TLS stack.)

Title comes from their blog post, which does make sense in that context (it's their first post). Doesn't work out of context though.

> "In the end we should have just had Michael do the whole name picking in thirty minutes and been done with it."

I think this overlooks the value of having everyone feel that they were involved/heard. Maybe going through this process at least once is a kind of rite of passage. Next time around, no-one would be as wedded to their ideas and the process would be quicker.

It's still there (currently at number 7).

https://news.ycombinator.com/item?id=9660339

> "There's only one way to be safe. And that's to collect only minimal amounts of data for minimal apps."

No. The only way to be really safe is to go live in a cave, not to have any friends and never go anywhere near any tech ever again. I'm sure you can tell that I don't consider that to be much of an option.

It's unhelpful to label 'data collection' as the source of the problem as 'collection' happens everywhere in our interactions with the world. There are valid arguments and discussions to be had about who really owns that data. It may well be about me, but that doesn't necessarily mean that it's mine. I'd say the majority of people are only just beginning to understand that a discussion needs to take place even though technical folks have known this for a long time.

One solution to the 'ownership' problem is to make it possible for everyone to run their own infrastructure. i.e. have their own 'backend' that apps/services can be installed into, which their end-devices can then connect to. This is already possible for the technically savvy but a lot of work is needed before I feel we can trust such systems (I'm working on approaches to this [1,2], based on unikernels).

In the meantime, I applaud business models that are not built around profiling (which is the crux of the issue cf. advertising). They're the only ones where the incentives have any hope of aligning.

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

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

So it happens the other way around. Pinterest buys Etsy. ... I can actually imagine that working.

For anyone interested in finding out where OCaml is taught, there's a page at http://ocaml.org/learn/teaching-ocaml.html

Useful/interesting discussions are sometimes reason enough to upvote.

MirageOS is more than just a research project. It's deployed in the wild by folks who weren't active researchers. I'd certainly call it an open-source project in its own right.

e.g. http://amirchaudhry.com/unikernels-for-everyone/

You can also visit the page on a16z that will let you download a free ebook of the old posts. There are also links to other sites that have archived the content (including this submission).

http://a16z.com/2015/01/09/pmarca-blog-ebook/

I'd still take issue with that but at this point we'd end up discussing the semantics of 'entrepreneur', 'startup' and 'business'.

Indeed. Just consider all those "Our incredible journey" posts that used to come with news of an acquihire. Would those early customers consider it a 'success'?

> "... entrepreneurs start businesses with the express purpose to be sold to a large company. That's the goal from day #1."

This is a rather narrow view and is not necessarily true. Plenty of people start companies to solve (or even explore) problems. Liquidity events (M&A, IPO, etc) are not always the end-game.

You're assuming that HN isn't keeping track of how often you downvote (or any patterns). Without knowing the set up, it's difficult to infer much. Of course, revealing that info might lead to gaming the system.

What you're describing isn't clear. I assume you meant to say "If someone comments on your negative comment ..." otherwise it appears you're describing how upvotes are generally expected to work.

I expect HNs algos could spot such a comment thread quite easily (thereby avoiding what you've described). That doesn't require a new user feature.

Why not leave the reason as a comment instead? I don't really see a need for a new feature.

> "Some problems that we all have in understanding how nature works, have more to do with our conviction that our intuitions are correct, despite the fact that our intuitions are often flawed in areas of experience outside of our normal environment."

This really stood out to me. It's applicable to more than just the current example.

If you could give everyone their own 'personal cloud', without having them become sysadmins, then it's possible (of course, that's not easy but it's also why it's a valuable goal). The work under Nymote has a longer term vision so not ready to help people just yet -- some more detail at http://nymote.org/blog/2015/brewing-miso-to-serve-nymote/

In this instance, I bet sandstorm.io could come up with a transition for Ninja Blocks users. I hope they think about it.

Although this is a shame it is yet another sign (for me) that the 'Internet of Things' is going to be DoA if we have to also rely on them for a backend cloud service. Most of these devices could be run in a completely decentralised way, such that if the company goes under, your device is hardly affected. e.g. I don't expect my light switches to stop working if the parent company gets acquired or shuts down.

There are real challenges to making distributed systems easier to build but I'm working with others on that c.f http://nymote.org and http://openmirage.org.

Some related links are:

MirageOS: https://mirage.io/

One VM per URL: http://www.skjegstad.com/blog/2015/03/25/mirageos-vm-per-url...

Heroku for Unikernels (pt2): http://amirchaudhry.com/heroku-for-unikernels-pt2/

What FUD? There appears to be more FUD in your comment than I've seen from any of the unikernel projects.

Most of the claims you've made seem to be coming from the existing paradigm of how people write code for the cloud. If you're determined to stay in that mindset, then unikernels will probably not make much sense to you. The whole point is to reevaluate our assumptions about developing for cloud-native environments, which leads to different approaches (many cloud-services are already single-purpose). No-one is claiming that unikernels are some kind of panacea but they are a useful addition to the toolbox.

Also, if you really want to compare security and vulnerabilities, then you should consider things like TCB and look at CVEs for both Xen and Linux. The way you describe it is almost disingenuous. The following talks have useful discussion points.

https://fosdem.org/2015/schedule/event/zombieapocalypse/

https://media.ccc.de/browse/congress/2014/31c3_-_6443_-_en_-...

I don't think anyone on the MirageOS team is a language zealot. Almost by definition, they'll be polyglots so understand the trade-offs you make when using different languages.

It turns out that OCaml is pretty good for systems programming, hence projects like MirageOS can survive and grow.