Linux più sicuro per Evans Data Corp.

[Ikitt_Claw]

Originariamente inviato da fek
Purtroppo pero' la prima regola dell'Ingegneria del Software e' di non fidarsi di nessuno, tantomeno di se' stessi.

Di quale branca dell'ingegneria del software?

Mentre tu mi dici che l'OS si basa sulla fiducia di modifiche (relativamente) sicure.

Anche su questo

Capirai che il confronto con sistemi formali di testing neppure si pone.

Con gli elementi sinora emersi dal thread, no.

Mancanza di politica testing e documentazione propria come hai ammesso, mancanza di check in formali e da questo concludi che l'OS e' alla lunga distanza meno difettoso? Mi sembra un'affermazione poco condivisibile.

Concludo che alla lunga e` in potenza meno difettoso.
Piuttosto, tu mi pare tendi a generalizzare un po` troppo: si verifica sperimentalmente che la documentazione e i test formali sono troppo spesso (piu` spesso di "raramente" e` comunque troppo spesso) lacunosi o mancanti, ma questo e` un difetto dei gruppi di sviluppo, non nel sistema OSS in quanto tale.

Non ho mai detto che l'OS funzioni per caso, dico che e' un sistema di costruire software intrinsecamente meno affidabile

Mi fai qualche esempio di constraint del'OS che lo rende intrinsecamente meno affidabile?

delle metodologie applicate nelle migliori aziende di software che prevedono analisi dei requisiti formali, specifiche, testing e code review formali, system testing.

...Tutto ortogonale alla metodologia di sviluppo utilizzata.

Mi fai un esempio di progetto OS che preveda code review formali?

No, perche` non sono addentro a progetti grossi (i quali, o implodono, o funzionano per caso, o hanno metodologia di testing di affidabilita` non nulla). Posso pero` farti qualche nome di qualche progetto OS che NON lo prevede (e si vede, infatti).

[IcemanX]

Che VS6 fosse una schifezza OK, ma il fatto che il .Net produca lo stesso "precompilato" indipendentemente dal linguaggio mi lascia un po' perplesso.

X quanto riguarda la programmazione Open/Close Source posso dire di non aver mai visto righe del tipo "non toccate questa ca$$o di riga porç@ tr0|@ xchè s'|nç"la tutto!" nel source di una distribuzione Linux

[afterburner]

Originariamente inviato da fek
Linux e' gratis per quelli il cui tempo vale nulla

Spiegati meglio .. sembra tanto una sparata fumosa

[afterburner]

Originariamente inviato da fek
Vorrei vedere chi darebbe da costruire un sistema life-critical, ad esempio, ad un gruppo OS

Ma ti rendi conto di quello che stai dicendo? Mi sa di proprio di no!
Definiscimi un sistema life-critical! Cos'e'? Un sistema che deve avere uptime sopra 99.9%? In un post ci sono le % dei server apache nel mondo .. Apache di chi e' frutto? E' Open-Source! e dove gira di solito httpd? su Linux! cos'e' Linux? E' OS!
Poi, per favore vivi un po' meno di sigle: fanno tanto sboron e basta

[cdimauro]

Credo di capire cosa voglia dire fek. Di recente ho concluso la tesi all'STM relativa allo sviluppo di un decoder JPEG2000 che verrà implementato in sistemi embedded. Non è un progetto da centinaia di migliaia di righe di codice (saranno circa 10mila), ma la metodologia per il suo sviluppo è stata ben diversa da quella che ho utilizzato per il software che ho normalmente sviluppato.

A parte il fatto che sono presenti più commenti che codice vero e proprio (e che descrivono veramente TUTTO ciò che il codice fa), ho dovuto utilizzare uno stile ben preciso (indentazione, identificatori scritti in un certo modo, dichiarazioni di macro strutturate secondo certi canoni, ecc.), dotare ogni funzione di un commento iniziale in cui si specifica ogni singolo dettaglio (perfino per le funzioni aventi UNA riga di codice), utilizzare solamente alcuni costrutti del linguaggio C (ANSI C puro) e in un certo modo, effettuare il prototype anche di funzioni interne, e chissà cos'altro sto dimenticando in questo momento.

Quando ho realizzato la seconda versione (la prima l'ho finita ai primi di aprile), ho dovuto annotare per filo e per segno tutte le modifiche fatte, quando sono state fatte, e cosa è stato cambiato. Dopo di ciò, siamo passati (con chi mi seguiva direttamente nel progetto) a una fase di testing intensiva, riprovando nuovamente tutti gli stream, anche quelli già testati, e confrondo i risultati con quelli di altri decoder realizzati per il testing; quando abbiamo trovato delle discordanze anche minime con essi (parliamo di immagini lossy, il che DOVREBBE essere normale), mi è stato chiesto di ricercare i motivi per i quali si verificano quegli scostamenti, ed eventualmente come sarebbe stato possibile avvicinarsi ai risultati dei modelli di riferimento.

Alla fine sono stati introdotti degli errori secondo varie distribuzioni di probabilità per testare che il tutto non si bloccasse (sono arrivato a testare stream aventi errori ogni 100 bit, e con burst fino a 8 bit).

Sicuramente avrà dimenticato molti dettagli, ma posso assicurarvi che anche per scrivere una sola riga di codice, la differenza fra un progetto "casalingo" e uno per conto di una società di un certo calibro, è veramente notevole. Pur utilizzando da anni Delphi come mio linguaggio preferito, che mi induce in maniera naturale a scrivere codice leggibile e secondo certi canoni, ho dovuto cambiare radicalmente il mio modus operandi ed entrare in un'ottica completa diversa.

Un'altra cosa: per chi dice che VisualStudio è un compilatore non aderente allo standard ANSI (C puro, nel mio caso), la versione 6 compilava perfettamente il decoder, senza generare alcun warning, mentre lo GNU C 3.2 (non mi ricordo la build esatta) generava dei warning semplicemente assurdi: definito un nuovo tipo con typedef, con ALCUNE (mica tutte!) funzioni che lo usavano per alcuni parametri, il compilatore mi dava un warning alla riga di codice relativa alla chiamata di funzione, quando come parametro passavo una variabile dello STESSO typedef; anche provando con vari cast, non c'è stato verso di rimuove il warning.
Vero è che il codice di GNU era decisamente più veloce (su un Celeron 600Mhz potevo avvertire la differenza "a occhio" ), ma è decisamente seccante vedere generare dei warning per del codice scritto come ANSI comanda.

[xcdegasp]

@ fek:
io non so' da che relatà vieni, io ho fatto esperienza in una grossa azienda italiana che ora fondendosi con altre aziende ha dato vita ad un Gruppo di ingenti dimensioni.
In quella realtà in cui sono "cresciuto" (ogni applicazione che veniva presa in carico doveva per forza di cose fornire i sorgenti) ho appreso che tenere a portata di tutti i sorgenti non fosse un male (i sorgenti erano visibili solo a chi apparteneva alla azienda), inquanto, successivamente alla fusione, le regole sui sorgenti sono venute meno.. bhè queste applicazioni guarda caso hanno da sempre avuto problemi esistenziali, una modifica non va' mai a buon fine e l'applicazione genera errori di certo rilievo anche senza toccarla..
questo per dire che se si è coscienti che il codice è visibile a TUTTI si ha più interesse a non fare errori madornali perchè cmq non sei più tu a creare quel pezzo di codice ma tu+pinco.

Ritornando a linux, questo non è sviluppato solo ed esclusivamente da Trovalds e amatoriale bensì hanno dato ulteriore contributo tutte quelle distro che esistono sul mercato internazionale!! Se per te non basta che Red Hat, Suse & Co "controllino" il software allora sei vermante mentecatto a credere che un software sviluppato unicamente da una azienda sia migliore!!
Nella azienda in cui lavoro ci sono molti più server Linux di Windows nonostante ci sia l'assistenza full time da parte di HP e IBM (nella lan cmq sono presenti dei imponenti server Unix), le quali non hanno mai spinto per acquistare o usare server windows.

Forse dovresti solo aprire la tua mente Fek, il mondo cambia.. quello che te avevi imparato a 20 anni ora i ragazzini di 13 anni lo sanno fare forse meglio di te all'epoca.

Bye

[xcdegasp]

@ fek, dimenticavo:
spiegami i problemi esistenziali dei server di posta lotus perchè IBM da un anno a questa parte non è riuscita a risolvere... prima si usava un sistema opensource che non dava mai problemi, era impeccabile!!
sono proprio curioso

direi che oltre a me ci sono altri 999 colleghi + altri 3000 derivati dalla fusione che attendono un tuo consiglio in merito. e sì che Lotus ha tutte le certificazioni e test per essere commercializzato e ritenuto valido

[cdimauro]

Originariamente inviato da xcdegasp
Ritornando a linux, questo non è sviluppato solo ed esclusivamente da Trovalds e amatoriale bensì hanno dato ulteriore contributo tutte quelle distro che esistono sul mercato internazionale!! Se per te non basta che Red Hat, Suse & Co "controllino" il software allora sei vermante mentecatto a credere che un software sviluppato unicamente da una azienda sia migliore!!

Secondo me non hai capito quello che fek ripete da un po' di messaggi a questa parte: mi sembra che abbia detto cose ben diverse rispetto a quanto stai scrivendo...

Forse dovresti solo aprire la tua mente Fek, il mondo cambia.. quello che te avevi imparato a 20 anni ora i ragazzini di 13 anni lo sanno fare forse meglio di te all'epoca.

Bye

Hai detto bene: forse. Perché finora noto soltanto tanti lamerini che si divertono a usare programmi arcinoti che sfruttano delle falle di sicurezza per "attaccare" i computer, e si spacciano per "hacker".
20 anni fa, invece, non era difficile incontrare gente che ti rivoltava come un calzino i computer dell'epoca (Vic20, C64, Spectrum, MSX, ecc. ecc.).

[cdimauro]

Originariamente inviato da xcdegasp
@ fek, dimenticavo:
spiegami i problemi esistenziali dei server di posta lotus perchè IBM da un anno a questa parte non è riuscita a risolvere... prima si usava un sistema opensource che non dava mai problemi, era impeccabile!!
sono proprio curioso

direi che oltre a me ci sono altri 999 colleghi + altri 3000 derivati dalla fusione che attendono un tuo consiglio in merito. e sì che Lotus ha tutte le certificazioni e test per essere commercializzato e ritenuto valido

Non puoi pretendere di generalizzare con un solo esempio...

Rileggiti qualche altra volta volta quel che ha scritto fek, che è meglio...

[DjMix]

mmmm io credo che vi stiate azzuffando per niente... dopo tutto il "come" i progetti vengano portati avanti varia molto da gruppo a gruppo, e con questo intendo sia Closed che Open. Prendiamo Linux ad esempio (il kernel), non mi pare che sia troppo allo sbando come programma! Ma esisteranno anche programmi closed portati avanti con chiarezza, qua non vi so fare esempi ma ne conoscerete per vostra esperienza personale... come poi ci sono programmi open allo sbando e ditte closed che non usano manco cvs per dire, hanno una directory condivisa e tutti ci mettono le mani... Secondo me sbagliate a discutere del metodo, perchè niente mi vieta di fare come ha raccontato cdimauro su un programma open, mica l'accesso in scrittura al cvs deve essere dato a chichessia! Ma il fatto che un programma sia closed non mi garantisce che non sia stato fatto da incompetenti o con leggerezza di metodo.

My 2 Eurocent

[DjMix]

P.S.1. l'esempio dell'usare solo una dir condivisa al posto che cvs o equivalenti è tratto dal vero
P.S.2. ho specificato linux kernel per essere sicuro di non creare fraintendimenti
P.S.3. il non dare accesso in scrittura a tutti su un cvs pubblico non significa impedire ad altri di lavorarci. Nessuno vieta a nessuno di copiarsi giù tutti i sorgenti e mettersi a sviluppare per i fatti suoi, e non si vieta neppure di mettere su un altro cvs pubblico con le modifiche e portare avanti un fork del programma... di solito però uno fa una modifica, prepara un diff e lo manda per mail al manteiner del progetto originario, che ci da un'occhiata e se gli piace lo integra col cvs. è così che funziona di solito, non sempre, ma di solito, e come vedete siamo di fronte ad uno sviluppo open dove tutti possono contribuire ma non per questo tutto deve andare allo sfacelo.... un minimo di controllo c'è sempre, ovviamente... meno burocratico magari! E la storia delle modifiche la tiene cvs

[jappilas]

Originariamente inviato da cdimauro
Hai detto bene: forse. Perché finora noto soltanto tanti lamerini che si divertono a usare programmi arcinoti che sfruttano delle falle di sicurezza per "attaccare" i computer, e si spacciano per "hacker".
20 anni fa, invece, non era difficile incontrare gente che ti rivoltava come un calzino i computer dell'epoca (Vic20, C64, Spectrum, MSX, ecc. ecc.).

la storia dei ragazzini di oggi è una cosa che mi rinfaccia sempre anche mio padre..
(specie ora che sono arrivato alla fine dell' uni con purtroppo poca esperienza di sviluppo "pratica" ... sigh troppi esami teorici.. magari adesso che mi tocca fare la tesi su sto framework realtime... )
[/PERSONAL MODE OFF]

però direi che hai ragione, il paragone tra gli "ACARI" (come li ho sentiti definire spesso ) di adesso e i geni che riuscivano a far stare giochini con grafica e musica in 64 KB (o meno, vedi i 48 KB disponibili sull' amstrad cpc464 togliendo i 16 occupati dal firmware) non si pone nemmeno...dubito che a 13 anni abbiano nozioni di ingsoft e procedure di testing ...

[DioBrando]

Originariamente inviato da dnarod
------------------
Marco Giuliani, non confondiamo Hackers con Crackers!
Gli Hackers, permettimelo, non sai chi sono e cosa fanno.

Pertanto ti pregherei di corregere la news e scrivere Crackers al posto di Hackers.


Grazie.
-----------------
mi sa che hai sbagliato persona per sfoderare la favoletta della biodiversita fra hacker e cracker....non siamo mica in un portale di cucina macrobiotica

n è una favoletta...sn differenze sostanziali a livello metodologico e di comportamento.


Ma la banalizzazione è un pò il trend di questi ultimi anni

[cdimauro]

x jappilas: ne dubito anch'io.

x DjMix: è chiaro che non si può generalizzare da ambo le parti, perché si possono trovare esempi negativi. Rimane il fatto che società di un certo calibro adoperano una metodologia estremanete rigorosa nello sviluppo e nel controllo del software, che trascende da una banale controllatina all'aggiornamento fatto dal "picciotto" XYZ (Ryo Saeba? ), da integrare nel nuovo branch CSV e rendere disponibili agli altri.

E' una mentalità diversa, che non avevo mai riscontrato da nessuna parte prima di quest'esperienza. Per dirtene un'altra che mi viene in mente adesso: figurati che, quando è stato necessario, mi è stato richiesto di creare dei grafici all'interno dei commenti con dei caratteri ASCII per rendere più chiara la parte di codice che, comunque, posso assicurarti era zeppa di commenti; in pratica, parte delle simulazioni su carta degli algoritmi che ho sviluppato li ho riportati "graficamente", e facendo vedere cosa accadeva passo passo al sistema e alle sue variabili: una specie di fumetto, insomma...

[samslaves]

Io posso portare altri studi riguardo alla sicurezza:

http://www.osopinion.com/modules.php?op=modload&name=News&file=article&sid=919

http://www.itweb.co.za/sections/computing/2004/0403090813.asp?A=HOME&O=FPIN

e ce ne sono tanti altri. Comunque sia Win in quanto falle e' veramente un colabrodo; basti pensare al numero di aggiornameti sicurezza chge ogni uno o due mesi mi vengono proposti (XP). Ora anche i cell con software M$ cominciano a essere colpiti da virus o comunque tentativi.

Boh!

Sam

[fek]

Originariamente inviato da Ikitt_Claw
Di quale branca dell'ingegneria del software?

Ti consiglio di leggere Martin Fowler e Herb Sutter oppure John Lakos per non andare su McConnel, giusto per rimanere sul pratico, con gente d'esperienza, senza scomodare branche dell'Ing. del Software piu' teoriche.

Concludo che alla lunga e` in potenza meno difettoso.

Se per te da una metodologia di sviluppo del tutto informale, si puo' concludere che in potenza e' meno difettoso, non posso che rispettare la tua opinione. Sebbene ne' io dalla mia esperienza, ne' chiunque abbia letto che ha scritto di questi argomenti, ne' dal punto di vista teorico, si puo' condividere. La via verso la minimizzazione dei difetti e' mettere in pratica test formali, code review formali, ovvero le metodologie applicate nello sviluppo di software life critical. Per chi mi ha domandato che cos'e' software life critical, un'applicazione di databse non lo e': un esempio e' il software di controllo di un bypass, se non di un aereo in fase di atterraggio, tutti ambienti dove i difetti non possono essere tollerati.

Mi fai qualche esempio di constraint del'OS che lo rende intrinsecamente meno affidabile?

Li hai nominati tu: il responsabile che si fida di un check in, ad esempio. L'assenza di test formali.

[fek]

Originariamente inviato da cdimauro
Sicuramente avrà dimenticato molti dettagli, ma posso assicurarvi che anche per scrivere una sola riga di codice, la differenza fra un progetto "casalingo" e uno per conto di una società di un certo calibro, è veramente notevole. Pur utilizzando da anni Delphi come mio linguaggio preferito, che mi induce in maniera naturale a scrivere codice leggibile e secondo certi canoni, ho dovuto cambiare radicalmente il mio modus operandi ed entrare in un'ottica completa diversa.

Esatto. Hai spiegato meglio di me quello che intendevo. Grazie.

[fek]

Originariamente inviato da DjMix
Ma il fatto che un programma sia closed non mi garantisce che non sia stato fatto da incompetenti o con leggerezza di metodo.

My 2 Eurocent

E' proprio questo il punto: esistono metodologie di costruzione del software abbastanza formali da garantirti che il codice non sia scritto da incompetenti e non sia inserito nel sistema con leggerezza, perche' deve prima attraversare fasi di testing e di reviewing, che come e' uscito in questo thread, non sono possibili in un ambiente OS.

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

[cdimauro]

Originariamente inviato da samslaves
Io posso portare altri studi riguardo alla sicurezza:

http://www.osopinion.com/modules.php...rticle&sid=919

http://www.itweb.co.za/sections/comp...?A=HOME&O=FPIN

e ce ne sono tanti altri.

Leggere per intero le news no, eh?

"The study, which was conducted by mi2g's Intelligence Unit, was based on the number of successful attacks against UK government and private server systems in January this year."

Mi sembra, quindi, che c'entri ben poco rispetto a quanto abbia scritto finora... Giusto per ricordarlo: confronto fra le metodologie di sviluppo e mantenimento del software.

Comunque sia Win in quanto falle e' veramente un colabrodo; basti pensare al numero di aggiornameti sicurezza chge ogni uno o due mesi mi vengono proposti (XP).

Mi sembra un giudizio quanto meno affrettato... Windows è il sistema più diffuso, e per giunta non si conosco i sorgenti: mi spieghi come arrivi a queste conclusioni?

Ora anche i cell con software M$ cominciano a essere colpiti da virus o comunque tentativi.

Boh!

Sam

Mi sembra che le ultime news non parlino di cellulari o palmari con sistemi MS affetti da virus, ma sono relativi ad altri sistemi: su questi cos'hai da dire, visto che MS non c'entra?

Bah.

x fek: di niente.

[Ikitt_Claw]

Originariamente inviato da fek
Ti consiglio di leggere Martin Fowler e Herb Sutter oppure John Lakos per non andare su McConnel,

Lo faro`, nun te preoccupe. Era comunque in programma (per Fowler o Sutter)

Se per te da una metodologia di sviluppo del tutto informale,
si puo' concludere che in potenza e' meno difettoso,

Non ricordo di aver mai scritto questo (se la memoria mi inganna, un quote chiarificatore sara` gradito).[1]
Oltretutto, che OSS corrisponda a metodologia di sviluppo del tutto informale e` una tua teoria, che peraltro non ha ancora trovato dimostrazione nel corso del thread.

Il software closed e` stabile quando il produttore lo dichiara stabile.
Se e` stabile perche` ha passato tutti i test o perche` e` arrivata la data della release non e` dato saperlo (business is business).
Se io sono un committente esigente, invece, col software OSS posso fare tutti i test che desidero -ho i sorgenti-, e trarre le mie conclusioni.

Tecnica, non marketing.

Li hai nominati tu: il responsabile che si fida di un check in

Dipende dal responsabile. Dipende dal progetto, dalla metodologia di sviluppo.
Cosi` come la quasi totalita` dei (presunti, sinora) difetti intrinseci del F/OSS o dei (presunti, sinora) pregi intrinseci del SW commerciale.

ad esempio. L'assenza di test formali.

Interessante. Mi mostreresti, per cortesia, dove nella definizione di F/OSS si vieta o si scoraggia l'applicazione di test formali?

Sei un po` parco di dati a sostegno delle tue tesi (si noti che non sto dicendo che sono sballate o che il F/OSS e` perfetto. Sto dicendo che mancano i dati).
Di solito l'onere della prova sta a chi propone la tesi...

+++

[1] NB: piu` sopra ho scritto "concludo che il software OSS e` in potenza alla lunga meno difettoso", ma concludo questo in contrapposizione alla teoria secondo la quale col tempo il software OSS implode sotto il peso di una somma di difetti e non date le premesse di fek, che non condivido, come si vede.