Forum libero

Scritto da:
> Scritto da: Renton Thurston
> > Scritto da:
> > > Scritto da: Renton Thurston
> > > >

Vai alla pagina
Visualizza embed

> > >
> > > portasse un solo dato a sostegno delle sue farneticazioni non sarebbe male
> >
> > Porta esperienze personali che ha avuto con questa gentaglia. Non è che te ne vai in giro con un registratore in tasca tutto il giorno...
> >
> > Speriamo semmai che sia un matto e che le sue siano davvero farneticazioni perché se non lo è e se ha detto la verità circa quello che sa e le esperienze che ha raccontato allora _davvero_ questa crisi è stata pianificata e _davvero_ è solo l'inizio della file.
>
> ok, ma la domanda è perchè?

In effetti il _perché_ me lo sono chiesto anche io. Non è certo il risultato del pensiero di una persona razionale.

D'altra parte è vero che c'è gente come quella che descrive, che prova disgusto verso i poveri, che si ritiene superiore (come i nobili di un tempo), che non sopporta l'idea che i poveri possano vestirsi come loro (vedi esempio postato dalla suora ieri) che possano godere degli stessi diritti, ecc.
Era il modo di pensare di quasi la totalità dei nobili passati. Probabilmente la rivoluzione francese gli sta ancora rodendo il culo.

> per avere un popolo più schiavo?

Anche mero disprezzo. Inoltre un popolo affamato e povero ha anche molti meno accessi alla cultura e perciò è molto più pilotabile.
D'altra parte uno di quelli che questo tizio cita è un pirla dell'Opus Dei... ovvero gente che prospera sull'ignoranza altrui.

> può essere, ma davvero il sistema reggerebbe o semplicemente esploderebbe, lasciando con nulla in mano chi ha progettato il tutto?
> a me convincie davvero poco

I feudatari, la nobiltà, ecc... sono stati parte della storia dell'uomo fino all'altro ieri... evidentemente per reggere regge.

Scritto da:
> Scritto da: Renton Thurston
> >

Vai alla pagina
Visualizza embed

>
> portasse un solo dato a sostegno delle sue farneticazioni non sarebbe male

Porta esperienze personali che ha avuto con questa gentaglia. Non è che te ne vai in giro con un registratore in tasca tutto il giorno...

Speriamo semmai che sia un matto e che le sue siano davvero farneticazioni perché se non lo è e se ha detto la verità circa quello che sa e le esperienze che ha raccontato allora _davvero_ questa crisi è stata pianificata e _davvero_ è solo l'inizio della file.

Scritto da: avvelentani
> http://my.opera.com/altg/blog/2013/01/16/that-was-...
>
> Doctors of the mind would never find it a good idea, but bringing memories on, rehearsing them to acknowlegde your faults, doesn't seem to change much.

Se avesse usato Dart tutto questo non sarebbe mai successo.

Scritto da:
> inattivo dal 2002 o poco più perché mio padre vuole dei file che non si è salvato, ma ciccia.
>
> Non si avvia il BIOS, non c'è il BEEP di approvazione. C'è una qualche possibilità di avviarlo prima di regalarlo a quelli che restaurano computer?
>
> Dovessi togliergli l'hard disk, a cosa potrei collegarlo per prenderne i dati?

In teoria è un normale disco IDE, quindi qualunque cosa che supporti i dischi IDE va bene.

Scritto da: Seu
> Scritto da: Renton Thurston
> > Scritto da: Seu
> > > Scritto da: Renton Thurston
> > > > Scritto da: Seu
> > > > > Scritto da: Renton Thurston
> > > > > > Scritto da:
> > > > > > > tu confondi compilare codice macchina e compilare bytecode
> > > > > > > retroingegnerizzare codice c è un casino e porta a risultati non consistenti
> > > > > > > retroingegnerizzare codice java è molto più semplice, ci sono programmi appositi e ti restituisce l'originale, a meno della semantica associata ai nomi delle entità coinvolte
> > > > > >
> > > > > > No non confondo proprio nulla.
> > > > > > La decompilazione dipende dal compilatore usato. Se il compilatore è buono e il bytecode è abbastanza base (ovvero è composto da operazioni semplici, come è l'assembly di un processore che puoi scegliere a caso) non hai grosse differenze fra decompilare codice macchina o decompiare bytecode. Alla fine il bytecode di una macchina virtuale lo puoi vedere come un assembly per una macchina che non esiste. Non è necessario copiare Java, io pensavo più a LLVM che come forse sai ha diversi front-end in diversi linguaggi fra cui C/C++, persino Erlang e converte tutto in una rappresentazione intermedia che assomiglia molto ad un assembly per una macchina che non esiste.
> > > > > >
> > > > > > Il punto comunque non è questo... qualsiasi programma può essere decompilato con un discreto sforzo, alcuni rendono il lavoro più difficile di altri, ma di certo è più complicato che capire codice javascript in chiaro o semplicemente "minimizzato".
> > > > > >
> > > > > > > > È più o meno come cercare di tornare indietro dal codice macchina ad un linguaggio ad alto livello... qualcosina la puoi anche fare, ma poi vai a capire tu il codice che ne salta fuori.
> > > > > > >
> > > > > > > vedi sopra
> > > > > >
> > > > > > Vedi sopra. L'obiettivo non è rendere impossibile la decompilazione (cosa non fattibile, in alcun linguaggio, in alcun assembly), ma renderla abbastanza difficile da renderla poco viabile. E comunque non è l'unico vantaggio di questa struttura a macchina virtuale.
> > > > > >
> > > > > > > e tu speri di riuscire a tipizzare fortemente a tempo di compilazione un linguaggio tipizzato debolmente?
> > > > > > > è semplicemente impossibile, mi immagino un campo di input in cui puoi inserire "1" oppure "a"
> > > > > > > come lo compili? concatenando stringhe o sommando numeri? come lo decidi?
> > > > > >
> > > > > > Non è così difficile come credi. Ti ricordo che qualsiasi linguaggio dinamico, per poter eseguire il tuo codice, alla fine DEVE tipizzarlo, e DEVE fare tutti i cast del caso... per la semplice ragione che la tua CPU _è_ tipizzata e ragiona su dati tipizzati. Non hai registri di CPU "dinamici", tutto alla fine deve convertirsi in una sequenza di istruzioni che hanno a che fare con numeri o stringhe. I linguaggi dinamici semplicemente si fanno carico di pensare per te quali tipi inserire, come e come usarli o convertirli di volta in volta. Questo li rende solitamente lenti e rendono la loro programmazione prona ad errori. Approcci stile Go e Scala sono più intelligenti... i tipi ce li hai ancora (sono staticamente tipizzati), ma nei limiti del possibile il linguaggio li assegna automaticamente cercando di capire che tipo è da come tu usi quei dati risparmiandoti di scrivere molte ovvietà e dandoti l'impressione di lavorare in un linguaggio dinamico.
> > > > > >
> > > > > > Un esempio di compilatore che già lo fa è proprio LLVM.
> > > > > > http://en.wikipedia.org/wiki/LLVM
> > > > > > Come puoi facilmente vedere è in grado di compilare anche Python che ha tipi dinamici. Vedi, non è impossibile. Anzi, come VM potrebbe probabilmente tranquillamente starci quella di LLVM. Fra l'altro da quanto ne so LLVM è un ottimo compilatore che spesso raggiunge e a volte oltrepassa in quanto ad efficenza persino i compilatori nativi in C.
> > > > >
> > > > > Sei proprio un rosikatore professionista
> > > > >
> > > >
> > > > Zitto, sto inventando il WEB 3.0
> > >
> > > È già iniziato, dovresti dedicarti al web4.0
> > >
> >
> > Ah. Ok. Sto inventando il WEB 4.0
>
> Casualmente ho un hd rubato pieno di agenti semantici automatici... Interessa l'affare?




Ma che roba è?

Scritto da: Seu
> Scritto da: Renton Thurston
> > Scritto da: Seu
> > > Scritto da: Renton Thurston
> > > > Scritto da:
> > > > > tu confondi compilare codice macchina e compilare bytecode
> > > > > retroingegnerizzare codice c è un casino e porta a risultati non consistenti
> > > > > retroingegnerizzare codice java è molto più semplice, ci sono programmi appositi e ti restituisce l'originale, a meno della semantica associata ai nomi delle entità coinvolte
> > > >
> > > > No non confondo proprio nulla.
> > > > La decompilazione dipende dal compilatore usato. Se il compilatore è buono e il bytecode è abbastanza base (ovvero è composto da operazioni semplici, come è l'assembly di un processore che puoi scegliere a caso) non hai grosse differenze fra decompilare codice macchina o decompiare bytecode. Alla fine il bytecode di una macchina virtuale lo puoi vedere come un assembly per una macchina che non esiste. Non è necessario copiare Java, io pensavo più a LLVM che come forse sai ha diversi front-end in diversi linguaggi fra cui C/C++, persino Erlang e converte tutto in una rappresentazione intermedia che assomiglia molto ad un assembly per una macchina che non esiste.
> > > >
> > > > Il punto comunque non è questo... qualsiasi programma può essere decompilato con un discreto sforzo, alcuni rendono il lavoro più difficile di altri, ma di certo è più complicato che capire codice javascript in chiaro o semplicemente "minimizzato".
> > > >
> > > > > > È più o meno come cercare di tornare indietro dal codice macchina ad un linguaggio ad alto livello... qualcosina la puoi anche fare, ma poi vai a capire tu il codice che ne salta fuori.
> > > > >
> > > > > vedi sopra
> > > >
> > > > Vedi sopra. L'obiettivo non è rendere impossibile la decompilazione (cosa non fattibile, in alcun linguaggio, in alcun assembly), ma renderla abbastanza difficile da renderla poco viabile. E comunque non è l'unico vantaggio di questa struttura a macchina virtuale.
> > > >
> > > > > e tu speri di riuscire a tipizzare fortemente a tempo di compilazione un linguaggio tipizzato debolmente?
> > > > > è semplicemente impossibile, mi immagino un campo di input in cui puoi inserire "1" oppure "a"
> > > > > come lo compili? concatenando stringhe o sommando numeri? come lo decidi?
> > > >
> > > > Non è così difficile come credi. Ti ricordo che qualsiasi linguaggio dinamico, per poter eseguire il tuo codice, alla fine DEVE tipizzarlo, e DEVE fare tutti i cast del caso... per la semplice ragione che la tua CPU _è_ tipizzata e ragiona su dati tipizzati. Non hai registri di CPU "dinamici", tutto alla fine deve convertirsi in una sequenza di istruzioni che hanno a che fare con numeri o stringhe. I linguaggi dinamici semplicemente si fanno carico di pensare per te quali tipi inserire, come e come usarli o convertirli di volta in volta. Questo li rende solitamente lenti e rendono la loro programmazione prona ad errori. Approcci stile Go e Scala sono più intelligenti... i tipi ce li hai ancora (sono staticamente tipizzati), ma nei limiti del possibile il linguaggio li assegna automaticamente cercando di capire che tipo è da come tu usi quei dati risparmiandoti di scrivere molte ovvietà e dandoti l'impressione di lavorare in un linguaggio dinamico.
> > > >
> > > > Un esempio di compilatore che già lo fa è proprio LLVM.
> > > > http://en.wikipedia.org/wiki/LLVM
> > > > Come puoi facilmente vedere è in grado di compilare anche Python che ha tipi dinamici. Vedi, non è impossibile. Anzi, come VM potrebbe probabilmente tranquillamente starci quella di LLVM. Fra l'altro da quanto ne so LLVM è un ottimo compilatore che spesso raggiunge e a volte oltrepassa in quanto ad efficenza persino i compilatori nativi in C.
> > >
> > > Sei proprio un rosikatore professionista
> > >
> >
> > Zitto, sto inventando il WEB 3.0
>
> È già iniziato, dovresti dedicarti al web4.0
>

Ah. Ok. Sto inventando il WEB 4.0

Scritto da:
> tu confondi compilare codice macchina e compilare bytecode
> retroingegnerizzare codice c è un casino e porta a risultati non consistenti
> retroingegnerizzare codice java è molto più semplice, ci sono programmi appositi e ti restituisce l'originale, a meno della semantica associata ai nomi delle entità coinvolte

No non confondo proprio nulla.
La decompilazione dipende dal compilatore usato. Se il compilatore è buono e il bytecode è abbastanza base (ovvero è composto da operazioni semplici, come è l'assembly di un processore che puoi scegliere a caso) non hai grosse differenze fra decompilare codice macchina o decompiare bytecode. Alla fine il bytecode di una macchina virtuale lo puoi vedere come un assembly per una macchina che non esiste. Non è necessario copiare Java, io pensavo più a LLVM che come forse sai ha diversi front-end in diversi linguaggi fra cui C/C++, persino Erlang e converte tutto in una rappresentazione intermedia che assomiglia molto ad un assembly per una macchina che non esiste.

Il punto comunque non è questo... qualsiasi programma può essere decompilato con un discreto sforzo, alcuni rendono il lavoro più difficile di altri, ma di certo è più complicato che capire codice javascript in chiaro o semplicemente "minimizzato".

> > È più o meno come cercare di tornare indietro dal codice macchina ad un linguaggio ad alto livello... qualcosina la puoi anche fare, ma poi vai a capire tu il codice che ne salta fuori.
>
> vedi sopra

Vedi sopra. L'obiettivo non è rendere impossibile la decompilazione (cosa non fattibile, in alcun linguaggio, in alcun assembly), ma renderla abbastanza difficile da renderla poco viabile. E comunque non è l'unico vantaggio di questa struttura a macchina virtuale.

> e tu speri di riuscire a tipizzare fortemente a tempo di compilazione un linguaggio tipizzato debolmente?
> è semplicemente impossibile, mi immagino un campo di input in cui puoi inserire "1" oppure "a"
> come lo compili? concatenando stringhe o sommando numeri? come lo decidi?

Non è così difficile come credi. Ti ricordo che qualsiasi linguaggio dinamico, per poter eseguire il tuo codice, alla fine DEVE tipizzarlo, e DEVE fare tutti i cast del caso... per la semplice ragione che la tua CPU _è_ tipizzata e ragiona su dati tipizzati. Non hai registri di CPU "dinamici", tutto alla fine deve convertirsi in una sequenza di istruzioni che hanno a che fare con numeri o stringhe. I linguaggi dinamici semplicemente si fanno carico di pensare per te quali tipi inserire, come e come usarli o convertirli di volta in volta. Questo li rende solitamente lenti e rendono la loro programmazione prona ad errori. Approcci stile Go e Scala sono più intelligenti... i tipi ce li hai ancora (sono staticamente tipizzati), ma nei limiti del possibile il linguaggio li assegna automaticamente cercando di capire che tipo è da come tu usi quei dati risparmiandoti di scrivere molte ovvietà e dandoti l'impressione di lavorare in un linguaggio dinamico.

Un esempio di compilatore che già lo fa è proprio LLVM.
http://en.wikipedia.org/wiki/LLVM
Come puoi facilmente vedere è in grado di compilare anche Python che ha tipi dinamici. Vedi, non è impossibile. Anzi, come VM potrebbe probabilmente tranquillamente starci quella di LLVM. Fra l'altro da quanto ne so LLVM è un ottimo compilatore che spesso raggiunge e a volte oltrepassa in quanto ad efficenza persino i compilatori nativi in C.

Scritto da: Giambo
> Scritto da: Renton Thurston
>
> > È quello che ottieni in una società giustizialista in cui le pene si sommano matematicamente
>
> Intanto Breivik si fa 20 anni.

E quindi?
Cambia qualcosa ai morti se si fa 20 anni o 2000?

Scritto da:
> > Una Applet oggi può per esempio bypassare le impostazioni del browser, può fottersene se il browser ha un proxy, ecc. La sicurezza è imposta dalla stessa Virtual Machine in cui è eseguita e il browser può solo "stare a guardare".
>
> Sarà un caso che Applet ha in comune le prime cinque lettere con Apple?

Brutti figli di...