Com’è ben noto, Windows permette di far girare non soltanto le applicazioni appositamente disegnate per esso, ma anche quelle per le versioni più vecchie, o addirittura sviluppate per l’ormai arcaico MS-DOS che ha dominato la scena per molti anni. Da notare che un’applicazione MS-DOS è MOLTO diversa da una per Windows: le API del sistema operativo di cui fa uso sono, infatti, poco o per nulla simili.
Tutto ciò (e molto di più) avviene proprio grazie all’utilizzo di particolari strumenti, chiamati subsystem nel gergo Microsoft.
Un subsystem è un processo che emula un ben preciso ambiente di un sistema operativo (d’ora in poi abbreviato s.o.) al quale s’interfacciano le sue applicazioni e che fanno uso dei servizi che espone. Questo significa che la relazione che lega un’applicazione scritta per Windows 3.1 al suo subsystem Win16 è di tipo client/server: quando all’applicazione serve un particolare servizio, effettua una chiamata al subsystem (tramite uno scambio di messaggi). Da evidenziare che, a parte Win32, i subsystem possono essere caricati dinamicamente, quando servono.
Un meccanismo così astratto può portare a pensare che Windows sia potenzialmente in grado di eseguire qualunque applicazione per qualunque s.o. senza alcuna emulazione di mezzo, posto che sia presente un subsystem per gestirla; quindi in maniera praticamente “nativa“. Ad esempio, sarebbe ipotizzabile l’esecuzione di applicazioni scritte per OS X clickando sull’apposito file.
La realtà, però, è ben diversa e ci riporta bruscamente coi piedi per terra. Esiste, infatti, un filo conduttore che lega tutti i subsystem, ed è il formato EXE, cioé il file dell’applicazione che contiene il suo codice e i suoi dati. Il formato EXE è stato introdotto con l’MS-DOS, e successivamente esteso per permettere di contenere codice e dati di applicazioni delle varie versioni di Windows.
Comunque il DOS e Windows non sono gli unici ad averlo adottato: l’hanno fatto anche OS/2 (progettato originariamente da IBM e MS) e… Unix! Più precisamente POSIX. Infatti MS con Windows NT ha sviluppato un sottosistema POSIX-compatibile che fa uso di una particolare estensione del formato EXE per le sue applicazioni. Entrambi i subsystem hanno avuto uno scarso successo, e infatti sono stati rimossi con l’introduzione di Windows XP.
OS/2 era presente soltanto per far girare queste applicazioni, ma questo s.o. è stato abbandonato da MS e lasciato soltanto in mano a IBM, per cui per MS aveva poco senso continuare a mantenerne il relativo subsystem. Quella di introdurre il subsystem POSIX era stata, invece, una scelta strategica di MS, che aveva bisogno che NT fosse accettato anche negli ambienti militari che richiedevano necessariamente l’aderenza allo standard POSIX. Poiché POSIX è molto ampio, ma prevede soltanto un limitato insieme di funzionalità di base che devono essere messe a disposizione, ovviamente MS implementò soltanto il minimo indispensabile rendendolo, di fatto, inutilizzabile.
D’altra parte MS non aveva interesse a espandersi nel mercato Unix. In passato l’aveva fatto con una sua versione, chiamata Xenix (che tra l’altro ebbe un discreto successo), ma decise di concentrarsi esclusivamente sul prodotto di cui deteneva tutti i diritti e che poteva quindi controllare a proprio piacimento.
Tolto il vincolo militare dell’obbligatorietà all’aderenza alle specifiche POSIX, il relativo subsystem è stato soppresso, visto che il suo mantenimento aveva un costo (seppur minimo, come vedremo dopo). E’ singolare, però, che con Vista sia stato introdotto un nuovo subsystem POSIX (che aderisce a un insieme molto più vasto delle specifiche). Questo subsystem non è immediatamente utilizzabile, ma è necessario installarlo dal pannello di controllo come componente aggiuntivo di Windows (chiamato SUA). Una volta installato, è anche possibile installare un’utilissima suite di strumenti a corredo che vanno dalla bash ai compilatori GCC e g++. Chi ha lavorato con Cygwin avrà già intuito che con questo subsystem si può anche fare a meno di questo progetto.
Tornando ai subsystem, si potrebbe pensare a questo punto che ognuno contenga il codice del rispettivo sistema operativo che emula, andando quindi ad appesantire anche notevolmente il sistema a causa dell’occupazione di memoria in particolare e del codice che deve eseguire (che a sua volta dev’essere in qualche modo “controllato” per renderlo gestibile all’interno di Windows). Oltre a ciò, tutto questo codice presente va ovviamente mantenuto e ciò, ancora una volta, costa.
Il problema è stato risolto racchiudendo tutto il codice “nativo” di Windows in appositi file e reso accessibile alle applicazioni esclusivamente tramite l’uso dei subsystem, che lo richiamano in maniera opportuna. Per essere più chiari, la funzione che crea un file su Windows è presente in copia unica ed esposta dalle API native di Windows a tutti i subsystem, che la richiamano quando le loro API hanno bisogno di eseguire un’operazione di questo tipo.
Questo vuol dire che sia l’API CreateFile() del subsystem Win32 che la create() di quello POSIX fanno entrambe uso dell’API nativa che è stata appositamente creata allo scopo. Ovviamente le API native di Windows sono più affini al subsystem Win32, e una chiamata di un’API di quest’ultimo si traduce quasi sempre in una sola chiamata a un’API nativa, mentre per gli altri subsystem probabilmente servirà un po’ di codice in più per ottenere lo stesso risultato (in gergo si parla di “wrapper“), ma in ogni caso non siamo in presenza di una riscrittura della funzionalità richiesta.
I subsystem permettono quindi di ottenere molteplici vantaggi:
- compatibilità con s.o. diversi (ma sempre legati al formato EXE);
- isolamento (le applicazioni che girano dentro un subsystem sono separate da quelle che girano in un altro);
- manutenibilità (c’è una sola copia del codice da gestire di cui fanno uso tutti i subsystem, più un’eventuale piccola parte per eseguire il wrapping ove necessario);
- estensibilità (possono essere creati altri subsystem).
Tradotto in soldoni, questo significa che in teoria (ma anche in pratica: è stato fatto con Vista, infatti) è possibile riscrivere tutto il codice delle API native senza intaccare minimamente i subsystem, grazie al mantenimento dell’interfaccia con queste ultime. Allo stesso modo, è possibile riscrivere completamente il codice di un subsystem senza avere impatti su quello delle API native.
Qualche differenza fra i vari subsystem, però, c’è, ed è anche facile intuirla: Win32 è attualmente il subsystem “standard”, cioé quello utilizzato dal s.o. e che al suo avvio viene contestualmente caricato (mentre gli altri possono essere caricati dinamicamente, come dicevo prima). Inoltre gli è demandata la gestione dell’I/O e dell’interfaccia grafica. Ciò significa che tutti gli altri subsystem che vogliono utilizzare l’I/O o renderizzare a video qualcosa, devono necessariamente passare per i servizi da lui esposti.
Questo serve non soltanto a centralizzare queste operazioni, ma anche a “omogeneizzare” l’esecuzione delle applicazioni dei diversi subsystem. Per chiarire meglio il concetto, se un’applicazione Windows 3.1 (che fa uso del subsystem Win16) decide di aprire una finestra, questa verrà in realtà gestita e renderizzata dal subsystem Win32 (a cui Win16 avrà passato pari pari tutte le relative chiamate alle sue API di I/O e grafica) in accordo con le impostazioni di sistema, dando all’utente l’idea di un sistema coerente (chi ha avuto a che fare con applicazioni Java dotate di interfaccia grafica conosce bene il problema della disomogeneità della rappresentazione dell’interfaccia utente nel s.o. su cui gira).
Il rovescio della medaglia è che se qualcosa dovesse andare storto nel subsystem Win32, l’intera interfaccia grafica diventerà inutilizzabile anche da parte degli altri subsystem. E’ un grosso e pesante limite di cui bisogna tener conto, ma al momento rappresenta la miglior soluzione per garantire la consistenza dell’interfaccia con l’utente a fronte della disomogeneità dei diversi subsystem.
In tutta questa lunga dissertazione c’è, però, un illustre assente: .NET. Questo in realtà non è un subsystem vero e proprio, in quanto poggia interamente su Win32 per la sua esecuzione e quello delle relative applicazioni che ne fanno uso. Dunque non meritava d’esser trattato. C’è, però, da sottolineare che le applicazioni .NET non “vedono” il sottostante subsystem Win32, ma soltanto l’ambiente .NET, per cui sono sostanzialmente indipendenti da Win32.
Non è, quindi, peregrina l’ipotesi di vedere invertite le parti in una futura versione di Windows, con .NET a rappresentare il subsystem “standard” e Win32 relegato al ruolo di subsystem, al pari di tutti gli altri. Ancor più interessante sarebbe l’integrazione di .NET quale sistema nativo su cui fondare l’intero s.o., perché permetterebbe di togliere di mezzo uno strato d’interfacciamento con le applicazioni, migliorando anche le prestazioni.
Ma forse sto galoppando troppo con la fantasia…
sicuri che sia un bene un futuro so basato pesantemente su .net? mi sembra un modo per perdere efficienza, con pochi elementi positivi.
del resto, gli applicativi gia’ si poggiano su un framework .net, ma non il so.
In Microsoft sembra in progetto una cosa del genere. Se da un approccio simile si possa avere un miglioramento tangibile del s.o. speriamo che chi prende le decisioni in casa Microsoft abbia il coraggio di percorrere questa strada.
Ottimo articolo! Sono contento che qualcuno abbia scritto qualcosa su questo argomento che mette in luce le qualita del kernel NT e il suo ottimo design.
Ho installato già da un po di tempo su Windows Server 2008 il Subsystem for Unix Application per fare qualche prova e far funzionare alcune applicazioni per Linux.
Anche su Windows Internal è spiegato molto dettagliatamente il meccanismo dei subsystem, qua in gennaio dovrebbe uscire la versione aggiornata su Vista.
Tempo fa parlando di queste cose sul forum era venuto fuori che secondo alcuni su Linux il problema della retrocompatibilita non sussiste in quanto POSIX è uno standard stabile da anni… ma non è quello il punto, il fatto di esporre direttamente alle applicazioni le API del kernel come fa Linux non è una buona cosa.
Il meccanismo dei subsystem su Windows è molto piu sofisticato e permette di evitare molti problemi, come ad esempio ricompilare i moduli dei driver ogni volta che si aggiorna il kernel anche a seguito di una banale modifica.
E poi le API di windows sono vastissime, spaziano dalle funzionalita di base di un OS alla gestione avanzata del multimediale, e grazie all’isolamento dei subsystem possono venire supportate per anni e anni senza creare problemi di retrocompatibilità.
Al contrario POSIX comprende solo delle API di base e le funzionalita avanzate sono gestire da librerie in user space spesso non stadardizzate, che variano da distro a distro e che non di rado presentano problemi di incompatibilita tra varie versioni. Riguardo questo è esemplificativo la gestione dell’audio su Linux:
http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html
Ma l’SUA (microsoft windows services for unix) non e’ stato eliminato dalla versione di windows vista che piu’ ne avrebbe avuto bisogno (business), lasciandolo solo sulla versione ultimate e enterprise ?
Questo e’ un enorme passo indietro, almeno rispetto a windows xp pro che ne consente l’installazione.
Inoltre nel passaggio da xp a vista questo subsystem ha perso alcuni componenti server tra cui Server per NFS, User Name Mapping, Server per NIS, etc…
Queste cose fanno girare le @@, invece di migliorare questo subsystem si tolgono funzionalita’ che erano disponibili nelle release passate ed inoltre si priva vista business da questo subsystem obbligando di fatto a passare ad una versione consumer del so (edizione ultimate).
@massimo m.: Java ha ormai performance comparabili a quelle del C, e C# è stato disegnato per essere più efficiente, per cui non mi preoccuperei troppo.
@vic20: lo spero anch’io. Anche perché su .NET ha investito tantissimo.
@Pietro R.: concordo. Esporre direttamente le API pone un vincolo maggiore fra s.o. e applicazioni.
Tra l’altro su Linux il problema della (retro)compatibilità è ben più sentito, proprio perché non possiede un’ABI stabile. Basti pensare ai salti mortali che devono fare i driver grafici per supportare ogni genere di configurazione del kernel.
Quel link sullo stato dell’audio di Linux lo avevo già letto tempo fa (grazie a un utente di hwupgrade, Jappilas :D) e dimostra, oltre a un persistente problema di compatibilità, anche la mancanza di una solida linea guida per lo sviluppo di ciò che sta attorno al kernel.
“Non di solo kernel vive un s.o.”. ;)
@goldorak: non so su quale versione di Vista è possibile installare SUA. Certamente, per il tipo di strumento, non mi aspetto che il suo target sia rappresentato dalla Home & Home Premium, ma se non fosse supportata la Business sarebbe veramente grave.
Comunque lo strumento è nuovo e abbraccia una parte decisamente più grande delle specifiche POSIX, al contrario del precedente. Se mancano degli strumenti di supporto così importanti, probabilmente verranno integrati in futuro, ma… almeno un “kernel” di tutto rispetto c’è. ;)
Da informatico credo che la retrocompatibilità sia più un male che un bene, anche se approcci di successo la usano alla grande: architettura x86, Windows e java.
Il fatto è che il binario va a male :-)
Quando un progetto non è più sviluppato o mantenuto e magari il sorgente non si sa neanche più dove sia, è destinato a morire. Quello che conta è avere codice moderno e “spazio mentale” nelle teste dei programmatori.
Io credo che tra 50 anni se l’infrastruttura informatica poggerà sempre più su codici open source, alcuni magari anche vecchi, ma sempre in grado di compilare e girare su piattaforme nuove.
Insomma credo nella avanti-compatibilità se mi passate il termine, invece che sperare (e pretendere) che sistemi del futuro siano retrocompatibili e si sobbarchino questa complessità.
Spero che si sia capito qualcosa. Chissà come sarebbe oggi il nostro computer se non si fosse mai badato a retrocompatibilità?
Non si può, però, ignorare la base di software installata e/o disponibile.
Se ad ogni nuova versione “rivoluzionaria” di un s.o. si potessero avere immediatamente a disposizione le applicazioni aggiornate che lo sfruttano, sarei il primo, da utente, a urlare di gioia e puntare il dito contro le soluzioni retrocompatibili.
Purtroppo la realtà è ben diversa e riguarda anche l’open source, come puoi leggere anche qui: http://www.appuntidigitali.it/2909/aggiornare-le-applicazioni-non-sempre-e-possibile/
Bell’articolo, mi è piaciuto veramente tanto, e lo dico da estimatore degli ambienti Unix-like. Mi informerò meglio sul subsystem POSIX di Vista, dato che sono un affezionatissimo utente di GCC, g++ e tanti altri tool di sviluppo opensource!
Spero solo che la “retrocompatibilità a tutti i costi” anche con le applicazioni ultra-legacy come quelle DOS e Win16 sia abbandonata in Windows 7 favore di una maggiore snellezza del codice.
Ricollegandomi infine ai miei interventi nell’altra, recente discussione su Windows ( http://www.appuntidigitali.it/2998/vista-vs-xp/ ) mi chiedo come sia possibile che Vista sia *così* più affamato di risorse rispetto ad XP, se tutti i vari subsystem oltre a quello principale sono caricati solo su richiesta… a parità di hardware impiegato e utilizzando solo applicazioni recenti, si dovrebbero avere le stesse performance, se non addirittura maggiori, rispetto a quelle di XP. Tuttavia così non è, almeno sui PC di cui dispone il sottoscritto (AMD Athlon64 X2 4600+ e Intel Core 2 Duo T9300, rispettivamente con 2 e 3 GB di RAM, non esattamente del vecchiume).
Sono d’accordo infine con Massimo (post #1): io non ce lo vedo assolutamente .NET diventare il subsystem principale di Windows. Stiamo pur sempre parlando di un (sotto)ambiente basato su codice semi-interpretato, alla stessa stregua di Java, che IMHO non sarà *mai* veloce quanto del codice nativo C++ o addirittura C… e il fatto che le macchine moderne sono sempre più potenti non può essere una scusante per perdere inutilmente punti in performance.
Post scriptum (mi scuso per il doppio post): confermo che Vista Home Premium *non* dispone del subsystem POSIX… peccato, mi sarebbe piaciuto provarlo.
DOS e Win16 sono stati già eliminati con XP x64 e Vista x64. Non credo che rimarranno supportati ancora per molto.
Sulle prestazioni c’è un altro articolo http://www.appuntidigitali.it/3000/le-nuove-versioni-di-windows-sono-sempre-piu-lente-delle-precedenti/ che ti invito a visionare.
Infine per quanto riguarda .NET, a differenza di Java è sempre compilato. Questo può avvenire una sola volta (convertendo l’intera applicazione in un eseguibile nativo) oppure sfruttando il compilatore JIT.
Le prestazioni sono ottime. Già Java ha prestazioni equivalenti a quelle del C: http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=java&lang2=gcc e C# è messo meglio (il runtime è stato pensato appositamente per essere soltanto compilato; la VM Java invece può decidere di interpretare il bytecode anziché compilarlo).
Con questi sistemi managed è l’occupazione di memoria il campo in cui si perde rispetto a linguaggi come C o C++. Anche qui, linguaggi come C# consumano meno risorse rispetto a Java.
Considerato i continui aumenti delle dotazioni di memoria (e di core dei processori), in futuro vedrei bene delle soluzioni basate su .NET. Ci sono molti vantaggi (in primis produttività, robustezza e sicurezza) che mi fanno propendere per essi.
senza voler andare troppo OT: come sono messi o meglio che ruolo giocano i sistemi ms a 64 bit in tutto ciò?
Se ti riferisci all’ultima parte del mio ultimo commento, direi che sono messi bene: il runtime .NET genera codice nativo a 64 bit che è pure abbastanza ottimizzato.
Se intendevi altro, se potessi essere un po’ più esplicito ti potrei rispondere meglio.
@Cesare (post #10): la pagina dei benchmark C vs Java considera programmi per la bioinformatica, che notoriamente sono decisamente data e cpu-intensive, ma mi piacerebbe vedere un confronto per quanto riguarda la gestione (ad esempio) della grafica 3D, che da sempre è stata la spina nel fianco dei linguaggi semi-interpretati: alla fine, se i videogames moderni vengono quasi sempre sviluppati in C/C++ (e non in Java o C#), un motivo oltre al minore consumo di memoria centrale ci sarà… :P
Articolo molto interessante!
@Tudhalyas. Di questo ne ha parlato un mio collega che lavora nell’industry: http://www.appuntidigitali.it/2711/videogiochi-non-solo-c/
Sembra che proprio le prestazioni non siano il problema più grosso, quanto il fine controllo che un linguaggio come C++ permette nell’allocazione (e disallocazione) degli oggetti istanziati e della memoria in generale.
Comunque i test di quella suite sono diversi: non c’è soltanto roba di bioinformatica, anche rispetto agli altri sono sicuramente di più. Certamente andrebbe estesa con altre tipologie di codice.
@Riccardo: grazie. :)
hops sono stato impreciso, vista l’ora :-)
intendevo se esiste un “win64” e se ad esempio win32 è un sottosistema di questo possibile win64…
ps: mi sbaglia il codice di conferma ripetutamente, dopo un paio di tentativi va a buon fine, anche a voi?
In questa pagina:
http://technet.microsoft.com/en-us/library/cc771672.aspx
c’è scritto che il nuovo Subsystem for UNIX-based Applications è supportato su Windows Server 2008 e Windows Vista, senza specificare alcuna versione particolare quindi presumo che funzioni su tutte.
Diverso è il discorso per il Utilities and SDK for Subsystem for UNIX-based Applications, un add-on che comprende una suite di 300 programmmi unix, compilatori, SDK, librerie e altro, e che è disponibile su queste versioni:
Windows Server 2008; Windows Vista Enterprise; Windows Vista Enterprise 64-bit edition; Windows Vista Service Pack 1; Windows Vista Ultimate; Windows Vista Ultimate 64-bit edition
Quindi se non sbaglio sulla Hom Premium si puo installare SUA che mette a disposizione il subsystem posix ma non è possibile installare (per ora?) il pacchetto con l’SDK e le utility.
Se vuoi provarlo per vedere come funziona puoi scaricare la trial di windows server 2008 e provarlo su una macchina virtuale (dura 8 mesi…):
http://technet.microsoft.com/it-it/evalcenter/cc137123.aspx
@flauzio: OK, adesso è chiaro. Nelle versioni a 64 bit di XP e Vista c’è ovviamente un subsystem Win64, e in questo caso le applicazioni a 32 bit che usano il subsystem Win32 vengono fatte girare con un meccanismo simile a quello che permette (nei sistemi a 32 bit) di far girare quelle a Win16.
Nel gergo MS in questi particolari casi il meccanismo viene chiamato WoW (che è la contrazione di Windows-on-Windows).
Complimenti al Sig. Di Mauro per l’ottimo articolo, letto con estremo interesse e scoperte alcune cose che ignoravo.
secondo me la retrocompatibilità esiste per ragioni prettamente di mercato, se guindows non fosse stato retrocompatibile “forse” non avrebbe avuto il successo che ha. .Net è il futuro per MS, sarebbe stupido da parte loro non spingere per far si che diventi la base dei nuovi so, tenendo conto anche del fatto che,per ammissione della stessa MS, si stanno dirigendo verso s.o. virtual-like, passatemi il termine
Comunque bell’articolo, davvero interessante ed esplicativo, Complimenti
Sì, è proprio questo che mi spinge a pensare a un futuro sempre più dominato da sistemi “managed”, cioé in cui le applicazioni (ma anche parti del s.o., appunto) girino all’interno di una macchina virtuale.
La retrocompatibilità, come dicevo prima, è necessaria per tutelare la base software esistente. Ricordiamoci che senza software un s.o., per quanto “bello”, non va da nessuna parte.
esattamente, e spero vivamente che sia così… con tutti questi core,ram, super gpu ci sono i presupposti per dirigersi verso questa direzione, così (probabilmente) si avranno sistemi più stabili e sicuri grazie alla virtualizzazione e al codice gestito; e come diceva sempre il mio professore “non saremo più costretti a reinvetare sempre la solita ruota…” :-)
scusate, forse nn ci ho capito molto da questo articolo ma la retrocompatibilità di cui si parla è la stessa che dovrebe permettere a un gioco nato sotto windows 95 di girare anche su xp? No perché a me è capitato di provare e il risultato è stato PIETOSO! a sto punto se la potevano risparmiare. Ma forse si tratta di qualcos’altro….
Sì, è esattamente ciò che pensi. Ma per Windows 9x c’è un problema: passando a NT e derivati, NON è possibile accedere direttamente all’hardware, per cui per tutte le applicazioni (giochi inclusi) che lo fanno, non è garantito il loro funzionamento.
Applicazioni scritte, invece, seguendo le linee guida e senza accedere all’hardware è quasi certo che funzionino.
[…] plausibile pensare che entro un anno scarso – pur considerando la retrocompatibilità fornita dal subsystem WOW64 – drivers e software in generale siano pronti al […]
[…] plausibile pensare che entro un anno scarso – pur considerando la retrocompatibilità fornita dal subsystemWOW64 – drivers e software in generale siano pronti al […]
Forse non l’avete capito ma la retrocompatibilità la tolgono soltanto per vendere del software nuovo che altrimenti non avrebbero mai venduto
Considerato quanto tempo passa quando si rimuove qualche subsystem, non vedo cosa ci sia da preoccuparsi.
E’ l’equivalente di ere geologiche nell’informatica.
Bell’articolo, e interessante anche il contenuto.
Non sono un amante di Windows, e queste notizie non possono che confermare questa situazione, l’idea, non lo nego, è buona, ma il fatto di gestire il tutto in modo così caotico (vedi solo che win32 è un subsystem, ma non è come gli altri, perchè è quello di default e tutti gli altri fanno riferimento al lui ecc…) che non può che generare instabilità.
Peccato, l’idea c’era, fosse stata gestita un pò meglio, rendendo indipendenti i subsystem tra loro forse, e facendo gesitire la grafica da un servizio indipendente in grado di interfacciarsi a tutti….
Così se win32 va a puttane si porta dietro tutto il sistema. Se fossero tutti indipendenti, parte del sistema resterebbe in piedi (anche se, vero, ormai di applicazioni win16 che ne sono poche…)
In conclusione vedo delle buone idee, ma
on si applica XD
Chiaro, ha delle limitazioni che possono essere pericolose, ma in parte condivisibili.
Considera, comunque, che quello dei subsystem è un meccanismo su cui sta lavorando un gruppo di sviluppatori su una versione di *BSD (non ricordo adesso se fosse FreeBSD, o uno dei suoi “cugini”, NetBSD o OpenBSD), proprio perché l’idea non è affatto male.