sabato 30 novembre 2013

Microkernel(s)

Quite often I find on the web threads related to the "microkernel" cutlure versus the "monolithic" kernel one.
First of all, I have to say I'm not an expert in the former, but I would like to provide some insights from what my experience has been so far about the two approaches.

Please consider we are not really and strictly talking about Operating Systems kernels here: the approach can be extended to pretty much every complex software system.
So what is a microkernel architecture? Essentially it is a complex system made up by small pieces that cooperates and coordinates each other; each component is pluggable and can be substituted without a whole system reboot or downtime. The key point here is that EVERY component can be replaced/upgraded at run-time without having to stop the system as a whole.
In order to achieve this run-time behavior, the system must provide a strong decoupling of modules via a kind of message-passing scheme, and therefore we could state that the messaging delivery system is the only one that is going to require a whole reboot when changed.

The most famous Operting System based on microkernel is Minix, but this is only a huge example of this kind of architecture. OSGi is another example of a dynamic system where pretty much everything can be plugged at run-time. STREAMS, the old SunOS networking layer was also based on such concept. Erlang reminds me a microkernel architecture.

Are microkernel systems good or bad? It depends. When the task has to be low level, microkernels are generally bad. As an evidence of this, even if Minix is still under active development, all the rest of the world has chosen another approach, and I believe that if great OSs like FreeBSD, OpenBSD, Linux have chosen and still continue to resist to microkernel, they cannot be totally wrong.
STREAMS have been kicked off as soon as the network load increased, due to the performance lack.
On the other hands, OSGi is very succesfull, being the system not a low level one. The same role/agents systems I developed during my research activity could have been thought of a microkernel kind of systems, and while they were very dynamic, performances were not so good as a statically bound system.

So what?
If dynamism and pluggable features are the most important parts of your project, go for a microkernel approach. If performance is your aim, avoid a microkernel.
This is my personal opinion.

mercoledì 27 novembre 2013

Editor di testi

Aron Seigo ha pubblicato un interessante post nel quale parla della sua "conversione" da Vim a Kate, l'editor di default dell'ambiente KDE (per chi non lo sapesse, Seigo e' stato il leader dello sviluppo della versione 4 di KDE).
Tre sono fondamentalmente le motivazioni del passaggio da Vim a KDE: (i) scorciatoie simili, (ii) la possibilita' di avere delle sessioni, ossia una sorta di project management per gruppi di file e (iii) la console integrata.

L'aspetto degli editor mi tocca sempre profondamente, anche perche' l'editor di testi e' effettivamente lo strumento piu' usato da uno sviluppatore software (e anche dai sysadmin). Francamente sono abituato a Emacs e tendo a vedere negativamente ogni altra possibilita'. Si tratta certamente di una mia inclinazione e preferenza, ma Emacs e' a tutti gli effetti uno di quegli strumenti che mi permette di fare tutto e, cosa non trascurabile, funziona su qualunque piattaforma io debba lavorare. E con piattaforma non intendo solo il sistema operativo/architettura, ma anche il sistema grafico (che potrebbe anche essere assente).
Purtroppo Emacs sta diventando, a mio avviso, sempre piu' un sistema per abitudinari, e questo fara' si che molte delle feature interessanti non vengano portate su Emacs facilmente.
Tuttavia continuo ad essere molto soddisfatto di Emacs, che fino ad ora mi permette di avere una interfaccia unificata verso file system, sviluppo di software, editing di testo e shell.

Questione di gusti.