The textbook of the draft can be accessed at:

https://ocw.mit.edu/resources/res-6-011-the-art-of-insight-i...

The process isolation is very useful but they've got a point, why we should run million lines of code until we get to the point to run a single web server? Have we ever asked our self why the operating system which its only responsibility is running a web-server should take 300 seconds to boot?

Boot time is rarely an issue when working with long running daemons such as web servers.

We run the millions of lines of code because web servers typically serve up web applications which in turn depend on a whole host of infrastructure being available. The millions of lines of code support all the possible hardware that you could throw at it (and so you can save some if you compile your kernel just for that purpose), and if you know exactly which services your web-app will depend on then you can prune even more.

Specialization always pays off in terms of efficiency and it always costs in terms of ease of expansion and adaptation to future needs.

Boot time of a server is somehow important when you dynamically spin new instances. If spinning a new instance were a sub-second process, you could allow the number of instances you run (and pay for) to follow the demand much more closely.

But here the boot time is a proxy metric of complexity.

It's great to have software that can do a wide spectrum of things. But your server most often does a narrow spectrum of highly predefined tasks. You often go to great lengths to obviate and disallow any other activity on it, for security reasons.

So it would be great if you took the universal software, somehow cut it to your task set, and could throw away the unused parts (which are 90%+). Unfortunately, this is not really attainable with traditional OSes. Unikernels allow you to do just that—with some quite noticeable limitations, as of now, though.

Sounds like a badly optimized install then. Unless you are running a disk check, or have a hardware raid controller, on every boot, getting a kernel and the minimal environment to run a web server up should take under 1/10 of that.

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

This reminds me of Ling/Erlangonxen, unfortunately Ling is not a free-software, it's opensource but not a free-software.

And the fact that your operating system is the actual language you're coding with, reminds me of the fantastic project by Niklaus Wirth, The Project Oberon. The project Oberon is a language and operating system you can learn more about it at http://www.inf.ethz.ch/personal/wirth/ProjectOberon/, http://www.inf.ethz.ch/personal/wirth/ and a video by professor Niklaus Wirth himself: http://bit.ly/1ClvKSX

How is Ling not free software? From its LICENSE¹, it's using the Berkeley DB/Sleepycat license, which is considered Free by both the OSI and FSF.

¹ https://github.com/cloudozer/ling/blob/master/LICENSE

The chat client uses Gyre which is port of Zyre [1] framework in Go. Disclaimer I'm the author.

[1] https://github.com/zeromq/zyre

Unfortunately there isn't much doc, but it's not that hard to set up. Take a look at run.sh file and config directory. Andrew Gerrand has a init script[1] in his fork for it which might be useful.

[1] https://github.com/nf/runsit/tree/master/doc/initd

Just an introduction: Currently I'm using runsit as an alternative for supervisord and I'm happy with it so far. Stdout and stderror of the processes can be queried with a very simple HTTP interface. Runsit watches a config directory for any changes and applies them immediately. Config files are in json format.

Mind sharing a (lightly commented) config? I've been using Supervisor to run my Go services for a long while (the built-in log rotation is one of the big attractions) but keen to try alternatives. I never found mmonit and other alternatives to be as comprehensive as Supervisor.

For instance I use following config (nginx.json) for nginx:

{ "user": ["_env", "${USER}"], "cwd": "/var/www", "standardEnv": true, "numFiles": 1024, "binary": "/usr/sbin/nginx" }

And php-fpm.json:

{ "user": ["_env", "${USER}"], "cwd": "/usr/sbin", "standardEnv": true, "numFiles": 1024, "binary": "php-fpm", "args": [ "-F" ] }

Hope that helps

Forgot to tell you that nginx shouldn't be daemonized:

  echo "daemon off;" >> /etc/nginx/nginx.conf

And the JSON parser is awesome, it gives user friendly error messages when the file has the wrong format. Very cool.

Yes it is.

Do you mind if I ask couple of technical questions?

- How did you cope with the traffic from HN?

- The image resize service you implemented (photo.pixomize.com) is so simple and clean I want to know how did you implemented it? is it implemented from scratch?

What I like about photo.pixomize.com is the simplicity in the URL and how you can simply create thumbnail and download it and it's pretty fast.

There are lot's of image resize services out there which do the exact same thing as a SaaS.

More than happy to answer. I am planning to write a blog post about technical parts soon.

The traffic was not that big for this kind of sites. Yesterday there seemed to be around 2.5K visitors from HN and each having average 2.1 page views per session.

The resizing service is implemented from scratch. It's very simple (resize and cache) and does not have the possibility to define point of interest (yet - I would like to do some experiences with that too).

I'm currently writing a technical blog post about Pixomize.