Se fossi /dev/urandom
inonderei la terra

divenendo /dev/null
inghiottirei il mondo

mutando in /dev/mem
dimenticherei ogni cosa

“Panic!”

Se_fossi

Non c’era verso per compilare il dannato 2.6.14, ho cambiato di tutto in quel codice.
Alla fine mi decido a mandare quel report in lista.

Stamani svegliandomi alle 5 decido di compilarlo. Come al solito nulla. Ero arrivato a patcharlo fino alla 2.6.15-rc7. Stesso errore.
Ma emerde mi ha salvato, ecco come e’ andata:

“Forse sono gli header, non so che c’entrano, ma potrebbero essere gli header in /usr/include”.
Bene:
emerde linux-headers-2.6.15_rc6.ebuild
Ed egli comincia a scaricare il tar.bz2 del 2.6.14 per poi patcharlo. Lo fermo e gli dico:

“Aspetta, ti aiuto io: cp /usr/src/linux-2.6.14.tar.bz2 /usr/portage/distfiles/”

Lui mi ringrazia di cuore e continua il download delle patch fino a quando non si accorge della verita’:

MD5 CHECKSUM ERROR

Il tarball che usavo da un mese del 2.6.14 era danneggiato!

Non ho idea di come possa essere accaduto, ma so’ benissimo perche’ non me ne sia mai accorto:
1) tar decomprimeva perfettamente
2) Le patch applicate da ketchup andavano a buon fine
3) L’errore che ottenevo era:

include/asm-generic/pgtable.h:114: Error: no such instruction: `static inline void ptep_mkdirty(pte_t *ptep)'
include/asm-generic/pgtable.h:115: Error: junk at end of line, first unrecognized character is `{'
include/asm-generic/pgtable.h:116: Error: invalid character '_' in mnemonic
include/asm-generic/pgtable.h:117: Error: invalid character '_' in mnemonic
include/asm-generic/pgtable.h:118: Error: junk at end of line, first unrecognized character is `}' ~> make[1]: ***


In pgtable.h riga 114 la funziona ptep_mkdirty era definita in modo perfetto…
peccato solamente che nelle nuove versioni del kernel quella funzione non esiste piu’.

In sostanza, Tar scompattando il tarball danneggiato, codava codice inesistente.

Ora, quello che piu’ mi duole e’ il fatto che abbia sovrascritto il vecchio tarball con una nuova copia. Fino ad oggi non avrei mai potuto pensare che la decompressione di un tarball danneggiato, che non da’ segni di errore, possa arrivare a tal punto.
“Ovviamente” la nuova copia del tarball compila.

Reboot.

Per ora non posso fare altro che ringraziare Emerde, tar e /dev/urandom.

GRAZIE DI TUTTO Tar il Bizippo

=spam [Msgs:34 New:34 1.4M]

Velocita’ instantanea Spam = Vs = 1.4M / 1 gg
Accelerazione Spam = As = 2.7182818284590 M*gg^-2

AAaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhh

ASSASSINI!

IPV6 MERDA MALE MALE MORTE

E’ PAZZESCO
P A Z Z E S C O

Hanno fatto una merda, hanno complicato TUTTO.
Perche’ usare 128bit per un indirizzo IP????????????
NON C’E’ BISOGNO DI 340282366920938463463374607431768211456 (2^128) di indirizzi ip,
bastava semplicemente un ip da 64bit se proprio si voleva allargare di molto
il range. MA NO, DAI, USIAMO QUATTRO INTEGER da 32bit, cosi’ siamo piu’
felici. Per fare una semplice operazione di somma o di sottrazione bisogna
lavorare con 4 int, e quindi se uno non vuole impazzire con le divisioni deve
usare le libgmp: Gnu Mathematic Precision, una libreria che lavora con numeri
che tendono all’INFINITO.

Hanno reso TUTTO automatico, per non far funzionare NULLA. Adesso esiste
l’addrconf stateless che ti gestisce automaticamente gli indirizzi da
prendere, poi non c’e’ piu’ bisogno dell’arp ma c’e’ il NDP che lavora
in MULTICAST, ale’ o/

Ancora nel 2004 ci sono RFC che dichiarano pezzi di ipv6 DEPRECATED
e propongono dei sistemi alternatici che sono ancora UNDER DEVElOPMENT.

Ora nel concreto:

Per mandare dei semplici pacchetti udp in broadcast devo usare il
MULTICAST, e devo stare attento alla configurazione automatica del kernel e
non togliere l’ip con SCOPE link-local perche’ la SCOPERTA DEL VICINATO non
funzionerebbe, perche’ il broadcast non esiste piu’.

Quindi per usare il vecchio semplice broadcast ho dovuto scrivere +100 righe
di codice dove per l’ipv4 ne uso QUATTRO.
DANNAZIONE io voglio mandare solamente un pacchetto a quei dannati di nodi che
mi stanno accanto, non voglio usare il MULTICAST.
Ma vabbe’…

Impazzendo col caffe’, alla fine il codice ti e’ sempre fedele.

Parlando con dei tizi vengo a scoprire per caso che nel Settembre del 2004 e’
apparso un nuovo RFC che dichiara deprecati gli indirizzi site scoped, questo
significa che gli indirizzi che potevano essere utilizzati per creare una
sottorete privata sono considerati DEPRECATI.
BENE! ma allora come faccio a creare una sottorete privata che sia separata da
Internet?
Mi rispondono dicendo di farmi dare dal mio ISP un’allocazioni di idirizzi ip
da usare per la rete privata.
ahahaha, che soluzione stupenda.
Dopo un intero pomeriggio di lacrime e sudore, riesco a fare capire ai tizi che mi SERVE
ASSOLUTAMENTE avere una sottorete privata per una fottutissima mesh network
dove ogni nodo puo’ collegarsi ad internet.
Cosa mi rispondono?
> Ah, perche’ non lo dicevi prima?
> Si, allora hai un problema.
Ecco, LO SO GIA’ CHE HO UN PROBLEMA A CAUSA DEL VOSTRO FOTTUTISSIMO AMATO
IPV6, THE NEXT GENERATION INTERNET PROTOCOL.

Forse a Settembre di quest’anno esce un altro RFC che dice che i site scoped
addresses non sono piu’ deprecated.

A parte questo decido di fottermene della compatibilita’ con Internet e quindi
rinunciare ad una sottorete privata.

Peccato pero’ che il multicast mi viene in aiuto confermando ancora una volta
quanto sia misericordioso l’Ipv6:
Visto che con l’Ipv6 un interfaccia puo’ avere piu’ di un indirizzo ip
associato ad essa, quando viene mandato un pacchetto in un multicast
LINK-SCOPED asdasd, il nodo che lo riceve vede come ip mittente solo l’ip
link-local.
Ora gli indirizzi link-local non servono ad un emirito NULLA poiche’ sono
validi solamente sul link: Se c’e’ il nodo x collegato ad y allora possono
comunicare tra loro usando un ip link-local, ma se c’e’ z collegato solo a y,
x non puo’ parlare con il fottutissimo z usando un link-local ip. OK?
PERO’ il link-local non si puo’ togliere, perche’ se no MUORI. I furbastri
dell’ipv6 hanno deciso di togliere l’arp ed usare il Neighbourd Discovery
Protocol che senza indirizzi link=local NON FUNZIONA, percio’ NON FARE MAI UN
ip addr flush dev eth0, o filtrare il traffico di indirizzi che incominciano
con FE80:, NON FUNZIONA NULLA.
Ora ritornando a noi: se non voglio ricevere come ip mittente un ip link-local
devo usare un multicast diverso.
BENE, USO il SITE-SCOPED.
PECCATO CHE NON FUNZIONI! E CHE IL KERNEL MI MANDI AFFANCULO.

Conclusione?
Morte all’Ipv6. Netsukuku girera’ sull’Ipv4, almeno fino a quando un altro RFC
non decidera’ di sistemare un po’ le cose.
L’unico motivo che mi spingeva ad usare l’ipv6 erano quei bei indirizzi grassi
e tozzi, ma ora BASTA.

GRAZIE, dico grazie a tutti gli sviluppaturi dell’ipv6.

Che sia benedetto.

Pace, Amore e Prosperita’ e morte all’Ipv6

Vi ricorda qualcosa il 6? Ipv666