Re: [Hackmeeting] censura di piratebay e chiusura di colombo…

Delete this message

Reply to this message
Author: NeuraL
Date:  
To: hackmeeting
Subject: Re: [Hackmeeting] censura di piratebay e chiusura di colombo bt
On Tuesday 26 August 2008, Massimiliano Leone wrote:

> Ma il garbage collector non sta ai comodi dell'incosciente, eh. Poi
> quando la macchina si schianta per "out of memory", magari il
> programmatore incosciente capisce che è bene sapere cosa è un
> puntatore e cosa è un riferimento (che usa java), come funziona il
> deferenziamento, eccetera, eccetera.


Certo, e se non lo comprendi molto bene, puoi fare memory leak ANCHE con
i garbage collector, come ben saprai. Quindi mi permetterai di dubitare
della effettiva utilita' di certi meccanismi che aggiungono solo
overhead e basta. Preferisco sbattermi con il formalismo esplicito
delle free.

> > Dipende sempre da che cosa ci vuoi fare.
> > Java e' un po' il BASIC degli home computer di 20 anni fa, in un
> > certo senso.
>
> ci vuole del coraggio barbaro per paragonare java al basic eh...


Ah no? :-)

> freenet è stato scritto 10 anni fa da gente che non sapeva
> programmare, e usa delle costruzioni che anche all'epoca erano


Piu' semplicemente, il linguaggio che hanno usato era inadatto per il
lavoro che volevano intraprendere. Solo a un pazzo verrebbe in mente di
usare java per codare un protocollo di rete o un servizio dove latenze
e immediatezza delle transazioni dei dati dovrebbero essere un
requisito imprescindibile, soprattutto se si parla di centinaia di
client a botta, da gestire velocemente e senza troppi fronzoli.

> viste come fumo negli occhi. Si, è stato scritto da gente che
> voleva ottenere tutto e subito senza avere arte nè parte.
> Risultato: è lento. L'avessero fatto in C, tutti gli utilizzatori
> avrebbero avuto le macchine bucate. Trovatevi contenti.


Opinabile. I bachi ci sono sempre. Fanno parte della programmazione,
risolverli, pure. Magari avrebbero guadagnato una comunita' di gente
motivata invece che scoglionata.
O forse vorresti dire che, usando java, hanno scelto un modello di
programmazione intrinsecamente SICURO e quindi era irrilevante?
Non lo trovi presuntuoso da parte loro? Ovviamente tutto ha un costo,
che poi era quello che dicevo.

> Dipende: prima di fare un cast ci si pensa quattro, non due volte.
> Chi sa fare OOP non fa i cast, semmai si crea altre gerarchie.


No guarda, realisticamente, piuttosto che rivedere la gerarchia delle
classi e ristrutturare in maniera piu' performante i metodi interni,
la gente fa dei cast e se ne sbatte, fidati, non gli viene neanche in
mente di riscrivere in modo diverso tutto l'ambaradan.

> > Il problema dal punto di vista del programmatore java e' che
> > molte cose non si possono fare (cose tipo i template stile c++)
>
> Esistono i Generics da 4 anni, implementati su tutte le classi


Si ma COME vengono implementati, sotto, i generics? Guarda che non e'
per niente la stessa cosa. Dico che per sua natura, JAVA, non puo' fare
certe cose, o meglio, hanno SCELTO di non fargliele fare perche'
avrebbero contaminato la sua PUREZZA di linguaggio OOP, dinamico,
virtualizzato. Quindi hanno implementato delle astrazioni per
rimpiazziare le cose mancanti ... il risultato COMUNQUE e' che non sai
bene come vengono gestite le cose a basso livello ed e' molto facile,
in Java, cadere in trappole e penalita' sulle prestazioni. Infatti pure
io credo che java sia tutto il contrario della facilita' d'uso. Sono
scelte pero', sia chiaro. Se usi java fai la scelta di avere un
linguaggio fragile che al minimo errore diventa un bradipo di lentezza;
in C++ sai che se sbagli l'applicazione schianta in mille modi diversi
ma lo fa molto velocemente :-)

> Quali sono le altre cose che non si possono fare ?

Lasciamo perdere. Hai completamente mancato il ragionamento che stavo
facendo :-)

> Io ci controllavo Netfilter, da java, tramite hook java/C... fai
> tu.


Appunto, per questo genere di cose java va benissimo.
Sia chiaro, non e' che ti serve sempre fare le cose in maniera
performante. MA SCRIVERE UN INTERO PROTOCOLLO DI RETE IN JAVA E'
CRIMINALE :-))) Te lo vedi il tcp/ip scritto in java? Secondo te
perche' sarebbe lento anche su macchine performanti tipo i server?

> noi ammettiamo le limitazioni di java.. ad esempio non metterremmo
> mai un servlet container su un pentium166, ma nel 2008 ancora c'è
> gente che li usa? si, ce n'è, ahinoi.


Si vabbe', prova a chiedere in giro quanto fai ingolfare un server a far
girare un servizio importante in java (usato da persone > 1).

> > Infatti un linguaggio che produce codice indiretto (poco
> > tracciabile)
>
> definisci "poco tracciabile"... usato mai un qualsiasi reverse
> engineer per java? ci sono di quelli che ti creano anche i grafici
> uml delle classi.. ma che java usate voialtri?


Si beh, in C basta leggere il codice che ti sta sotto il naso e sai cosa
fa, che giro fanno i dati e sai come tagliare e ricucire per ottenere
quello che desideri. Io non fido di un linguaggio che richiede l'uso di
un decompilatore per verificare ogni volta cosa ha combinato. Poi fai
tu :-)

> > ausa facilmente troppi accessi "compulsivi" alla memoria e questo
> > fa serare le pipeline del processore.
>
> un pentium166 forse, non una QUALSIASI Sun


Nessuno usa NIAGARA, se non per sturare i cessi :) Sto parlando ANCHE di
un Core 2 quad. Rileggiti l'archiettura dell'ultima generazione di
processori (intel, amd), se hai tempo... capirai che la loro velocita'
si basa essenzialmente su quanto il processore riesce a tenere sature
le pipeline, altrimenti va tutto in merda e diventa piu' lento di un
pentium 166. L'hyperthreading non e' la risposta.
Java tende a generare codice lento per questo motivo, non solo perche'
c'e' una virtual machine di mezzo (un processore virtuale da eseguire
su quello reale) ma proprio perche' i paradigmi con cui e' stato
generato quel codice (tradotto x86 finche' ti pare) valgono per il
processore virtuale e NON necessariamente per far andare a regime
quello reale. L'obbiettivo di un qualsiasi compilatore C invece e
generare codice efficiente per l'architettura su cui gira,
direttamente. Risultato: se in java non ti fai un culo al cubo
studiando al microscopio il codice generato, rifacendo classi e
sventrando il tuo codice, hai cache miss a votamazza, un uso
disorganizzato della memoria esterna significa il suicidio per un
microprocessore MODERNO. Mettici anche tutte le penalita' di run-time
dell'archiettura java e il quadretto e' fatto.
E' piu' chiaro adesso?

> Si traduca in: se programmi male, fai cagate. Ma non c'era bisogno
> di scomodare l'ennesimo flame su java per saperlo.


In C le cagate sono EVIDENTI a tutti. Sono scritte e si possono
cambiare.
In java devi cambiare le specifiche del linguaggio (hint: e' una cosa
che non puoi fare).


> nel mercato server dei grandi portali no?
> ebay, google, oracle, vodafone, tim, ibm? ah! questi sconosciuti!


Secondo te quelli che citi usano java per l'implementazione del core sw
delle loro applicazioni? Sei proprio sicuro di questo? Magari qualche
interfaccia e' una cosa un po' diversa eh. Sai io potrei anche scrivere
un database relazionale in JAVA ma poi nessuno lo userebbe
(giustamente).

> "date a cesare quel che è di cesare", eccetera.


Se non fosse che io ho cercato di farlo e mi sei venuto a bacchettare i
coglioni avrei anche lasciato perdere :)

> E basta co sti flame inutili eh. Che io ne ho le scatole piene di
> leggere strafalcioni, e di dover rispondere per rimediare a queste
> offese al pudore.


il pudore dei piu' va offeso, SEMPRE, possibilmente a morte.

Dai,
baci :-)

--
... "Nel tempo dell'Inganno Universale, dire la verita' e' un atto
rivoluzionario" - George Orwell

[Neural]
Mailbox: neural@???
GPG Key Available: gpg --recv-key DB75A587
Key fingerprint = A2AB 88A2 B9C5 3247 AD4E 3221 9152 9340 DB75 A587