seppuku

Hai una FONera da qualche parte che da bravo fricchettone usi per condividere la tua connessione a internet? Hai deciso che vuoi smanettarci per usarla come access point multiplo o per amplificare il segnale della rete dei vicini? Hai deciso che semplicemente non sei d’accordo coi “terms of service” di FON?

La FONera is awesome!

Sei nel posto giusto!

Gli ingredienti sono i seguenti:

• Un unix con Apache attivato
• Un cavo ethernet (qualunque, cross o meno)
• Una FONera 2100 (controllate l’etichetta per il modello esatto)
• Tre file che trovate qui dentro
• Il firmware di DD-WRT più recente, precisamente linux.bin

Se avete un modello diverso controllate qui perché di sicuro sono più preparati, dopotutto è la guida da cui ho copiato io.

Attivare SSH via WiFi

La password WiFi di default, se non avete mai usato la FONera, è il numero di serie che c’è scritto sotto – l’ESSID è MyPlace.

SSH probabilmente è attivato di default tramite ethernet, la password di root è “admin”. Via WiFi invece bisogna fare un lavoretto di injection. Create due file, 1.html e 2.html e ficcateci dentro, rispettivamente:

e nel 2.html:

Dopodiché apriteli uno dopo l’altro e aspettate che rispettivamente vi rimandino alla schermata di FON. A questo punto connettetevi via SSH a 192.168.10.1 e via.

Preliminari

Con scp spostate openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma e out.hex in una dir qualsiasi della FONera (/tmp va bene), dopodiché, dal terminale (della FONera, ovviamente):

Ovviamente si riavvierà, ma non ci metterà molto. La wireless funzionerà ancora al riavvio, per cui OK. Dopo il passo seguente invece la wireless non funzionerà più; anche qui, nel mio caso non c’ha messo molto.

RedBoot

Date un IP alla vostra scheda ethernet (per me sarà 192.168.1.33).

Collegate il cavo ethernet e riavviate la FONera brutalmente, staccando e riattaccando la corrente. A questo punto entro 4-5 secondi potete andare tramite telnet sulla FONera, che avrà IP 192.168.1.254, sulla porta 9000. Avete pochi secondi di tempo per farlo, io ho dovuto fare un paio di tentativi (staccando e riattaccando).

Se siete connessi, i.e. appare

ma non appare il prompt, premete invio e dovrebbe apparirvi

Ovviamente come le varie righe di comando da terminale antidiluviano, RedBoot non conosce le frecce, per cui se sbagliate un comando lo dovete riscrivere. Incollo esattamente tutto il prompt così si capisce sia l’input che l’output.

Dato “fis init”, per inizializzare il flashing della FONera, l’output dovrebbe essere esattamente questo. A questo punto copiate nella DocumentRoot di Apache (/var/www su Linux, /Library/WebServer/Documents su Mac OS X, ma prima va attivato, ovviamente) il firmware linux.bin; dopodiché tornate sul terminale di RedBoot:

Col primo comando state solo configurando il collegamento, col secondo invece state richiedendo l’upload tramite HTTP. Questi comandi non sono “distruttivi” e dovreste avere una risposta abbastanza veloce.

Ora invece lanciate

Questo ci metterà molto, nel mio caso circa mezz’ora. Ça va sans dire che dipende dalla FONera e non dalla vostra CPU, per cui i tempi saranno comunque lunghi. Inoltre è distruttivo, per cui forse è una buona idea non perdere il collegamento telnet, non staccare il cavo, etc.; l’output preciso, che appare solo alla fine, è questo qui.

A questo punto serve un’ultima cosa, che è la creazione dello script di avvio.

Le ultime due righe sono chiaramente quelle che dovete scrivere voi (pari pari), e dopodiché vi chiederà svariate cose, ma i settaggi di default andranno bene:

Alla fine di tutto riavviate con “reset”, e DD-WRT dovrebbe essere installato.

DD-WRT

Avendo DD-WRT si possono fare un sacco di cose; è un ottimo firmware, per cui potete farci quello che volete, e si trovano molte guide a riguardo su internet.

Per usare il vostro nuovo AP come AP vero e proprio è sufficiente un collegamento al router e la configurazione della Wireless primaria a vostra discrezione, e non ci sono grossi problemi. Se invece (cosa “darwiniananamente legale”) volete usare l’AP come “ripetitore”, ovvero volete che si connetta a una seconda rete WiFi di cui “ripeta il segnale” ovviamente sotto forma di un’altra rete dovete configurare la Wireless principale come “client” (nella wireless mode) e mettere i dati della WiFi esterna, mentre quella interna deve essere creata come interfaccia “virtuale”, e sinceramente è meglio cifrarla (come WPA2).

Buon divertimento. Una cosa utile da notare è che se la rete attraverso la quale passate è scoperta c’è l’eventualità che sia un honeypot (it’s a trap!), per cui rimando al post precedente per quello che riguarda i tunnel SSH …

La procura di Bergamo ha deciso che visto che “thepiratebay fa perdere millions of dollars a non si capisce bene chi” è bene imporre ai provider un relay di tutto il traffico verso thepiratebay.org a 127.0.0.1. In altre parole, hanno bloccato thepiratebay in Italia.

How do I unlock thepiratebay.org?

Di nuovo? Sì, di nuovo. Non voglio perdermi troppo in seghe mentali, mi limito a dire che gli idioti che hanno proclamato tale verdetto hanno preso un grosso abbaglio. Le sentenze di questo tipo sono delle sanzioni a un colpevole che non esiste, che ha commesso un reato che non esiste, un po’ come le bestemmie.

D’altra parte, se questo provvedimento funzionasse, non potrei mai raccontarvi un modo efficace per scavalcarlo, nell’attesa che cambino IP e risulti di nuovo raggiungibile. Innanzitutto, se andate all’Università (o in qualche altro ente pubblico in cui le reti siano poco monitorate) potete comodamente andare su thepiratebay.org da lì, perché il provvedimento colpisce solo i provider, dunque i privati.

In caso contrario potete provare con un proxy HTTP da qui. Per usarlo è bene usare un file .pac come quello che incollo di seguito.

Incollate quelle righe in un file che chiamate “proxy.pac” sostituendo ovviamente IP e porta del proxy al posto di INDIRIZZO:PORTA ( e.g. 127.0.0.1:3128 ). Come si associa il .pac al browser forse è bene che lo sappiate, ma fortunatamente l’Università di Pavia ha una bella guida ( ovviamente dovete mettere il vostro .pac, mica il loro ).

Una soluzione un po’ più affidabile ( i proxy vanno e vengono ), ma molto più rognosa, è avere accesso SSH ad una macchina dalla quale thepiratebay.org è raggiungibile. Nel mio caso fortunatamente è così. Una soluzione abbastanza semplice – ma un po’ sbattimento – è creare un tunnel ssh verso quella macchina.

Innanzitutto occorre installare squid sul computer remoto, in modo che esso stesso faccia da proxy; nel mio caso ha su Debian per cui il setup di default di squid va bene ( apt-get install squid3 e via ). Ci sarebbero un po’ di cose da configurare per renderlo sicuro, ma si può soprassedere senza problemi.

A questo punto aprite un terminale sul vostro computer e digitate

Dopodiché dovete sempre importare il .pac ( questa volta con indirizzo 127.0.0.1:3128 ) e dovreste riuscire a connettervi. Un’alternativa che in generale è molto utile ( magari non in questo caso ) è fare un tunneling di tutto il traffico, senza bisogno di passare per squid, e in questo caso il comando è semplicemente

In questo caso 127.0.0.1:PORTA_LOCALE diventa il vostro proxy SOCKS e il traffico è ( come nella circostanza precedente ) interamente cifrato.

Se non avete capito niente di tutto ciò, beh, potete sempre aprire un gruppo su facebook e piagnucolare. Se siete riusciti a far funzionare il trucco vi invito a diffonderlo, se invece avete un’idea migliore segnalatemela.

Tenersi aggiornati su tutto è difficile, fortuna che per merito di un amico ho visto questo.

Una tipica reazione alle conseguenze di Flash

Perché il fatto che YouTube e altri siti abbiano in beta un lettore in HTML5 dovrebbe riguardare minimamente qualcuno?

Un po’ di storia. C’era una volta un mondo in cui i siti internet erano tutti come quelli di Geocities, in cui la gente credeva che WordArt fosse figo, che avere uno sfondo celeste “color caramella all’anice” fosse una gran figata, che gli arcobaleni fossero qualcosa più che un inno all’omosessualità.

Se ne vedevano di tutti i colori, cursori sbrilluccicosi, barre di Internet Explorer colorate, iFrames e le schifezze più aberranti.

Un bel giorno si aggiunse un’altra idea fantastica; un software prodotto da Macromedia che permetteva l’aggiunta di contenuto multimediale interagente col sito web ma immerso in esso, in modo da risultare leggermente estraneo. Chi sapeva fare con Flash in effetti faceva cose decenti, giochini, video, e tutte quelle cose fantastiche che conosciamo ora. Piano piano il web si divise in siti con lo sfondo celeste e le scritte gialle, e siti coi bottoni animati che suonavano.

A un certo punto però cominciano i problemi, in concomitanza con l’inizio del calo di popolarità di Windows, e compaiono dal nulla utenti desktop “comuni” – i.e. non più i soliti sfigati – che usano Mac OS e Linux, per cui si pone il problema di rilasciare Flash per queste nuove piattaforme. La cosa viene fatta con diligenza, ma nel frattempo la priorità rimane Windows e Flash continua ad avere sempre più features, che sono noiose da implementare in più OS contemporaneamente.

Nel frattempo Adobe compra Macromedia, per cui, come l’effetto D’Alema in Puglia, tutti i prodotti che furono di Macromedia iniziano a fare pesantemente schifo. Anche quelli che normalmente erano Adobe nonostante la potenza hanno i loro problemi ( Photoshop su Mac OS X occupa più di 1GB, qualcuno mi spieghi perché ), ma pazienza.

Il risultato è che Flash viene aggiornato sporadicamente per altre piattaforme. Gli utenti Linux su AMD64, un’architettura ormai diffusissima attendono quasi cinque anni prima di vedere una cazzo di versione del plugin di Flash funzionante! E per citare Steve Jobs, “chi se ne frega se nell’iPad non c’è Flash, Flash fa cagare”; ha ragione, anche sul fatto che la maggior parte dei crash dei browser è colpa di Flash.

Steve Jobs aggiunse anche “ormai c’è HTML5″, per cui arriviamo ai nostri giorni. Flash è un software schifoso, basato sullo stesso modello di business che ha rovinato Sun Microsystems: fare un prodotto di qualità, diffonderlo e tenere la specifica chiusa ti pone in una condizione di monopolio estremamente fragile, e prima o poi la perderai, perché qualcuno deciderà di imitarti e fare quel passo in più, aprire la specifica, che la gente ( e anche altre aziende ) apprezzerà. Microsoft c’ha provato con Silverlight, ma si sa, la reputazione di Microsoft ormai è rovinata.

HTML5 è la nuova versione della specifica HTML, che include la possibilità di infilare nelle pagine web contenuti video delegando al client la decodifica. Questo vuol dire che il video è compresso come ritiene opportuno il sito web che lo presenta, e siccome siamo nel 2010 e procurarsi un codec video è abbastanza semplice ( e anche lì quelli che hanno la specifica aperta sono quelli che sbancano ), di sicuro più semplice che aspettare che quei figli di puttana di Adobe rilascino una versione ad hoc di Flash, io metto un video sul mio sito web, e tu lo guardi se hai il codec, che è una circostanza per l’appunto quasi certa.

Il tutto ovviamente avrà una cornice AJAX perché chiaramente ci dovranno essere dei controlli ( che so, play, pausa, volume, etc. ), e questo si può fare senza problemi.

In sintesi, Flash non ha più ragione di esistere perché quasi tutto il contenuto “interattivo” della serie “io scrivo una cosa che viene memorizzata prima che io schiacci un tasto”, come GMail, WordPress, e così via, beh, è tutto gestito tramite AJAX – che sostanzialmente è JavaScript più qualche altra finezza; d’altra parte per i video probabilmente entro l’anno si vedrà un aggiornamento di Vimeo, YouTube e tutti gli altri servizi analoghi. Probabilmente le animazioni saranno un problema, ma anche lì ci sono standard migliori.

Dunque mollare Flash è come mollare Geocities e tutte quelle buone idee che hanno sempre funzionato di merda perché chi ci lavorava su non ha mai avuto un eccesso di lungimiranza a riguardo. Sul “quando” ovviamente è difficile speculare, ma intanto possiamo iniziare a dire “ciao ciao” a Flash, non ci mancherà.

Pensavo meno, in realtà è passato un anno e mezzo da questo post, che a questo punto merita qualche aggiornamento.

Quando ho sentito che con la 10.6 non ci sarebbe stato nessun cambiamento ho subito pensato “era ora”. Anche quando ho sentito il prezzo; tuttavia, per colpa degli imperdonabili ritardi dell’Apple Store di Pavia mi sono dovuto arrangiare in altro modo.

Non aggiungere nulla di vistoso in genere porta a fare grandi passi avanti, anche perché spesso a rendere tutto “migliore” è un’aggiunta inaspettata ( o meno ) nel backend; un esempio fu il complesso HAL/D-Bus su Linux qualche anno fa, che avrebbe dato un bel colpo di grazia all’usabilità di Windows, se solo i distributori di hardware si fossero degnati di distribuire driver ( o quantomeno specifiche ) in tempo.

Snow Leopard non porta rivoluzioni di nessun tipo, almeno in apparenza, però ci sono svariate cose interessanti.

Installazione, etc.

Purtroppo quasi tutto dica sull’installazione è distorto dal fatto che l’ho eseguita ( sputando sangue ) via USB.

Una cosa inedita è la possibilità di installare senza riavviare. Ovviamente è una balla, perché nel giro di 5 secondi il computer si riavvia comunque; in realtà non me ne ero nemmeno accorto, infatti quando ho visto il monitor spegnersi ho dato sfogo ad una colorita gamma di bestemmie.

In ogni caso è possibile installare sopra Leopard senza formattare, e contrariamente a quanto si può leggere on the net, non è una cattiva idea e non funziona male. Non si perdono dati, non si perdono programmi, etc.

Cosa c’è di nuovo ?

Ci sono due cose che si notano:

• Occupa meno
• È più veloce

Il tutto è imputabile principalmente al fatto che il supporto ai PowerPC è stato buttato nel cesso, col benestare di tutti i possessori di suddette macchine. Con tutto quello che ne consegue; ad esempio eliminato la distribuzione dell’intero OS con binari Universal a prova di idiota; dopotutto sarebbe stato sufficiente semplicemente distribuire due versioni, ma a questi qui piace unificare le cose.

Se no poi di che ci si vanta quando il sistema occupa la metà ?

Per il discorso “velocità” mi piacerebbe avere più voce in capitolo perché gran parte dei cambiamenti riguardano il layer di base a 64 bit, e avendo un Core Duo sono brutalmente estromesso dal club.

Niente di nuovo sull’interfaccia, se non qualche inezia e una tamarrissima ombra blu nelle finestre di Exposé.

Ad essere sincero non sono mai riuscito a trovare un uso utile per Quick Look; per vedere testi e immagini le applicazioni rispettive sono sufficientemente veloci. Ora si possono zoomare le icone direttamente dal Finder, come su GNOME, e l’anteprima viene via via riscalata; si può ingrandire un PDF fino a poterlo leggere e sfogliare le pagine “dall’icona”. Carino, ma totalmente inutile per chi ha cartelle con più di 4-5 files.

Davvero non c’è niente di nuovo ?

Nella recensione di Leopard sono stato relativamente categorico su QuickTime e da allora non ho mai cambiato opinione. La nuova versione – che nulla ha a che vedere con la vecchia, nemmeno nel codice – è tutt’altra cosa. Per cominciare, funziona.

Apple ha la mania di eliminare il più possibile le preferenze, per cui c’è un po’ da lavorare, anche perché per ora la nuova versione ha addirittura meno features della vecchia, ma per lo meno è completamente gratis; è abbastanza evidente come si siano sentiti stringere il culo dall’onnipresenza di VLC e MPlayer, per cui prima o poi un lettore decente bisognava tirarlo fuori.

Ciononostante QuickTime X permette di fare screencast del desktop, che è una di quelle cose che “quando serve non c’è mai”, per cui yeah.

Nello spirito dei ritocchi “qua e là” l’aggeggio di configurazione delle reti continua a ricevere qualche aggiustata, soprattutto nel settore WiFI, in cui sia l’autenticazione che l’eventuale segnalazione di timeout sono diventate più rapide.

Finder è stato totalmente riscritto in Cocoa imitando nel modo più fedele possibile la versione precedente, difatti è pressoché impossibile accorgersi della differenza, se non per il fatto che ( come tutto il resto ) è stato farcito di animazioni.

Cose più serie

Una cosa che non avevo notato di Leopard ( che mi ha precettato l’uso di iTerm ) è che il Terminale di OSX ha le tabs ed è più configurabile del previsto, quindi vale la pena fare un mea culpa e notarlo ora.

D’altra parte, veniamo davvero alle cose più serie. Le versioni di default di gcc e Python sono rispettivamente 4.2 e 2.6. Mi sarei aspettato gcc 4.4, ma è evidente che Apple va verso un’altra direzione. Nella fattispecie, quella direzione era già annunciata dai tempi di Leopard e si chiama LLVM, solo che all’epoca non capivo un cazzo e la cosa mi era di scarsa utilità.

Fondamentalmente, LLVM è un piccolo progetto Open Source che consiste in una VM che “simula” cose a basso livello; più che un intero computer, una CPU, ad esempio, per cui l’idea è che il compilatore non deve più compilare da sé in linguaggio macchina “al meglio”, ma è sufficiente che deleghi la cosa a LLVM. Apple spinge la cosa più in là con clang, che è un compilatore C interamente costruito su LLVM, compatibile con gcc.

A prima vista sembra che una cosa del genere vada pesantemente a scapito della performance. In realtà facendo un paio di prove coi miei soliti programmini si nota che la versione compilata con llvm-gcc è leggermente più veloce. Per dirne una, anche Adium compila più velocemente.

Per cui, con Leopard è iniziato tutto ciò, ora senza essercene accorti è diventato praticamente “la via migliore”.

XCode 3.2 non è un gran passo avanti rispetto alla versione precedente, ma “col nuovo motore” si vedono cambiamenti anche all’esterno, come, finalmente, dei messaggi d’errore utili da parte del compilatore.

In realtà i cambiamenti a livello di backend sono proprio tanti, però solo qualcuno è degno di nota, per un elenco esaustivo c’è l’ottima recensione di Ars Technica.

Conclusioni

Snow Leopard è la versione migliorata di Leopard, e ormai tutte le “novità” funzionano a dovere: Spaces funziona, Stacks è diventato quasi utile, etc.; il punto è che l’unico motivo per cui un comune mortale cui non può fottere di meno del fatto che tutto ormai è a 64bit e si regge su una VM a basso livello dovrebbe comprare la nuova versione è il prezzo, unito alla consapevolezza che “fra un po’ Leopard non sarà più supportato”.

Questo è anche confermato dal fatto che Snow Leopard è installabile senza problemi sopra Leopard, in modo che non ci siano scuse per rimanere indietro.

Come detto varie volte, da fuori sembra praticamente una release minore, per cui non ha senso dire “ehi, aggiornate, vale proprio la pena”; poco ma sicuro entro qualche mese diventerà un obbligo, per ovvi motivi.

Una recente toccata e fuga di una giornata su un computer con Linux mi ha fatto ricordare un paio di cose. Ad esempio, una pittoresca metafora: OS X è una gelateria che ha solo nocciola, e in una varietà sola; particolarmente buona eh, però se non ti piace la nocciola sei fottuto. Linux invece è una gelateria enorme piena di gusti. Il problema è che fanno quasi tutti cagare.

Non sono mai stato un Apple fanboy, e ogni giorno che passa mi convinco che chi ostenta “il nuovo mac” che s’è comprato “perché il mac è meglio” non abbia la minima idea di cosa stia parlando; tuttavia d’altra parte mi son sempre chiesto cosa spinga gli sviluppatori di certi teams ( freedesktop, ad esempio ) a cercare le peggiori tamarrate – finestre gommose, finestre con fuoco e fiamme – quando, ad esempio, i font vengono sempre e comunque renderizzati di merda. E perché la gente deve perdere tempo a fare queste schifezze quando il compositing di Linux fa acqua da tutte le parti ?

Ho sempre odiato i “pacchettoni” Apple, quelli per colpa dei quali il computer si riempie di inutili librerie ridondanti, che fanno rimpiangere le shared objects di Linux. Per chi non ha mai notato il problema, le applicazioni su OS X sono delle cartelle con dentro anche buona parte delle librerie che le applicazioni usano, per cui se cinque applicazioni separate usano una libreria di terza parte ( non Apple ) relativamente grossa, avrò cinque duplicati della stessa libreria.

Linux risolve condividendole; si risparmia spazio, ed è comodo quando devo fare un programma che usa quattro cose da una libreria esterna. Il problema è che tutto va a farsi fottere quando una libreria cambia nome; questo in genere viene risolto per tempo dagli sviluppatori, ma ci sono programmi che hanno cicli di release abbastanza lunghi ( e magari vengono usati in ambienti in cui non si è soliti aggiornare il sistema ), come ad esempio i compilatori Intel, che su Linux rimangono inutilizzabili per un po’; magari fossero open source qualcuno avrebbe risolto il problema. Quindi beh, the lord giveth and the lord taketh away.

Per onestà intellettuale è bene sottolineare che il modello “gelateria con un solo gusto” ha una valanga di svantaggi. Le scorciatoie da tastiera sono inconfigurabili ed è impossibile liberarsi dei tasti inutili ( l’invio affianco alle frecce può essere un ottimo sostituto per alt gr ) senza manomettere il kernel. Da un lato meno nerd invece ci si deve abituare a “quello che offre la casa” per svariate funzioni: iTunes fa cagare, Numbers fa cagare, e così via. Fortuna che da bravo “uomo di scienza” non ho bisogno di un word processor, perché anche Pages fa cagare. Fortunatamente è pieno di applicazioni open source perfettamente funzionanti.

L’ironia della sorte è che persino emacs compilato a mano su OS X funziona meglio che come precompilato su Debian.

Per il resto oggi ho avuto la mia prima esperienza “sensata” con Cocoa. Tutte le altre volte finivo sempre per chiudere tutto dopo un mare di bestemmie. Questa volta invece forse anche grazie ad una sorta di guida per sfigati che spiegava un paio di passaggi che mi mancavano son riuscito a capirci qualcosa.

Venendo da GTK e “gli oggetti senza gli oggetti” un toolkit che invece forza una programmazione OO è una sorta di incubo. Cocoa ha un sacco di cose che lo rendono meglio di GTK; non essendo minimamente pensato per essere cross-platform è perfettamente integrato con sé stesso ed essendo l’unica via per scrivere GUI su Mac è anche sviluppato piuttosto bene; i problemi con GTK sono infatti spesso problemi con X11 o cose simili.

Ci sono due cose che rimpiango di GTK. La prima è che con Cocoa non c’è un modo immediato di scrivere un’interfaccia grafica senza coinvolgere Xcode. Con GTK in linea di principio fare le cose “a mano” era anche l’unico modo – spesso era irritante, ma almeno “c’era e funzionava”. La cosa peggiore invece è dovuta all’approccio “it’s not a bug, it’s a feature” di come viene trattata la class inheritance nella documentazione Apple. Ovvero, se un oggetto eredita da altri sette è difficile capire a quale dei sette fa capo una certa funzione; in particolare, il lavoro inverso, “come monitoro lo stato di un pulsante o qualcos’altro ?”, è abbastanza noioso.

Il problema finale è che la documentazione è molto disorganizzata. È tanta, ma molto dispersa. Non essendoci un equivalente soddisfacente di devhelp questo è un vero e proprio palo nel culo.

Per il resto ci sono molte sorprese piacevoli. Ad esempio, la versione distribuita da Apple di gcc ha un sacco di tweaks che ottimizzano vistosamente il codice, e l’integrazione di Aqua con la riga di comando dopo un paio di anni di esperienza non è più così problematica, tanto che ritornando ad usare Linux in parallelo non si sente troppo la differenza, anche se le tty mancano un po’.

Tempo fa avevo iniziato un programmino che simulasse un ferromagnete di Ising in due dimensioni. Ho avuto due problemi: il generatore di numeri casuali era troppo lento e non avevo idea di che algoritmo usare.

In realtà il secondo problema l’avevo risolto inventandone uno che avesse più o meno il risultato che volevo. Tutt’ora la 0.1 ha quell’algoritmo; probabilmente è sbagliato, pazienza. Il primo problema invece era dovuto a troppe letture da /dev/urandom che per quanto a basso livello non potevano avere risultati affidabili.

Una soluzione temporanea è stata fregare questo generatore da un tizio della Intel, che generava tanti numeri ( anche un centinaio di milioni al secondo ) e anche se non erano poi così casuali funzionava tutto bene. Con una ricerca migliore ho trovato un generatore ben più preciso fatto da un paio di nerds giapponesi e con un README scritto in engrish.

Tutto questo pippone TL;DR per dire che ho aperto la controparte statica del blog, Happy Seppuku !

Nella sezione execute ci sono per ora un paio di programmini CPU-GPU intensivi: un ferromagnete di Ising e una goccia in moto browniano in 2D – tipo “espansione a macchia d’olio”; il primo dovrebbe funzionare decentemente in ogni computer relativamente recente, mentre il secondo – coi settaggi di default – è al limite della sensibilità ottica ( ~25 fps ), per cui probabilmente con un processore meno potente di un Core Duo da 2 GHz il programma si impiccherà.

Un paio di screenshot di inkdrop:

Qualche iterazione di inkdrop, senza alpha blending

... e con alpha blending

Aggiunto l’alpha blending il risultato è molto diverso e anche più piacevole da vedere, per quanto manchi totalmente la fluidità che fa pensare a una “goccia” ( sembra più un ammasso globulare ).

Gli attrezzi del mestiere sono semplicemente un po’ di dimestichezza col C, un po’ meno con OpenGL, e un generatore di numeri casuali potente. Non importa troppo la qualità dei numeri in questo caso, mentre è cruciale che sia veloce, infatti come esplicitato ovunque su Happy Seppuku, tutto ciò non è fatto per essere portabile, anche se potenzialmente può girare su qualunque computer recente; in ogni caso, chi ha la minima idea di cosa stia parlando è pregato di testare ( pare che ci siano problemi di qualche tipo su Linux su amd64 ) e farmi sapere.

Il ferromagnete di Ising invece funziona decentemente già circa da un mese e tutte le modifiche più recenti sono state banalità. Contrariamente alla goccia d’inchiostro è un programma irrilevante per chiunque non abbia la minima idea di cosa significhi il titolo del programma.

Prima e dopo la transizione ferromagnetica

In ogni caso questi due programmi ( e tre giochini che ho fatto tempo fa ) sono disponibili qui.

Enjoy.

Sempre sulla scia del non avere molto da fare – e poco sonno – mi sono divertito a cercare un po’ di nuove vecchie gare di sputi BSD vs. Linux.

Non che abbia cercato molto, ma questa qui è particolarmente divertente.

L’autore è un utente Linux a tempo pieno, per cui personalmente non essendo neppure io ormai un utente Linux a tempo pieno posso dichiararmi nella sua stessa situazione, senza conflitti d’interessi di sorta.

In sintesi:

1. BSD è semplicissimo
2. Crea il tuo OS
3. Velocità
4. Stabilità
5. Pacchetti Software
6. Sicurezza
7. Tutela della Proprietà Intellettuale

Veniamo ai commenti.

Semplicità, personalizzazione, pacchetti software (1, 2, 5)

In poche parole: it’s not a bug, it’s a feature. Nel post precedente criticai la scelta dei BSD di forkare tutto, kernel e userspace, creando una dispersione di lavoro immensa. Il risultato è che i comandi base GNU ( ls, cp, blabla ), mantenuti da un team molto più grande, riescono a diventare molto più immediati, e probabilmente, potendoci dedicare risorse umane, più veloci. Il risultato più immediato del BSD way of life invece è che non avendo troppa gente a disposizione se volete ls con l’output colorato dovrete attendere un po’; dopotutto è la semplicità che conta.

È molto bello anche pensare che creare più sistemi operativi ( NetBSD, FreeBSD, OpenBSD, etc. ) risponda alle esigenze di qualsiasi utenza. Dopotutto nel paese dei puffi i grafici fanno l’OS per grafici, i sysadmin fanno l’OS per sysadmin, gli sfigati faranno l’OS per sfigati. Il paese dei puffi era il mondo prima degli anni ‘90. Poi tutti hanno capito che il modello vincente era un OS che andasse bene per grafici, sysadmin e sfigati, e tutti quelli che pianificavano soluzioni “mirate” sono colati a picco ( SGI, per dirne una ). Su Linux le “scelte” si chiamano distribuzioni. Dopotutto a che pro farsi i pipponi su come debba essere il modulo ideale per la mia scheda wireless, se per vederla funzionare devo aspettare due anni, e tutto ciò perché io sono uno sfigato e ci sono poche persone come me che programmano al mio OS preferito ? Sfido a dire che per i sysadmin non valga lo stesso.

Che dire, l’importante è che funzioni, e bene.

L’esempio fatto a sostegno della tesi “creare un OS commerciale a partire da BSD è fattibile” è Mac OS X. È buffo vedere che non solo sia un ottimo esempio sia anche l’unico, per cui ok, “tecnicamente” è possibile, ma “in realtà” per avere un prodotto decente occorrono sforzi immani.

Per i pacchetti software il discorso è simile. Pensare che i ports siano un sistema figo “tanto che sono stati persino imitati da una distribuzione Linux” è una infantile e beata ingenuità. Nessuna persona nel 2009 vuole compilare tonnellate di software per installarle, e le release frequenti di TeX e OpenOffice ( due esempi di programmi mastodontici ) fanno cadere le palle a chi pensa che “ok, alcune cose le compiliamo, altre le installiamo precompilate”. Che sia compilare “a mano” o in modo automatizzato fa poca differenza. L’autore non ha evidentemente mai usato Debian.

Velocità, stabilità, sicurezza (3, 4, 6)

Tre cose che si sentono dire da anni sui BSD rispetto a Linux. Sarà vero ?

Linux è molto usato in ambienti desktop, per cui i due punti in genere vanno a farsi fottere. D’altra parte i BSD forniscono un setup minimale con pochissime applicazioni server-side, per cui la sicurezza è il solito approccio “se non giochi non perdi mai”.

Secure by default, può essere, ma sono ben convinto che con un paio di giochetti dal lato sicurezza BSD e Linux siano pressoché indistinguibili. Sulla velocità il discorso è analogo, e spesso dipende anche dall’hardware. Non solo: in genere i buchi non sono relativi al kernel ma ai programmi stessi. Una injection via web è un bug di MySQL o di Apache, e questo frega sia l’admin Linux che quello BSD. Inoltre, come prima: più persone sviluppano, più persone testano, più persone aggiustano.

La stabilità in genere è legata all’utente finale. Io voglio le ultime release, software possibilmente aggiornato ( e veloce ). Se ogni tanto crasha non è un problema. Se invece voglio puntare sul software ampiamente testato spero proprio che sarà ben più stabile e sicuro. Non è così mitologico.

Tutela della Proprietà Intellettuale (7)

Questo punto è semplicemente un problema della GPL che a modo suo cerca di imporre ai fabbricanti di hardware l’apertura del codice, al contrario della licenza BSD che permette la redistribuzione anche nella sola forma binaria. Per quello che mi riguarda la GPL è stata sacrosanta per il kernel Linux, perché è grazie a questo che molti programmatori dipendenti di importanti produttori hardware sono anche diventati sviluppatori del kernel stesso.

Se Linux fosse stato rilasciato sotto BSD dal principio molti moduli sarebbero stati nelle condizioni dei driver 3D NVIDIA e ATI: una enorme schifezza da non toccare in nessun modo, perché il padrone non vuole.

Per il resto è ampiamente mostrato che il modello open source “a tutti i costi” funziona anche da un lato economico¹, per cui esigere la chiusura del codice ( pretendendo anche che nessuno cerchi di crackarlo ) è un revocabile privilegio, e qualunque imprenditore che voglia investire nel business dei sistemi operativi deve arrendersi al fatto che il capitalismo non è “io mi arricchisco, voi state alle mie regole”, e la “tutela” della proprietà intellettuale non è un diritto naturale, ma una gentile concessione della licenza da una parte e del legislatore dall’altra.

In sintesi, se uno è un dipendente della discomafia la tutela della proprietà intellettuale rende la licenza BSD una figata. Allo stesso modo, se uno vive in un enorme palazzo governativo di una solida dittatura, beh, anche la pena di morte diventa una figata.

Dunque ?

Tutto ciò insegna che le guerre fra poveri facevano ridere nel 2002 e fanno ridere tutt’ora, ma dopotutto Internet senza flamewars sarebbe triste come un mondo senza studenti di scienze della comunicazione.

1. Persino Microsoft sta aprendo le specifiche delle nuove tecnologie. Una decina di anni fa sarebbe stata mitologia

Per i veri nerds l’estate è quel periodo dell’anno in cui si possono fare le cose che si fanno di solito, ma con molto più tempo a disposizione, e meno sensi di colpa. Incoraggiato dalla noia ho dovuto colmare le mie lacune in materia di “virtualizzazione” e ho deciso di condividere col mondo le mie esperienze in merito.

Gli ingredienti di oggi sono

• Virtualbox
• Una immagine CD di OpenBSD per i386 ( install45.iso, quella grossa )

OpenBSD: where unix meets ketamine

Un po’ di storia. OpenBSD è un unix celebre fra gli script kiddies e i vergini over 25 reso popolare da un logo particolarmente buffo ( contrariamente al pinguino di Linux, ad esempio ) e dal fatto che “sono stati trovati due soli buchi nell’installazione di default”. Era uno solo fino a poco tempo fa, che storia.

Il motivo della sicurezza di OpenBSD è lo stesso principio per cui un prete ha poche chances di prendere l’AIDS, ovvero “se non giochi non perdi mai”. Un’altra cosa folkloristica di OpenBSD è che un tempo, per qualche strano motivo, gli sviluppatori ritenevano “troppo sbatti” fare le immagini per i CD, per cui le opportunità erano l’acquisto del set, farti un’immagine a mano, o usare quelle per i floppy che si trovavano sul sito. Dopodiché passato il down da MDMA uno degli sviluppatori deve aver guardato il calendario, per la prima volta nella sua vita.

In short: sicurezza e stabilità. Sembra quasi un luogo comune, ma.

Ad ogni modo, the adventure begins !

Il primo passo è il setup, dopo una facile configurazione di virtualbox che, devo dire, è gratis e fa quello che deve fare.

Sempre al passo coi tempi

Il setup sembra Zork. È una serie di domande y/n più il partizionamento dei dischi. Ricorda molto i setup testuali di distribuzioni Linux di metà anni 90, però fatti da persone molto pigre.

Una nota di merito riguarda il partizionamento, che proprio per essere sicuri che funzioni ovunque è fatto con fdisk e usa come unità di misura di default i blocchi. Almeno FreeBSD dava la scelta. In ogni caso, fortuna che il setup non è l’unico luogo in cui per OpenBSD il tempo non è mai passato.

Dopo un pochino di y/n, spade e tesori si riesce finalmente a combinare qualcosa. Non c’è da sperare che il setup riavvii da solo, persino scrivere “reboot” era troppo.

Sounds familiar ?

Prima di arrivare a qualcosa di confrontabile con lo screenshot bisogna fare un paio di cose e ringraziare virtualbox per il suo router virtuale, senza il quale non avrei potuto installare un beneamato cazzo.

Il prompt che ci si trova davanti è una banalissima ksh ( “# _” è il massimo che si può ottenere ), che oltre a non avere niente di utilizzabile non credo sia più sviluppata. Chissà perché.

Molte altre configurazioni di base non sono poi così intuitive. Contrariamente alla scelta che ci si ritrova con Linux i layout per la tastiera sono pochini e nessuno funzionava bene. L’unico editor di base installato era vim ( che personalmente non sopporto – e non so usare ), e per altro coi vecchi comandi, quindi niente backspace o invio, troppo avanzati.

L’aggeggio per installare i pacchetti si chiama pkg_add, e ricorda molto quello di Slackware. Il che vuol dire “no pacchetti, no party” ( anche se non sono così pochi ).

Sull’uso in generale difficile andare oltre, anche perché è impensabile pretendere “calcoli intensi” da una virtual machine con 64MB di RAM, però si possono puntualizzare alcune cose.

La prima è che gli sviluppatori di OpenBSD non hanno idea del significato della parola “utente tipico”, e nello spirito di “it’s not a bug, it’s a feature” la confondono con “libertà di scelta”. Che è come dire che siccome è pieno di case di vario tipo che puoi pensare di progettare, per ora stai pure in una tenda.

Non esiste un setup decente, il che più che ad un OS sicuro “per sviluppatori” si addice ad un brutto ricordo degli anni 90: l’installazione tipica installa pochissime cose. Per la versione i386 è difficile persino pensare di farne un uso come “server domestico”, vista la ben nota scarsa compatibilità hardware ( per non parlare quindi di un uso su un laptop ). E poi perché usare gcc 3.3 ? Il 4 non è abbastanza stabile ?

Proprio per questioni cronologiche non si capisce a chi sia rivolta la versione i386, visto che al login chiede persino “che tipo di terminale vuoi ?”. Come se nel 2009 una persona qualunque sulla ventina conosca le varie differenze.

Per quanto riguarda il networking ci sarebbe una nota a margine abbastanza spassosa: molti dei router commerciali montano unix per questioni di “versatilità”. Non ho mai visto BSD su uno di quegli aggeggi, mentre si vedono molte distribuzioni Linux. Il fanboy BSD potrebbe dire che “non montano BSD perché sono pigri”. Può essere anche vero, però se un OS fa cagare come ambiente desktop ci si immagina che possa fare scintille sui sistemi embedded. Se poi si scopre che i sistemi embedded commerciali snobbano i BSD, beh.

Diciamo la verità, OpenBSD attira abbastanza per la questione “strong cryptography” però nessuno ha mai capito a cosa serva tutto ciò. In realtà neppure io ho investigato più di tanto, ma se da una qualsiasi distribuzione Linux è facile criptarsi tutto il filesystem / ( lo feci anni fa, ovviamente con l’eccezione ovviamente del kernel e di un paio di oggetti di avvio ) non si può andare troppo oltre, anche se è notevole il fatto che la libreria di default includa numerose funzioni per cifrare dati al volo con una bella scelta di algoritmi.

È più che apprezzabile che ci siano progetti ( pure se scarsamente sviluppati ) che ambiscono a creare distribuzioni basate su kernel BSD ( Debian/kFreeBSD, Gentoo/OpenBSD ), perché pure se il kernel BSD è effettivamente migliore su certi fronti del kernel di Linux, l’userspace vanilla è quasi tutta da buttare nel cesso, praticamente per quasi tutti i tipi possibili di utenza.

Tempo fa avevo accennato ad un po’ di cazzate che mi divertii a fare con Python e matplotlib, per la serie “facciamo a meno di scilab”. Devo ammettere che non avendo la minima idea di dove mettere le mani per fare un qualche tipo di “intero a risoluzione infinita” e qualsiasi altro complicato algoritmo numerico da informatico, beh, Python fornisce un’ottima alternativa alla pigrizia.

L’idea momentanea era la seguente: siccome è ridicolo vedere uno sproposito di programmini in java per simulazioni numeriche ( con qualche bel disegnino, magari ), perché non farne uno in un linguaggio che non faccia vomitare ? Dopotutto non deve essere troppo difficile.

Sembrano anche esserci degli esempi funzionanti su Internet. Provando quel programmino insospettisce un po’ che senza un minimo di sleep l’animazione di una sinusoide che va avanti indietro risulti così fluida – e neppure troppo; dopotutto qualsiasi programma OpenGL banale richiede un refresh sincronizzato con la complessità del disegno; per disegnare qualcosa di stupido almeno quanto una svastica rotante ( di circa un grado per frame ) ci vuole un refresh dell’ordine del ms, per la cronaca.

La maestosa inculata è che a quanto pare matplotlib non è fatta per animazioni “complesse”, ma a quanto pare nemmeno per animazioni semplici. Certo, i grafici sono carini, ma forse conviene evitare qualsiasi cosa si muova. In effetti ho anche pensato che fosse un problema di backend, ma data la pigrizia non ho voglia di sbattermi a cercarne uno decente¹.

Dunque, il problema è – se ne vedon tanti² – fare un coso che simuli un ferromagnete di Ising in due dimensioni. La soluzione è calzata in un centinaio di righe di C, per quanto riguarda il solo scheletro. Per ora l’unica funzione che lavora fa questo:

Ovvero, “riempi a caso in bianco e nero”. Quando capirò come far interagire gli spin probabilmente la cosa si farà più interessante, ma per ora ci si accontenta. In ogni caso non sembra avere grossi problemi di performance, nemmeno con una matrice 100 x 100.

Sempre in tema OpenGL, avevo in mente di fare anche una versione di Pong e una di Tron ma penso che rimanderò.

In realtà era tutta una scusa per testare il plugin che colora la sintassi, ma dopotutto, dopo Michael Jackson e il papa che bestemmia dopo essersi rotto la mano, beh, le notizie sono finite da un pezzo.

1. compito per casa per chiunque usi Linux/*BSD: provate questo programmino, magari funziona in modo dignitoso
2. questo è un esempio, fatto molto bene, fra l’altro

Non ho la minima idea del perché la mia cartella htdocs del sito fosse in 066 ( che per quelli che hanno una vita sociale vuol dire “con permessi di lettura e scrittura da parte di altri ma non da me” ), ma questo spiega perché il mio fottuto RSS non funzionasse, anche se non spiega perché non me l’abbia fatto notare nessuno.

THIS IS MALICIOUS CODE: DO NOT WANT

Anyway, come si può notare su google, gli amici adsttnmq1 e sdioyslkjs2 fanno qualcosa in più che non semplicemente rompere gli RSS e le palle; ad esempio, riempiono, oltre all’RSS, tutte le pagine del sito infettato con una lista di link spazzatura; sfortunatamente nel mio caso ( e probabilmente quello di chiunque usi wordpress ) tale lista andava a finire sotto </html>, per cui i vari link non erano cliccabili, ma d’altra parte non erano manco visibili, quindi non so da quanto tempo quella merda fosse qui.

Il problema dunque è che non ho idea di come tutto ciò sia finito qui, ma se può consolare è stato sufficiente impostare un po’ i permessi e dare un’occhiata ai vari file php fondamentali ( soprattutto alle date di modifica ).

« Cose più vecchie