Ieri ho avuto modo di scoprire che è morto Dennis Ritchie.
Fa specie che si parli solo di Jobs (RIP pure a lui), ma tant’è, il global mourning necessita i suoi idoli – e di sicuro Ritchie non era un personaggio pubblico.
Una cosa certa è che dmr è morto l’8 ottobre 2011 a 70 anni, ma prima di morire ha prodotto il C (insieme a Kernighan) e ha collaborato alla creazione di Unix, gettando le basi per l’informatica che attualmente tutti utilizziamo in un modo o nell’altro.
Se ne va un tipo sveglio, insomma – molta sostanza e poca fuffa.
Ed è una discreta tristezza.
Linko anche un bello scritto di Herb Sutter che ho trovato commovente.
C is a poster child for why it’s essential to keep those people who know a thing can’t be done from bothering the people who are doing it. (And keep them out of the way while the same inventors, being anything but lazy and always in search of new problems to conquer[...])
Nel capitolo Basics of the Unix Philosophy di The Art of Unix Programming è scritto:
[...] The Unix philosophy (like successful folk traditions in other engineering disciplines) is bottom-up, not top-down. It is pragmatic and grounded in experience. It is not to be found in official methods and standards, but rather in the implicit half-reflexive knowledge, the expertise that the Unix culture transmits. It encourages a sense of proportion and skepticism — and shows both by having a sense of (often subversive) humor.
Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition, had this to say at the time:
(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
(iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
(iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
He later summarized it this way (quoted in A Quarter Century of Unix):
This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
Sto pensando alla scena di Idiocracy dove l’addetto all’infermeria non sa che pulsante pigiare per un mal di testa.
Mi piace continuare a pensare che i flussi di testo siano ancora un’interfaccia universale e utile per tutti, non solo per i programmi.
Generalmente ogni rete (medio-piccola) ha un mailserver che comunica con l’esterno e che invia e riceve la mail degli utenti verso e da il mondo. 
Configurare completamente un exim è un lavoraccio di cui attualmente non parlerò.
I mailclient (mutt, thunderbird, outlook) operano in maniere differenti, a seconda del fatto che sappiano parlare direttamente il protocollo SMTP o no. Di sicuro gli MTA sanno parlare l’SMTP, ma non aiutano gli utenti finali a scrivere le mail.
Mentre un client come thunderbird parla direttamente i protocolli necessari con l’MTA remoto, uno come mutt si limita a “impostare” la mail, e poi la consegna ad un MTA locale che la dovrebbe consegnare al mailserver che fa da ponte con il resto del mondo.
(Nota: Attualmente anche mutt ha il supporto SMTP (dalla ver. 1.5.x), ma c’è chi dice sia una bestemmia usarlo per questo. 
Nel caso interessi, guardare le FAQ e settare le variabili smtp_* (ie: smtp_url) SENZA l’account name – che si incarta.)
Ogni box unix ha un MTA locale – la sua natura di stazione multi-utente fa si che gli utenti della box abbiano la possibilità di comunicare fra di loro come default.
Le debian installano autonomamente la versione light di exim con una configurazione che permette di inviare e ricevere mail localmente.
Nel caso sia necessario configurare senza troppe pretese l’exim-light per permettere all’MTA locale di comunicare con l’MTA sul mailserver della lan, si può usare:
# dpkg-reconfigure exim4-config
sfruttando come smarthost il mailserver di cui sopra.
Più di un anno fa m’ero installato un sistema FreeBSD sulla box avanzata di casa, ma per mancanza di tempo e di capacità non ci avevo giocato molto.
Attualmente il tempo non è aumentato, ma l’esperienza sì e così mi sono ri-cimentato.
Così ho brasato radon e creato rodio.
La nuova versione di FreeBSD è la 7.1; fare il CD di boot e installarla è stato banale.
Ho deciso di completare un’installazione minima (senza pacchetti), per poi personalizzarla ed esplorarla a modo in un secondo tempo.
Giusto per iniziare bene, ho scagliato l’appartenenza ai gruppi – se si vuole che un normal user possa diventare root, meglio appartenere al gruppo wheel.
In generale, # sysinstall è il comando sempre pronto a dare una mano: sysinstall -> Configure -> Distribution -> man per esempio.
I sorgenti del kernel sono accattabili attraverso sysinstall in Configure -> Distribution -> src -> sys, e serve “base” per avere il Makefile e altre cose utili sul fs.
Tempo addietro avevo segnalato un buon tutorial di sed.
Visto che ci sono altre cose su quel sito meritevoli di nota, e poichè mi sono ritrovato a cascarci sopra per caso… lo risegnalo in tutto il suo splendore:
The Grymoire – a web site containing a collection of useful incatations for wizards, be you computer wizards, magicians, or whatever.
La parte Unix.
Era troppo fantasy per non segnalarlo per bene…
Mi ha ricordato tanto i bei vecchi tempi di Rolemaster. :-/
I file system sono quella parte del Sistema Operativo che si occupa di gestire le informazioni memorizzate (in file) su supporti permanenti. Il file system permette all’OS di identificare e operare sui file e sulle loro proprietà.
Il Network File System (NFS per gli amici) ebbe origine quando la condivisione di drive non era comune come oggi (in ambiente Win): questo fs permette di condividere spazio nell’hdd di un grande server con molti piccoli client.
Un esempio tipico è quello di un server centrale che detiene le home dei singoli utenti sul suo hdd locale, ma le condivide tramite NFS (quindi i client montano in effetti le home degli utenti dal server, e non sfruttano quelle sulle proprie macchine).
Dal mio punto di vista “casalingo” NFS può risultare molto utile per concedere un po’ di spazio a box che non ne hanno tanto, e magari per tenere certi dati del client su box di cui mi fido di più. Il bello è che essendo partizioni montate, il client è convinto di operare sul suo hdd, che in realtà è virtuale: di fatto il client salva i dati sul server.
More »
In Linux, quando si installa un sistema su di un bellissimo hard disk nuovo di zecca, si nota che il disco in questione è stato partizionato in una parte primaria – dove ci stanno dati, boot e altro – e una parte di swap.
Name Flags Part Type FS Type [Label] Size (MB) sda1 Primary Linux ext3 60003.42 sda2 Boot Primary Linux ext3 [idrogeno] 98999.48 sda3 Primary Linux swap / Solaris 1036.39
Ma cos’è la swap partition?
Una utile guida mi viene in aiuto: Linux Partition HOWTO, di Anthony Lissot version 3.5, 30 Nov 2005, (basata sulla guida di Kristian Koehntopp del 1997)
Ogni processo funzionante sul nostro computer è localizzato in un numero di blocchi nella RAM. Questi blocchi sono chiamati pages. Il set di istruzioni che andrà presto in uso è detto working set; Linux prova a predire questi accessi alla memoria (assumendo che le pages usate di recente siano usate anche nel prossimo futuro) e tiene queste pages nella RAM, se possibile.
In Linux, RAM e spazio swap si sommano (non è vero per tutti gli Unix). In sostanza: 256 Mb di RAM + 256 Mb di swap fanno un totale di 512 Mb di memoria virtuale.
Se ci sono troppi processi avviati sulla box, il kernel tenterà di liberare RAM scrivendo le pages sul disco: questa è la ragione per cui esiste lo spazio di swap; in effetti esso incrementa l’ammontare di memoria disponibile – è necessario comunque ricordare che l’I/O del disco è centinaia di volte più lento della RAM. (Insomma, la memoria è di emergenza, e non un’extra.)
Se la memoria diventa così scarsa che il kernel va a leggere i processi (working set) sul disco, la box comincia a rallentare enormemente e il disco viene letto in maniera molto insistente.