Thanked Posts

1

Java / Re:Da jar a exe senza rivelare i sorgenti

« on: February 25, 2017, 01:07:56 AM »

Quando vado in pizzeria, la pizza la mangio dopo che è stata nel forno, non prima. Non la giudico in base a come il pizzaiolo ha messo gli ingredienti sulla massa cruda, ma dal sapore che ha.

Se compariamo lo sviluppo di codice al cucinare una pizza (con tutto il rispetto per i pizzaioli) sicuramente arriviamo alle conclusioni sbagliate. Giudicare il codice dal suo funzionamento (penso che questa sia l'analogia col sapore della pizza  ) piuttosto che da come è stato scritto, ci ritroviamo poi con problemi di scalabilità, sia al livello di funzionalità che al livello di sviluppi aggiuntivi da fare sullo stesso programma. Per di più, eventuali bug o funzioni maligne verrebbero nascoste agli utenti, che di conseguenza avrebbero ancora meno interesse ad usare il tuo programma.


Se vuoi un'analogia più azzeccata: tu utilizzeresti un'auto che si accende e cammina per fare un viaggio di 1000km, senza assicurarti che il motore sia a posto, le ruote gonfie, i freni a posto e le sospensioni integre? E senza nemmeno poter controllare, perché chi l'ha prodotta ha nascosto tutte queste parti sotto un cofano che il proprietario non può aprire (e magari ci ha anche nascosto un gps tracker dentro)?

Io, personalmente, se installo un programma o una libreria pretendo di vederne il codice sorgente (e lavoro su Mac OS). Tuttalpiù faccio eccezioni quando il programma è sviluppato da aziende come Apple o Google, perché almeno so chi va a prendere i miei dati o chi denunciare qualora avessi problemi.

per g: nella pagina linkata da CrashTest, sezione 4.2, viene spiegato come funziona la compilazione. In short, la risposta è si. Ecco il link di nuovo: You are not allowed to view links. Register or Login

2

Java / Re:Da jar a exe senza rivelare i sorgenti

« on: February 22, 2017, 03:51:44 AM »

Java non è propriamente un linguaggio compilato, nè un linguaggio interpretato. Quello che succede quando passi da codice sorgente a eseguibile è che un compilatore Java (su Unix-like javac) compila i file .java in file .class, che altro non sono che la versione compilata in Java Bytecode del tuo codice sorgente. Una Java Virtual Machine (JVM) poi prende il Bytecode generato dalla compilazione e lo esegue o compilandolo in machine code (di solito nei sistemi embedded), oppure eseguendo direttamente le istruzioni dal Bytecode come se fosse uno script (compilazione JIT - Just In Time).
Il tuo file .jar altro non è che una raccolta di tutti i file .class contenenti Java Bytecode.
La ragione per cui non puoi nascondere il tuo codice in Java è perchè il Java Bytecode, dovendo essere abbastanza generico da poter essere interpretato facilmente dalle JVM indipendentemente dall'architettura hardware e dal sistema operativo, è facilmente decompilabile in codice Java. Questa è proprio la maniera in cui è stato ideato Java, e c'è poco da fare.
Esistono dei sistemi per "offuscare" il codice, i quali modificano i nomi delle variabili, delle classi e delle funzioni in maniera da rendere il codice illeggibile anche se decompilato, ma non è una soluzione definitiva, in quanto un attaccante esperto può risalire al codice sorgente studiando il codice decompilato.


Mettere una password al .exe piuttosto che al .jar non è una soluzione, in quanto renderesti illeggibile il file alla JVM che deve interpretare il Bytecode, e l'unica maniera per renderlo di nuovo utilizzabile sarebbe di togliergli la password.


Detto ciò, per quale motivo ci tieni tanto a nascondere il codice? C'è una proprietà intellettuale all'interno di cui vuoi riservarti i diritti facendo un brevetto? È un programma talmente unico nel suo funzionamento da volerlo proporre a livello commerciale? Se la risposta a una di queste domande è si, allora si potrebbe anche discutere di tenere il codice sorgente nascosto (e comunque, anche in questi casi, non è sempre una buona idea), altrimenti ti assicuro che tenere il codice nascosto è inutile e, anzi, controproducente!

3

EXPLOITED / Re:[EXPLOITED] Prima versione Alpha del programma... Per rendere l'idea

« on: February 15, 2017, 03:42:37 AM »

Mi piace quello che hai fatto Dario, e infatti la stelletta te l'ho messa! Ci sono un po' di cose da migliorare però, ci sto dando un'occhiata sulla mia VM ubuntu

4

Comunicazioni dagli Admins - Comunicazioni dagli Admins / Re:AAA: Cercasi moderatori

« on: February 07, 2017, 05:15:09 PM »

Eccomi! Io prenderei i progetti comuni e Javascript, che è rimasto senza mod

5

EXPLOITED / Re:[EXPLOITED] Prima versione Alpha del programma... Per rendere l'idea

« on: February 07, 2017, 03:56:05 AM »

Concordo con Dario sul problema di verificare prima lo spazio di indirizzi su cui andare a fare il ping sweep.
Modificando leggermente il codice che ha postato proprio Dario dovrebbe essere semplice integrare questa funzionalità.


Per quanto riguarda la tua paura di mettersi a lavorare in concorrenza sulle stesse features, su github ci sono varie maniere per gestire la cosa. La mia preferita (e una delle più utilizzate nei grandi progetti open source) è questa:
 1. Chiunque identifichi una feature aggiuntiva o una falla, aggiunge una nuova issue (You are not allowed to view links. Register or Login).
 2. Se ne discute sul topic dedicato, quindi si sceglie una persona che ci lavora su, che diventa assignee della issue.
 3. L'assignee, e solo lui, forka l'intero repository e lavora sull'implementazione del bugfix/nuova feature. Tutte le comunicazioni riguardanti quel problema vengono fatte sul topic di quella issue su github.
 4. Quando ha finito, l'assignee fa una pull request sul repo principale, aggiungendo nel commento una reference alla issue originale.
 5. Se ci sono problemi nel merge automatico, o se si vogliono fare altre aggiunte, si ricomincia dalla 3. altrimenti si prosegue fa il merge della nuova feature/bugfix e si chiude la issue.


Ti apro una issue con il problema evidenziato da Dario, proviamo a seguire questo flow?

6

0.1a / Re:feedback, betatesters, qualcuno l'ha provata?

« on: February 03, 2017, 07:40:58 AM »

Devo ancora installarlo, ma posso solo provarla sul raspi B2! I B3 che ho non sono proprio miei... 
Intanto propongo un'idea per la prossima versione, che potrebbe essere utile a scopi didattici.


Si potrebbe mettere a disposizione della gente che segue i vari corsi la possibilità di connettersi da remoto ai raspberry del lab tramite una web shell, in maniera tale che possano testare roba e/o fare esercizi in maniera super semplice (e sicura).


Non chiedetemi perché, ma ho già lavorato su un sistema che funziona più o meno così:


- All'utente viene dato username-password del raspi per fare login sulla shell.
- L'utente si registra su un portale/piattaforma web.
- I raspi hanno un servizio che comunica con il portale/piattaforma web attraverso internet (ovviamente).
- I raspi non hanno ip pubblico.
- L'utente si logga sulla piattaforma, e viene autorizzato a connettersi da remoto al raspi.
- L'utente va su una pagina web dalla quale verrà esposta una shell del raspi.
- Il raspi indicato riceve dal portale web una notifica della richiesta di connessione. Allegati alla richiesta ci sono una chiave privata RSA valida temporaneamente, e la porta su cui il portale esporrà la shell, scelta a random.
- Il raspi fa partire il server che espone la web shell.
- Il raspi apre un reverse SSH tunnel verso il portale web, dalla porta dove lui serve la web shell alla porta dove verrà servita dal portale web.
- Il raspi notifica il server che il tunnel SSH è stato aperto.
- L'utente viene reindirizzato verso la pagina dove ora viene servita la web shell del raspi.


Alla chiusura:
- Il portale web notifica il raspi che deve chiudere il tunnel SSH, ed elimina la chiave privata RSA usata per la connessione.
- Il raspi spegne il server che espone la web shell e chiude il tunnel SSH.
- Il raspi notifica il server che il tunnel è stato chiuso.


Ho trovato su github un bel progetto per una web shell, che viene già distribuito nei repository di alcune distro, per quanto sia più stabile e funzionale se buildato dal source.
Eccolo: You are not allowed to view links. Register or Login


Con una architettura di questo genere si evita di creare VPN, spesso instabili a causa di firewall o altri problemi nella rete, e si ha pieno controllo delle autorizzazioni degli utenti nell'accedere da remoto ai raspberry.


Che ne dite?

7

Java / Re:Semplice Applet, copiata identica da due manuali, non funziona

« on: February 03, 2017, 06:21:13 AM »

Mai lavorato con applet java su browser purtroppo (o per fortuna!). Considera che è una tecnologia che sta sparendo, non la trovi più praticamente da nessuna parte.
Il mio consiglio è, almeno che non ti venga richiesto esplicitamente o per ragioni didattiche, passa a una soluzione Java server-side/Javascript client side!

8

Progetti Comuni / Re:Sviluppo dei Tools per la distro

« on: January 29, 2017, 10:20:22 PM »

Sembra interessante! Solito consiglio: metti il codice su github e posta il link qui, così che possiamo partecipare tutti insieme allo sviluppo di questo tool

9

Java / Re:Creare una sorta di "goto" uscendo da un if-else

« on: January 24, 2017, 03:51:49 AM »

Purtroppo non tutti gli autori dei libri sono bravissimi a trasmettere le informazioni, specie quando si tratta di argomenti tecnici, che non sono proprio semplici ne da acquisire, ne da trattare.
Finchè non inventeranno la trasmissione di informazioni brain to brain, dobbiamo purtroppo arrangiarci con le risorse che abbiamo: libri, corsi online, corsi fisici e l'aiuto delle persone su internet.
Anche io, quando ero alle prime armi, avevo difficoltà a disegnarmi in mente gli algoritmi dei programmi che sviluppavo. È una cosa che viene con il tempo e con l'esperienza, ma solo se ci si impegna a migliorarsi con le risorse a disposizione. Non certo se si abbandona perchè un libro è troppo complicato da leggere.
Non esiste una regola generale che dice che in Java gli errori vanno gestiti tramite eccezioni e non a priori. Anzi, un approccio del genere è spesso deleterio nei confronti delle performance dei programmi. La questione varia caso per caso, e soprattutto bisogna sapere come utilizzare i try...catch all'interno del flusso dei programmi (quindi all'interno di eventuali cicli o ricorsioni).
Secondo me hai bisogno di rivedere un po' di teoria, se non riesci a controllare il flusso del programma senza il goto. La maggior parte dei linguaggi moderni non ha il costrutto goto proprio per evitare di incorrere in bad practices e per indurre gli sviluppatori a scrivere dei programmi ben strutturati.
Continua a provare e a studiare, vedrai che ce la farai!

10

Java / Re:Creare una sorta di "goto" uscendo da un if-else

« on: January 18, 2017, 02:52:41 AM »

Credo che dovresti anche leggere la documentazione del modulo Scanner che contiene la funzione .nextInt() che stai usando per parsare l'input da tastiera.
Probabilmente il problema si verifica perchè la funzione .nextInt() genera un errore che non stai gestendo quando le passi un carattere non numerico.

11

Java / Re:Creare una sorta di "goto" uscendo da un if-else

« on: January 16, 2017, 09:50:58 PM »

Non so bene come java gestisca la input.nextInt(), ma sicuramente se il valore di ritorno lo metti in un int non è possibile che ci sia un valore floating point li dentro!
Se vuoi che sia possibile avere r, i e g come floating point devi utilizzare delle variabili float, e una funzione diversa da input.nextInt() per prenderli dallo standard input.
Per quanto riguarda la verifica che fai, anche avendo i valori come floating point stai facendo una cosa assurda ed inefficiente: indipendentemente dal cast da int a stringa, che come efficienza varia da linguaggio a linguaggio, quando vai a cercare il punto nella stringa stai sicuramente eseguendo un algoritmo O(n), dove n è la lunghezza della stringa.
Questo è incredibilmente più inefficiente di fare un semplice modulo 1 (var % 1) per ottenere la parte decimale e poi semplicemente verificare che questa sia uguale a 0.


Io credo che più che focalizzarti su un corso per un linguaggio specifico, dovresti guardare prima gli algoritmi di base, magari con esempi in linguaggio C. Saranno argomenti molto teorici all'inizio, ma ti assicuro che una volta imparati bene ti serviranno per qualunque linguaggio e applicazione andrai a sviluppare in futuro.

12

Raspberry Pi / Re:[TOOL] Crea la tua distro per il Raspberry Pi

« on: January 16, 2017, 11:18:29 AM »

La forza di github (o bitbucket o qualunque soluzione simile) è proprio questa! Anche se gli script non sono completi e funzionanti nel 100% dei casi, pubblicandoli aprite anche ad eventuali contributi da parte degli altri, ed evitate di fare il lavoro due volte!
Immaginate se dario avesse pubblicato il suo script, invece che scriverne uno suo da capo, davenull avrebbe potuto forkare quello di dario e farci le modifiche che gli sembravano necessarie, e magari poi mandare una pull request a dario perchè mergiasse le sue modifiche nel repo principale.
Invece di scrivere il mio, io avrei potuto prendere il risultato del vostro lavoro, aggiungerci delle mie modifiche e contribuire anch'io!
Vi suggerisco di pubblicare tutto quello che fate su github, anche se potenzialmente incompleto.
Per quanto riguarda le licenze, al momento della creazione di un nuovo repo pubblico github vi da la possibilità di scegliere la licenza che preferite, senza che dobbiate nemmeno andare a cercarvi il testo ed aggiungerlo al repo lo aggiunge lui in automagico!

13

Java / Re:Creare una sorta di "goto" uscendo da un if-else

« on: January 16, 2017, 11:10:28 AM »

D'accordissimo con davenull e dario sul fatto di fare programmi modulari e object-oriented, quindi divisi in classi.
Se il problema però è solo di non chiedere da capo i primi due dati, basta letteralmente spostare la riga del while 4 righe più sotto, dopo aver salvato il valore di i ma prima di chiedere g.
Come utilizzare i cicli al posto dei goto per evitare algoritmi non strutturati è una delle basi della programmazione moderna!
Hai mai letto documentazione o un libro sugli algoritmi di base e le loro implementazioni?