Linux più sicuro per Evans Data Corp.

[Ikitt_Claw]

Originariamente inviato da fek
che come e' uscito in questo thread, non sono possibili in un ambiente OS.

quote, grazie.

[DjMix]

(in riferimento al post sopra) Ma sopratutto: e perchè non sarebbero possibili?

Originariamente inviato da fek
A scanso di equivoci, non sto affermando che l'OS sia sbagliato, anzi, come tutte le metodologie ha i suoi vantaggi e i suoi svantaggi: un vantaggio e' la velocita' di propagazione dei fix, uno svantaggio e' l'intrinseca propensione ai difetti e la poca stabilita' del codice (per stabilita' non intendo il crashare o meno in questo ambito).

Ma siamo sicuri che OpenSource e ClosedSource siano metologie? Io pensavo che metodologia fosse il modo con cui un programma viene sviluppato, non il fatto che i sorgenti fossero disponibili o meno.

Piuttosto, il fatto che siano disponibili i sorgenti porta a molte altre conseguenze:
1) uno può controllarseli così si fa in casa la sua parte della metologia, se non si fida degli altri;
2) non c'è scritto da nessuna parte che chichessia possa mettere le mani in un progetto. C'è scritto che uno può modificarlo e proporre le modifiche al manteiner del progetto, ovvero al capo di chi porta avanti la tanto famosa metologia, ma se il manteiner non vuole aiuti esterni non li considera e basta.
3) uno se si vede sempre rifiutate le modifiche al progetto e le vuole integrare si forka il progetto e si arrangia, son fatti suoi, il progetto originale non lo toccherà nessuno, punto e basta.

[fek]

I quote che mi avevi chiesto:

Originariamente inviato da Ikitt_Claw
I test periodici e/o le nightly build (quando ci sono )

Spesso non esistono, non sempre.

Si parlava di unit test, che non sono neppure test formali. Se spesso mancano le unit test, come fanno ad esserci test formali?

Potrai non condividere la mia tesi, ma le premesse sono state poste e confermate da te: mancano spesso i test formali (lo hai scritto tu), mancano review formali, mancano le basi minime per software di qualita'. Infatti, come ripeto, quando l'applicazione richiede alta qualita' come nel caso di sistemi life critical, non si applicano metologie OS. Questo e' un dato di fatto.

Quando parlavo di stabilita' mi riferivo alla stabilita' del code base, non alla stabilita' del sistema: il termine stabilita' nell'ingegneria del software non ha il significato che gli attribuiamo informalmente.

[cdimauro]

Originariamente inviato da DjMix
Ma siamo sicuri che OpenSource e ClosedSource siano metologie? Io pensavo che metodologia fosse il modo con cui un programma viene sviluppato, non il fatto che i sorgenti fossero disponibili o meno.

In linea teorica puoi applicare qualunque metodologia di sviluppo e mantenimento all'OSS e al CSS. Il problema sollevato riguarda quel che effettivamente accade nell'ambito OSS, come evidenziato da fek (mancanza di test formali).

Piuttosto, il fatto che siano disponibili i sorgenti porta a molte altre conseguenze:
1) uno può controllarseli così si fa in casa la sua parte della metologia, se non si fida degli altri;

Hai detto bene: PUO'. E da ciò nascono due considerazioni: può anche non farlo, e se lo fa, può non essere abbastanza esperto di metodologie di testing.

2) non c'è scritto da nessuna parte che chichessia possa mettere le mani in un progetto. C'è scritto che uno può modificarlo e proporre le modifiche al manteiner del progetto, ovvero al capo di chi porta avanti la tanto famosa metologia, ma se il manteiner non vuole aiuti esterni non li considera e basta.

Non mi risulta sia così: questo è ciò che avevo ipotizzato qualche tempo addietro quando proponevo un nuovo tipo di licenza alla cui base ci fosse, appunto, un team di coordinamento esperto che dettava le linee generali e vagliava le modifiche. Sono stato quasi sbranato, per cui ritengo che le cose stiano diversamente...

3) uno se si vede sempre rifiutate le modifiche al progetto e le vuole integrare si forka il progetto e si arrangia, son fatti suoi, il progetto originale non lo toccherà nessuno, punto e basta.

Hai detto niente: la cosa che impari quando entri a far parte di un team di sviluppo fuori dai canoni dilettantistici, è che ogni nuova idea viene esaminata A FONDO dal team di sviluppo, e vengono studiate le implicazioni pratiche che avrebbe sul progetto; un'idea non si scarta perché "non piace" al team, ma perché oggettivamente, dopo aver analizzato DETTAGLIATAMENTE i pro e i contro, si conviene alla decisione finale, su basi puramente tecniche.

Al più, se è interesse dell'azienda, nel codice vengono introdotte delle compilazioni condizionali per permettere in qualsiasi momento di scegliere quale tipo di codice attivare, ma sempre tenendo in mente il fatto che tutto ciò rientri nei suoi piani; tanto per fare UN esempio, nel decoder che ho sviluppato, il codice di error detection e concealment viene compilato su base condizionale, perché l'azienda ha intenzione di differenziare il prodotto finale in base al target.

Da tutto ciò puoi ben vedere che l'idea stessa di fork del progetto è semplicemente INCONCEPIBILE in un ambiente di lavoro professionale: nessuno si sognerebbe mai di fare o proporre una cosa del genere né tanto meno di pensarla (proprio non esiste).

[Ikitt_Claw]

Originariamente inviato da fek
I quote che mi avevi chiesto:
Si parlava di unit test, che non sono neppure test formali. Se spesso mancano le unit test, come fanno ad esserci test formali?

Potrai non condividere la mia tesi, ma le premesse sono state poste e confermate da te: mancano spesso i test formali (lo hai scritto tu), mancano review formali, mancano le basi minime per software di qualita'. Infatti, come ripeto, quando l'applicazione richiede alta qualita' come nel caso di sistemi life critical, non si applicano metologie OS. Questo e' un dato di fatto.

Che manchino in una rilevantissima quantita` di progetti F/OSS e`, ahime`, un dato di fatto.
Ma mancano perche` i team manager non possono/vogliono/sanno farlo, non perche` e` il modello F/OSS in quanto tale a impedirlo.

Il modello di sviluppo F/OSS in quanto tale non impedisce certo l'applicazione di metodologie rigide e rigorose a piacere di analisi, test e QA.

[Ikitt_Claw]

Originariamente inviato da cdimauro
In linea teorica puoi applicare qualunque metodologia di sviluppo e mantenimento all'OSS e al CSS.

Esattamente. Ma mi pareva che nel thread si sostenesse che l'OSS preclude automaticamente alcune metodologie che sono implicite nel CSS o mi sbaglio?

Non mi risulta sia così: questo è ciò che avevo ipotizzato qualche tempo addietro quando proponevo un nuovo tipo di licenza alla cui base ci fosse, appunto, un team di coordinamento esperto che dettava le linee generali e vagliava le modifiche. Sono stato quasi sbranato, per cui ritengo che le cose stiano diversamente...

Non ricordo che la cosa fosse messa giu` in questi termini (forse non ho partecipato al thread?)!
Forse qualcuno (non sto facendo il vago, sto parlando in generale) ha l'idea che in un progetto OSS il primo che passa
puo` modificare tutto quel che gli pare come gli pare, beh, le cose non stanno esattamente cosi`, non sempre almeno.
Il mantainer ha sempre la possibilita` (ovviamente!) di rigettare le patch per qualunque motivo, o perche` la luna e` allineata con saturno, o perche` il nickname del proponente lo fa ridere, o perche` la modifica non passa una batteria sterminata di test di varia natura...

Per dire un paio di cose -non strettamente attinenti col filone che ha preso il thread-, una patch che non rispetta lo stile di codifica del progetto sara` rigettata quasi automaticamente; ci sono stati dei "casi" abbastanza clamorosi (nel senso che han fatto scalpore) di patch non accettati sia in Linux (kernel) sia in GCC che in molti altri SW, creando in alcuni casi dei fork, in altre dei flame clamorosi.

La natura aperta dell'OSS ha come conseguenza fondamentale il fatto che chiunque ha la possibilita` di proporre patch, non ha pero` la certezza che venga accettata per millemila diversi motivi...
...In quel caso puo` farsi un fork, pero`

Hai detto niente: la cosa che impari quando entri a far parte di un team di sviluppo fuori dai canoni dilettantistici, è che ogni nuova idea viene esaminata A FONDO dal team di sviluppo, e vengono studiate le implicazioni pratiche che avrebbe sul progetto; un'idea non si scarta perché "non piace" al team, ma perché oggettivamente, dopo aver analizzato DETTAGLIATAMENTE i pro e i contro, si conviene alla decisione finale, su basi puramente tecniche.

...Cosa che si puo` fare, e a volte si fa (a volte no, ahime`), anche nel mondo F/OSS...

Al più, se è interesse dell'azienda, nel codice vengono introdotte delle compilazioni condizionali per permettere in qualsiasi momento di scegliere quale tipo di codice attivare, ma sempre tenendo in mente il fatto che tutto ciò rientri nei suoi piani; tanto per fare UN esempio, nel decoder che ho sviluppato, il codice di error detection e concealment viene compilato su base condizionale, perché l'azienda ha intenzione di differenziare il prodotto finale in base al target.

...Cosa che si puo` fare, e a volte si fa (a volte no, ahime`), anche nel mondo F/OSS...

Da tutto ciò puoi ben vedere che l'idea stessa di fork del progetto è semplicemente INCONCEPIBILE in un ambiente di lavoro professionale: nessuno si sognerebbe mai di fare o proporre una cosa del genere né tanto meno di pensarla (proprio non esiste).

Questo e` un discorso diverso, che non affronterei qui per non appesantire il thread.

[ilmanu]

ehmm.... ma da quando Linux e' diventato un Sistema Operativo???????

[Ikitt_Claw]

Originariamente inviato da ilmanu
ehmm.... ma da quando Linux e' diventato un Sistema Operativo???????

Touche`
Pero` quando RMS si mette a puntualizzare, tutti giu` a tacciarlo di pignoleria...

[fek]

Originariamente inviato da Ikitt_Claw
Che manchino in una rilevantissima quantita` di progetti F/OSS e`, ahime`, un dato di fatto.
Ma mancano perche` i team manager non possono/vogliono/sanno farlo, non perche` e` il modello F/OSS in quanto tale a impedirlo.

Il modello di sviluppo F/OSS in quanto tale non impedisce certo l'applicazione di metodologie rigide e rigorose a piacere di analisi, test e QA.

Quindi, in pratica, non e' vero che l'OS e' meno difettoso, anzi, perche', in pratica, non si usano nella maggioranza dei casi metodologie formali.

In conclusione del thread, possiamo affermare che l'affermazione "l'OS e' una metodologia alla lunga meno difettosa" e' in pratica falsa. Come ho affermato fin dall'inizio.

Se poi vogliamo analizzare quello che accade nella minoranza dei casi nei quali tu hai detto che metodologie formali si possono applicare, ti prego ancora di citarmi un esempio di applicazione life critical OS, giusto per capire se quello che dici tu avvenga mai anche solo in sparuti casi.

Originariamente inviato da cdimauro
Da tutto ciò puoi ben vedere che l'idea stessa di fork del progetto è semplicemente INCONCEPIBILE in un ambiente di lavoro professionale: nessuno si sognerebbe mai di fare o proporre una cosa del genere né tanto meno di pensarla (proprio non esiste).

Direi che c'e' poco altro da aggiungere

[afterburner]

Originariamente inviato da ilmanu
ehmm.... ma da quando Linux e' diventato un Sistema Operativo???????

Solita leggenda metropolitana .. Non fidarti!!

Originariamente inviato da cdimauro
Da tutto ciò puoi ben vedere che l'idea stessa di fork del progetto è semplicemente INCONCEPIBILE in un ambiente di lavoro professionale: nessuno si sognerebbe mai di fare o proporre una cosa del genere né tanto meno di pensarla (proprio non esiste).

Ovvio che se lavoro per un'azienda che porta avanti un progetto e sono stipendiato da tale azienda, se una mia modifica (o proposta di miglioramento) non viene accettata "prendo, intasco e me la metto via" .. Nel mondo OSS e' diverso .. Linux stesso (il kernel) e' un fork del progetto Minix del prof. Tanenbaum ..
Professionale o meno l'importante e' che funzioni

[DjMix]

Originariamente inviato da cdimauro
Da tutto ciò puoi ben vedere che l'idea stessa di fork del progetto è semplicemente INCONCEPIBILE in un ambiente di lavoro professionale: nessuno si sognerebbe mai di fare o proporre una cosa del genere né tanto meno di pensarla (proprio non esiste).

Non hai capito il mio discorso. Io sto dicendo che, se un team sviluppa un programma, e lo mette sotto una licenza free o open, non è obbligato in alcun modo a subire ingerenze esterne dal primo che capita. Ma se c'è un qualcuno che mette mano al codice (se lo copia giù dal cvs pubblico) e fa modifiche, le propone al team e questo le rigetta, questo qualcuno può prendere il codice che si è tirato giù dal cvs e usarlo come base per un progetto diverso (si fa un fork). Il team del programma originale continua per la sua strada, sto qualcuno continua per la sua, e fine della storia. Tu continui ad usare il programma originale e sei a posto. Non intendevo affatto che i programmatori del team dentro l'azienda si mettano a forkare il progetto fra di loro, sarebbe una gran cazzata eh!

[fek]

Originariamente inviato da afterburner
Professionale o meno l'importante e' che funzioni

E' proprio qui il nodo del discorso: l'importante non e' che funzioni, l'importante e' che sia semplice da mantenere quando le cose non funzionano oppure sia facile da estendere quando e' necessario.

In poche parole, che sia software di Qualita'.

[afterburner]

Originariamente inviato da fek
E' proprio qui il nodo del discorso: l'importante non e' che funzioni, l'importante e' che sia semplice da mantenere quando le cose non funzionano oppure sia facile da estendere quando e' necessario.

In poche parole, che sia software di Qualita'.

OK, partendo dal tuo punto di vista posso darti ragione.
A te, programmatore per azienda X ti danno da fare il maintaining di un software della stessa azienda X, sicuramente scritto da qualcun altro anni prima .. se e' software di qualita' e di cui disponi della documentazione vai come una scheggia, se e' software che funziona ma senza docs e manco un commento allora fai prima a riscrivere tutto da zero. Sono d'accordo.

Cio' non significa che nel mondo open-source non ci sia software di Qualita' .. forse i nostri punti di vista sulla Qualita' del software sono diversi .. tu punti molto su "code review formali" e altra terminologia specifica da programmatore d'azienda .. per me Qualita', tra le altre cose,significa nessuna falla di sicurezza e sono sicuro che piu' gente si legge i sorgenti di openssh, piu' i bug vengono al pettine e piu' ssh e' sicuro.

[leoneazzurro]

Tornando al discorso, se il modello OS ha le sue lacune, ha anche dei vantaggi interessanti, se non altro per gli "stimoli" che può dare ai programmatori.

Mi fate qualche esempio di software life critical basato su Win?

Ad ogni modo, sappiamo tutti che l'OS (usato spesso nei server) che ha avuto meno falle di tutti è OpenBSD Non supporterà tanto hardware, ma per essere solido è solido...

[DjMix]

Quello che non capisco è come facciate ad arrivare alla conclusione

Software Libero/open source = sviluppato dai programmatori della domenica
Software closed = sviluppato seguendo i crismi

Da quel che mi raccontano i miei amici freschi di ingegneria informatica, che han trovato posto in aziende di software, la situazione è disastrosa! Ovvio che son solo parole mie, ma caspita fidatevi, non vengo certo a sparare balle... il fatto che sia closed o portato avanti da una società non significa automaticamente che sia fatto bene! E per assurdo l'F/OSS ti consente di renderti *esattamente* conto di come viene portato avanti un programma, cosa che non puoi quasi mai fare in un programma closed! Come fate ad essere così convinti delle vostre idee di fronte a questi fatti?

[Mason]

non ho letto l'articolo, non ho letto tutti i msg, non mi interessa "avere ragione".

imho:

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.
concordo che il modello che sta alla base ha anche altri aspetti di valutazione che possano essere formalizzati e quindi valutati in scale concordate, ma hanno un peso minore nella valutazione della bonta' di un modello rispetto a quello della correttezza.

secondo me il metodo di sviluppo e indipendente dagli strumenti utlizzati:
posso usare tutti i case test del mondo siain open sia in closed,benchmark regolati da un cert formalismo, falgs di compilazione severamente definite e via dicendo, ma sia un un modello open source che in un modello closed source.Le differenza nei 2 modelli che ci vedo sono sopratutto nel ciclo di vita e nella politica di relase del software, non molto nel modello di implementazione

per la appicazione a cui dovrei affidare la mia vita mi piacerebbe curiosarla, anche se non ci capisco un cazzo, non pretendo per di capire conectti da formicaio tiipo "morte di uno salvezza di molti", forse quelli e meglio celarli nella quadratura ragione.

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

[fek]

Originariamente inviato da afterburner
Cio' non significa che nel mondo open-source non ci sia software di Qualita' .. forse i nostri punti di vista sulla Qualita' del software sono diversi .. tu punti molto su "code review formali" e altra terminologia specifica da programmatore d'azienda .. per me Qualita', tra le altre cose,significa nessuna falla di sicurezza e sono sicuro che piu' gente si legge i sorgenti di openssh, piu' i bug vengono al pettine e piu' ssh e' sicuro.

Piano, la definizione di Qualita' del software e' univoca, non c'e' la mia o la tua. Per farla semplice, scrivere software di Qualita' signfica:

- implementare le specifiche
- minimazzare i difetti
- massimizzare l'estensibilita'
- minimizzare i costi di mantenimento

Nessuno dice che non ci possa essere software di qualita' nel mondo OS, sto dicendo che esistono metodologie precise, documentate e comprovate nell'Ingegneria del Software per scrivere software di Qualita' e queste metodologie, come e' uscito in questo topic, sono spesso disattese in ambienti OS.

[Ikitt_Claw]

Originariamente inviato da fek
Quindi, in pratica, non e' vero che l'OS e' meno difettoso, anzi, perche', in pratica, non si usano nella maggioranza dei casi metodologie formali.

Che sia la maggioranza o meno dei casi non lo so. Che una fase intensiva di testing (e di analisi, in certi casi) sia latitante, l'ho convenuto dall'inizio del thread.
Che il software OSS sia piu` o meno difettoso di quello commerciale non sono in grado di quantificarlo.

In conclusione del thread, possiamo affermare che l'affermazione "l'OS e' una metodologia alla lunga meno difettosa" e' in pratica falsa. Come ho affermato fin dall'inizio.

Ma io direi proprio di no. Certo, non avendo letto estensivamente Fowler o Sutter non credo di aver diritto di parola, ma di certo questo thread non e` stato convincente.
Per inciso, a me pareva che fin dall'inizio tu sostenessi che...

Quello che sto dicendo e' che affermare che l'OSS e' intrinsecamente meno "difettoso" e' una bestialita': al massimo e' il contrario, visto che e' un sistema di costruzione del software intrinsecamente anarchico e non strutturato dove maVorreinca totalmente un sistema formale di QA.

Che non e` esattamente quello che dici adesso.

Se poi vogliamo analizzare quello che accade nella minoranza dei casi nei quali tu hai detto che metodologie formali si possono applicare, ti prego ancora di citarmi un esempio di applicazione life critical OS, giusto per capire se quello che dici tu avvenga mai anche solo in sparuti casi.

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...

[Ikitt_Claw]

Originariamente inviato da fek
Nessuno dice che non ci possa essere software di qualita' nel mondo OS, sto dicendo che esistono metodologie precise, documentate e comprovate nell'Ingegneria del Software per scrivere software di Qualita' e queste metodologie, come e' uscito in questo topic, sono spesso disattese in ambienti OS.

Su questo punto, se non fosse chiaro, convengo con la tua posizione. E infatti l'ho precisato all'inizio del thread.
Il punto, ribadisco, su cui non sono affatto d'accordo, e` che tali metodologie sono benissimo applicabili anche nel caso dell'OSS. Semplicemente (purtroppo) non vengono applicate per 1000+1 motivi, ma non e` che fare un progetto OSS esclude automaticamente farlo di qualita`, mentre vale il contrario per il CS, come invece mi pareva stesse emergendo dal thread.
Forse c'e` solamente dietro un grosso malinteso...

[Ikitt_Claw]

Originariamente inviato da DjMix
Quello che non capisco è come facciate ad arrivare alla conclusione

Software Libero/open source = sviluppato dai programmatori della domenica
Software closed = sviluppato seguendo i crismi

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