Surface review of OS Inferno

So let's start with the main thing - where is the place under the Sun for Inferno , where and how does it make 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 can do 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).
• Homogenous environment (application written in Limbo will work equally well under Windows, under Unix, and on embedded devices).
• Embedded devices (Inferno supports many processors and devices ... maybe Inferno is already working inside your gadget, you just don’t realize it :)).

But personally, Inferno primarily attracts me, not by these possibilities, but by the elegance and simplicity of the architecture, which makes it possible to solve my tasks much simpler and more elegant than in other systems / languages. And here I mean the most common tasks that are not related to either distributed computing or the other basic features of Inferno!

Simplicity

• All existing documentation on the system in general and on programming Limbo was read by me in 4 days, including almost completely analogous to 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 a poorly documented system, but to its simplicity!
• Inferno contains very little code, compared to other systems. And the code is fully open. This gives a real opportunity to thoroughly understand the system and modify / 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 machine and Limbo compiler - for comparison, only the linux kernel takes an order of magnitude more. All application software and libraries are written in Limbo, and take up 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 your server: :) your application and the libraries it needs (if used).
• And most importantly - architectural simplicity. But I want to open this topic separately, she deserves it!

Efficiency

• Very light threads: you can create threads with thousands and tens of thousands and the system works perfectly and quickly (if I do not confuse, they made dynamic memory allocation for the stack of threads a la heap to save memory).
• Jit In general, Dis (virtual machine) works quite well. 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, Dis bytecode was originally designed to simplify JIT compilation for most existing processors.

Portability

• Bytecode We compile once, then we run under any Inferno - no matter, native or hosted, and on which processor it all runs. The authors of Inferno guarantee the same operation of applications on any system.
• In hosted mode, all popular OS are supported.
• In native mode, many processors are supported.

Limbo language

• Parallel programming (concurrent programming).
• Hoare's Communicating Sequential Processes (CSP) developed idea is used to synchronize threads, which greatly simplified programming. (By the way, on this topic you can see Rob Pike's Google TechTalk .)
• Strongly typed.
• Heap support for high-level features (tuples, alt, etc.). I will also disclose this topic separately. :)

Security

• Access to ALL resources, both local and remote, is done through 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 issuing certificates; in an application, as a rule, there is no need to program anything specifically for security.

Possible limitations (my personal observations)

• There is no support for unix socket yet, but there is a chance that it will be added soon. Update: support added for 20110329.
• Each blocking syscall in host OS (linux / windu / etc.) Is performed in a separate thread in order not to block the work of the whole Inferno. With a large number of blocking syscols at the same time (for example, the server on which simultaneously hangs and makes I / O 10,000+ clients) there may be problems.
• There is no support for semi-closed sockets (i.e., you cannot send EOF to the remote side using shutdown (SHUT_WR) without closing the socket. And it won't be. Because this, as I was explained, is 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 perhaps not all features are implemented.

It should be noted that most of these restrictions can be circumvented thanks to the Inferno feature: it is possible to run host OS processes and interact with them. Those. I can, for example, call a linuhov 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 from Limbo to syslog).

Links

citforum.ru/operating_systems/inferno_programming

(plus a bunch 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 habr)