Superficial review of OS Inferno

So, let's start with the main thing - where is the place under the Sun for Inferno , where and how it makes sense to use Inferno. No, I don’t offer Inferno for the role of a desktop or server, these warm places are currently occupied. :) But there are at least three tasks that Inferno will cope better than others.

• Distributed computing and Grid (thanks to the Styx protocol, access to local and remote resources is no different, which makes it very easy to write distributed systems).
• Homogeneous environment (an application written in Limbo will be guaranteed to work equally under Windows, and under Unix, and on embedded devices).
• Built-in devices (Inferno supports many processors and devices ... maybe Inferno already works inside your gadget, you just don’t suspect about it :)).

But personally, Inferno primarily attracts me not with these features, but with the elegance and simplicity of the architecture, which allows me to solve my problems much easier and more elegantly than in other systems / languages. And here I am referring to the most common tasks, which are in no way connected either with distributed computing or with other main features of Inferno!

Simplicity

• I read all the existing documentation on the system in general and on Limbo programming in 4 days, including almost completely the analogue of sections 2 (system calls) and 3 (library functions) of the man documentation! True, I read about 18 hours a day. :) And this is due not to the poor documentation of the system, but to its simplicity!
• Inferno contains very little code compared to other systems. And the code is completely open. This gives a real opportunity to understand the system in detail and change / correct it yourself if the authors refuse to make any changes / corrections. (I now calculated through find and wc the volume of all .c and .h files: respectively 750,000 lines in 15MB and 100,000 lines in 3.5MB - this is the code of the OS itself for all platforms (both native and hosted!), Drivers, virtual machines and Limbo compiler - for comparison, only the linux kernel takes an order of magnitude longer. All application software and libraries are written in Limbo, and occupy 500,000 lines in 10MB.)
• To run your Limbo application on, for example, a linux server, you need to copy 3 Inferno files with a total size of 1.1MB to the server :) your application and the libraries it needs (if used).
• Well and most importantly - architectural simplicity. But I want to open this topic separately, it deserves it!

Efficiency

• Very light threads: you can create threads with thousands and tens of thousands, and the system works fine and quickly (if I don’t confuse anything, they made dynamic memory allocation for the thread stack a la heap to save memory).
• Jit. In general, Dis (virtual machine) works quite fast. But for maximum efficiency, Inferno has JIT support, i.e. the byte code on the fly is compiled into the native codes of the processor on which it is executed. Moreover, the Dis byte code was originally designed to simplify JIT compilation for most existing processors.

Portability

• Bytecode. We compile it once, then run it under any Inferno - it doesn’t matter, native or hosted and on which processor it is all running. The authors of Inferno guarantee the same application on any system.
• In hosted mode, all popular OSs are supported.
• In native mode, multiple processors are supported.

Language Limbo

• Concurrent programming
• For synchronization of flows, the developed idea of Hoare's Communicating Sequential Processes (CSP) is used , which greatly simplified programming. (By the way, Rob Pike’s Google TechTalk can be viewed on this subject .)
• Strongly typed.
• Support for a bunch of high-level features (tuples, alt, etc.). I will also discuss this topic separately. :)

Security

• Access to ALL resources, both local and remote, is via the Styx protocol. And Styx has built-in support for authentication, authentication and encryption in the style of SSL certificates. Thus, security is ensured at the stage of system administration and issuance of certificates; in an application, as a rule, nothing special has to be programmed for security already.

Possible limitations (my personal observations)

• There is no unix socket support yet, but there is a chance that it will be added soon. Update: support added 20110329.
• Each blocking syscall in host OS (linux / Windows / etc.) Is executed in a separate thread so as not to block the work of the entire Inferno. With a large number of blocking syskols at the same time (for example, a server on which simultaneously hangs and makes I / O 10000+ clients) there can be problems.
• There is no support for semi-closed sockets (that is, you cannot send EOF to the remote side using shutdown (SHUT_WR) without closing the socket. And it won’t. Because, as I was told, this is an ideologically wrong thing. :)
• I'm not sure, but maybe SSLv3 is not fully supported. Those. it is, by https: // you can go to sites, but maybe not all features are implemented.

It should be noted that most of these restrictions can be circumvented due to one feature of Inferno: it is possible to start host OS processes and interact with them. Those. I can, for example, call a linux perl script from an application on Limbo, transfer data to it and read data from it. Using this feature, I have already secured access from Limbo to unix sockets (I really wanted to write to syslog from Limbo).

References

citforum.ru/operating_systems/inferno_programming
(plus a lot of useful links at the end of this article)
powerman.name/Inferno
(my site, there is a Russian dock on Limbo)
habrahabr.ru/search/?q=%5Binferno%5D&target_type=posts
( other articles on OS Inferno on a habr)