Dubbio sicurezza opensource

[k0nt3]

ohmmadonna! è arrivato l'elfo! comunque pensa ke a me all'esame di ingSW mi hanno valutato x la qualità della javadoc ke ho prodotto! cmq non sono io il professore kiedi al tuo amico fek la mail di ghezzi e non mi tormentate!
ahah commentare non serve! xkè adesso noi parliamo in C! C è una classe di equivalenza del linguaggio naturale! in C si può esprimere qualsiasi cosa! ok adesso devo scappare mi dispiace! comunque è stato divertente!!

ps. ah grazie x avermi detto dei nomi delle variabili autoesplicativi! pensa ke io le kiamavo pippo1, pippo2 e pippo3!

[VICIUS]

Originariamente inviato da fek

Ma tu vic sei un noto lamma inviato da Sun per diffondere Java a noi poveri programmatori

Sistema la build machine invece di perdere tempo qui nel forum a parlare del piu e del meno

ciao

[k0nt3]

ah fek! dimenticavo! sai ke JML nn ci azzecca niente con UML vero?

[fek]

Originariamente inviato da k0nt3

ohmmadonna! è arrivato l'elfo! comunque pensa ke a me all'esame di ingSW mi hanno valutato x la qualità della javadoc ke ho prodotto! cmq non sono io il professore kiedi al tuo amico fek la mail di ghezzi e non mi tormentate!

Ma stai ancora paragonando un esamino di ingegneria del software a piu' di 10 anni di esperienza nel settore... su su su ma siamo seri e perdi piu' tempo a studiare che ne hai bisogno

[k0nt3]

Originariamente inviato da fek

Ma stai ancora paragonando un esamino di ingegneria del software a piu' di 10 anni di esperienza nel settore... su su su ma siamo seri e perdi piu' tempo a studiare che ne hai bisogno

mi sembri fuori topic! se fossi il moderatore ti bannerei! non devi prenderla sul personale!! rispondi alle domande invece! byez (sul serio)

[fek]

Originariamente inviato da k0nt3

ah fek! dimenticavo! sai ke JML nn ci azzecca niente con UML vero?

Ti ripeto di si', sono entrambi linguaggi di modellazione del design formali, uno basato su diagrammi (ad esempio i diagrammi di classe di UML), l'altro sulla descrizione mediante una grammatica formale e piu' vicino al linguaggio naturale delle precondizioni, postcodinzioni e invarianze (JML). Una specie di Design By Contract alla Eiffel, ma decisamente meno elegante.

Sono due strumenti diversi che perseguono gli stessi scopi (e che non adoro).

[fek]

Originariamente inviato da k0nt3

mi sembri fuori topic! se fossi il moderatore ti bannerei! non devi prenderla sul personale!! rispondi alle domande invece! byez (sul serio)

Sono perfettamente in topic invece, visto che stai insultando chiunque non ti dia ragione, mi limito a riportarti in riga

[pinok]

Originariamente inviato da fek

Ha bisogno di commenti?

Si, perché è comprensibile ma non gestibile; non so se rendo l'idea.
Immaginati di essere uno che si trova con quel pezzo di codice davanti la prima volta, o tu stesso dopo 3 anni; a mio avviso ci vorrebbero dei commenti che rispondessero alle domande che riporto.

	mConfig.UseHDR          = true;   // Variabile che serve a cosa e dove? Nel pezzo di codice subito seguente non è usata...
	mAutoExposureEnabled = true;  // Impostata a true perchè? Non è dichiarata qua, quindi resetto il valore qualunque fosse stato prima

	if (CheckCapabilities()) // OK, faccio un controllo; ma in merito a cosa? Alla memoria, alla banda, ai puffi?  
	{
		CreateRenderTargets();
		CreateFilters();

		EnableBloom(mBloomEnabled);
		EnableColorCorrection(mAutoExposureEnabled);
	}
	else
	{
		mForceDisabled = true;  // Ok, lo imposto a true, ma perché nell'if non l'ho impostato a false?
	}

Per gli if e gli else, puoi anche non commentare la chiusura perché sono poche righe, ma se fossero di più farebbe comodo; lo stesso se ne avvessi più annidati, è comodo sapere l'else a quale if fa riferimento.
Non è che devi commentare proprio tutto, ma dove serve.
E ora mi darai del figlio di Sun di nuovo, ma se scrivi bene dei commenti durante lo sviluppo, poi hai anche la documentazione (leggi javadoc)
Non mi dire che "quando modifichi, poi non li aggiorni", perché allora ti potrei rispondere che "quando modifichi senza commento, prendi cantonate".
Dipende dall'attenzione con cui fai le cose, in un caso e nell'altro.

[jappilas]

Originariamente inviato da k0nt3

pensa ke a me all'esame di ingSW mi hanno valutato x la qualità della javadoc ke ho prodotto!

pensa ke a me all' esame di Ing SW hanno fatto studiare un frammento di codice di un paio di centinaia di linee, con complessità ciclometrica intorno a 35 (se non ricordo male), determinando domini di correttezza per i casi di percorrenza di: tutte le condizioni, tutte le istruzioni, condizioni AND istruzioni... il secondo esercizio consisteva nell' analisi di un' applicazione che gestisse manipolazione da client esterni su strutture dati gerarchiche e aggregate, e modellazione tramite i DP necessari (se non ricordo male ci andava un Composite, un Observer, il Proxy e una Factory... il diagramma mi prese 3 fogli A4... )

cmq non sono io il professore kiedi al tuo amico fek la mail di ghezzi e non mi tormentate!

nessuno ti tormenta... faccio solo un confrontino tra un esame di ingsoft vecchio e nuovo ordinamento

ahah commentare non serve! xkè adesso noi parliamo in C! C è una classe di equivalenza del linguaggio naturale! in C si può esprimere qualsiasi cosa!

commentare non è inutile a priori... spesso però potrebbe tranquillamete essere sostituito da una naming convention più "umana"
hai la fortuna che un simbolo in C non ha praticamente vincoli sul naming... perchè non sfruttarlo per far assomigliare un programma a un "discorso" in inglese?

[fek]

Originariamente inviato da pinok

Si, perché è comprensibile ma non gestibile; non so se rendo l'idea.
Immaginati di essere uno che si trova con quel pezzo di codice davanti la prima volta, o tu stesso dopo 3 anni; a mio avviso ci vorrebbero dei commenti che rispondessero alle domande che riporto.

O tipo me stasera dopo un anno e mezzo che l'avevo scritto. Beh, e' scritto in inglese, infatti e' stato perfettamente gestibile.

	mConfig.UseHDR          = true;   // Variabile che serve a cosa e dove? Nel pezzo di codice subito seguente non è usata... // Imposta l'uso dell'HDR, c'e' scritto :)
	mAutoExposureEnabled = true;  // Impostata a true perchè? Non è dichiarata qua, quindi resetto il valore qualunque fosse stato prima Imposta l'uso dell'autoesposizione, c'e' scritto :)

	if (CheckCapabilities()) // OK, faccio un controllo; ma in merito a cosa? Alla memoria, alla banda, ai puffi?   // Fa un controllo delle capabilities, c'e' scritto :)
	{
		CreateRenderTargets(); // Crea i render target, c'e' scritto :)
		CreateFilters(); // Crea i filtri, c'e' scritto :)

		EnableBloom(mBloomEnabled); // Abilita il bloom a seconda della variabile, c'e' scritto. :)
		EnableColorCorrection(mAutoExposureEnabled); // Abilita la correzione del colore in base al valore della variabile impostata prima, c'e' scritto pure questo :)
	}
	else
	{
		mForceDisabled = true;  // Ok, lo imposto a true, ma perché nell'if non l'ho impostato a false? // Perche' e' impostato dal costruttore, c'e' scritto nella lista di inizializzazione :)
	}

Per gli if e gli else, puoi anche non commentare la chiusura perché sono poche righe, ma se fossero di più farebbe comodo; lo stesso se ne avvessi più annidati, è comodo sapere l'else a quale if fa riferimento.

Infatti io non annido gli if, ma creo nuovi metodi, non ho bisogno di commentare if molto annidati, riscrivo il codice per renderlo piu' chiaro. Classico esempio di come commentare invece ti preclude la possibilita' di strutturare meglio il codice.

Non è che devi commentare proprio tutto, ma dove serve.

No, devi commentare solo cio' che non e' esprimibile altresi' in codice, di solito assunzioni sull'algoritmo che non puoi documentare con l'assert delle precondizioni direttamente nel codice, oppure note di complessita' computazionale dell'algoritmo che stai implementando. Questi sono esempi di buoni commenti. Scrivere che CreateRenderTargets crea i render target non e' un buon commento. Oppure commentare al quinto if annidato a quale branch si riferisce non e' un buon commento, e' roba da principianti.

E ora mi darai del figlio di Sun di nuovo, ma se scrivi bene dei commenti durante lo sviluppo, poi hai anche la documentazione (leggi javadoc)
Non mi dire che "quando modifichi, poi non li aggiorni", perché allora ti potrei rispondere che "quando modifichi senza commento, prendi cantonate".
Dipende dall'attenzione con cui fai le cose, in un caso e nell'altro.

Si', ti dico che spesso e volentieri i commenti non vengono aggiornati e oltre a essere inutili diventano anche dannosi. Al danno la beffa. Non e' questione di attenzione del codice, sarebbe come dire che basta fare attenzione e non si introducono bug, magari
E' questione che il 99% dei commenti sono una chiara violazione del principio DRY come ho detto, sono nient'altro che una duplicazione delle informazioni. E duplicare le informazioni quando si programma e' un male, diminusce la mantenibilita' del codice.

Prova a scrivere meno commenti, concentrati sul codice stesso, riscrivilo in maniera piu' chiara di modo che sia leggibile come fosse inglese: il tuo codice ti ringraziera'.

I commenti sono come il deodorante per la puzza, meglio lavarsi

[fek]

Originariamente inviato da jappilas

commentare non è inutile a priori... spesso però potrebbe tranquillamete essere sostituito da una naming convention più "umana"
hai la fortuna che un simbolo in C non ha praticamente vincoli sul naming... perchè non sfruttarlo per far assomigliare un programma a un "discorso" in inglese?

Esatto

Come dicevo non e' inutile commentare in tutti i casi, e' inutile commentare laddove una semplice riorganizzazione del codice porta ad una struttura piu' leggibile e comprensibile senza essere appesantito da inutili commenti che non fanno altro che riaffermare cio' che il codice gia' afferma. Inoltre il codice che si autodocumenta e' per definizione sempre in perfetta sincronia con se' stesso.

Poi rimane il restante 1% di commenti utili alla comprensione delle assunzioni. L'esempio che faccio sempre in questo caso e' quello della complessita' computazionale di un algoritmo: e' spesso utile commentare che, ad esempio, una ricerca e' O(N) piuttosto che O(N^2) per informare il cliente sul suo utilizzo. E' perfettamente inutile commentare, invece, il fatto che un metodo chiamato FindRecord sta cercando un record

[jappilas]

Originariamente inviato da pinok

Si, perché è comprensibile ma non gestibile; non so se rendo l'idea.

imho l' esplicazione di alcuni dei metodi non chiari in quel frammento, si troverà quasi certamente oltre il frammento o in quelle consuetudini che dopo un po' di tempo finiscono nel DNA degli sviluppatori di una certa azienda o di un certo settore
ad esempio... la CheckCapabilities: a me appare quasi scontato che ad essere verificate saranno delle flag relative a funzionalità delle directx supportate o meno, e probabilmente qualunque sviluppatore del settore grafico si troverà a scrivere una funzione con quello scopo e, per esplicatività, a darle un nome simile a quello scelto da fek

Immaginati di essere uno che si trova con quel pezzo di codice davanti la prima volta, o tu stesso dopo 3 anni; a mio avviso ci vorrebbero dei commenti che rispondessero alle domande che riporto.

imho proprio perchè certe cose, quindi anche certi meccanismi, vengono acquisiti magari per via del settore in cui si opera, fek o un suo collega comprenderà quel codice anche tra 3 anni
in questo caso un commento che vedrei bene riguarda se una flag sia attesa vera o falsa di default, non il significato delle variabili...

Originariamente inviato da fek

e' spesso utile commentare che, ad esempio, una ricerca e' O(N) piuttosto che O(N^2) per informare il cliente sul suo utilizzo.

o anche questo
ps: mi scuso per la scarsa chiarezza, sono un tantino stanco...

[pinok]

@fek e jappilas
Vi offendete se vi dico che sono punti di vista ??
Non potete partire dal presupposto che un codice è scritto in uno stile che per consuetudine comprendete.
Io che non arrivo dalla computer grafica, devo potere comprendere cosa fa un singolo pezzo di codice senza dovermi studiare i pezzi prima o i pezzi dopo.
Poi semmai vado a vederli.
Può darsi che per voi le Capabilities siano una cosa, ma che arrivi un programmatore che con Capabilities ne intende un altra. Un minimo cenno evita menate.

Nei "controcommenti" mi hai detto cosa fanno certe variabili, ma questo si capiva. Infatti ho detto che il codice era comprensibile.
Ma non mi hai detto il perché lo fanno li, piuttosto che non altrove, o perché in un modo piuttosto che in un altro.
E' questo che giustifica la logica del codice: non deve fare qualcosa, ma arrivare a qualcosa. Ti potrei sbattere lì un loop che non fa niente e dirti: "E' chiaro, sta contando da 1 a 1000". Ok, grazie. Ma perché? Se non c'è un perchè, probabilmente è un refuso.
Per quel che ne so, tra 2 mesi guardano quel pezzo di codice che hai postato, potrebbe avere avuto senso inizializzare la variabile a false. Perchè non l'ho fatto? Vuoi mica che mi vada a risfogliare 2000 pagine di specifiche, sempre che esistano ?

Probabilmente alla Sun sono rimasti indietro perché hanno scritto troppo codice

[cdimauro]

Originariamente inviato da Zorcan

Sarà, ma se il motore cigola preferisco avere la libertà di aprire il cofano e stringermi la vitina piuttosto che andare in officina e farmi smontare mezza automobile senza capire esattamente cosa gli è successo. La libertà di intervenire, quindi, fa una grande differenza. Ovvio che la faccia anche per chi guadagna dal fatto che il software sia chiuso e veda nell'opensource svanire una discreta somma, ma è il prezzo da pagare quando la gente prende coscienza del proprio diritto alla conoscenza e alla trasparenza.

E' un discorso che non regge. L'utente medio non se ne farà niente né dei sorgenti di un programma né del progetto / schema della macchina, perché non saprà intervenire.

E' una questione di conoscenza ed esperienza: se ho sufficienti capacità acquisite, potrò mettere le mani al sorgente di un programma, al motore di una macchina, ma anche all'eseguibile di un programma di cui non ho il sorgente.

[cdimauro]

Originariamente inviato da pinok

Mi sembrano le contestazioni che fa un dipendente di M$ ben istruito da Bill, comunque ....

Non ti permetto di fare illazioni false e tendenziose sul mio conto: non ho alcun rapporto con MS & co., se non in qualità di semplice utente. Mettitolo bene in testa.

Tu chiami comportamento anomalo un modem che si scollega e ricollega, un PC che genera elevato traffico, il disco che ti si riempie ?
L'analisi è comunque più facile se hai il sorgente, piuttosto che no.
Se ci lavori un po' come programmatore, dovresti sapere che dal comportamento anomalo, come lo chiami tu, non risali mai alla causa, ma a cio' che l'ha generato. Da lì parti a circoscrivere il problema, analizzi il codice relativo a quella porzione e vai alla causa.

Certamente, ed è più facile avendo i sorgenti in mano, non c'è dubbio, ma anche senza è possibile lavorare (vedi crack, ricercatori di falle di sicurezza, reverse engineering, ecc.).

Non è che per forza di cose, se cambi una riga tra true a false apri nuovi bugs

Non è per forza di cose, ma è possibilissimo e dovresti saperlo, se hai esperienza nel campo della programmazione.

e comunque preferisco che venga tappato subito un bug noto e rischiare per un bug non noto (che darà un po' da studiare), che non stare con le braghe calate ad aspettare che M$
1) raccolga tot segnalazioni per prenderlo in considerazione
2) indica una riunione per valutare il problema
3) organizzi un piano di intervento
4) istituisca una commissione di sorveglianza
... pausa caffè....
5) distribuisca i pezzi di codice a vari sottogruppi.

La patch che ne uscirà avra meno bugs (dubito), ma nel frattempo mi hanno rigirato per bene il computer oppure ho dovuto staccarlo dalla rete con i danni che ne conseguono.

Infatti la situazione non è come la descrivi, visto che alla segnalazione di un bug MS risponde almeno con un workaround al problema, in attesa di realizzare la patch secondo il suo modello di sviluppo.

P.S.:
Non sono sicuro, ma a differenza di quello che dici, credo che in M$ pochi abbiano la visibilità completa del codice; per lo più ricevono incarico di sviluppare su specifica delle porzioni che poi qualcun altro riassemblerà.

Mi sembra che la situazione non sia diversa da tante altre realtà simili.

[cdimauro]

Originariamente inviato da pinok

Ti contraddici
Nell'attesa che chi produce l'allarme ne rilasci un nuovo modello, il ladro, senza bisogno di impegnarsi in nuovi studi, svaligia l'intera città, non la casa e quando l'antifurto sarà pronto, non ci sarà più niente da proteggere.

Nessuna contraddizione: la vedi soltanto tu.

Pensaci Bill

Se continui così chiederò l'intervento del moderatore.

[cdimauro]

Originariamente inviato da Artemisyu

Dal fatto che è un continuo far notare punti deboli di questo sistema di sviluppo,

Mi sembra che non manchino pro e contro di entrambi i modelli nei miei messaggi: se tu vuoi continuare a vedere soltanto le cose che t'interessano, non posso farci niente.

preferendo addirittura un attività di bugfixing interna all'azienda rispetto alla revisione paritaria del codice.

Non ho detto questo: rileggi meglio.

Appunto.
E comunque non era l'opensource che conosciamo oggi.

Hai ragione: era nettamente migliore, visto che non aveva vincoli e licenze a cui sottostare.

Perchè linux non è una soluzione desktop.
Lo si può usare su un desktop ovviamente, al prezzo di qualche compromesso.

Perfettamente d'accordo.

Mi riferisco al fatto che ho dovuto smettere di propinare GNU/Linux ai miei clienti, perchè dopo l'installazione ed un po' di formazione, il sistema andava talmente bene che si dimenticavano della mia esistenza, ed io non guadagnavo più una lira.
Questo, in un modo o nell'altro, è "qualità".

Hai ragione: sarà per lo stesso motivo che sono pochi i clienti, parenti e amici che mi chiamano dopo che gli ho sistemato il computer con Windows.

[cdimauro]

Originariamente inviato da Artemisyu

Concordo.
Io fossi in lui farei una bella donazione alla SCO, che sta portando avanti una crociata molto simile alla sua su questo forum.

ciao ciao!

Io non sto facendo nessuna crociata: dateci un taglio, o chiederò provvedimenti.

[cdimauro]

Originariamente inviato da pinok

Prima di fare questa affermazione, dovresti solo sforzarti di ripensare a quella scena in cui un certo Bill Gates, alla presentazione del suo bel closed source (mi pare Win98), attaccò uno scanner per dimostrare la potenzialità del suo prodotto e venne fuori una schermata blu.

A me sarebbe venuta voglia di spararmi per una figuraccia simile in mondovisione

Cazzi suoi.

Comunque io mi riferivo alla qualità del codice prodotto (ai sorgenti).

[ilsensine]

Originariamente inviato da ReNeSiS

Questa è la più bella che ho sentito negli ultimi anni!

Chiunque abbia la sventura di passare parecchie ore della sua vita davanti al codice, sa che è vero...