Linux più sicuro per Evans Data Corp. [Archivio]

IcemanX

30-07-2004, 09:55

Scusa Cagnaluia, da quand'è che paghi x avere una distribuzione di Linux? A meno di non comprarne una complete di qualche milione di programmi basta andare sul sito della casa e scaricarsela a gratis...
Al contrario Win lo dovresti pagare, e pure tanto.

"gli utenti pagano un sistema operativo perchè funzioni e sia fruibile.. non certo per metterci le mani a livello di config di sicurezza... che gia si pensa siano ben adeguate"
La sicurezza a parità di impostazioni (ossia senza toccare niente) è cmq più elevata su Linux che su Windows e i quasi 200MB che ti scarichi da win update tra SP1 e roba varia dovrebbero suggerire qualcosa, più l'arrivo dell'SP2 incentrato praticamente SOLO sulla sicurezza.

Linux NON è un sistema x chiunque, nonostante le interfacce siano ormai al pari di Win/Panther e compagnia bella il resto richiede più esperienza.
Ma se x esempio vuoi programmare codice C/C++ standard (che non ha nulla a che fare con Visual Studio) ti scarichi una release qualunque e vai ;)

ciao

Kars

30-07-2004, 09:57

Come gia' detto non si parla di sistemi home :rolleyes: cmq anche linux non sara' gratuito per sempre :muro:

ilsensine

30-07-2004, 10:02

Originariamente inviato da Kars
cmq anche linux non sara' gratuito per sempre :muro:
Ancora con la storia del prezzo...:(
http://www.fsf.org/philosophy/free-sw.it.html

Kars

30-07-2004, 10:12

Lasciamo perdere va' ritiro quello che ho detto ;) pero' la storia di red hat e fedora... :muro:

afterburner

30-07-2004, 10:13

Originariamente inviato da Kars
Eppure credevo che un Hacker non lasciasse tracce :rolleyes:

Non voglio tirare fuori la distinzione tra Hacker e Cracker .. e' una battaglia persa: per un giornalista un hacker e' un teppista informatico .. per Linus Torvalds hackers sono coloro che gli hanno dato e gli danno tutt'ora una mano con kernel e quant'altro ( vedi sezione What is Linux? at www.kernel.org )

Comunque se un hacker entra nel tuo sistema con pieni diritti di root, di solito ti lascia un bel README.POLLO in / o /root con le indicazioni sulla vulnerabilita' sfruttata per entrare. :D
Se e' un cracker non ti dice nulla, cancella le tracce che puo' cancellare e sfruttera' il tuo sistema in qualche maniera :rolleyes:

Tutte le spiegazioni lette finora sul xche' Linux e' piu' sicuro sono corrette: io aggiungerei che Linux e' usatissimo nei sistemi server e poco come desktop .. nei sistemi server c'e' quasi sempre un admin e l'admin di solito sa sempre con cosa ha a che fare e come proteggerlo.
Windows e' usatissimo nei desktop ed allora eccoti la segretaria (nulla contro le segretarie eh!) che ti apre qualsiasi allegato di posta superVirusCazzutissimo.exe
Ho visto sistemi win2k server con centinaia macchine client all'Active Directory e centinaia di utenti che se gestiti da un admin con i controc... non hanno mai avuto problemi.

HyperText

30-07-2004, 10:14

Originariamente inviato da dnarod
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 :D
Spiegati meglio.

ilsensine

30-07-2004, 10:14

Originariamente inviato da Kars
Lasciamo perdere va' ritiro quello che ho detto ;) pero' la storia di red hat e fedora... :muro:
E' un modello di sviluppo che credo avrà un buon successo.
Cosa c'è di sbagliato?

HyperText

30-07-2004, 10:15

Originariamente inviato da afterburner
Non voglio tirare fuori la distinzione tra Hacker e Cracker .. e' una battaglia persa: per un giornalista un hacker e' un teppista informatico .. per Linus Torvalds hackers sono coloro che gli hanno dato e gli danno tutt'ora una mano con kernel e quant'altro ( vedi sezione What is Linux? at www.kernel.org )

Comunque se un hacker entra nel tuo sistema con pieni diritti di root, di solito ti lascia un bel README.POLLO in / o /root con le indicazioni sulla vulnerabilita' sfruttata per entrare. :D
Se e' un cracker non ti dice nulla, cancella le tracce che puo' cancellare e sfruttera' il tuo sistema in qualche maniera :rolleyes:

Tutte le spiegazioni lette finora sul xche' Linux e' piu' sicuro sono corrette: io aggiungerei che Linux e' usatissimo nei sistemi server e poco come desktop .. nei sistemi server c'e' quasi sempre un admin e l'admin di solito sa sempre con cosa ha a che fare e come proteggerlo.
Windows e' usatissimo nei desktop ed allora eccoti la segretaria (nulla contro le segretarie eh!) che ti apre qualsiasi allegato di posta superVirusCazzutissimo.exe
Ho visto sistemi win2k server con centinaia macchine client all'Active Directory e centinaia di utenti che se gestiti da un admin con i controc... non hanno mai avuto problemi.
:winner:

cagnaluia

30-07-2004, 10:16

Originariamente inviato da ilsensine
sysadmin di professione, vedo :p

Di nuovo: NON si sta parlando di sistemi desktop, ma di sistemi server.

si lo vedo! ma allora è meglio scrivere AMMINISTRATORE e non UTENTE del sistema... perchè in realtà su un server, l'utente non esiste!!

ilsensine

30-07-2004, 10:17

Originariamente inviato da afterburner
nei sistemi server c'e' quasi sempre un admin e l'admin di solito sa sempre con cosa ha a che fare e come proteggerlo.
Per la verità il mondo è pieno di "disastrmin", indipendentemente dal s/o...:D

ilsensine

30-07-2004, 10:21

Originariamente inviato da cagnaluia
si lo vedo! ma allora è meglio scrivere AMMINISTRATORE e non UTENTE del sistema... perchè in realtà su un server, l'utente non esiste!!
Sì esiste; già l'amministratore è un utente (con l'accesso al pulsante rosso di autodistruzione). Poi ci sono profili utente con privilegi di amministrazione limitati ad alcuni programmi (un pò come i "power user" di windows). Poi ci sono i vari programmi, che su un sistema ben configurato non sono eseguiti permanentemente con i privilegi di amministratore o sul namespace di sistema -- sono un pò dei "power user" automatici.

afterburner

30-07-2004, 10:30

Originariamente inviato da ilsensine
Per la verità il mondo è pieno di "disastrmin", indipendentemente dal s/o...:D

:D :D :D Vero ...
Il problema e' chi valuta l'admin!! I capi? No di certo, loro non ne sanno nulla e basta che tutto funzioni. L'admin e' valutato dagli USERS ed allora un admin per essere un "veramente buon administrator" per gli USERS si trova a dover: permettere il P2P, non bloccare i siti XXX, lasciare attive robe dell'altro mondo ('ma io non voglio ssh! sono 20 anni che uso telnet' .. gia' e sono vent'anni che ti entra il mondo sul server :)
Quindi, morale della favola, tante volte un buon admin, alla luce degli users e' un disastradmin o un BOFH

ilsensine

30-07-2004, 10:38

Originariamente inviato da afterburner
:D :D :D Vero ...
Il problema e' chi valuta l'admin!! I capi?
No i cracker :sofico:

Kars

30-07-2004, 10:48

Non e' che l'admin un giorno si sveglia e decide di bloccare il traffico p2p, magari fosse cosi'

Zerk

30-07-2004, 11:02

Lunga vita a WIndows!!! che tiene in piedi centinaia di centri di assistenza che risolvono i problemi di utenti che piantano nelle maniere piu disparate i loro PICCI

Maddoctor

30-07-2004, 11:10

Beh, forse se gli utonti usassero Linux sarebbe anche peggio !!!!

fek

30-07-2004, 11:36

"Le ragioni per le quali i sistemi Linux sono più sicuri sono semplici, molte più teste sullo stesso codice significa meno falle e un sistema sempre più sicuro"

Chi ha scritto questa frase evidentemente non ha mai scritto codice.

Originariamente inviato da IcemanX
Ma se x esempio vuoi programmare codice C/C++ standard (che non ha nulla a che fare con Visual Studio) ti scarichi una release qualunque e vai ;)

Il Visual Studio 7 e' il compilatore che si conforma piu' allo standard ANSI sul pianeta ;)

eraser

30-07-2004, 11:38

Scusate ma leggo ora tutte queste risposte.

Per chi corregge Hacker con Cracker, non vedo con quale giudizio possa fare una correzione simile. Nell'articolo non è scritto che i sistemi sono stati danneggiati e/o sono state rubate informazioni segrete e rivendute sul mercato nero. Questi sono i crackers.
Nell'articolo si parla di sistemi compromessi, e per compromettere un sistema basta aver scoperto una vulnerabilità e installare un rootkit, una backdoor e così via (senza che faccio molti esempi). Anche senza far danni si può compromettere un sistema, magari lasciando un file di testo dove il presunto ATTACKER (magari così evitiamo commenti vari e superflui) spiega all'admin la vulnerabilità e come correggerla.
Ma sull'articolo non era specificato niente di questo, quindi mi sembra alquanto superfluo tirare fuori la differenza tra hacker e cracker. Invece di concentrarsi su queste cose IN QUESTO CASO marginali, sarebbe meglio discutere del succo della news ;)

Per chi dice che gli hacker non lasciano tracce, beh ragazzi scusate ma avete in mente lo stereotipo dell'hacker ;) In generale possono non lasciare tracce, ma chi lo dice che non ne lascino?

Cioè ragazzi, non attacchiamo così senza motivo ;) Perché discutere di queste cose marginali (ripeto, marginali in questa news) quando la notizia è tutt'altra? ;)

HyperText

30-07-2004, 12:03

Un computer sicuro è un computer spento (neanche).

jappilas

30-07-2004, 12:06

Originariamente inviato da HyperText
Un computer sicuro è un computer spento (neanche).

sì vabbè.. l' ho sentita N volte... :rolleyes:

però vedi il punto è che un computer spento è un computer inutile...

Ikitt_Claw

30-07-2004, 12:13

jappilas

30-07-2004, 12:22

Originariamente inviato da Ikitt_Claw
la metodologia F/OSS si avvicina pericolosamente all'XP ;)

dovrei recuperare materiale sulle metodiche eXtreme Programming, sapresti mica dove posso...? ;)

Dreadnought

30-07-2004, 12:23

...ma siamo sul forum di punto informatico è c'è stato un travaso di utenti? :eek:

eraser

30-07-2004, 12:24

perché, c'è qualcuno di PI? :D mai frequentato :D

Ikitt_Claw

30-07-2004, 12:30

Originariamente inviato da jappilas
dovrei recuperare materiale sulle metodiche eXtreme Programming, sapresti mica dove posso...? ;)

Trovandomi nella stessa situazione ho deciso di prendere il libro omonimo di Beck;
non so consigliarti alcun sito o risorsa gratis in particolare, ma se sei disposto a spendere ~25 EUR il suddetto testo di Beck fa una panoramica abbastanza ampia, ed e` disponibile pure in italiano e con una traduzione decente ;)

Ikitt_Claw

30-07-2004, 12:31

Originariamente inviato da Dreadnought
...ma siamo sul forum di punto informatico

Ma spero vivamente di no!
:muro: :muro: :muro:

jappilas

30-07-2004, 12:38

Originariamente inviato da Ikitt_Claw
Trovandomi nella stessa situazione ho deciso di prendere il libro omonimo di Beck;
non so consigliarti alcun sito o risorsa gratis in particolare, ma se sei disposto a spendere ~25 EUR il suddetto testo di Beck fa una panoramica abbastanza ampia, ed e` disponibile pure in italiano e con una traduzione decente ;)

tnx
tra l' altro non ricordavo il nome dell' autore ;)

Dreadnought

30-07-2004, 13:28

Originariamente inviato da Ikitt_Claw
Ma spero vivamente di no!
:muro: :muro: :muro:

beh il livello di conoscenza di certa gente che ha fatto i commenti e il tipo di commenti non so perchè ma mi ricordano perfettamente quel forum... :rolleyes:

senza contare il continuo puntializzare sta storia di cracker/hacker, come se qua ci fosse qualcuno che si offende... :rotfl:
penso che tutti quelli a cui era indirizzata sta notizia conoscono la sottilissima differenza tra cracker e hacker e non c'è bisogno di puntualizzarla ogni volta con 20 post :rolleyes:

frankie

30-07-2004, 13:40

Originariamente inviato da Madmind
e' anche vero che linux non e' diffuso quanto windows e soprattutto non e' altrettanto odiato quanto quest'ultimo...
se le percentuali di utilizzatori di un sistema piuttosto che l'altro si invertissero, saremmo probabilmente qui a discutere di quanto sia sicuro windows piuttosto che linux

mmmh linux non è diffuso???

Quanto era la percentuale tra apache web server e IIS ????

Forse se non ricordo male 92% apache e 8%IIS.

Ovvio poi ci sono iserver non Web.

Grazie Knoppix per avermi fatto salvare i dati senza installare niente.

Grazie zio bill perchè se si impasta il S.O. devo ricorrere a non so cosa tipo DOS oppure CD strani di bravi autori che pubblicano GNU su sourceforge, tipo ultimate boot CD

afterburner

30-07-2004, 13:51

Originariamente inviato da fek
"Le ragioni per le quali i sistemi Linux sono più sicuri sono semplici, molte più teste sullo stesso codice significa meno falle e un sistema sempre più sicuro"

Chi ha scritto questa frase evidentemente non ha mai scritto codice.

Permettimi di non capire il tuo commento alla frase di Petreley!!
Ogni tanto c'e' gente che si passa qualche oretta alla sera prima di andare a letto con una bella cicca, na birra e un bel "ma vediamo sto sorgente che fa di bello" .. sperando che sia commentato in maniera decente si capisce cosa fa,come e perche' .. se qualcosa non convince o ci si accorge di una falla si avverte il pusher del tar.gz .. o, ancora meglio, si corregge e si posta un diff :O

IcemanX

30-07-2004, 15:38

x fek
Io uso il .net 2003, ma a parte le scelte evidenti riguardo a namespace e richiamo di funzioni dalle sue librerie come da specifiche ANSI mi è parso che in compilazione si faccia un po' li affari suoi; idem compilando il codice con DEV-C++ che teoricamente dovebbe essere esattamente lo standard.
Poi potrò anche sbagliarmi, ma i pregiudizi sono nati col VS6 che ho usato x molto tempo...

fek

30-07-2004, 16:44

Originariamente inviato da afterburner
Permettimi di non capire il tuo commento alla frase di Petreley!!
Ogni tanto c'e' gente che si passa qualche oretta alla sera prima di andare a letto con una bella cicca, na birra e un bel "ma vediamo sto sorgente che fa di bello" .. sperando che sia commentato in maniera decente si capisce cosa fa,come e perche' .. se qualcosa non convince o ci si accorge di una falla si avverte il pusher del tar.gz .. o, ancora meglio, si corregge e si posta un diff :O

E chi autorizza la modifica?
E chi testa che la correzione al bug non introduca un altro bug?
E chi scrive la unit test che traccia che il bug sia effettivamente corretto?
E chi scrive le unit test che tracciano che il bug non abbia introdotto altri bug?
E chi autorizza il check in se tutte le unit test (che non esistono) passano?

Programmare in maniera professionale non e' certo andare a letto con una cicca e una birra leggendo che fa questo sorgente.

Originariamente inviato da IcemanX
x fek
Io uso il .net 2003, ma a parte le scelte evidenti riguardo a namespace e richiamo di funzioni dalle sue librerie come da specifiche ANSI mi è parso che in compilazione si faccia un po' li affari suoi; idem compilando il codice con DEV-C++ che teoricamente dovebbe essere esattamente lo standard.
Poi potrò anche sbagliarmi, ma i pregiudizi sono nati col VS6 che ho usato x molto tempo...

Il VS6 era una bella schifezza :D

fek

30-07-2004, 16:48

Originariamente inviato da jappilas
dovrei recuperare materiale sulle metodiche eXtreme Programming, sapresti mica dove posso...? ;)

http://www.amazon.com/exec/obidos/tg/detail/-/0201616416/104-3341887-2061564?v=glance

http://www.xprogramming.com/
http://www.xprogramming.com/index.htm

http://www.programming-x.com/programming/kent-beck.html

stefanotv

30-07-2004, 16:56

x frankie

apache gira su linux, windows, solaris, hp-ux, netware, aix, tru64....

p.s. sono andato a curiosare su netcraft (che analizza solo web server pubblici)

apache 67,2%
IIS 21,3%
sun 3,2%

xcdegasp

30-07-2004, 17:37

E chi autorizza la modifica?
E chi testa che la correzione al bug non introduca un altro bug?
E chi scrive la unit test che traccia che il bug sia effettivamente corretto?
E chi scrive le unit test che tracciano che il bug non abbia introdotto altri bug?
E chi autorizza il check in se tutte le unit test (che non esistono) passano?

Programmare in maniera professionale non e' certo andare a letto con una cicca e una birra leggendo che fa questo sorgente.
evidentemente non sai neanche cosa sia un progetto GPL e come sia strutturato..
un progetto GPL qualsiasi persona può dare il suo contributo ma solitamente si organizzano in comunità dove ciasc'una modifica di questa comunità viene prima testata da essa e poi data al sito predisposto alla divulgazione questo fa sì che altre N comunità possano verificare quella modifica ed in caso integrarla con altro codice e via così..
Per esempio Emule è un progetto GPL e siamo abituati ad avere N mod basate su una versione esempio di versione 0,43b abbiamo l'ufficiale ma anche quella sviluppata dalle comunità virtuali quindi avranno lo stesso cuore ma integreranno cose differenti come del resto le distribuzioni linux dove Red Hat è differente da Suse ecc... :)

afterburner

30-07-2004, 17:38

Originariamente inviato da fek
Programmare in maniera professionale non e' certo andare a letto con una cicca e una birra leggendo che fa questo sorgente.

Giusto!! Questo e' programmare per passione ..
Linux e' nato da programmatori per passione a tempo perso dato che e' GRATIS e magari con una cicca ed una birra ...
Windows e' nato da programmatori che programmano in maniera professionale ...

fek

30-07-2004, 18:15

Originariamente inviato da xcdegasp
evidentemente non sai neanche cosa sia un progetto GPL e come sia strutturato..
un progetto GPL qualsiasi persona può dare il suo contributo ma solitamente si organizzano in comunità dove ciasc'una modifica di questa comunità viene prima testata da essa e poi data al sito predisposto alla divulgazione questo fa sì che altre N comunità possano verificare quella modifica ed in caso integrarla con altro codice e via così..
Per esempio Emule è un progetto GPL e siamo abituati ad avere N mod basate su una versione esempio di versione 0,43b abbiamo l'ufficiale ma anche quella sviluppata dalle comunità virtuali quindi avranno lo stesso cuore ma integreranno cose differenti come del resto le distribuzioni linux dove Red Hat è differente da Suse ecc... :)

Ullalla', fossi in te ci penserei due volte ad affermare con tanta sicurezza che non so che cosa sia un progetto GPL ;)

Allora, mi dici chi si occupa di scrivere le unit test nel tuo progetto GPL? E chi fa i test di sistema? E chi si occupa del QA? E chi lo certifica?

Qui si sta parlando di progetti di una certa dimensione, non di un progettino da qualche centinaia di migliaia di righe di codice come Emule.

Originariamente inviato da afterburner
Giusto!! Questo e' programmare per passione ..
Linux e' nato da programmatori per passione a tempo perso dato che e' GRATIS e magari con una cicca ed una birra ...
Windows e' nato da programmatori che programmano in maniera professionale ...

Linux e' gratis per quelli il cui tempo vale nulla :)

Ikitt_Claw

30-07-2004, 18:26

Originariamente inviato da fek
E chi autorizza la modifica?
Chi ha dato l'accesso in scrittura al CVS

E chi testa che la correzione al bug non introduca un altro bug?
I test periodici e/o le nightly build (quando ci sono :muro: )

E chi scrive la unit test che traccia che il bug sia effettivamente corretto?
E chi scrive le unit test che tracciano che il bug non abbia introdotto altri bug?
Come sopra

E chi autorizza il check in se tutte le unit test (che non esistono) passano?
Spesso non esistono, non sempre.

Programmare in maniera professionale non e' certo andare a letto con una cicca e una birra leggendo che fa questo sorgente.
Programmare in maniera professionale e` troppo spesso un concetto astratto, sia nel mondo OSS sia nel mondo Closed Source.

Con la differenza che nel mondo OSS non e` semplicemente possibile nascondere la polvere sotto il tappeto.

Ikitt_Claw

30-07-2004, 18:29

Originariamente inviato da fek
Qui si sta parlando di progetti di una certa dimensione, non di un progettino da qualche centinaia di migliaia di righe di codice come Emule.

Nel mondo F/OSS, per limitazioni oggettive o per costituzione, non esistono molti progetti da milioni di righe di codice.
E un progetto da qualche centinaia di migliaia di righe di codice non lo chiamerei "ino".
Ci sono componenti critici del sistema di quelle dimensioni, o anche piu` piccole.

fek

30-07-2004, 18:31

Originariamente inviato da Ikitt_Claw
Chi ha dato l'accesso in scrittura al CVS

Chi ha dato accesso al CVS ti fa anche la review per autorizzare il check in? Sicurissimo? :)

I test periodici e/o le nightly build (quando ci sono :muro: )

Come sopra

Esatto, quando ci sono.

Con la differenza che nel mondo OSS non e` semplicemente possibile nascondere la polvere sotto il tappeto.

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.

Vorrei vedere chi darebbe da costruire un sistema life-critical, ad esempio, ad un gruppo OS :D

Ikitt_Claw

30-07-2004, 18:38

Originariamente inviato da fek
Chi ha dato accesso al CVS ti fa anche la review per autorizzare il check in? Sicurissimo? :)
Se X da a Y il permesso di fare commit (e non solo checkout!) dal CVS di solito e` perche` si fida di Y, quindi sa che le sue modifiche sono (relativamente) sicure, o perche` e` un genio, o perche` si spara i test opportuni a casa o quel che e`.
Quando del codice entra nel CVS di solito e` gia` ragionevolmente testato. A meno di progetti kamikaze, ovviamente.

Esatto, quando ci sono.

Effettivamente nel mondo F/OSS manca sovente una solerte politica di testing. E` un punto dolente assieme alla doc.
I motivi sono molteplici, comprensibili o meno, ma la lacuna rimane.

Quello che sto dicendo e' che affermare che l'OSS e' intrinsecamente meno "difettoso" e' una bestialita':
Ovviamente. E` potenzialmente meno difettoso, ma alla lunga distanza, non alla corta.

al massimo e' il contrario, visto che e' un sistema di costruzione del software intrinsecamente anarchico e non strutturato
Fai due nomi per cortesia, che detta cosi` sembra una sparata abbastanza clamorosa.
Qualche lettore malizioso potrebbe essere portato a credere che il software F/OS funziona sostanzialmente per caso...

dove maVorreinca totalmente un sistema formale di QA.

L'avere un progetto CS non implica avere un sistema funzionante (non solo marketing) di QA.

Vorrei vedere chi darebbe da costruire un sistema life-critical, ad esempio, ad un gruppo OS :D
Definisci "gruppo OS". Perche` anche questa puo` sembrare una sparata. La caratteristica fondamentale dello sviluppo OS prevede "disponibilita` di sorgenti e liberta` di utilizzo". Il resto sono particolarita` del progetto e degli sviluppatori.

fek

30-07-2004, 19:06

Originariamente inviato da Ikitt_Claw
Se X da a Y il permesso di fare commit (e non solo checkout!) dal CVS di solito e` perche` si fida di Y, quindi sa che le sue modifiche sono (relativamente) sicure, o perche` e` un genio, o perche` si spara i test opportuni a casa o quel che e`.
Quando del codice entra nel CVS di solito e` gia` ragionevolmente testato. A meno di progetti kamikaze, ovviamente.

Purtroppo pero' la prima regola dell'Ingegneria del Software e' di non fidarsi di nessuno, tantomeno di se' stessi. Mentre tu mi dici che l'OS si basa sulla fiducia di modifiche (relativamente) sicure. Capirai che il confronto con sistemi formali di testing neppure si pone.

Effettivamente nel mondo F/OSS manca sovente una solerte politica di testing. E` un punto dolente assieme alla doc.
I motivi sono molteplici, comprensibili o meno, ma la lacuna rimane.

Ovviamente. E` potenzialmente meno difettoso, ma alla lunga distanza, non alla corta.

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.

Fai due nomi per cortesia, che detta cosi` sembra una sparata abbastanza clamorosa.
Qualche lettore malizioso potrebbe essere portato a credere che il software F/OS funziona sostanzialmente per caso...

Non ho mai detto che l'OS funzioni per caso, dico che e' un sistema di costruire software 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. E' come paragonare il giochino shareware scritto in casa a quello prodotto da un team di sviluppo come l'ID (per restare nel mio ambito :)).

Definisci "gruppo OS". Perche` anche questa puo` sembrare una sparata. La caratteristica fondamentale dello sviluppo OS prevede "disponibilita` di sorgenti e liberta` di utilizzo". Il resto sono particolarita` del progetto e degli sviluppatori.

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

Ikitt_Claw

30-07-2004, 19:11

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

30-07-2004, 19:49

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 :D

afterburner

30-07-2004, 20:02

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

Spiegati meglio .. sembra tanto una sparata fumosa

afterburner

30-07-2004, 20:10

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

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

30-07-2004, 22:27

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

30-07-2004, 23:02

@ 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

30-07-2004, 23:09

@ 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 :p

cdimauro

31-07-2004, 05:32

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

31-07-2004, 05:33

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 :p
Non puoi pretendere di generalizzare con un solo esempio... :rolleyes:

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

DjMix

31-07-2004, 10:20

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! :p 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

31-07-2004, 10:29

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

31-07-2004, 13:10

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.. :rolleyes:
(specie ora che sono arrivato alla fine dell' uni con purtroppo poca esperienza di sviluppo "pratica" ... sigh troppi esami teorici.. :cry: magari adesso che mi tocca fare la tesi su sto framework realtime... :rolleyes: )
[/PERSONAL MODE OFF]

però direi che hai ragione, il paragone tra gli "ACARI" (come li ho sentiti definire spesso :D) 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 ...:D

DioBrando

31-07-2004, 14:04

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 :D

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

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

cdimauro

31-07-2004, 15:07

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? :D), 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

01-08-2004, 12:07

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

01-08-2004, 15:14

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

01-08-2004, 15:15

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

01-08-2004, 15:19

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

01-08-2004, 15:20

Originariamente inviato da 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.
Leggere per intero le news no, eh? :rolleyes:

"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. :rolleyes: :muro:

x fek: di niente. :)

Ikitt_Claw

01-08-2004, 15:49

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.

Ikitt_Claw

01-08-2004, 15:50

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

DjMix

01-08-2004, 20:06

(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

01-08-2004, 20:25

I quote che mi avevi chiesto:

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

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

02-08-2004, 06:16

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

02-08-2004, 07:05

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

02-08-2004, 07:14

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

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

02-08-2004, 09:20

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

Ikitt_Claw

02-08-2004, 09:43

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

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

fek

02-08-2004, 10:06

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

02-08-2004, 10:25

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

Solita leggenda metropolitana .. Non fidarti!! :D

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 :sofico:

DjMix

02-08-2004, 10:32

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

02-08-2004, 10:44

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

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

02-08-2004, 11:24

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

02-08-2004, 11:27

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? :D

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

02-08-2004, 11:37

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

02-08-2004, 11:37

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

02-08-2004, 11:38

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

02-08-2004, 11:41

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

02-08-2004, 11:45

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

02-08-2004, 11:47

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

fek

02-08-2004, 11:59

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

02-08-2004, 12:03

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

02-08-2004, 12:19

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

02-08-2004, 12:26

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

02-08-2004, 12:33

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

02-08-2004, 12:38

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

02-08-2004, 12:41

Appunto mettevo "o quasi" ;)

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

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

DjMix

02-08-2004, 12:46

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

02-08-2004, 12:55

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/ASIN/0974514020/qid=1091447574/sr=1-1/ref=sr_1_11_1/026-8141626-4355647

fek

02-08-2004, 13:05

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 :p

Mason

02-08-2004, 13:07

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

02-08-2004, 13:21

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

02-08-2004, 13:26

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! :Puke:
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

02-08-2004, 14:15

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

02-08-2004, 14:48

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

02-08-2004, 15:33

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/kernel_testing/osdl_database_test_suite/
http://www.osdl.org/lab_activities/kernel_testing/stp/overview.html/document_view
http://www.osdl.org/lab_activities/lab_projects/active_projects/display_projects.html?query=Active
http://sourceforge.net/projects/plm/
http://www.osdlab.org/cgi-bin/eidetic.cgi?modulename=hardware_schedule&command=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 (http://www.nsa.gov/selinux/code/download5.cfm) è tutto software libero, con tanto di sorgenti :cool:

Ikitt_Claw

02-08-2004, 15:34

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

02-08-2004, 17:08

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" :D) 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

02-08-2004, 17:31

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 (http://www.nsa.gov/selinux/code/download5.cfm) è tutto software libero, con tanto di sorgenti :cool:

Dell'NSA non parlo per motivi politici :p

fek

02-08-2004, 17:32

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

fek

02-08-2004, 17:39

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

Il tuo discorso non farebbe una grinza se si ignorasse il fatto che un fix non e' di per se' esente da difetti. Come dicevo all'inizio del thread, chi mi garantisce che il tuo fix non introduca nuovi difetti?
Nessuno.
Ci vogliono dei metodi per garantirlo e qui entrano in gioco i metodi formali, ed una parte di questi non puo' essere implementata in un modello OS.

Ad esempio, il fatto che chiunque puo' contribuire al software aumenta i costi di mantenimento, non li dimunisce. Per costi non intendiamo solo in termini di denaro, ma anche in termini di tempo e, si', di stabilita'. Ricordiamoci che aggiungere un programmatore ad un progetto tende ad aumentare i tempi di sviluppo, non a diminurli.

Implementare le specifiche significa che se io chiedo un software per calcolare il numero di clienti in un database e tu mi consegni un software che calcola con precisione esatta il tempo che fara' domani, avrai scritto un gran programma, magari totalmente esente da difetti (anche se e' impossibile ;)), ma non implementa le specifiche richieste, quindi mi e' inutile :)

afterburner

02-08-2004, 18:28

Originariamente inviato da fek
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".
1."L'articolo affermava che Linux e' piu' SICURO":
Non sono io pinco pallino afterburner ad affermarlo ma qualcuno che prima di dirlo, sapendo che tra l'altro andava contro MS, ci avra' pensato parecchio ..
2. ".. per concludere che l'OSS e' intrinsecamente di minor qualita' rispetto a codice scritto "on site":
Ho capito che il tuo concetto di QUALITA' viene dall'eXtreme Programming e nell'ambito di questa metodologia puoi aver ragione.

A questo punto, almeno slega il binomio QUALITA'-SICUREZZA!! La sicurezza di un software openSource e' proprio data dal fatto che chiunque puo' leggere i sorgenti e le cappelle vengono fuori.
La sicurezza di algoritmi tipo RSA,DSA,ECC e' data dal fatto che sono algoritmi crittografici noti .. l'algoritmo tutti lo conoscono e dopo anni di studi non e' stato possibile craccarli matematicamente: e' la conoscenza dell'algoritmo che fa la sicurezza di questi sistemi cosi' come la conoscenza dei sorgenti di un software fa la sicurezza di quel software.
OT: Vado a farmi una pasta .. di qualita' .. buona serata a tutti :D

Ikitt_Claw

02-08-2004, 18:38

Originariamente inviato da fek
Mi sembrava chiaro che software di qualita' non vuol dire esente da bug ;)

Per essere chiaro, era chiaro...

Ikitt_Claw

02-08-2004, 18:42

Originariamente inviato da fek
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.
Chiaramente.

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.
Altro punto largamente discutibile, infatti (Cfr prima pagina di questo thread). Ma la propaganda non c'e` solo e` soltanto per il SW commerciale :D

DjMix

02-08-2004, 20:02

Originariamente inviato da fek
qui si sta parlando di metodologia di sviluppo OSS

E ridaje. Ma la smetti? OSS non è una metolologia!!! Ti ho già spiegato che puoi benissimo sviluppare un software opensource seguendo le regole che scrivevi qualche post fa, perchè insisti? E ti ho spiegato pure che CSS non significa automaticamente che le tue regole vengano applicate, anzi "di solito" non vengono manco prese in considerazione!!!

Originariamente inviato da fek
con sviluppo decentralizzato. E' cio' di cui abbiamo discusso fino ad ora.

Che non è implicato nella definizione OSS, ma ne è una conseguenza. Non una regola, quindi. E la discussione finora è andata a senso unico, perchè hai bellamente ignorato tutto quel che ti si diceva riguardo a questo.

Originariamente inviato da fek
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.
Non c'è scritto da nessuna parte che si _debba_ rilasciare il sorgente al pubblico. L'unico dovere è rilasciarlo solo a chi lo usa e che ne fa richiesta. Poi questo può darlo a chi gli pare, ma non lo obbliga nessuno.

Originariamente inviato da fek
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.
Nelle metodologie di sviluppo ci sono pure i test, e un pinco pallino che si scarica il programma e mi manda una mail dicendo "guarda che ho fatto così e così e non funziona un tubo" ma non mi manda una riga di codice COMUNQUE mi ha dato una mano nel fare dei test e nel trovare bachi, e scusa tanto ma a me pare proprio che questo faccia aumentare la qualità, non la diminuisce di certo!

Originariamente inviato da fek
Ora, il punto del discorso e': l'articolo affermava che Linux e' piu' sicuro perche' la metodologia di sviluppo OS
che non è una metodologia
Originariamente inviato da fek
(e distribuita abbiamo specificato in seguito lungo il thread)
che non è per forza distribuita
Originariamente inviato da fek
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".
Ma grazie tante, te l'abbiamo detto anche noi che spesso non vengono fatte le cose come dici tu! Ma nemmeno nel CSS vengono fatte sempre! E di nuovo OSS non significa _per_forza_ che gli sviluppatori siano ogniuno ai 4 angoli della terra!

Non so se l'hai notato ma la discussione te la sei fatta e finita da solo, e la conclusione pure. OSS non è una metodologia, e le regole che dici tu gli si possono applicare benissimo, e CSS non significa assolutamente che le suddette vengano applicate. Il fatto che OSS sia alla lunga più sicuro è dato da motivi che stanno al di fuori dalle tue regole e questo, che ti piaccia o no, è sotto agli occhi di tutti.

DjMix

02-08-2004, 20:03

sorry, pasticciato coi bottoni :D

cdimauro

03-08-2004, 06:32

Originariamente inviato da Ikitt_Claw
Esattamente. Ma mi pareva che nel thread si sostenesse che l'OSS preclude automaticamente alcune metodologie che sono implicite nel CSS o mi sbaglio?
Il problema è che, di fatto, ciò avviene, come ha spiegato fek. Dal punto di vista formale non v'è nulla dire, ma bisogna anche piantare i piedi per terra...
Non ricordo che la cosa fosse messa giu` in questi termini (forse non ho partecipato al thread?)!
Sei intervenuto, invece. :) Quando parlavamo di una licenza che permettesse, in buona sostanza, di evitare il fork del progetto, le cui linee guida fossero dettate da un team.
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. :D
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...
Anche quest'arbitrarietà del mantainer è non poco preoccupante, mi basta ricordare le "idee" :rolleyes: di Torvald relative all'utilizzo del C++ quale linguaggo di sviluppo per il kernel, tanto per fare un esempio non tanto lontano nel tempo e di cui abbiamo parlato qui in un thread...
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...
Se fossero tecnici, e soprattutto se si potesse aprire una LIBERA discussione in merito, mi starebbe già bene.
...In quel caso puo` farsi un fork, pero` ;)
Che fai, stuzzichi? :D
...Cosa che si puo` fare, e a volte si fa (a volte no, ahime`), anche nel mondo F/OSS...

...Cosa che si puo` fare, e a volte si fa (a volte no, ahime`), anche nel mondo F/OSS... ;)
Diciamoci la verità: tante volte no, ed è questo il problema... :)
Questo e` un discorso diverso, che non affronterei qui per non appesantire il thread.
No problem. Tanto prima o poi salterà fuori un thread "a tema"... ;)

cdimauro

03-08-2004, 06:36

Originariamente inviato da afterburner
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" ..
Le cose non stanno esattamente così, come ho già avuto modo di spiegare: le proposte sono sempre vagliate scrupolosamente e vengono prospettati i costi e i benefici della nuova soluzione rispetto alla precedente. Dopo un ATTENTO esame, viene scelta la soluzione ottimale.
E posso assicurarti che il libero arbitrio, l'antipatia nei confronti del proponente, o le paturnie del responsabile del progetto hanno ben poco a che vedere in tutto ciò. ;)
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 :sofico:
Questo, però, è un altro discorso. ;)

cdimauro

03-08-2004, 06:39

Originariamente inviato da DjMix
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!
Forse non hai capito il mio, di discorso: il fork di un progetto che ne genera un altro avente praticamente gli stessi obiettivi, penso sia una cosa inutile e grave (opinione personale).
Il mio discorso puntalizza il fatto che in un'azienda che utilizza certe metodologie, ciò è semplicemente impensabile: è il modus operandi che proprio non ti fa nemmeno passare per la testa una cosa del genere!

cdimauro

03-08-2004, 06:42

Originariamente inviato da 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.
Indubbiamente. Ma è un altro discorso. ;)
Mi fate qualche esempio di software life critical basato su Win? :D
Quello usato nella macchina utilizzata per farmi operare alla vista col laser a eccimeri, tre anni fa. :eek:
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...
Solidità in termini di ingegneria del software? Bisogna vedere... :D

cdimauro

03-08-2004, 06:45

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
Non è che stai forzando un po' troppo le conclusioni? Mi sembra che il discorso affrontato sia ben chiaro... :rolleyes:
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...
Nessuno lo nega: il marcio lo trovi un po' ovunque.
il fatto che sia closed o portato avanti da una società non significa automaticamente che sia fatto bene!
NESSUNO l'ha mai negato!
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?
Forse ti sfugge che, all'interno dell'azienda, il software non è certo "closed", ma "open": tutto il team, o chi è interessato e autorizzato, può prenderne tranquillamente visione. ;)

Ikitt_Claw

03-08-2004, 06:46

Originariamente inviato da cdimauro
Il problema è che, di fatto, ciò avviene, come ha spiegato fek. Dal punto di vista formale non v'è nulla dire, ma bisogna anche piantare i piedi per terra...

Diciamoci la verità: tante volte no, ed è questo il problema... :)

La "verita`" (meglio: la situazione reale) ve/te la dico senza problemi, e mi pare di averla piu` volte ribadita anche nel corso del thread (cominciando dalla prima pagina per giunta ;) )

Il punto pero` e` che fek insiste nell'usare l'aggettivo "intrinseco" rifendosi a certi difetti o punti discutibili della situazione attuale del F/OSS.
Su questo punto, come s'e` visto, sono in totale e forte disaccordo, e nel corso del dibattere non sono ancora emersi elementi determinanti (per me) a favore di questa teoria.

cdimauro

03-08-2004, 06:51

Originariamente inviato da DjMix
Tetto? o ditta? Se ti basta la seconda, eccolo:

http://www.teammosaico.biz/Ricordiamoci che questo vale da tutte e due le parti ;)
Hai provato a scaricarti i sorgenti di Mosaico? Bene, fallo e dai un'occhiata al progetto. Ti accorgerai di un po' di cose:

1) utilizza componenti esterni al progetto, di cui alcuni closed source e/o a pagamento
2) utilizza Delphi, che è closed source e a pagamento
3) i sorgenti non rispecchiano neppure lontanamente i canoni su cui sono stato abituato a lavorare all'STMicroelectronics; neppure di striscio...

Forse hai scelto l'esempio sbagliato... ;)

cdimauro

03-08-2004, 06:56

Originariamente inviato da 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
Bene. Non ho mai avuto accesso a quei sorgenti, ma piacerebbe vederne la struttura. Anche nei sorgenti che ho scritto all'STM c'era il campo "remarks", e potevo scrivere ciò che mi pareva... ;)
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?
Politica adottata dall'azienda.
forse perche' non e' poi scritto cosi' bene?
E' da vedere, appunto.
winxp e' scritto in tutti i linguaggi possibili, dal c al basic, assembler e tanti altri, parti di codice che risalcono alla dosshell....
L'hai visto? Puoi provarlo? Comunque si scrive assembly (il linguaggio), non assembler (che è il compilatore)!
no...non e' cosi' che si lavora bene....
Aspettiamo dimostrazioni...
se la filosofia del del close e' migliore
Mi sembra che i termini della questione siano un po' diversi.
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......
Questo lo pensi tu, e non porti prove concrete. Aggiungici IMHO. ;)

cdimauro

03-08-2004, 07:27

Originariamente inviato da afterburner
1."L'articolo affermava che Linux e' piu' SICURO":
Non sono io pinco pallino afterburner ad affermarlo ma qualcuno che prima di dirlo, sapendo che tra l'altro andava contro MS, ci avra' pensato parecchio ..
Bisogna vedere su quali basi può affermarlo, però. Finora mi sembra si tratti esclusivamente di statistiche, non di confronto di metodologie di sviluppo...
A questo punto, almeno slega il binomio QUALITA'-SICUREZZA!! La sicurezza di un software openSource e' proprio data dal fatto che chiunque puo' leggere i sorgenti e le cappelle vengono fuori.
Ne abbiamo già parlato in abbondanza in passato: permettemi di dubitarne (e qui il buon ilsensine storcerà il naso ;))
La sicurezza di algoritmi tipo RSA,DSA,ECC e' data dal fatto che sono algoritmi crittografici noti .. l'algoritmo tutti lo conoscono e dopo anni di studi non e' stato possibile craccarli matematicamente: e' la conoscenza dell'algoritmo che fa la sicurezza di questi sistemi cosi' come la conoscenza dei sorgenti di un software fa la sicurezza di quel software.
Mi spiace, ma il paragone non calza: la sicurezza, in questi casi non ha alcuna relazione. Si tratta proprio di cose completamente diverse! :)

cdimauro

03-08-2004, 07:28

Originariamente inviato da DjMix
Il fatto che OSS sia alla lunga più sicuro è dato da motivi che stanno al di fuori dalle tue regole e questo, che ti piaccia o no, è sotto agli occhi di tutti.
Questo, che ti piaccia o no, non è MAI stato dimostrato: e scusa se è poco... ;)

cdimauro

03-08-2004, 07:29

Originariamente inviato da Ikitt_Claw
La "verita`" (meglio: la situazione reale) ve/te la dico senza problemi, e mi pare di averla piu` volte ribadita anche nel corso del thread (cominciando dalla prima pagina per giunta ;) )
Benissimo. Almeno a un punto di convergenza siamo arrivati. :)
Il punto pero` e` che fek insiste nell'usare l'aggettivo "intrinseco" rifendosi a certi difetti o punti discutibili della situazione attuale del F/OSS.
Oggettivamente, pensi che la situazione possa migliorare in futuro?
Su questo punto, come s'e` visto, sono in totale e forte disaccordo, e nel corso del dibattere non sono ancora emersi elementi determinanti (per me) a favore di questa teoria.
E non è detto che ci arrivi. :) L'importante è che, se ci sono dei dubbi e si ha la disponibilità a parlarne, qualcosa di nuovo esca fuori per provare a chiarire la situazione. E mi sembra che il thread, per questo, sia fra i più interessanti che abbiamo mai avuto in questo forum... :)

ilmanu

03-08-2004, 07:29

quando cdimauro posta incomincio a sudare, basti vedere il numero di raplay consecutivi, scusa la grammatica e la terminologia magari sbagliata, pero' vedo che cmq hai capito cosa intendevo.... come sempre.... :D :D :D

hai pvt

ilsensine

03-08-2004, 07:51

Originariamente inviato da fek
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.
Se ridai una occhiata a inizio thread, vedrai che sono stato io ad avanzare i primi dubbi sulla bontà dell'articolo.
Però poi si è finiti col dire il contrario, ovvero che l'OSS e il suo sviluppo "decentralizzato" è "intrinsecamente meno affidabile" per quel che riguarda la qualità del prodotto. Lavorando con software libero in prima persona ho solo precisato che non è così: i progetti portati avanti da professionisti (kernel, gnome, kde, xfree, openoffice e tanti altri) non hanno nulla da invidiare a controparti commerciali: in più, la disponibilità del codice ha reso possibile (ed è stato ed è continuamente fatto!) auditing approfonditi da parti terze e imparziali.
Lo sviluppo decentralizzato non è un limite, in quanto ogni sviluppatore deve sempre passare per il gestore di riferimento del ramo di appartenenza, che effettua test e validazioni prima di proporre il lavoro ai gestori dei rami superiori, che a loro volta faranno altri test e validazioni. E' una struttura (quasi) piramidale che (almeno per il kernel, con il quale ho più esperienza) ha prodotto risultati notevoli. Non funziona alla "facciamo un pò come c***o ci pare", e le revisioni rigide vengono fatte in tutti i punti della "catena di montaggio" ;)

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

I fatti smentiscono quest'affermazione: il software libero sviluppato in maniera professionale non ha nulla da invidiare ai software commerciali alternativi. Ti ho portato un pò di link per farti rendere conto di alcuni processi di test e auditing che sicuramente non conoscevi, prendilo almeno con il beneficio del dubbio ;)

Ikitt_Claw

03-08-2004, 08:44

Originariamente inviato da cdimauro
Oggettivamente, pensi che la situazione possa migliorare in futuro?

Non e` facile da dirsi.

Se l'interesse commerciale continua a crescere, e/o se GNU/Linux continua ad acquisire importanza e penetrazione nel mercato, e` quasi inevitabile che la qualita` del software assuma via via un'importanza sempre maggiore, com'e` ovvio e giusto che sia.
Vedendo anche la situazione corrente e del recente passato, direi che le componenenti fondamentali dell'OS (X server, librerie di sistema, DE, kernel, framework quali mono, server piu` popolari) saranno inevitabilmente soggetti a raffinamento sempre piu` accurato.

Ea anche da notare pero` che l'aumento di popolarita` del sistema attirera` inevitabilmente programmatori (o Software House...) poco attente, poco capaci o poco preparati a questi aspetti.
La qualita` media potrebbe quindi subire una flessione, a fronte di -relativamente- pochi progetti eccellenti (nel contesto o in assoluto) e una marea di sw mediocre o comunque non eccellente.

Similmente a quanto accade gia` adesso su freshmeat.net, peraltro.

PS: tutto cio` detto, io continuo a ravvisare un'abuso del termine "intrinseco".
Anche se la situazione non migliorasse o peggiorasse, o quel che e`, i difetti attuali e in generale la mancanza di qualita` del SW libero o opensource non sono -a parer mio- in alcun modo imputabili alla licenza.

leoneazzurro

03-08-2004, 09:53

Originariamente inviato da cdimauro
Indubbiamente. Ma è un altro discorso. ;)

Probabile, ma persone con stimoli lavorano meglio ;)

Quello usato nella macchina utilizzata per farmi operare alla vista col laser a eccimeri, tre anni fa. :eek:

Proprio LIFE critical non è (come complessità, oltretutto). Ma sicuramente abbastanza delicata.

Solidità in termini di ingegneria del software? Bisogna vedere... :D

vediamo, vediamo. :)

fek

03-08-2004, 10:01

Originariamente inviato da DjMix
E ridaje. Ma la smetti? OSS non è una metolologia!!! Ti ho già spiegato che puoi benissimo sviluppare un software opensource seguendo le regole che scrivevi qualche post fa, perchè insisti? E ti ho spiegato pure che CSS non significa automaticamente che le tue regole vengano applicate, anzi "di solito" non vengono manco prese in considerazione!!!

Calmati, qui stiamo facendo un discorso serio, pacato e interessante. Tu, riguardo alle metodologie di sviluppo software, non hai nulla da spiegarmi.

ilmanu

03-08-2004, 10:02

Originariamente inviato da fek
Calmati, qui stiamo facendo un discorso serio, pacato e interessante. Tu, riguardo alle metodologie di sviluppo software, non hai nulla da spiegarmi.
pecche' vi scannate? e poi ricordati che c'e' sempre da imparare....

fek

03-08-2004, 10:27

Originariamente inviato da ilsensine
Se ridai una occhiata a inizio thread, vedrai che sono stato io ad avanzare i primi dubbi sulla bontà dell'articolo.
Però poi si è finiti col dire il contrario, ovvero che l'OSS e il suo sviluppo "decentralizzato" è "intrinsecamente meno affidabile" per quel che riguarda la qualità del prodotto. Lavorando con software libero in prima persona ho solo precisato che non è così: i progetti portati avanti da professionisti (kernel, gnome, kde, xfree, openoffice e tanti altri) non hanno nulla da invidiare a controparti commerciali: in più, la disponibilità del codice ha reso possibile (ed è stato ed è continuamente fatto!) auditing approfonditi da parti terze e imparziali.
Lo sviluppo decentralizzato non è un limite, in quanto ogni sviluppatore deve sempre passare per il gestore di riferimento del ramo di appartenenza, che effettua test e validazioni prima di proporre il lavoro ai gestori dei rami superiori, che a loro volta faranno altri test e validazioni. E' una struttura (quasi) piramidale che (almeno per il kernel, con il quale ho più esperienza) ha prodotto risultati notevoli. Non funziona alla "facciamo un pò come c***o ci pare", e le revisioni rigide vengono fatte in tutti i punti della "catena di montaggio" ;)

Ho capito il tuo discorso, ma ancora nessuno e' riuscito a spiegarmi come si possa, ad esempio, fare pair programming in un progetto OS anche portato avanti da professionisti. E' semplicemente impossibile, dico bene?

Semplificando: ci sono passi e tecniche ben precise per massimizzare la qualita' del software.
In una metodologia e' possibile usare alcune di queste tecniche (tralasciamo per ora che si usano solo di rado), ma altre sono intrinsecamente impossibili da attuare.
In un'altra metodologia si possono usare tutte queste tecniche, quale delle due e' intrinsecamente migliore?

Direi che alla fine si e' trasformata in una comparazione fra metodi di sviluppo distribuiti e in house, piu' che open/closed source.

I fatti smentiscono quest'affermazione: il software libero sviluppato in maniera professionale non ha nulla da invidiare ai software commerciali alternativi. Ti ho portato un pò di link per farti rendere conto di alcuni processi di test e auditing che sicuramente non conoscevi, prendilo almeno con il beneficio del dubbio ;)

Ho letto quei link, mi hai dimostrato che ci sono alcuni enti che fanno test su linux, ad esempio. Ma convieni che e' diverso da un ambiente in cui i test sono scritti dal programmatore stesso e sottoposti a rigidi controlli formali?

fek

03-08-2004, 10:27

Originariamente inviato da ilmanu
pecche' vi scannate? e poi ricordati che c'e' sempre da imparare....

Da chi e' educato si', c'e' sempre da imparare. Da chi e' maleducato, no.

ilmanu

03-08-2004, 10:39

Originariamente inviato da fek
Da chi e' educato si', c'e' sempre da imparare. Da chi e' maleducato, no.
:uh: :uh: :uh: :uh: :uh: :uh:

ilsensine

03-08-2004, 10:47

Originariamente inviato da fek
Ho capito il tuo discorso, ma ancora nessuno e' riuscito a spiegarmi come si possa, ad esempio, fare pair programming in un progetto OS anche portato avanti da professionisti. E' semplicemente impossibile, dico bene?
Non conosco quella tecnica quindi non ti posso rispondere. Mi sembra però che stai facendo ruotare tutto il mondo attorno al "pair programming": o c'è, o il sw non può essere affidabile al 100% -- lo dicono i libri.
Non so se questi test vengano effettuati da qualcuno, non mi stupirebbe se lo fossero, ma non mi stupirebbe neanche se ne fossero fatti altri di diversi. Alcuni auditing li ho visti, e ti assicuro che sarebbero stati impossibili da fare senza la disponibilità del codice per terze parti. E non sto parlando di test effettuati da un semplice dilettante.

Semplificando: ci sono passi e tecniche ben precise per massimizzare la qualita' del software.
Mi fai un esempio di un qualsiasi sw famoso che ritieni "affidabile" sul quale sai per certo che vengono effettuati i test che dici? Uno solo a tua scelta. Per rendermi conto meglio di cosa intendi.

In una metodologia e' possibile usare alcune di queste tecniche (tralasciamo per ora che si usano solo di rado), ma altre sono intrinsecamente impossibili da attuare.
In un'altra metodologia si possono usare tutte queste tecniche, quale delle due e' intrinsecamente migliore?
L'auditing di terze parti è possibile utilizzando codice closed source?
No, ma non vado di certo a dire che per questo il sw closed è meno affidabile del sw libero.

Ho letto quei link, mi hai dimostrato che ci sono alcuni enti che fanno test su linux, ad esempio. Ma convieni che e' diverso da un ambiente in cui i test sono scritti dal programmatore stesso e sottoposti a rigidi controlli formali?
I link parlano anche di questo, forse non in maniera tanto esplicita...
L'open source developement labs (osdl) è nato in buona parte per tale scopo.

Ikitt_Claw

03-08-2004, 10:56

Originariamente inviato da fek
ancora nessuno e' riuscito a spiegarmi come si possa, ad esempio, fare pair programming in un progetto OS anche portato avanti da professionisti.

Prendi N ( con N%2 == 0, preferibilmente :D ) programmatori, e li fai stare per tot tempo sotto lo stesso tetto.
Esattamente come col software commerciale.

ilsensine

03-08-2004, 11:03

afterburner

03-08-2004, 11:56

Originariamente inviato da Ikitt_Claw
Prendi N ( con N%2 == 0, preferibilmente :D ) programmatori, e li fai stare per tot tempo sotto lo stesso tetto.
Esattamente come col software commerciale.
I programmatori linux sono artisti, non puoi farli stare sotto lo stesso tetto e tantomeno fargli fare pair programming.
Sarebbe come prendere Dali' e Picasso, metterli davanti ad una tela e dirgli "adesso fatemi un quadro in due" .. si ucciderebbero a vicenda. :D :D :D

fek

03-08-2004, 12:16

Originariamente inviato da ilsensine
Non conosco quella tecnica quindi non ti posso rispondere. Mi sembra però che stai facendo ruotare tutto il mondo attorno al "pair programming": o c'è, o il sw non può essere affidabile al 100% -- lo dicono i libri.
Non so se questi test vengano effettuati da qualcuno, non mi stupirebbe se lo fossero, ma non mi stupirebbe neanche se ne fossero fatti altri di diversi. Alcuni auditing li ho visti, e ti assicuro che sarebbero stati impossibili da fare senza la disponibilità del codice per terze parti. E non sto parlando di test effettuati da un semplice dilettante.

Il pair programming e' un esempio, piu' o meno ben conosciuto. Possiamo parlare di reviewing o di unit testing effettuate da un altro ingegnere che poi spiega a voce e sul PC del programmatore le modifiche vuole. E' un processo di sviluppo molto piu' veloce ed efficiente del classico "programmo, faccio il checkin, e spero che tutto vada bene".

Mi fai un esempio di un qualsiasi sw famoso che ritieni "affidabile" sul quale sai per certo che vengono effettuati i test che dici? Uno solo a tua scelta. Per rendermi conto meglio di cosa intendi.

DirectX 9.0c, .net Framework 2.0, il futuro XNA.

fek

03-08-2004, 12:17

Originariamente inviato da ilsensine
No, i programmatori di linux non si lavano quindi trovano sgradevole lavorare nella stessa stanza :D

ahah :D

maxone78

03-08-2004, 12:27

Originariamente inviato da cdimauro
Le cose non stanno esattamente così, come ho già avuto modo di spiegare: le proposte sono sempre vagliate scrupolosamente e vengono prospettati i costi e i benefici della nuova soluzione rispetto alla precedente. Dopo un ATTENTO esame, viene scelta la soluzione ottimale.
E posso assicurarti che il libero arbitrio, l'antipatia nei confronti del proponente, o le paturnie del responsabile del progetto hanno ben poco a che vedere in tutto ciò. ;)

e tu che ne sai? il fatto che ti spacci per "Dott" non ti fa il genio dell'informatica. :O

Ma come? ;)

Marco Fan Club

afterburner

03-08-2004, 13:30

Originariamente inviato da cdimauro
Originariamente inviato da afterburner
1."L'articolo affermava che Linux e' piu' SICURO":
Non sono io pinco pallino afterburner ad affermarlo ma qualcuno che prima di dirlo, sapendo che tra l'altro andava contro MS, ci avra' pensato parecchio ..

Bisogna vedere su quali basi può affermarlo, però. Finora mi sembra si tratti esclusivamente di statistiche, non di confronto di metodologie di sviluppo...

L'articolo parla di SICUREZZA dei sistemi non di metodologie di sviluppo!
Non confondere per favore!
Se mastro Geppetto trova la maniera di creare la cassaforte piu' invulnerabile al mondo, magari avra' una metodologia di sviluppo NON professionale e NON di qualita' ma rimane comunque la cassaforte piu' sicura del mondo. Chi me lo garantisce? I ladri che cercano di scassinarla e le statistiche delle casseforti scassinate.

A questo punto, almeno slega il binomio QUALITA'-SICUREZZA!! La sicurezza di un software openSource e' proprio data dal fatto che chiunque puo' leggere i sorgenti e le cappelle vengono fuori.

Ne abbiamo già parlato in abbondanza in passato: permettemi di dubitarne (e qui il buon ilsensine storcerà il naso ;))

Permettimi di esserne parecchio sicuro :D
Tu sarai anche laureato in informatica, io sono ING. informatico .. dottore :boxe:

La sicurezza di algoritmi tipo RSA,DSA,ECC e' data dal fatto che sono algoritmi crittografici noti .. l'algoritmo tutti lo conoscono e dopo anni di studi non e' stato possibile craccarli matematicamente: e' la conoscenza dell'algoritmo che fa la sicurezza di questi sistemi cosi' come la conoscenza dei sorgenti di un software fa la sicurezza di quel software.

Mi spiace, ma il paragone non calza: la sicurezza, in questi casi non ha alcuna relazione. Si tratta proprio di cose completamente diverse! :)
Il paragone calza e pure bene! Se non lo capisci e' un altro discorso :D

ilsensine

03-08-2004, 14:09

Originariamente inviato da fek
"programmo, faccio il checkin, e spero che tutto vada bene".

Mi sto sgolando per dirti che le cose non funzionano proprio così :muro:

ilsensine

03-08-2004, 14:11

Originariamente inviato da fek
DirectX 9.0c, .net Framework 2.0, il futuro XNA.
<ot> per curiosità, le dx <9.0c e il .net <2.0 erano sviluppati con tecniche "meno rigorose"?

fek

03-08-2004, 14:39

Originariamente inviato da ilsensine
Mi sto sgolando per dirti che le cose non funzionano proprio così :muro:

Ho capito che non funzionano sempre cosi', funzionano spesso cosi' ;)

La mia domanda: e' intrinsecamente di maggiore qualita' una metodologia dove puoi applicare tutti i principi o solo una parte?

Originariamente inviato da ilsensine
<ot> per curiosità, le dx <9.0c e il .net <2.0 erano sviluppati con tecniche "meno rigorose"?

Sono circa 5 anni che in MS usano metodologie di sviluppo decisamente all'avanguardia, quindi direi di si', ma con relativa sicurezza ti posso parlare solo di queste versioni.

fek

03-08-2004, 14:51

Originariamente inviato da afterburner
L'articolo parla di SICUREZZA dei sistemi non di metodologie di sviluppo!

L'articolo cita la metodologia:

"Le ragioni per le quali i sistemi Linux sono più sicuri sono semplici, molte più teste sullo stesso codice significa meno falle e un sistema sempre più sicuro"

Sono una decina di pagine che stiamo discutendo su questa frase :)

Kars

03-08-2004, 15:03

Originariamente inviato da fek
L'articolo cita la metodologia:

"Le ragioni per le quali i sistemi Linux sono più sicuri sono semplici, molte più teste sullo stesso codice significa meno falle e un sistema sempre più sicuro"

Sono una decina di pagine che stiamo discutendo su questa frase :)

Una frase un po' troppo "riduttiva".

ilsensine

03-08-2004, 15:08

Originariamente inviato da fek
Sono circa 5 anni che in MS usano metodologie di sviluppo decisamente all'avanguardia, quindi direi di si', ma con relativa sicurezza ti posso parlare solo di queste versioni.
Ho capito; l'ho chiesto perché volevo rendermi conto, all'atto pratico, delle implicazioni sulla qualità, paragonando con dei sw che potevo conoscere. Sinceramente non direi che negli ultimi anni la Microsoft abbia entusiasmato, anche se sembra che una svolta dovrebbe (finalmente) aversi con il SP2 di XP.
Comunque ti ripeto:

La mia domanda: e' intrinsecamente di maggiore qualita' una metodologia dove puoi applicare tutti i principi o solo una parte?
Nel mondo del sw libero puoi non poter applicare dei principi (in particolare l'odiosa "security by obscurity") ma ne puoi applicare altri (ad es. auditing di terze parti).
Non sono in grado di giudicare quale dei due sia il migliore; da sviluppatore posso solo dire che lavorare con il sw libero lo trovo molto produttivo, soddisfacente e qualitativamente elevato. Senza nulla togliere ai miei colleghi che lavorano con sistemi diversi, ovviamente.

Ikitt_Claw

03-08-2004, 15:15

Originariamente inviato da ilsensine
Nel mondo del sw libero puoi non poter applicare dei principi (in particolare l'odiosa "security by obscurity") ma ne puoi applicare altri (ad es. auditing di terze parti).

E, ritornando alla radice del discorso, che l'auditing di terze parti sia propedeutico alla sicurezza di un software, mi pare anche pienamente sensato.

fek

03-08-2004, 16:27

Originariamente inviato da ilsensine
Ho capito; l'ho chiesto perché volevo rendermi conto, all'atto pratico, delle implicazioni sulla qualità, paragonando con dei sw che potevo conoscere. Sinceramente non direi che negli ultimi anni la Microsoft abbia entusiasmato, anche se sembra che una svolta dovrebbe (finalmente) aversi con il SP2 di XP.
Comunque ti ripeto:

In passato sicuramente la MS ha fatto parecchie porcate :)
Ma negl'ultimi anni sono diventati sicuramente il miglior sviluppatore di codice al mondo, anche solo perche' hanno preso tutti i migliori in circolazione, un po' come il Real Madrid. Ok, il Real non e' un esempio forte... ;)

Nel mondo del sw libero puoi non poter applicare dei principi (in particolare l'odiosa "security by obscurity") ma ne puoi applicare altri (ad es. auditing di terze parti).
Non sono in grado di giudicare quale dei due sia il migliore; da sviluppatore posso solo dire che lavorare con il sw libero lo trovo molto produttivo, soddisfacente e qualitativamente elevato. Senza nulla togliere ai miei colleghi che lavorano con sistemi diversi, ovviamente.

Dov'e' il problema nell'auditing di terze parti? Ci sono aziende che fanno solo quello al quale puoi appaltare l'auditing.
Pensa che NVIDIA propone assieme al co-marketing l'auditing del motore 3d nei propri lab. Un esempio.

ilsensine

03-08-2004, 16:33

Originariamente inviato da fek
Ma negl'ultimi anni sono diventati sicuramente il miglior sviluppatore di codice al mondo
Ehiehiehi, è un invito al flame :D
Permetti a me e ad altri rivoluzionari di dissentire ;)

Dov'e' il problema nell'auditing di terze parti? Ci sono aziende che fanno solo quello al quale puoi appaltare l'auditing.
Pensa che NVIDIA propone assieme al co-marketing l'auditing del motore 3d nei propri lab. Un esempio.
Completamente un altro discorso.
Una cosa è pagare una/due ditte per questo compito, per un certo prodotto, per un certo tempo; un'altra disporre di _molte_ ditte, università e quant'altro che lo effettuano. Guarda, puoi criticarci su tutto, ma sul discorso dell' "auditing di terze parti" non temiamo concorrenza alcuna.
La stessa Microsoft "ci studia", lo so... :D

afterburner

03-08-2004, 17:35

Originariamente inviato da fek
In passato sicuramente la MS ha fatto parecchie porcate :)
Ma negl'ultimi anni sono diventati sicuramente il miglior sviluppatore di codice al mondo

Terra chiama fek ...
Terra chiama fek ...
;)

fek

03-08-2004, 18:06

Originariamente inviato da ilsensine
Ehiehiehi, è un invito al flame :D
Permetti a me e ad altri rivoluzionari di dissentire ;)

Ti permetto di dissentire solo se mi nomini un altro sviluppatore che annovera a libro paga gente del calibro di Herb Sutter, Don Box e Hejlsberg ;)

Rispetivamente, il riconosciuto massimo esperto mondiale di C++, il padre di COM e il padre di linguaggi come Turbo Pascal e C#. Praticamente Zidane, Ronaldo e Raul :D

Completamente un altro discorso.
Una cosa è pagare una/due ditte per questo compito, per un certo prodotto, per un certo tempo; un'altra disporre di _molte_ ditte, università e quant'altro che lo effettuano. Guarda, puoi criticarci su tutto, ma sul discorso dell' "auditing di terze parti" non temiamo concorrenza alcuna.
La stessa Microsoft "ci studia", lo so... :D

E' meglio disporre di un programmatore sicuramente ottimo o di molti programmatori dei quali non conosci nulla (ne' che siano ottimi ne' che non lo siano).
Non dico che avere molto auditing di terze parti sia una cosa negativa, anzi, ben venga. Qui sto dicendo che puo' essere un salto nel buio, e gia' sviluppare software e' piuttosto aleatorio di suo, se e' possibile diminuire le variabili, sono felice. Comunque hai ragione, e' tutto un altro discorso.

Ikitt_Claw

03-08-2004, 18:21

Originariamente inviato da fek
Rispetivamente, il riconosciuto massimo esperto mondiale di C++, il padre di COM e il padre di linguaggi come Turbo Pascal e C#. Praticamente Zidane, Ronaldo e Raul :D

Senza stare a scomodare la vituperata Inter o altri esempi eccellenti... ;)

...Avere una squadra di 11 campioni non implica vincere tutto il vincibile. Tant'e` che il Real Madrid non fa granche` faville ultimamente. Quantomeno, gioca peggio (e sopratutto, ottiene risultati inferiori) di quanto ci potrebbe aspettare data la caratura tecnica.

Tutto questo, senza voler togliere proprio nulla agli Esperti (la maiuscola non e` casuale) che hai citato. Massimo rispetto per quelli.

ilmanu

03-08-2004, 19:35

ma la volete finire o no? siete andati copletamente ot e poi e' 2 gg che ripete le stesse cose, ora e' chiaro che nessuno vuole cambiare idea, che ognuno si tenga la sua senno' fra un po' diventano troppo grosse e non ci stanno nemmeno sul foro
senza rancore
:(

cdimauro

03-08-2004, 21:00

Originariamente inviato da ilmanu
quando cdimauro posta incomincio a sudare, basti vedere il numero di raplay consecutivi, scusa la grammatica e la terminologia magari sbagliata, pero' vedo che cmq hai capito cosa intendevo.... come sempre.... :D :D :D

hai pvt
OK. Comunque non c'è niente da temere dai miei post. ;) E i miei sono sempre pieni zeppi di errori: mi spiace, ma proprio non ho il tempo di correggerli. :p

cdimauro

03-08-2004, 21:29

Originariamente inviato da Ikitt_Claw
Ea anche da notare pero` che l'aumento di popolarita` del sistema attirera` inevitabilmente programmatori (o Software House...) poco attente, poco capaci o poco preparati a questi aspetti.
La qualita` media potrebbe quindi subire una flessione, a fronte di -relativamente- pochi progetti eccellenti (nel contesto o in assoluto) e una marea di sw mediocre o comunque non eccellente.
Considerato l'andazzo attuale, col popolo di lamer che si spacciano per "programmatori", non vedo un futuro molto roseo (in generale...)
Similmente a quanto accade gia` adesso su freshmeat.net, peraltro.
Non conosco: di che tratta?
PS: tutto cio` detto, io continuo a ravvisare un'abuso del termine "intrinseco".
Anche se la situazione non migliorasse o peggiorasse, o quel che e`, i difetti attuali e in generale la mancanza di qualita` del SW libero o opensource non sono -a parer mio- in alcun modo imputabili alla licenza.
Per quanto mi riguarda, e l'ho già scritto, è una questione meramente pragmatica, più che formale...

cdimauro

03-08-2004, 21:30

Originariamente inviato da ilsensine
No, i programmatori di linux non si lavano quindi trovano sgradevole lavorare nella stessa stanza :D
Permettimi di dissentire: molto probabilmente tu non hai mai partecipato a qualche "hacker contest" o "massive core attack" in un centro sociale... :eek: :D

cdimauro

03-08-2004, 21:35

Originariamente inviato da maxone78
e tu che ne sai? il fatto che ti spacci per "Dott" non ti fa il genio dell'informatica. :O

Ma come? ;)

Marco Fan Club
Indubbiamente non è l'abito che fa il monaco: gli uomini si misurano dai fatti, non dalle parole. ;)

Per quanto mi riguarda, pur essendo un dottore, non sono certo un oculista, ma ti consiglio comunque di rileggerti i miei precedenti messaggi: troverai le risposte che cerchi. :cool:

cdimauro

03-08-2004, 21:48

Originariamente inviato da afterburner
L'articolo parla di SICUREZZA dei sistemi non di metodologie di sviluppo!
Non confondere per favore!
Se mastro Geppetto trova la maniera di creare la cassaforte piu' invulnerabile al mondo, magari avra' una metodologia di sviluppo NON professionale e NON di qualita' ma rimane comunque la cassaforte piu' sicura del mondo. Chi me lo garantisce? I ladri che cercano di scassinarla e le statistiche delle casseforti scassinate.
Qualcuno t'ha già risposto. ;)
Permettimi di esserne parecchio sicuro :D
Tu sarai anche laureato in informatica, io sono ING. informatico .. dottore :boxe:
Benissimo, e visto che parliamo la stessa lingua, ti chiedo gentilmente di dimostrare la tua affermazione ("La sicurezza di un software openSource e' proprio data dal fatto che chiunque puo' leggere i sorgenti e le cappelle vengono fuori.") ... :D
Il paragone calza e pure bene! Se non lo capisci e' un altro discorso :D
Per quanto mi riguarda (e posso assicurarti di non essere il solo ;)), se un algoritmo è dimostrato essere NP-Completo (il che non ha nulla che fare con la sua divulgazione, ma questo lo dovresti già sapere ;)), che sia open o closed source ha poca importanza: IN OGNI CASO sarà "abbastanza" :sofico: sicuro.

Quanto al concetto di "conoscenza" e di "pubblicazione" di un software, non vedo l'implicazione logica: la pubblicazione di un software non ti porta necessariamente alla sua conoscenza.

Detto ciò, su quest'ultimo argomento potremmo continuare a filosofeggiare vita natural durante. :) Sul primo, invece, penso che ci sia ben poco da eccepire. ;) In ogni caso, non vedo alcune legame fra la sicurezza relativa agli algoritmi crittografici e quella dei sorgenti: sempre disponibile a ricredermi, in caso ciò venga dimostrato. :D

ilsensine

04-08-2004, 07:34

Originariamente inviato da fek
Ti permetto di dissentire solo se mi nomini un altro sviluppatore che annovera a libro paga gente del calibro di Herb Sutter, Don Box e Hejlsberg ;)

Potrei farti nomi di gente che fisicamente non può appartenere al limitato-mentalmente genere umano, che lavorano esclusivamente per il sw libero, ma non servirebbe a molto visto che probabilmente non sono noti dalle tue parti.

E' meglio disporre di un programmatore sicuramente ottimo o di molti programmatori dei quali non conosci nulla (ne' che siano ottimi ne' che non lo siano).
_TU_ non conosci nulla di quei programmatori... ;)

fek

04-08-2004, 08:00

Originariamente inviato da ilsensine
_TU_ non conosci nulla di quei programmatori... ;)

Nessuno conosce nulla. Tu mi insegni che dietro ad una email possono anche esserci dieci persone diverse.

ilsensine

04-08-2004, 08:03

Originariamente inviato da fek
Nessuno conosce nulla. Tu mi insegni che dietro ad una email possono anche esserci dieci persone diverse.
Puoi rigirarti le cose come vuoi, ma non cambia nulla.
Non segui lo sviluppo di linux come faccio io, questo è chiaro, quindi almeno abbi la discrezione di non bollarmi con un pò di retorica.

ilsensine

04-08-2004, 08:39

Originariamente inviato da fek
Dell'NSA non parlo per motivi politici :p
Allora questa notizia non ti farà affatto piacere :p (e almeno qui avremo un punto in comune):
http://punto-informatico.it/p.asp?i=49253

maxone78

04-08-2004, 10:30

Originariamente inviato da cdimauro
Indubbiamente non è l'abito che fa il monaco: gli uomini si misurano dai fatti, non dalle parole. ;)

Per quanto mi riguarda, pur essendo un dottore, non sono certo un oculista, ma ti consiglio comunque di rileggerti i miei precedenti messaggi: troverai le risposte che cerchi. :cool:

E tu si sa che non sei un uomo (sessualmente parlando) :sofico: :oink:

Mmmhhhh, in questo caso l'oculista lo consiglio a te visto che non mi hai nemmeno riconosciuto, caro il mio "amicone perverso di Marco" ;)

Marco Fan Club -----> Melilli ;)
:sofico:

Ora mi riconosci? ;)

afterburner

04-08-2004, 10:40

Originariamente inviato da cdimauro
Qualcuno t'ha già risposto. ;)

Non la considero una risposta .. qui ognuno rigira la torta come gli fa piu' comodo :D

Benissimo, e visto che parliamo la stessa lingua, ti chiedo gentilmente di dimostrare la tua affermazione ("La sicurezza di un software openSource e' proprio data dal fatto che chiunque puo' leggere i sorgenti e le cappelle vengono fuori.") ... :D

La dimostrazione Tesi .. Ipotesi .. CVD non riesco a dartela, ma tu sicuramente non puoi falsificare la mia affermazione e quindi siamo punto e a capo.
Fek sta cercando di falsificare la mia (nostra) teoria sfruttando regole della eXtreme Programming ma la XP e' una teoria costruita su assiomi non dimostrabili (altrimenti non sarebbero assioni :))
Non puoi usare una teoria non dimostrata essere corretta per falsificarne un'altra :D

Per quanto mi riguarda (e posso assicurarti di non essere il solo ;)), se un algoritmo è dimostrato essere NP-Completo (il che non ha nulla che fare con la sua divulgazione, ma questo lo dovresti già sapere ;)), che sia open o closed source ha poca importanza: IN OGNI CASO sarà "abbastanza" :sofico: sicuro.

Yup! Che bei ricordi! A meno che non dimostrino che P=NP .. parecchio improbabile :) Comunque tra due algoritmi esponenziali, uno open e uno closed source, che mi risolvono il TSP o il ciclo hamiltoniano con esponente basso, preferisco quello open :D

In ogni caso, non vedo alcune legame fra la sicurezza relativa agli algoritmi crittografici e quella dei sorgenti: sempre disponibile a ricredermi, in caso ciò venga dimostrato. :D
Io ci riprovo ma non e' detto che ci riesca :D
RSA, algoritmo noto, craccabile se fattorizzi il prodotto di 2 numeri primi parecchio grandi (ti pagano pure!) vedi http://www.rsasecurity.com/rsalabs/node.asp?id=2093 lo si cracca per brute-force ma algoritmi rapidi per fattorizzare un numero non ci sono neancora ( senno' ricadremmo in P=NP )
Kernel Linux, sorgenti noti e scaricabili .. quanta gente pensi se li sia studiati per riuscire a trovare una debolezza, magari causare anche un solo DoS, trovare la forma di quel pacchetto IP che inchioda netfilter-iptables? Non ti da' soldi ma punti stima nel mondo hacker .. secondo me parecchi ci provano e chi trova qualcosa di solito invece di sfruttarla comunica il bug ai maintainers.
Windows, sorgenti noti all'interno di MS .. ci sara' sicuramente chi cerca bugs ma il numero sara' sicuramente di tanto inferiore a quello di chi analizza il codice di Linux.
A questo punto interviene fek che dice "meglio pochi sapientoni che tanti lamer" ... non mi convince, nessun lamer sa completamente zero ;)

fek

04-08-2004, 13:04

Originariamente inviato da ilsensine
Puoi rigirarti le cose come vuoi, ma non cambia nulla.
Non segui lo sviluppo di linux come faccio io, questo è chiaro, quindi almeno abbi la discrezione di non bollarmi con un pò di retorica.

Ti pare che provi a rigirarti con un un po' di retorica? Stiamo solo chiacchierando ed e' piacevole chiacchierare con chi come te ne sa. Non si deve per forza avere la stessa opinione.

Originariamente inviato da ilsensine
Allora questa notizia non ti farà affatto piacere :p (e almeno qui avremo un punto in comune):
http://punto-informatico.it/p.asp?i=49253

Francamente, a me di quello che fa l'US Army frega poco o niente. Anzi, se sbaraccassero tutto sarei piu' felice :p

Originariamente inviato da afterburner
Fek sta cercando di falsificare la mia (nostra) teoria sfruttando regole della eXtreme Programming ma la XP e' una teoria costruita su assiomi non dimostrabili (altrimenti non sarebbero assioni :))
Non puoi usare una teoria non dimostrata essere corretta per falsificarne un'altra :D

Non parlare di cose che non sai, per cortesia. Gli unit testing formali, il pair programming e compagnia cantando sono strumenti usati in svariate metodologie. XP Programming e' solo una delle metodologie.

A questo punto interviene fek che dice "meglio pochi sapientoni che tanti lamer" ... non mi convince, nessun lamer sa completamente zero ;)

Ma un lamer puo' creare un sacco di casini e perdite di tempo.

ilmanu

04-08-2004, 13:17

@fek: posso chiederti che lavoro fai o quanto meno che ruolo ricorpi?

fek

04-08-2004, 13:20

Originariamente inviato da ilmanu
@fek: posso chiederti che lavoro fai o quanto meno che ruolo ricorpi?

Sono 3D Programmer e Software Engineer alla Lionhead.
Al momento lavoro su Black&White 2.

jappilas

04-08-2004, 13:34

Originariamente inviato da fek
Sono 3D Programmer e Software Engineer alla Lionhead.
Al momento lavoro su Black&White 2.

O_o <- /me is seriously impressed

ilsensine

04-08-2004, 13:37

Originariamente inviato da jappilas
O_o <- /me is seriously impressed
/me is seriously incazzed, dal sito della Lionhead non vedo titoli per linux :huh:
:D

fek

04-08-2004, 13:47

Originariamente inviato da ilsensine
/me is seriously incazzed, dal sito della Lionhead non vedo titoli per linux :huh:
:D

Ci hanno provato con Tribes 2... avranno venduto 1000 copie... bancarotta :D

eraser

04-08-2004, 13:52

Originariamente inviato da fek
Sono 3D Programmer e Software Engineer alla Lionhead.
Al momento lavoro su Black&White 2.

viene su bene come gioco? :D :D

fek

04-08-2004, 13:54

Originariamente inviato da eraser
viene su bene come gioco? :D :D

Esce quando e' pronto.
Ah scusa, non era questa... Peter dice di si' :D

ilsensine

04-08-2004, 13:58

Originariamente inviato da fek
Ci hanno provato con Tribes 2... avranno venduto 1000 copie... bancarotta :D
Già si sono arresi? Altre case continuano ostentatamente a proporre titoli per linux...
Poi se non ricordo male il porting lo fece a suo tempo la Loki, che aveva strategie di marketing completamente sballate.

Per ora customers--, hai visto mai che faccio numero... ;)

eraser

04-08-2004, 14:01

vendere su due cd magari la versione per windows e quella per linux? così non c'è nessun fallimento, chi compra la versione di windows compra anche quella per linux e può scegliere su che piattaforma giocare.
L'azienda non fallisce perché se tanto il gioco è bello, gli utenti lo comprano.

[IGNORANZA MODE ON :D]

fek

04-08-2004, 14:06

Originariamente inviato da eraser
vendere su due cd magari la versione per windows e quella per linux? così non c'è nessun fallimento, chi compra la versione di windows compra anche quella per linux e può scegliere su che piattaforma giocare.
L'azienda non fallisce perché se tanto il gioco è bello, gli utenti lo comprano.

[IGNORANZA MODE ON :D]

Quando il potenziale mercato Linux rappresenta meno dell'1%? I programmatori e i tester per il porting Linux devono essere pagati, se la versione Linux non genera ritorni in termini di copie vendute (e non li genera :p) non ha senso pagarli.

ilsensine

04-08-2004, 14:06

Originariamente inviato da eraser
vendere su due cd magari la versione per windows e quella per linux? così non c'è nessun fallimento, chi compra la versione di windows compra anche quella per linux e può scegliere su che piattaforma giocare.
L'azienda non fallisce perché se tanto il gioco è bello, gli utenti lo comprano.

[IGNORANZA MODE ON :D]
La strategia migliore (che viene adottata per parecchi giochi) è realizzare il solo cd per windows, e rendere disponibile i programma per linux (che ovviamente necessita del cd con i file di gioco).

Il problema è realizzare il codice multipiattaforma: o viene pianificato all'inizio del progetto, oppure dopo è un casino...

ilsensine

04-08-2004, 14:11

Originariamente inviato da fek
Quando il potenziale mercato Linux rappresenta meno dell'1%? I programmatori e i tester per il porting Linux devono essere pagati, se la versione Linux non genera ritorni in termini di copie vendute (e non li genera :p) non ha senso pagarli.
"write once, compile everywhere..." :fiufiu: (slogan di un toolkit multipiattaforma)

Non vorrei vedervi tra alcuni anni a rincorrere le "case concorrenti": per ora saremo pure meno dell'1% (anche se mi risulta che i sistemi desktop linux sono odiernamente di più), ma per tua informazione gli utenti linux hanno una incomprensibile allergia nei confronti della pirateria... ;)

fek

04-08-2004, 14:12

Originariamente inviato da ilsensine
La strategia migliore (che viene adottata per parecchi giochi) è realizzare il solo cd per windows, e rendere disponibile i programma per linux (che ovviamente necessita del cd con i file di gioco).

Il problema è realizzare il codice multipiattaforma: o viene pianificato all'inizio del progetto, oppure dopo è un casino...

Ma il codice multipiattaforma ha un costo, qualunque generalizzazione ha un costo non solo in termini di tempo ma anche in termini di performance.
Se io sto scrivendo un motore 3d che sfrutta particolarita' dei driver e della libreria (D3D) per andare veloce, se lo devo scrivere multipiattaforma perdo nettamente in prestazioni.

Oltre al fatto che un eventuale gioco multipiattaforma andrebbe scritto in OpenGL (ho i brividi al solo pensiero...)

ilsensine

04-08-2004, 14:20

Originariamente inviato da fek
Ma il codice multipiattaforma ha un costo, qualunque generalizzazione ha un costo non solo in termini di tempo ma anche in termini di performance.
Se io sto scrivendo un motore 3d che sfrutta particolarita' dei driver e della libreria (D3D) per andare veloce, se lo devo scrivere multipiattaforma perdo nettamente in prestazioni.
Su questo campo ho completa ignoranza, sarei curioso di sapere come hanno fatto gli altri...

Non vi biasimo affatto per le vostre decisioni, ma almeno capirai perché stimo tanto aziende come la IBM (che quando ha deciso di rischiare i fondelli puntando su linux, aveva gli stessi vostri problemi. Eppure non si sono tirati indietro, e hanno avuto un ritorno degli investimenti talmente rapido da polverizzare anche le loro più rosee previsioni).

afterburner

04-08-2004, 14:24

Originariamente inviato da fek
Ti pare che provi a rigirarti con un un po' di retorica? Stiamo solo chiacchierando ed e' piacevole chiacchierare con chi come te ne sa. Non si deve per forza avere la stessa opinione.

Pienamente d'accordo :cool:

Francamente, a me di quello che fa l'US Army frega poco o niente. Anzi, se sbaraccassero tutto sarei piu' felice :p

Pienamente d'accordo :cool:
Anzi, metti mai che condizionino lo sviluppo del kernel .. speriamo di no!

Non parlare di cose che non sai, per cortesia. Gli unit testing formali, il pair programming e compagnia cantando sono strumenti usati in svariate metodologie. XP Programming e' solo una delle metodologie.

Ho sempre voluto ignorare queste cose lo ammetto .. pero' "X Y formali" e "pair Z" mi sono sempre stati propinati da seguaci della metodologia XP. Cio' non toglie che qualsiasi metodologia tu usi non puoi falsificare la mia affermazione che "i sorgenti open contribuiscono alla sicurezza".
Cio' non toglie che neanch'io posso falsificare le affermazioni tue e di dimauro
E siamo punto e a capo se non che abbiamo fatto 4 chiacchere interessanti :D

Ma un lamer puo' creare un sacco di casini e perdite di tempo.
Bisogna selezionarli bene! C'e' il lamer che si spaccia per hacker per far colpo sulle tipe (davvero!! credeteci!) .. c'e' il lamer che lo e' per passione, sa di essere mediocre ma vuole diventare un buon programmer e con dell'impegno ce la fara'

fek

04-08-2004, 14:26

Originariamente inviato da ilsensine
Su questo campo ho completa ignoranza, sarei curioso di sapere come hanno fatto gli altri...

Come hanno fatto chi?
Io parlo dell'Industry e solo di questo ora. Non dubito che in altri campi si possa fare profitto scrivendo software per Linux, altrimenti non esisterebbe neppure.
Nell'Industry, scrivere per Linux e' un suicidio economico, tanto e' vero che molti di quelli che ci hanno provato sono falliti. E se pensi che gia' molte aziende falliscono normalmente in questo campo, capirai perche' nessuno rischia le chiappe.

ilsensine

04-08-2004, 14:34

Originariamente inviato da fek
Come hanno fatto chi?
Io parlo dell'Industry e solo di questo ora. Non dubito che in altri campi si possa fare profitto scrivendo software per Linux, altrimenti non esisterebbe neppure.
No intendevo gli "altri che distribuiscono versioni dei giochi per linux".
Ad es. doom3 è in previsione anche per linux.

afterburner

04-08-2004, 14:35

Giochi per linux??
e chi ci gioca?
L'amministratore linux di turno col suo bel cluster opteron cosi' se si pianta il gioco pianti webServer, mailServer e fileServer? :D
Ho un paio di linux su alphaserver .. facciamo il porting anche per questo?? :D :D

ilsensine

04-08-2004, 14:38

Originariamente inviato da afterburner
Giochi per linux??
e chi ci gioca?
L'amministratore linux di turno col suo bel cluster opteron cosi' se si pianta il gioco pianti webServer e mailServer e fileServer? :D
Ho un paio di linux su alphaserver .. facciamo il porting anche per questo?? :D :D
Fortunatamente al mondo c'è anche gente che la pensa diversamente da te.
E a molti di loro piace giocare.

fek

04-08-2004, 14:46

Originariamente inviato da ilsensine
No intendevo gli "altri che distribuiscono versioni dei giochi per linux".
Ad es. doom3 è in previsione anche per linux.

5 anni di sviluppo :)
Non tutti hanno il budget dell'ID che si permette di buttare 5 anni di sviluppo in un motore 3d OpenGL.

afterburner

04-08-2004, 14:47

Originariamente inviato da ilsensine
Fortunatamente al mondo c'è anche gente che la pensa diversamente da te.
E a molti di loro piace giocare.
Anche a me piace giocare!
Rimane che:
1-Linux e' usatissimo come server
2-Linux NON e' usatissimo come sistema desktop
Ho parecchie divergenze di pensiero con fek pero' qui ha pienamente ragione. IBM investe su linux ( e grazie IBM ) perche' vuole vendere server e servizi .. con i giochini non funziona cosi'.

jappilas

04-08-2004, 14:53

Originariamente inviato da fek
5 anni di sviluppo :)
Non tutti hanno il budget dell'ID che si permette di buttare 5 anni di sviluppo in un motore 3d OpenGL.

uhm, però come giochi non penso esista solo Doom...
e dal punto di vista delle piattaforme, spero la situazione non sia AUT pc wintel (dove si dispone di directx) , AUT console ... mi sembrerebbe un tantino deprimente e vorrebbe dire tagliare fuori (tra ' altro ) gli apple...
e non sono sicuro che chi ha acquistato un G5 , dotato di radeon 9800, sia contento di sentirsi dire
"guarda questo gioco potrebbe girare sulla tua macchina, e pure bene date le prestazioni oggettive,
tra altro non dovresti neppure trafficare coi settaggi di antialising e livello dettaglio perchè praticamente tutti i G5 hanno o una scheda o l' altra, quindi c' è molta meno varianza ...
però non ci va di investire il nostro budget in qualche sviluppatore extra che si dedichi alla conversione..."
:rolleyes:

ilsensine

04-08-2004, 14:59

Originariamente inviato da afterburner
1-Linux e' usatissimo come server
2-Linux NON e' usatissimo come sistema desktop

Il fatto che siamo una stretta minoranza non fa di noi esseri verdi con strane antenne sulla testa, e permettimi di avere un particolare occhio di rispetto per chi ci considera "degni di esistere" per lo meno al pari degli utenti Mac.

Aver scelto linux come sistema desktop ci ha obbligato a parecchie rinuncie, lo sappiamo e non ci lamentiamo di questo. Evidentemente riteniamo di essere stati ben compensati con gli interessi in altri modi ;)

ilsensine

04-08-2004, 15:01

Originariamente inviato da fek
5 anni di sviluppo :)
Non tutti hanno il budget dell'ID che si permette di buttare 5 anni di sviluppo in un motore 3d OpenGL.
Vuoi dire che l'ID ha cominciato a sviluppare un prodotto con requisiti hw che 5 anni fa non si immaginava neanche potessero essere disponibili?
Permettimi di avere qualche dubbio ;)

jappilas

04-08-2004, 15:12

Originariamente inviato da ilsensine
Vuoi dire che l'ID ha cominciato a sviluppare un prodotto con requisiti hw che 5 anni fa non si immaginava neanche potessero essere disponibili?
Permettimi di avere qualche dubbio ;)

su un altro thread dove si discoteva dei requisiti di doom3 però, mi pare si gridasse allo scandalo per via degli fps che il motore farebbe su piattaforme allo stato dell' arte adesso ( p4 , Geforce 6800) ....

ho l' impressione cha alla id i requisiti hw non li abbiano mai definiti, ma abbiano inseguito per 5 anni la visione dell' effetto finale, a prescindere dall' hw su cui ottenerlo ... e contando sull' evoluzione della piattaforma pc che avrebbe reso tale hw disponibile :rolleyes:

afterburner

04-08-2004, 15:13

Originariamente inviato da ilsensine
Il fatto che siamo una stretta minoranza non fa di noi esseri verdi con strane antenne sulla testa, e permettimi di avere un particolare occhio di rispetto per chi ci considera "degni di esistere" per lo meno al pari degli utenti Mac.

Aver scelto linux come sistema desktop ci ha obbligato a parecchie rinuncie, lo sappiamo e non ci lamentiamo di questo. Evidentemente riteniamo di essere stati ben compensati con gli interessi in altri modi ;)
E lo dici a me??? Adesso scrivo da Konqueror su RH9b kernel 2.4.24-openmosix1 .. non mi considero un essere verde, mi piacerebbe tantissimo che molti usassero Linux come desktop ma purtroppo non e' cosi' e nell'ambito del pc gaming il discorso di fek non fa una piega.

ilsensine

04-08-2004, 15:23

Originariamente inviato da jappilas
su un altro thread dove si discoteva dei requisiti di doom3 però, mi pare si gridasse allo scandalo per via degli fps che il motore farebbe su piattaforme allo stato dell' arte adesso ( p4 , Geforce 6800) ....

ho l' impressione cha alla id i requisiti hw non li abbiano mai definiti, ma abbiano inseguito per 5 anni la visione dell' effetto finale, a prescindere dall' hw su cui ottenerlo ... e contando sull' evoluzione della piattaforma pc che avrebbe reso tale hw disponibile :rolleyes:
Se per girare _oggi_, quel gioco fatica con simili risorse hw, mi viene da pensare che 5 anni fa sia stata un puro "annuncio ad effetto di marketing". Il fatto che fek non conosca queste tecniche fa onore alla serietà della sua azienda.

fek

04-08-2004, 15:25

Originariamente inviato da jappilas
uhm, però come giochi non penso esista solo Doom...
e dal punto di vista delle piattaforme, spero la situazione non sia AUT pc wintel (dove si dispone di directx) , AUT console ... mi sembrerebbe un tantino deprimente e vorrebbe dire tagliare fuori (tra ' altro ) gli apple...

La tua speranza e' vana, perche' la situazione e' proprio questa: o giochi su PC con wintel o giochi su console (o ti accontenti di 5 giochi l'anno che escono su Mac o Linux).

Ed e' giusto e normale che sia cosi', perche' e' sempre facile fare il budget coi soldi degl'altri, ma quando commettere un errore signifca fallire, ogni azienda va per il mercato che gli assicura i maggiori ritorni per il proprio investimento (PC + wintel oppure console) oppure scompare dal mercato.

Originariamente inviato da ilsensine
Vuoi dire che l'ID ha cominciato a sviluppare un prodotto con requisiti hw che 5 anni fa non si immaginava neanche potessero essere disponibili?
Permettimi di avere qualche dubbio ;)

Linux e' il tuo campo, ma giochi e 3d sono casa mia :D

I tuoi dubbi sono infondati perche' il primo renderer di Doom 3 e' stato scritto mentre il resto della ID lavorava a Quake Team Arena e sfruttava la GF3.
Esistono ancora in giro interviste a Carmack nelle quali afferma che una GF3 Doom3 avrebbe fatto girare Doom3 senza problemi.
Poi cambiano le estensioni OpenGL e si riscrive il renderer, cambiano di nuovo e si scrive un nuovo code path, esce un'altra GPU ed un'altro code path. Le gioie di programmare multipiattaforma sotto OpenGL.

fek

04-08-2004, 15:26

Originariamente inviato da ilsensine
Il fatto che fek non conosca queste tecniche fa onore alla serietà della sua azienda.

Che cosa intendi di preciso, perche' qui il discorso sta prendendo una piega che non mi piace proprio. Spero di aver capito male io.

afterburner

04-08-2004, 15:33

Penso ilsensine si riferisca alle tecniche di marketing della ID di 5 anni fa ...

ilsensine

04-08-2004, 15:36

Originariamente inviato da fek
Che cosa intendi di preciso, perche' qui il discorso sta prendendo una piega che non mi piace proprio. Spero di aver capito male io.
Da quello che ho capito (non ho letto il thread su doom3 e posso sbagliarmi), quel gioco è stato annunciato 5 anni fa. Oggi il gioco è praticamente pronto, e mette paura per le richieste hw attuali. Mi chiedo allora cosa hanno annunciato 5 anni fa... :confused:
A meno che a suo tempo non hanno chiaramente detto "ci vorranno 5 anni per sviluppare il gioco e per avere l'hw in grado di farlo girare", mi sembra solo (quello di 5 anni fa) un annuncio ad effetto. Molte ditte (non necessariamente di giochi) fanno annunci simili per oscuri motivi di marketing; a volte i sw "promessi" non vengono neanche mai realizzati...
Te la sentiresti _oggi_ di divulgare le caratteristiche di un gioco che potrete rilasciare solo tra 5 anni, senza avere idea di che tipo di hw sarà presente?
Correggimi se sbaglio

fek

04-08-2004, 15:36

Originariamente inviato da afterburner
Penso ilsensine si riferisca alle tecniche di marketing della ID di 5 anni fa ...

Infatti penso di aver capito male io :)

jappilas

04-08-2004, 15:38

Originariamente inviato da afterburner
Penso ilsensine si riferisca alle tecniche di marketing della ID di 5 anni fa ...

penso anch'io... anche perchè non mi pare la lionhead abbia creato hype intorno a BW2 , il che dimostra una discreta modestia e magiore serietà nel fare le cose (imho) ;)

fek

04-08-2004, 15:39

Originariamente inviato da ilsensine
Te la sentiresti _oggi_ di divulgare le caratteristiche di un gioco che potrete rilasciare solo tra 5 anni, senza avere idea di che tipo di hw sarà presente?
Correggimi se sbaglio

Non lo so, sono un programmatore non faccio marketing.
Il renderer di Doom 3 girava su GF3, nella sua forma di allora, quindi quell'intervista di Carmack, dal punto di vista puramente tecnologico, e' assolutamente condivisibile. Poi il renderer e' stato modificato per fare uso delle nuove caratteristiche delle GPU che sarebbero uscite. Non c'e' nulla di poco serio a mio avviso.

fek

04-08-2004, 15:41

Originariamente inviato da jappilas
penso anch'io... anche perchè non mi pare la lionhead abbia creato hype intorno a BW2 , il che dimostra una discreta modestia e magiore serietà nel fare le cose (imho) ;)

Parliamo d'altro va :D

afterburner

04-08-2004, 16:03

Originariamente inviato da fek
Non lo so, sono un programmatore non faccio marketing.
fekPuntiStima += 1000 :D :D
A volte me la prendo anche coi programmatori ... magari stavo cercando invano di compilare-correggere alcune zozzerie :muro: :muro:

cdimauro

04-08-2004, 20:58

Originariamente inviato da maxone78
E tu si sa che non sei un uomo (sessualmente parlando) :sofico: :oink:

Mmmhhhh, in questo caso l'oculista lo consiglio a te visto che non mi hai nemmeno riconosciuto, caro il mio "amicone perverso di Marco" ;)

Marco Fan Club -----> Melilli ;)
:sofico:

Ora mi riconosci? ;)
Porca £($/&%$"! Non avrei MAI immaginato che mi venissi a molestare anche qui!!!! :)

Scusate l'OT... :p

cdimauro

04-08-2004, 21:12

Originariamente inviato da afterburner
Non la considero una risposta .. qui ognuno rigira la torta come gli fa piu' comodo :D
OK, quindi abbiamo assodatao che non sei in grado di smentirla... :D
La dimostrazione Tesi .. Ipotesi .. CVD non riesco a dartela,
Ma come, prima dici pomposamente di esserne parecchio sicuro, e adesso ti tiri indietro? ;)
ma tu sicuramente non puoi falsificare la mia affermazione e quindi siamo punto e a capo.
Sicuro? Guarda, l'ho già dimostrato una volta che, proprio per il fatto che i sorgenti siano disponibili, un software open source può essere molto più insicuro di uno closed source. Fatti qualche ricerca nel forum su questo tema, e vedrai. ;)
Fek sta cercando di falsificare la mia (nostra) teoria sfruttando regole della eXtreme Programming ma la XP e' una teoria costruita su assiomi non dimostrabili (altrimenti non sarebbero assioni :))
Non puoi usare una teoria non dimostrata essere corretta per falsificarne un'altra :D
Difatti preferisco che sia fek a risponderti su questo tema (come ha già fatto... ;))
Yup! Che bei ricordi! A meno che non dimostrino che P=NP .. parecchio improbabile :) Comunque tra due algoritmi esponenziali, uno open e uno closed source, che mi risolvono il TSP o il ciclo hamiltoniano con esponente basso, preferisco quello open :D
OK, vedo che ti sei smentito da solo. ;)
Io ci riprovo ma non e' detto che ci riesca :D
RSA, algoritmo noto, craccabile se fattorizzi il prodotto di 2 numeri primi parecchio grandi (ti pagano pure!) vedi http://www.rsasecurity.com/rsalabs/node.asp?id=2093 lo si cracca per brute-force ma algoritmi rapidi per fattorizzare un numero non ci sono neancora ( senno' ricadremmo in P=NP )
Benissimo, e fin qui non ci sono problemi: hai enunciato il problema. :)
Kernel Linux, sorgenti noti e scaricabili .. quanta gente pensi se li sia studiati per riuscire a trovare una debolezza, magari causare anche un solo DoS, trovare la forma di quel pacchetto IP che inchioda netfilter-iptables? Non ti da' soldi ma punti stima nel mondo hacker .. secondo me parecchi ci provano e chi trova qualcosa di solito invece di sfruttarla comunica il bug ai maintainers.
OK, adesso ci siamo: spiegami il nesso fra questo e il fatto che un algoritmo come RSA sia più sicuro se è open anziché closed source.
Windows, sorgenti noti all'interno di MS .. ci sara' sicuramente chi cerca bugs ma il numero sara' sicuramente di tanto inferiore a quello di chi analizza il codice di Linux.
Anche questo non ha nulla a che vedere con la sicurezza degli algoritmi di crittazione. ;)
E tra l'altro, non conoscendo il modus operandi di chi lavora dentro MS, non puoi certo quantizzare e qualificare il lavoro di ricerca dei bug. Indi per cui, un confronto con ciò avviene con la piattaforma Linux non è possibile. :D
A questo punto interviene fek che dice "meglio pochi sapientoni che tanti lamer" ... non mi convince, nessun lamer sa completamente zero ;)
Hai ragione: in genere ne sanno meno di zero, perché spesso producono dei disastri... ;)

OK, bella discussione, ma mi sembra che sei un po' arrugginito quanto a dimostrazioni... :D

afterburner

05-08-2004, 09:24

Ma come, prima dici pomposamente di esserne parecchio sicuro, e adesso ti tiri indietro?

Ci sono cose di cui si puo' essere sicuri ma non dimostrabili con metodogia tesi-ipotesi-cvd .. la metodologia per dimostrare la sicurezza di un sistema informatico comprende anche la statistica e le statistiche sono a favore dei sistemi server open-source.

Sicuro? Guarda, l'ho già dimostrato una volta che, proprio per il fatto che i sorgenti siano disponibili, un software open source può essere molto più insicuro di uno closed source. Fatti qualche ricerca nel forum su questo tema, e vedrai.
MIO DIO!!! Senti, dopo questa non me la sento di continuare la discussione ...
rieccomi .. e invece continuo!

OK, vedo che ti sei smentito da solo.

EHHHH??? Spiegami dove mi sono smentito ..

OK, adesso ci siamo: spiegami il nesso fra questo e il fatto che un algoritmo come RSA sia più sicuro se è open anziché closed source.

Non sto parlando dell'implementazione dell'algoritmo! Sto parlando dell'algoritmo stesso! Ci sono programmi di cifratura che usano algoritmi non pubblici e si credono sicuri perche' l'algoritmo e' segreto .. ci sono programmi di cifratura (tipo openssl o pgp) che usano algoritmi pubblici e sono sicuri perche' l'algoritmo puo' essere studiato da chiunque.
Quelli con algoritmo segreto usano algoritmi da dilettanti e con un po' di debugging scopri che fa un po' di xor, scopri l'algoritmo e scopri il punto debole. RSA non ha punti deboli.
Il discorso e' analogo per il software opensource .. l'analogia con i software di cifratura e' algoritmo<->sorgente
Sorgente close = security by obscurity
Sorgente open = tutti lo possono analizzare e far notare i bug di sicurezza
Se non capisci neancora, prendi il tuo certificato di laurea, riportalo all'universita' dove te l'han dato e di' loro che non sei degno di possederlo :D

cionci

05-08-2004, 20:25

A parte l'ultima frase sono completamente d'accordo con afterburner...

DioBrando

05-08-2004, 20:38

mi sn perso qlc pagina...morale della favola chi è contro l'open source ( sviluppo in generale e sicurezza?) :huh:

cdimauro

06-08-2004, 06:05

Originariamente inviato da afterburner
Ci sono cose di cui si puo' essere sicuri ma non dimostrabili con metodogia tesi-ipotesi-cvd ..
Il mondo è pieno di assiomi e postulati, ma hanno motivo di esistere.
la metodologia per dimostrare la sicurezza di un sistema informatico comprende anche la statistica
Anche, vuol dire ne esistono altre: quali sono?
e le statistiche sono a favore dei sistemi server open-source.
I numeri forse, ma non le statistiche... ;)
MIO DIO!!! Senti, dopo questa non me la sento di continuare la discussione ...
rieccomi .. e invece continuo!
Benissimo. Ritorniamo al discorso. Tu hai scritto: "La sicurezza di un software openSource e' proprio data dal fatto che chiunque puo' leggere i sorgenti e le cappelle vengono fuori."
Hai detto sopra che ci sono cose che non si possono dimostrare, pur essendone sicuri. Bene. In questo caso sarebbe abbastanza difficile: dovresti provare che qualunque sistema open source è sicuro (per i motivi che hai esposto). Per smontare la tua affermazione, invece, basta trovare almeno un esempio per cui non sia verificata: MOLTO più semplice, indubbiamente.
A questo punto costruire un esempio che non soddisfi la tua tesi si tratta di un puro esercizio di logica. Riesci ad arrivarci da solo, o preferisci che ti spiatelli la prima soluzione che mi passa per la testa? ;)
EHHHH??? Spiegami dove mi sono smentito ..
E fortuna che avevo usato il grassetto per evidenziarlo... :rolleyes: Comunque, te lo scrivo dopo...
Non sto parlando dell'implementazione dell'algoritmo! Sto parlando dell'algoritmo stesso! Ci sono programmi di cifratura che usano algoritmi non pubblici e si credono sicuri perche' l'algoritmo e' segreto .. ci sono programmi di cifratura (tipo openssl o pgp) che usano algoritmi pubblici e sono sicuri perche' l'algoritmo puo' essere studiato da chiunque.
Quelli con algoritmo segreto usano algoritmi da dilettanti e con un po' di debugging scopri che fa un po' di xor, scopri l'algoritmo e scopri il punto debole. RSA non ha punti deboli.
Ecco, finalmente ci sei arrivato: è l'algoritmo la chiave di tutto, non il fatto che sia pubblico o privato. Se riesco a dimostrare che un algoritmo è NP-Completo, che sia reso pubblico o no, non intaccherà MAI la sua sicurezza. Lo posso benissimo tenere nascosto e dormire ugualmente sonni tranquilli, perché tanto con cambierebbe niente. ;)
Il discorso e' analogo per il software opensource .. l'analogia con i software di cifratura e' algoritmo<->sorgente
Sorgente close = security by obscurity
Sorgente open = tutti lo possono analizzare e far notare i bug di sicurezza
Vedi, a parte il discorso di cui sopra, che già basta a mettere un muro di separazione fra le due cose, il problema è che non è assolutamente provato che il fatto che un sorgente sia pubblico garantisca automaticamente che vengano fatti notare i bug di sicurezza. Come non è provato che di un sorgente chiuso non si possano trovare efficacemente i bug di sicurezza.
Se non capisci neancora, prendi il tuo certificato di laurea, riportalo all'universita' dove te l'han dato e di' loro che non sei degno di possederlo :D
Vediamo se riesci a capire tu, invece, come stanno i termini della questione: mi sembra che la sicurezza che ostentavi all'inizio vacilli non poco. ;)
L'università e i titoli lasciali stare: io non li ho tirati in ballo, perché non ne ho avuto bisogno. Sarebbe un segno di debolezza: meglio affidarsi ai fatti e alla logica... ;)

cdimauro

06-08-2004, 06:07

Originariamente inviato da DioBrando
mi sn perso qlc pagina...
Anche troppe. :D
morale della favola chi è contro l'open source ( sviluppo in generale e sicurezza?) :huh:
Chi, io? Sono sempre stato a favore... :asd:

afterburner

06-08-2004, 09:49

Originariamente inviato da cdimauro
Il mondo è pieno di assiomi e postulati, ma hanno motivo di esistere.

Mumble mumble .. non mi hai convinto. Comunque un assioma non e' dimostrabile e partendo da assiomi diversi arrivi a teorie diverse: nel campo dei reali 1+1=2 .. se crei un campo (nel senso di corpo commutativo) a 2 elementi che soddisfi tutti gli assiomi per essere definito campo algebrico hai che 1+1=0 :D

Hai detto sopra che ci sono cose che non si possono dimostrare, pur essendone sicuri. Bene. In questo caso sarebbe abbastanza difficile: dovresti provare che qualunque sistema open source è sicuro (per i motivi che hai esposto). Per smontare la tua affermazione, invece, basta trovare almeno un esempio per cui non sia verificata: MOLTO più semplice, indubbiamente.
A questo punto costruire un esempio che non soddisfi la tua tesi si tratta di un puro esercizio di logica. Riesci ad arrivarci da solo, o preferisci che ti spiatelli la prima soluzione che mi passa per la testa? ;)

Impossibile provare che qualsiasi sistema OS e' sicuro .. nulla da eccepire. Nel termine sistema includo anche il fattore umano sysman e users quindi se il sys e' un pippone il sistema sara' sicuramente meno sicuro di un sistema server windows dove il sys ha i controcoglioni .. questo l'avevo gia' detto all'inizio del thread.
Resto dell'idea che a parita' di skillness dei sysman, un sistema server basato su linux e' piu' sicuro.

E fortuna che avevo usato il grassetto per evidenziarlo... :rolleyes: Comunque, te lo scrivo dopo...

Ma lo sai che browser uso? Lo usava Alan Turing :D:D
Cmq adesso ho visto ..
"tra due algoritmi esponenziali .. preferisco quello open"
Sono entrambi esponenziali ovviamente e non mi sembra di smentirmi .. Preferisco un algoritmo che posso analizzare io ed il mondo matematico piuttosto di uno closed che magari han sbagliato a dimostrare essere NP oppure lo e' solo per un sottoinsieme di casi

Ecco, finalmente ci sei arrivato: è l'algoritmo la chiave di tutto, non il fatto che sia pubblico o privato. Se riesco a dimostrare che un algoritmo è NP-Completo, che sia reso pubblico o no, non intaccherà MAI la sua sicurezza. Lo posso benissimo tenere nascosto e dormire ugualmente sonni tranquilli, perché tanto con cambierebbe niente. ;)

In parte ti ho risposto sopra .. quanti matematici hai assoldato per dimostrare che e' Nondeteterministic Polinomial? Ci sono algoritmi che dimostri essere NP in 4 passaggi, altri richiedono 4 pagine o 4 libri .. Sicuro sia veramente NP? Sicuro lo sia per tutte le possibili stringhe di input? Sicuro non ci sia un sottoinsieme di queste che lo porta ad essere P?
Piu' gente lo vede, piu' se lo studia il mondo scientifico, piu' ritengo sia sicuro .. RSA e' solo uno degli esempi

Vediamo se riesci a capire tu, invece, come stanno i termini della questione: mi sembra che la sicurezza che ostentavi all'inizio vacilli non poco. ;)

Mai vacilled!! Io sono sicuro di quello che dico e al di la' delle statistiche .. qua i server li gestisco io e so dove ci sono piu' rogne :D

L'università e i titoli lasciali stare: io non li ho tirati in ballo, perché non ne ho avuto bisogno. Sarebbe un segno di debolezza: meglio affidarsi ai fatti e alla logica... ;)
Pienamente ragione e ti chiedo scusa .. Se faccio quello che faccio non e' certo perche' sono ING. informatico ma perche' mi sono fatto il culo su libri e documentazione che a ingegneria non sanno neanche cosa sono (pero' gli studi hanno aiutato parecchio a velocizzare lettura e comprensione :D)

maxone78

06-08-2004, 10:24

Originariamente inviato da cdimauro
Porca £($/&%$"! Non avrei MAI immaginato che mi venissi a molestare anche qui!!!! :)

Scusate l'OT... :p
Ahahahaahaahahahaahah :yeah:
ciao Cesarone, ti aspetto sempre a casa mia :ubriachi:

PS: mi raccomando, comportati bene qui sul forum ;)

Scusate tutti anche me per l'OT
:p

DioBrando

06-08-2004, 10:41

Originariamente inviato da cdimauro
Anche troppe. :D

vabbè quando torno dalle vacanze definitivamente :cry:, rileggerò con + accuratezza :D

Chi, io? Sono sempre stato a favore... :asd:

:muro::D

non dispongo di conoscenze/nozioni/esperienza così profonde da rispondere punto per punto alle obiezioni proposte da te e da fek ma mi limito a guardare quello che ho davanti.

Se davvero l'open source fosse una filosofia che non garantisce risultati all'altezza nè come sicurezza nè come riuscita di un qualsiasi applicativo allora dovremmo per forza di cose notare un netto dominio dei programmi closed src/proprietari in qualsiasi campo...e invece le cose n stanno così.

Apache domina il settore dei web servers, Firefox è un browser dalle caratteristiche sicuramente superiori a IE ( lo stop-popup integrato è sinonimo di sicurezza, l'assenza di pacchetti cumulativi di patch vuol dire che il prodotto è cmq riuscito abb bene a differenza del pari MS ecc...), Thunderbird idem nei confronti di Outlook e si potrebbe ancora andare avanti...

Se ci sn tutti questi ottimi progetti intorno a noi ( e ce ne sn parecchi, basta dare un'occhiata a sourgeforce.net o al già citato freshmeat), se ci sn persone che consapevolmente adottano Debian e l'OpenSSL, se ci sn AZIENDE che scelgono linux per i propri servers e altre cche investono miliardi su miliardi in questo modo di sviluppare non credo sia così facile bollare il tutto come un qlc di "poco sicuro" o "metodologia errata", altrimenti dovremmo dire per simmetria che tutte le persone prima citate sn degli idioti perchè non affidano le proprie sorti a un Windows a un IIS a un XXX...

Al di là dei sofismi tecnici e delle procedure + o - collaudate, l'esperienza dà una diversa visione delle cose...
Perchè se non è sempre vero che + teste sn meglio di una ( a volte il progetto può subire dei ritardi o entrare in st-by perchè vi è una confusione a livello organizzativo), non è nemmeno sempre vero che - persone, ma PAGATE e seguite a livello dirigenziale-manageriale, sfornino prodotti all'altezza della concorrenza e giustifichino magari il prezzo alto per l'utente finale.

Non considerare ciò che abbiamo davantial di là delle proprie preferenze è da persone miopi, non di mentalità aperta :rolleyes:

capito Cesarone? :asd:;)

cdimauro

07-08-2004, 05:47

Originariamente inviato da afterburner
Mumble mumble .. non mi hai convinto.
In cosa non t'avrei convinto?
Impossibile provare che qualsiasi sistema OS e' sicuro .. nulla da eccepire.
OK, quindi finalmente cade questa tesi. ;)
Nel termine sistema includo anche il fattore umano sysman e users quindi se il sys e' un pippone il sistema sara' sicuramente meno sicuro di un sistema server windows dove il sys ha i controcoglioni .. questo l'avevo gia' detto all'inizio del thread.
Bene, ma questo è un altro discorso, e intacca tanto Linux quanto Windows.
Resto dell'idea che a parita' di skillness dei sysman, un sistema server basato su linux e' piu' sicuro.
Possibile, ma rimane sempre un'opinione personale... ;)
Ma lo sai che browser uso? Lo usava Alan Turing :D:D
Quello scritto con la sua famosa macchina? :sofico:
Cmq adesso ho visto ..
"tra due algoritmi esponenziali .. preferisco quello open"
Sono entrambi esponenziali ovviamente e non mi sembra di smentirmi ..
Quindi sono egualmente "sicuri", è questo il punto.
Preferisco un algoritmo che posso analizzare io ed il mondo matematico piuttosto di uno closed che magari han sbagliato a dimostrare essere NP oppure lo e' solo per un sottoinsieme di casi
E' vero che può capire di sbagliare una dimostrazione (siamo pur sempre esseri umani :)), ma mi sembra obiettivamente difficile che gente di un certo calibro che lavora a roba come questa possa fallire in un esercizio che si risolve spesso in poco tempo.
Quando un algoritmo si ritiene NP-completo, è un po' come il profumo della primavera: lo senti nell'aria :); da lì a passare alla dimostrazione sarà soltanto una questione di tempo. ;)
In parte ti ho risposto sopra .. quanti matematici hai assoldato per dimostrare che e' Nondeteterministic Polinomial? Ci sono algoritmi che dimostri essere NP in 4 passaggi, altri richiedono 4 pagine o 4 libri .. Sicuro sia veramente NP? Sicuro lo sia per tutte le possibili stringhe di input? Sicuro non ci sia un sottoinsieme di queste che lo porta ad essere P?
Vedi sopra: se hai avuto modo di studiare/lavorarci, ti sei fatto un'idea di cosa voglia dire essere NP-Completo per un algoritmo; un'idea che ti permette di confrontare la complessità di un algoritmo con quella di un altro "candidato"; da lì alla dimostrazione formale non è che serva un'orda di matematici agguerriti. Questa branca dell'informatica sarà anche un po' ostica e poco conosciuta, ma è anche una delle più studiate dagli informatici, e da tempo.
Se all'università hai avuto modo di studiarla, avrai sicuramente visto tanti esempi di problemi NP-Completi, oltre a quelli che i professori sadicamente :asd: propinano agli studenti agli scritti con loro somma disperazione... :D
Piu' gente lo vede, piu' se lo studia il mondo scientifico, piu' ritengo sia sicuro .. RSA e' solo uno degli esempi
De gustibus. La mia opinione in questo ramo dell'informatica/matematica l'ho esposta chiaramente, e non credo di essere il solo a sostenerla... ;)
Mai vacilled!! Io sono sicuro di quello che dico e al di la' delle statistiche ..
Ehm. Anche sull'intrinseca sicurezza dei sistemi open source?. ;)
qua i server li gestisco io e so dove ci sono piu' rogne :D
OK. Questa non è materia su cui possa disquisire. ;)
Pienamente ragione e ti chiedo scusa .. Se faccio quello che faccio non e' certo perche' sono ING. informatico ma perche' mi sono fatto il culo su libri e documentazione che a ingegneria non sanno neanche cosa sono (pero' gli studi hanno aiutato parecchio a velocizzare lettura e comprensione :D)
Indubbiamente. Io ho coronato la mia esperienza universitaria dopo parecchi anni (meglio tardi che mai :asd: ), ma alle spalle ne avevo tanti altri passati a gironzolare fra i meandri di tanti sistemi... ;)

cdimauro

07-08-2004, 05:56

Originariamente inviato da DioBrando
vabbè quando torno dalle vacanze definitivamente :cry:, rileggerò con + accuratezza :D
OK. :)
:muro::D

non dispongo di conoscenze/nozioni/esperienza così profonde da rispondere punto per punto alle obiezioni proposte da te e da fek ma mi limito a guardare quello che ho davanti.
Puoi sempre rispondere solamente alle cose su cui ti senti di intavolare una discussione. :)
Se davvero l'open source fosse una filosofia che non garantisce risultati all'altezza nè come sicurezza nè come riuscita di un qualsiasi applicativo allora dovremmo per forza di cose notare un netto dominio dei programmi closed src/proprietari in qualsiasi campo...e invece le cose n stanno così.
Le argomentazioni di fek sono ben chiare in merito: non è possibile applicare alcune metodologie all'OSS. Personalmente, e l'ho già scritto, dal punto di vista formale non vedo differenze fra OSS e CSS, ma da quello pratico mi sembra che non esistano esempi a favore dell'OSS.
Ciò non dimostra che il CSS è migliore a priore: si "spaghetti software" di questo tipo il mondo ne è pieno, sfortunamente... :muro:
Se ci sn tutti questi ottimi progetti intorno a noi ( e ce ne sn parecchi, basta dare un'occhiata a sourgeforce.net o al già citato freshmeat), se ci sn persone che consapevolmente adottano Debian e l'OpenSSL, se ci sn AZIENDE che scelgono linux per i propri servers e altre cche investono miliardi su miliardi in questo modo di sviluppare non credo sia così facile bollare il tutto come un qlc di "poco sicuro" o "metodologia errata", altrimenti dovremmo dire per simmetria che tutte le persone prima citate sn degli idioti perchè non affidano le proprie sorti a un Windows a un IIS a un XXX...
Difatti la mia esperienza non porta certo a queste conclusioni, e da quel che ho scritto mi sembra che ciò traspaia, no? ;)
Al di là dei sofismi tecnici e delle procedure + o - collaudate, l'esperienza dà una diversa visione delle cose...
Perchè se non è sempre vero che + teste sn meglio di una ( a volte il progetto può subire dei ritardi o entrare in st-by perchè vi è una confusione a livello organizzativo), non è nemmeno sempre vero che - persone, ma PAGATE e seguite a livello dirigenziale-manageriale, sfornino prodotti all'altezza della concorrenza e giustifichino magari il prezzo alto per l'utente finale.
Indubbiamente. Vedi sopra. ;)
Non considerare ciò che abbiamo davantial di là delle proprie preferenze è da persone miopi, non di mentalità aperta :rolleyes:

capito Cesarone? :asd:;)
Io sì, e da tempo. ;) Rileggiti bene il thread, e poi eventualmente ne riparliamo... :)

x max: ok, faccio il bravo. Appena possibile passo a trovarti e a prendermi qualche infarto a Silent Hill 4... :eek: :D