Linux più sicuro per Evans Data Corp.

[fek]

Originariamente inviato da Ikitt_Claw
Non conosco, in assoluto, progetti Life Critical.
Ribadisco, en passant, che l'onere della prova sta al proponente la tesi. Se vuoi provare che il software OSS e` intrinsecamente (e non a causa di "worst pratice") di qualita` inferiore, ben venga. Ma devi fornirle tu le prove, non puoi limitarti a dire che e` cosi` sinche` qualcuno non dimostra il contrario...

Meglio dire che non accetti le nostre prove, perche' ne ho portate

Una semplice dimostrazione di come l'OS (inteso non come il semplice rilasciare il sorgente, ma come dici tu la possibilita' che chiunque previa autorizzazione possa mettere mano al codice): saprai certamente che alcune metodologie di reviewing formale, prevedono uso estensivo di pair reviewing e pair programming. In pratica, due programmatori si mettono assieme a fare la review di un pezzo di codice e altri due programmatori si mettono assieme a fare refactoring.
Se io e te decidessimo di fare pair programming su un progetto OS, come dovremmo configurarci? Io sono qui in UK tu in Italia, dovremmo essere allo stesso PC. E il pair programming e' un requisito sempre piu' importante per assicurare la Qualita'. Altro esempio di come l'OS sia intrinsecamente di minore Qualita'.
Questa metodologia non e' applicabile all'OS, che unito al fatto che molte altre metodologie non vengono applicate di fatto porta alla dimostrazione della mia tesi.

Originariamente inviato da Ikitt_Claw
E` esattamente il punto che non condivido affatto e che contesto anch'io.
Vedo che non sono il solo allora

Ma anch'io non condivido quest'affermazione, nessuno dice che i programmatori open source siano piu' scarsi di quelli professionali.
La Qualita' non deve dipendere (fortemente) dalla qualita' dei programmatori ma dalle metodologie usate nella costruzione del software.

[fek]

Originariamente inviato da Mason
l'ultimo commento di fek mi sembra un po estremo, se un software non funziona, per quanto il suo modello che sat alla base sia generalizzabile fallisce nel suo nodo di creazione, il suo scopo primo, il suo funzionamento.

Mi sono spiegato male: se un software non funziona, fallisce il primo requisito di Qualita'.
Se funziona e risolve il problema, garantisce solo il primo requisito, poi ce ne sono altri altrettanto importanti come l'estensibilita' e la facilita' di manutenzione.

Se un software risolve il problema, ma tende ad essere pieno di difetti ed ogni difetto richiede altissimi costi per essere corretto, ed ogni correzione tende ad introdurre nuovi di difetti, non e' certo software di qualita', giusto?

Perche' ricordiamoci che non esiste software esente da difetti.

[DjMix]

Originariamente inviato da fek
Una semplice dimostrazione di come l'OS (inteso non come il semplice rilasciare
[CUT]
metodologie non vengono applicate di fatto porta alla dimostrazione della mia tesi.

Potresti spiegarmi cosa sono il pair programming e il pair reviewing? Non sapendolo non riesco a seguire il discorso

Originariamente inviato da fek
Ma anch'io non condivido quest'affermazione, nessuno dice che i programmatori open source siano piu' scarsi di quelli professionali.
La Qualita' non deve dipendere (fortemente) dalla qualita' dei programmatori ma dalle metodologie usate nella costruzione del software.

"programmatori della domenica" non era inteso nel senso letterale. Messa più correttamente:

F/OSS: programma di scarsa qualità
Closed: programma di qualità

Sulla seconda non ho dubbi che non è affatto vero, perchè nessuno mi garantisce che un programma sia portato avanti con metodo, e sopratutto dopo aver visto il codice di qualche programma che viene venduto per vari euro, mi son reso conto di quanto male siamo presi. Certo c'è anche chi fa le cose fatte bene, ma fino ad adesso ho avuto la sfortuna (nella PMI, almeno) di vedere solo programmi fatti maluccio (pochi commenti, niente strumenti come cvs o equivalenti e sopratutto nessuno che si sogna manco lontanamente di star li ad annotare le modifiche al codice...

Per la prima puoi rendertene conto tu stesso, basta che ti segui lo sviluppo di Linux (kernel!), di gnome, di kde, cosa che puoi fare perchè il codice è li a tua disposizione e anche le mailing list dei developer sono accessibili a tutti, così vedrai che non siamo così alieni dal fare le cose fatte bene. È _chiaro_ che moltissimi programmi son fatti con leggerezza, però.

Io mi arrischio a dire cosa penso: penso che in grossi progetti, sia closed che open, ci siano tutti gli strumenti necessari a garantire la qualiltà e tutto il resto che hai spiegato più sopra. Nei progetti piccoli/medi, _sia_ open _sia_ closed, le cose sono fatte in allegria[1]. Questo per il poco rappresentato dalle mie esperienze personali. Magari mi sto prendendo una cantonata, ma penso sia così che và.

[1] non sto dicendo che lo facciano tutti. Dico che lo fanno in molti.

[Ikitt_Claw]

Originariamente inviato da fek
Meglio dire che non accetti le nostre prove, perche' ne ho portate

Veniamoci incontro vah: non ritengo (affatto) determinanti le prove sin qui emerse nel thread.

[...]Se io e te decidessimo di fare pair programming su un progetto OS, come dovremmo configurarci? Io sono qui in UK tu in Italia, dovremmo essere allo stesso PC. E il pair programming e' un requisito sempre piu' importante per assicurare la Qualita'.

OK, fin qui ci sto.

Altro esempio di come l'OS sia intrinsecamente di minore Qualita'.

Ma neanche per sogno. E` un problema derivante dallo sviluppo decentralizzato. Una qualsiasi SH, magari multinazionale, con sedi in due fusi orari (anche a 200 KM/h di distanza), si troverebbe a fronteggiare. E` verissimo che il F/OSS soffre di questo problema (raramente i programmatori operano sotto lo stesso tetto), e` vero che cio puo` portare (porta nella maggioranza dei casi) SW di minor qualita`, ma non e` un difetto intrinseco dell'OSS.
ibadisco il termine "difetto intrinseco".

Questa metodologia non e' applicabile all'OS, che unito al fatto che molte altre metodologie non vengono applicate di fatto porta alla dimostrazione della mia tesi.

Salti un po` troppi passaggi per i miei gusti.

Comunque, ribadisco:
- se si dice "la qualita` media del F/OSS non e` eccellente", concordo.
- se si dice "molti progetti F/OSS non seguono rigorose politiche di test/analisi/"best pratice" di programmazione", concordo
- se si dice "l'essere F/OSS preclude automaticamente l'attuare metodologie rigorose di analisi/test/"best pratice" e la produzione di SW di qualita`", NON concordo.

[leoneazzurro]

Diciamo che poi, come in tutte le aziende commerciali, nelle case produttrici di software si fanno anche dei compromessi.
Perchè se fosse vero che il software closed source viene controllato, certificato ed analizzato a fondo, avremmo programmi commerciali privi o quasi di bug. Questo non si verifica, anche perchè c'è l'aspetto economico, e tante volte si preferisce immettere un prodotto sul mercato quando è "accettabilmente" privo di bug. Quell'accettabilmente poi può essere più o meno indicativo.
Io uso svariati programmi commerciali (lasciamo stare l'ambito Windows) ad esempio di CAD e product managing (non faccio nomi). I service pack e bug fix sono parecchi: certo, alcuni interessano problemi di cui io non sarei mai stato afflitto, ma altri sono stati anche piuttosto antipatici. E su software che costano migliaia di euro è abbastanza seccante vedere il tuo CAD che ogni tanto si resetta su hardware perfettamente funzionante.
Quello che voglio dire è che, nel software (a parte i discorsi su certificazioni, approvazioni et similia che spesso, non sempre, ma in molti casi è così, sono più formali che di sostanza), così come nelle altre discipline ciò che conta è fare le cose con criterio. Certi strumenti aiutano, ma fondamentale è la testa di chi fa le cose.

[fek]

Originariamente inviato da DjMix
Potresti spiegarmi cosa sono il pair programming e il pair reviewing? Non sapendolo non riesco a seguire il discorso

Detto alla buona, il pair programming e' mettere due programmatori allo stesso PC e farli programmare assieme. Letteralmente sullo stesso PC.
Pair reviewing e' mettere due programmatori a controllare sullo stesso PC un pezzo di codice.

Ma neanche per sogno. E` un problema derivante dallo sviluppo decentralizzato. Una qualsiasi SH, magari multinazionale, con sedi in due fusi orari (anche a 200 KM/h di distanza), si troverebbe a fronteggiare. E` verissimo che il F/OSS soffre di questo problema (raramente i programmatori operano sotto lo stesso tetto), e` vero che cio puo` portare (porta nella maggioranza dei casi) SW di minor qualita`, ma non e` un difetto intrinseco dell'OSS.
ibadisco il termine "difetto intrinseco".

Lo sviluppo decentralizzato non e' intrinseco all'OS? Non puoi rispondermi di no, altrimenti mi devi nominare un solo progetto OS con tutti i programmatori sotto lo stesso tetto, ed intendo tutti, perche' se vuoi fare le cose formalmente corrette, quello che ho detto e' applicato a tutti (tutti fanno pair programming, tutti scrivono unit test, tutti fanno pair review, etc).
Se lo sviluppo decentralizzato e' intrinseco alla metodologia, allora la metodologia e' intrinsecamente meno di Qualita'. Da questo punto non se ne esce: e' una prova conclusiva della tesi.

Poi, ovviamente puoi anche non accettarla come tale

Originariamente inviato da leoneazzurro
Perchè se fosse vero che il software closed source viene controllato, certificato ed analizzato a fondo, avremmo programmi commerciali privi o quasi di bug.

No, perche' e' impossibile avere alcun programma privo di bug.

[leoneazzurro]

Appunto mettevo "o quasi"

Il problema è sempre quel "livello di accettabilità".

Comunque ricordati che B&W 2 lo prenderò di sicuro... mi raccomando

[DjMix]

Originariamente inviato da fek
mi devi nominare un solo progetto OS con tutti i programmatori sotto lo stesso tetto

Tetto? o ditta? Se ti basta la seconda, eccolo:

http://www.teammosaico.biz/

Originariamente inviato da fek
No, perche' e' impossibile avere alcun programma privo di bug.

Ricordiamoci che questo vale da tutte e due le parti

[fek]

Originariamente inviato da Mason cosa intendi per test formali? mi sfugge, mi sembra troppo generico, se non e sbttimento mi dai un link, senno cerco io.

Una veloce introduzione:
http://www.revealnet.com/newsletter-v2/unit_test.htm

Libro interessante sullo unit testing:
http://www.amazon.co.uk/exec/obidos/...141626-4355647

[fek]

Originariamente inviato da leoneazzurro
Appunto mettevo "o quasi"

Il problema è sempre quel "livello di accettabilità".

Comunque ricordati che B&W 2 lo prenderò di sicuro... mi raccomando

E non sara' privo di bug

[Mason]

thx per i link, gli do un occhio , ma da quanto avevo capito in una frase precedente (non mi sembra il caso di ricercarla) sembrava che un ben definito test formale che tu avevi in testa era != da un test sulla casistica su un unit piu o meno definita: solo incomprensione.

[ilmanu]

avete mai letto qualcvhe stralcio dei commenti hai sorgenti di windows che circolavano tempo fa? i programmatori si offendevano lasciando monologhi al posto di commentare il codice, tipo per colpa di quel xxxxxxx che ha scritto quel codice col xxxxxx io ora mi devo fare un mazzo tanto per fare cosi cosi cosi


e vi posso garantire che i termini farebbero impallidire totti

quindi, se window se tanto scritto bene perche' io che pago non posso avere il DIRITTO di vedere cosa protegge la mia privacy? perche' se lo tengono avidamente stretto? forse perche' non e' poi scritto cosi' bene? winxp e' scritto in tutti i linguaggi possibili, dal c al basic, assembler e tanti altri, parti di codice che risalcono alla dosshell....no...non e' cosi' che si lavora bene....se la filosofia del del close e' migliore windows non puo' essere usato come esempio.... perche' pur usufruendo di team di sviluppo che lavorano fianco a fianco non cavano un ragno dal buco......

[afterburner]

Originariamente inviato da fek
Detto alla buona, il pair programming e' mettere due programmatori allo stesso PC e farli programmare assieme. Letteralmente sullo stesso PC.
Pair reviewing e' mettere due programmatori a controllare sullo stesso PC un pezzo di codice.
...
Se lo sviluppo decentralizzato e' intrinseco alla metodologia, allora la metodologia e' intrinsecamente meno di Qualita'. Da questo punto non se ne esce: e' una prova conclusiva della tesi.

Argghhhhhhhh!!!
Pair programming! Pair reviewing! eXtreme Programming i suppose!
Perdonami ma con i seguaci di questa filosofia ( religione? Kent Beck=Ron Hubbard? XP=scientology? ) non riesco ad andarne fuori e forse e' per questo che gira e rigira siamo tutti qui a ridire sempre le stesse cose .. buona giornata

[ilsensine]

x fek:
Ho letto i tuoi interessanti interventi, ma non credo che hai avuto modo di conoscere come avviene la produzione di un software libero di qualità come il kernel linux. Mi limito a farti osservare che se l'ultimo robottino spedito su Marte utilizzava linux, e se la NSA ha scelto linux tra le piattaforme software di riferimento per la sicurezza, non dovrebbe essere quell'accozzaglia sconfusionaria scarsamente testata che si deduce leggendo i tuoi interventi.
Per la scrittura di software di qualità non è necessario operare specificamente in campo open o closed source, come ben sai. Lo sviluppo di software libero, ben organizzato, non può influire sulla qualità, ma anzi può essere uno stimolo per migliorarla.

[fek]

Originariamente inviato da ilsensine
x fek:
Ho letto i tuoi interessanti interventi, ma non credo che hai avuto modo di conoscere come avviene la produzione di un software libero di qualità come il kernel linux. Mi limito a farti osservare che se l'ultimo robottino spedito su Marte utilizzava linux, e se la NSA ha scelto linux tra le piattaforme software di riferimento per la sicurezza, non dovrebbe essere quell'accozzaglia sconfusionaria scarsamente testata che si deduce leggendo i tuoi interventi.
Per la scrittura di software di qualità non è necessario operare specificamente in campo open o closed source, come ben sai. Lo sviluppo di software libero, ben organizzato, non può influire sulla qualità, ma anzi può essere uno stimolo per migliorarla.

Ma nessuno ha detto che Linux non e' un buon Sistema Operativo
Ho provato qui a dimostrare che metodologie formali di scrittura del codice che sono comprovate portare a software di qualita', non sono applicabili all'OS, rendendolo intrinsecamente meno di qualita'.
Il robottino spedito su Marte utilizzava linux, ma il software di controllo non era OS

[ilsensine]

Originariamente inviato da fek
Ma nessuno ha detto che Linux non e' un buon Sistema Operativo
Ho provato qui a dimostrare che metodologie formali di scrittura del codice che sono comprovate portare a software di qualita', non sono applicabili all'OS, rendendolo intrinsecamente meno di qualita'.

Sei proprio sicuro di questo?
http://www.osdlab.org/lab_activities...se_test_suite/
http://www.osdl.org/lab_activities/k.../document_view
http://www.osdl.org/lab_activities/l...l?query=Active
http://sourceforge.net/projects/plm/
http://www.osdlab.org/cgi-bin/eideti...ommand=display
ecc.
Più innumerevoli e disparati test sia runtime che di analisi automatica del codice effettuati da aziende e università (puoi trovare sulla linux kernel mailing list i dettagli se ti interessa).
Sicuramente altri produttori fanno test simili e forse più esaustivi, ma noi lo facciamo alla luce del sole.

Il robottino spedito su Marte utilizzava linux, ma il software di controllo non era OS

Avrebbero fatto girare un bel software su un S/O non affidabile ?
E la NSA? Questo è tutto software libero, con tanto di sorgenti

[Ikitt_Claw]

Originariamente inviato da fek
Lo sviluppo decentralizzato non e' intrinseco all'OS?

"intrinseco" determina caratteristica inevitabile, fondamentale.
Lo sviluppo decentralizzato non mi risulta sia caratteristica intrinseca dell'OSS, in quanto non facente parte, direttamente o meno, della sua definizione (http://www.opensource.org/docs/definition.php)

Ciononidimeno, la quasi totalita` dei progetti OSS viene sviluppata in modo decentralizzato, e infatti molto software OSS soffre dei difetti che (giustamente) evidenzi.

Non puoi rispondermi di no, altrimenti mi devi nominare un solo progetto OS con tutti i programmatori sotto lo stesso tetto,

Non conoscendo la totalita` del software OSS sviluppato, non posso in effetti risponderti su questo punto.

Se lo sviluppo decentralizzato e' intrinseco alla metodologia, allora la metodologia e' intrinsecamente meno di Qualita'. Da questo punto non se ne esce: e' una prova conclusiva della tesi.

C'e` quel "se" di mezzo pero`.
Anyway, e` quell'"intrinseco" cosi` insistentemente ripetuto il motivo del contendere...

Poi, ovviamente puoi anche non accettarla come tale

Non devi convincere me, non voglio aver ragione a tutti i costi: i difetti dell'OSS non li nego di certo. Quando sono tali, pero`.

No, perche' e' impossibile avere alcun programma privo di bug.

E allora e` impossibile avere del software di qualita`

[t0mcat]

questa è probabilmente la discussione più interessante degli ultimi mesi.

volevo quindi dire la mia.

premesso che non ho alcuna esperienza in programmazione di alcun tipo (se non un pochetto sviluppo di applicazioni web - e.g. php/mysql - che un qualunque web master degno di questo nome dovrebbe conoscere), e che sconosco le metodologie [in]formali di sviluppo e testing del software in ambito più o meno professionale...

...il discorso di fek, seppur esposto a mio avviso in termini fin troppo fiscali, non fa una grinza, almeno fino a quando si parla di applicazioni con uno scopo molto specifico e dal contesto per niente vasto, come le più volte citate life-critical.
In questo ambito, da quello che so, si tratta di applicazioni che hanno un compito specifico, progettate per essere eseguite in hardware altrettanto specifico, quindi il tutto in un contesto piuttosto selezionato.
In tal caso, a mio modesto parere, l'OSS risulta inadatto perché non mi pare che sia questo il contesto per il quale è nato.

Nel momento in cui invece si parla di Personal Computer, quindi di hardware con un'infinità di possibili variazioni, sul quale far girare del software con un'infinità di possibili scopi, mi sembra sia proprio il CSS un pesce fuor d'acqua.

Considerato che l'OSS si basa sul contributo degli utilizzatori stessi, degli appassionati che capitano per caso su un software, e per saziare la loro inarrestabile voglia di sapere (che io chiamerei più "innata propensione al cazzeggio" ) si mettono a spulciare i sorgenti, per poi eventualmente correggerli, modificarli, e/o evolverli a loro piacimento, non vedo come tutto ciò possa avverarsi in un contesto differente da quello dei Personal Computer.
Non ha senso parlare di questo fondamento dell'OSS in ambiti specialistici come le già citate (fino alla nausea) applicazioni life-critical.
Chi cacchio è che avrebbe interesse a spluciarsi i sorgenti di un software di controllo di un radiofaro di un aeroporto, rispetto a quanti invece hanno interesse ad avere funzionalità aggiunte al kernel del Sistema Operativo che viene fatto girare sul proprio computer di casa (o sul server della propria azienda)?

E considerato che l'architettura di un personal computer implica delle complicazioni nello sviluppo del software, risulta molto più vantaggioso l'OSS in quest'ambito, perché sicuramente il tizio che ha sviluppato un proprio software non ha avuto la possibilità di testarlo in ogni configurazione hardware possibile, lo rilascia comunque stabile, e poi magari si scopre un bug che avviene solo su determinati componenti installati.
In questo caso se il soft in questione è CSS, bisogna aspettare che la SH testi il tutto sull'hardware incriminato, dopodiché bisogna aspettare che rilasci un fix, sempre che tutto ciò venga ritenuto vantaggioso economicamente... (perché magari non si mettono a rilasciare i fix per dell'hardware che non è abbastanza diffuso, perché ad una SH tutto ciò costa). Se la SH decidesse di non rilasciare il fix, il malcapitato utente non avrà alternative che cambiare hardware o non utilizzare quel soft.
Se invece il soft è OSS, lo scopritore del bug, che ha avuto la sfiga di possedere quel componente che non gli fa girare il soft a dovere, ha la possibilità di far tutto da sé, senza nessun dispendio di tempo da parte del tizio che ha sviluppato il soft, che oltretutto non ha interesse economico alcuno, visto che il suo soft è libero. Il bug verrà notificato alla community, nella quale probabilmente si troverà qualcun altro con lo stesso problema che sottoporrà il fix ai test del caso, e poi verrà sottoposto all'attenzione del programmatore originario, il quale magari ufficializzerà il fix. Se non lo farà, il fix sarà comunque disponibile per chiunque, aperto anche a successive modifiche.

In questa storiella mi pare ci siano racchiusi i parametri di Qualità che fek ha citato:

- minimazzare i difetti (l'utente del soft OSS ne ha appena eliminato uno, e una miriade di altre persone come lui può fare lo stesso, nel caso del CSS invece il difetto rimane)
- massimizzare l'estensibilita' (magari non ho ben chiaro cosa voglia dire, ma cosa c'è di più estensibile di un codice aperto a chiunque voglia aggiungervi funzionalità?)
- minimizzare i costi di mantenimento (chiunque può contribuirvi, e lo fa per passione, non per denaro, per primo il creatore del soft. Chi lo fa evidentemente ha parecchio tempo libero, ed il tempo libero lo si impiega come si vuole, quindi ha il valore che ognuno vuole attribuirgli)
- implementare le specifiche (questo lo vorrei spiegato )


Concludendo, restando nell'ambito del personal computing, sicuramente esistono molti più esempi di software CSS di qualità inferiore all'OSS piuttosto che il contrario, e non sto qui a citare il più ovvio, sarebbe scontato.


tutto ciò ovviamente IMVHO.

[fek]

Originariamente inviato da ilsensine
Più innumerevoli e disparati test sia runtime che di analisi automatica del codice effettuati da aziende e università (puoi trovare sulla linux kernel mailing list i dettagli se ti interessa).
Sicuramente altri produttori fanno test simili e forse più esaustivi, ma noi lo facciamo alla luce del sole.

Facciamo un distinguo, cosi' rispondo anche a Ikitt: qui si sta parlando di metodologia di sviluppo OSS, con sviluppo decentralizzato. E' cio' di cui abbiamo discusso fino ad ora. Non si sta parlando dell'opportunita' o meno di rilasciare i propri sorgenti al pubblico che e' un discorso completamente diverso e sul quale non ho un'idea precisa.
Sicuramente il solo fatto di rendere un sorgente pubblico non ne aumenta la qualita', questo e' sicuro, perche' la qualita' dipende dalle metodologie di sviluppo.

Con questo non ho mai affermato che non esistano suit di testing per sviluppatori in ambiente Linux. Sono certo che esistano, e sono certo che ci sono team di sviluppo che usano test formali anche sotto Linux. Si scrive software commerciale anche sotto Linux. Per altro non ho mai neppure partecipato alla guerra Linux vs Windows perche' credo sia una cosa stupida.

Ora, il punto del discorso e': l'articolo affermava che Linux e' piu' sicuro perche' la metodologia di sviluppo OS (e distribuita abbiamo specificato in seguito lungo il thread) e' intrinsecamente piu' sicura. No, mi sono affannato a dimostrare il contrario, portando svariati esempi che includono sia le pratiche che di solito vengono disattese in questa metodologia, sia le pratiche che sono assolutamente impossibili (ho citato il pair programming), per concludere che l'OSS e' intrinsecamente di minor qualita' rispetto a codice scritto "on site".

Avrebbero fatto girare un bel software su un S/O non affidabile ?
E la NSA? Questo è tutto software libero, con tanto di sorgenti

Dell'NSA non parlo per motivi politici

[fek]

Originariamente inviato da Ikitt_Claw
E allora e` impossibile avere del software di qualita`

Mi sembrava chiaro che software di qualita' non vuol dire esente da bug