Discussione:
[EMBEDDED] Sul caso Toyota...
(troppo vecchio per rispondere)
Capoccetta
2010-02-05 07:30:54 UTC
Permalink
...e l'affidabilità del software:

http://www.edn.com/blog/1690000169/post/630052463.html?nid=3351&rid=350389

un pò tecnico ma interessante, anche i commenti dei lettori
Marcoxxx
2010-02-05 09:39:21 UTC
Permalink
Capoccetta ha scritto:

> ....e l'affidabilità del software:

> http://www.edn.com/blog/1690000169/post/630052463.html?nid=3351&rid=350389

> un pò tecnico ma interessante, anche i commenti dei lettori


Intanto direi che e' interessante proprio perche' e' un po' tecnico :-).

Non ho il tempo di leggere le risposte dei lettori ma
mi vengono in mente alcune considerazioni in ordine sparso:

1 - Quando io scrivo i test case (e' una delle mie maggiori occupazioni
degli ultimi anni), aggiungo *sempre* nell' header o nel footer del
documento

"Program testing can be used to show the presence of bugs, but never to
show their absence!" (Dijkstra)"

Ma tanto non lo capiscono. E non lo capiscono perche' ragionano
"da imprenditori" e non "da tecnici".

"Sono stati fatti i test funzionali ?" Si'.
"Hanno rivelato malfunzionamenti ?" No

"Allora il software e' a posto!".

Ma chiunque non abbia conoscenze informatiche derivanti solo da
smanettamenti vari che la risposta dovrebbe essere "a posto una s**a!!"

Ma se lo vai a dire in azienda... in azienda ovviamente non si dice e se
lo dici tu sei lo s***o ingegnere che pensa di essere ganzo solo lui
perche' e' laureato mentre io sono il programmatore figo che ho imparato
sul campo
e magari ho fatto anche i soldi (magari mettendo su una b.r.) e quindi io
sono piu' esperto informatico di te (io la mia azienda informatica ce
l'ho, tu no: quindi io so cosa e' l'informatica!): io ho fatto un software
che ha passato i test quindi va bene e quindi mi devono pagare!!

2 - Concordo al 100% su

"There simply is no systematic approach to ensuring the quality of an
integrated hardware/software system."

And this is a tragedy."

Anzi, aggiungerei che non c'e' approccio "sistematico" nemmeno per
assicuraere la qualita' del software. O meglio l'approccio sistematico
c'e', solo che e' palesemente mancante di correttezza, sebbene rispetti
tutte le str***te previste dagli standard di qualita' dei processi.

3- "Thirty years ago (...) computer scientists such as Edsger Dijkstra
were making strides in methodology to create formally proven software. But
along came C, UNIX, and the cult of the bemused hobby programmer, and the
entire notion of formal correctness vanished under a smokescreen of
hacking.

So now, after decades invested in metrics-driven verification, formal
verification, and methodology management, we find that our chips don't
work as expected because the software is still being "verified" by feeding
it test cases until the schedule expires. And we find that our cars run
into things for the same reason, and the press of course will blame the
problem on "electronics.""

A me, da ex programmatore C con decennale esperienza dispiace ammetterlo,
ma credo che abbia ragione al 100%, anche se, per quel poco che ne so io,
non e' che anche la progettazione elettronica presenti questi metodi
eccezionali dal punto di vista della verifica formale di correttezza.




4- "The only parties in this little comedy that have an interest in
actually improving the state of the art are the engineers, who won't be
consulted, and the victims, who will be silenced by the lawyers. How much
better for everyone if it were a principle of civil law that when it is
found that damage has been inflicted by a failure, all of the diagnostic
information determined by the vendor and by independent parties must be
placed in the public domain, and may not be used to assess or assign
damages."

Io approverei alla grande, ma no sarebbe "better for everyone". In primo
luogo non sarebbe meglio per gli avvocati e probabilmente non sarebbe
meglio nemmeno per molti imprenditori.

Pero' gli imprenditori (e probabilmente anche gli avvocati) ci fanno
crescere, gli ingegeri no.

" Such a notion might somewhat restrict the income opportunities of
litigators,"

Appunto: non sarebbe quindi "better for everyone"

" but it would unquestionably assist the engineering community in learning
from our mistakes."

Gli imprenditori, gli avvocati (e magari anche "i litigators") ci fanno
crescere. Gli engineers invece no!


Ciao,
Marco

--

questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ***@newsland.it
AleTV
2010-02-05 10:01:09 UTC
Permalink
"Marcoxxx" ha scritto nel messaggio news:hkgp09$h87$***@news.newsland.it...

> "Sono stati fatti i test funzionali ?" Si'.
> "Hanno rivelato malfunzionamenti ?" No
>
> "Allora il software e' a posto!".
>
> Ma chiunque non abbia conoscenze informatiche derivanti solo da
> smanettamenti vari che la risposta dovrebbe essere "a posto una s**a!!"
>

Sempre un passo avanti rispetto a:
"Ma compila senza errori?" Si.
"Allora il sw è a posto!"
Capoccetta
2010-02-05 13:50:14 UTC
Permalink
On 5 Feb, 10:39, ***@web.de (Marcoxxx) wrote:

>

>
> "There simply is no systematic approach to ensuring the quality of an
> integrated hardware/software system."
>
> And this is a tragedy."
>
> Anzi, aggiungerei che non c'e' approccio "sistematico" nemmeno per
> assicuraere la qualita' del software. O meglio l'approccio sistematico
> c'e', solo che e' palesemente mancante di correttezza, sebbene rispetti
> tutte le str***te previste dagli standard di qualita' dei processi.

In realtà in alcuni settori molto specifici come credo l'aerospaziale
ho letto che stanno cercando di arrivare al punto di far generare il
software automaticamente da una specie di CAD utilizzabile
direttamente dal progettista, senza intermediazione di programmatori;
tempo fa avevo letto un articolo su una delle riviste di cui ogni
tanto posto i link, ipotizzavano che in seguito la cosa si potesse
estendere ad altri settori dell'embedded meno di punta.
>

>
> A me, da ex programmatore C con decennale esperienza dispiace ammetterlo,
> ma credo che abbia ragione al 100%, anche se, per quel poco che ne so io,
> non e' che anche la progettazione elettronica presenti questi metodi
> eccezionali dal punto di vista della verifica formale di correttezza.

Però per la progettazione elettronica esistono delle prove oggettive:
EMC, sicurezza elettrica (che in realtà a loro volta possono essere
inficiate da problemi del firmware); l'equivalente per il software non
credo esista.
ispas
2010-02-06 13:55:39 UTC
Permalink
On 5 Feb, 10:39, ***@web.de (Marcoxxx) wrote:
> "Program testing can be used to show the presence of bugs, but never to
> show their absence!"  (Dijkstra)"

Certo che la frase è specialmente vera fino a quando il software è
scritto con linguaggi rudimentali, dal punto di vista del controllo
formale di correttezza. Confronta C, C++, Java/C#, Python, VB, ecc.
con Haskell od Ada (ma anche parzialmente Pascal, su scala più
ridotta).
lowcost
2010-02-06 21:41:09 UTC
Permalink
Il 05/02/2010 10.39, Marcoxxx ha scritto:
> "Program testing can be used to show the presence of bugs, but never to
> show their absence!" (Dijkstra)"

sembra molto logico, ma non e' del tutto vero: se ogni singola funzione
viene testata al 100%, con tutte le possibili combinazioni di dati in
ingresso, il baco non puo' scappare; se pero' ci si affida ad un test
funzionale complessivo e incompleto..

> "There simply is no systematic approach to ensuring the quality of an
> integrated hardware/software system."
>
> And this is a tragedy."
>
> Anzi, aggiungerei che non c'e' approccio "sistematico" nemmeno per
> assicuraere la qualita' del software. O meglio l'approccio sistematico
> c'e', solo che e' palesemente mancante di correttezza, sebbene rispetti
> tutte le str***te previste dagli standard di qualita' dei processi.

eppure esistono intorno a noi apparecchi safety critical che funzionano
bene, senza farsi notare, senza difetti, senza causare danni o perdita
di vite umane; il software, in particolare, e' costruito sulla base di
normative, che definiscono esattamente i metodi per ottenere software
sicuro; questo in modo indipendente dal linguaggio. [es IEC60730]

> 3- "Thirty years ago (...) computer scientists such as Edsger Dijkstra
> were making strides in methodology to create formally proven software. But
> along came C, UNIX, and the cult of the bemused hobby programmer, and the
> entire notion of formal correctness vanished under a smokescreen of
> hacking.
>
> So now, after decades invested in metrics-driven verification, formal
> verification, and methodology management, we find that our chips don't
> work as expected because the software is still being "verified" by feeding
> it test cases until the schedule expires. And we find that our cars run
> into things for the same reason, and the press of course will blame the
> problem on "electronics.""
>
> A me, da ex programmatore C con decennale esperienza dispiace ammetterlo,
> ma credo che abbia ragione al 100%, anche se, per quel poco che ne so io,
> non e' che anche la progettazione elettronica presenti questi metodi
> eccezionali dal punto di vista della verifica formale di correttezza.

ma se anche fosse, la correttezza formale non garantisce affatto la
correttezza funzionale.

> 4- "The only parties in this little comedy that have an interest in
> actually improving the state of the art are the engineers, who won't be
> consulted, and the victims, who will be silenced by the lawyers. How much
> better for everyone if it were a principle of civil law that when it is
> found that damage has been inflicted by a failure, all of the diagnostic
> information determined by the vendor and by independent parties must be
> placed in the public domain, and may not be used to assess or assign
> damages."

rendere accessibile ai concorrenti tutta quella tecnologia costosa e
vitale ? non avverra' mai.


tornando ad un aspetto del problema, che era formalmente corretto:

"With the software fix, if the throttle is depressed and you step on
the brake, the electronics will say, "The driver wants to stop more
than he wants to go ahead, so we'll cut off the engine,'" Cole said.

cioe' era: freno + acceleratore = acceleratore


infine, questo e' sacrosanto, ma sistematicamente ignorato:

Fault tolerant design focuses on keeping the system running or safe in
spite of failures. These techniques are commonly applied in high value
designs where people’s lives are at stake (like airplanes, space ships,
and automobiles), but there are techniques that can be applied at even
lesser impact consumer level designs. [robertcravotta]


saluti
--
lowcost
equinozio
2010-02-06 22:06:02 UTC
Permalink
> sembra molto logico, ma non e' del tutto vero: se ogni singola funzione
> viene testata al 100%, con tutte le possibili combinazioni di dati in
> ingresso, il baco non puo' scappare;  se pero' ci si affida ad un test
> funzionale complessivo e incompleto..

Non è del tutto vero neppure questo : nei sistemi complessi
semplicemente non puoi testare tutto. Le alternative sono inteligenza
artificiale, sistemi ridondanti, sistemi di sicurezza passiva ed
attiva.

> eppure esistono intorno a noi apparecchi safety critical che funzionano
> bene, senza farsi notare, senza difetti, senza causare danni o perdita
> di vite umane; il software, in particolare, e' costruito sulla base di

Io direi che ci sono molti apparecchi dove l'errore è tollerato o
gestito, più o meno accuratamente.

> normative, che definiscono esattamente i metodi per ottenere software
> sicuro;  questo in modo indipendente dal linguaggio.   [es IEC60730]

non conosco la normativa, ma conosco elettronica ed informatica, e
semplicemente non è possible fare sistemi hardware e software
complessi privi di errore.

Certo, se il software deve solo giocare a tetris ne puoi scriverne
uno molto sicuro. Ma se includi nel sistema l'hardware di esecuzione e
quello di interfaccia le cose cambiano, e realizzare un braccio robot
che fa una cosa semplice come giocare a tetris sempre senza sbagliare
la vedo, a oggi, impossibile.

[cut]
STeve
2010-02-07 00:05:39 UTC
Permalink
On Feb 6, 3:41 pm, lowcost <***@invalid.com> wrote:
> sembra molto logico, ma non e' del tutto vero: se ogni singola funzione
> viene testata al 100%, con tutte le possibili combinazioni di dati in
> ingresso, il baco non puo' scappare;  se pero' ci si affida ad un test
> funzionale complessivo e incompleto..

E' da poco che lavori vero ? :-)
E' il "sistema" che devi provare. Avere le singole funzioni testate
non copre ogni possibile interazione, anzi, ti da' un falso senso di
sicurezza.
Certo, e' positivo avere questo test fatto ma e' ben lontano
dall'essere sufficiente.
Been there, done that, got the t-shirt.

Si vede che non ci hai ancora sbattuto il naso :-)

> eppure esistono intorno a noi apparecchi safety critical che funzionano
> bene, senza farsi notare, senza difetti, senza causare danni o perdita
> di vite umane;

Non significa che non ci siano bachi.

> normative, che definiscono esattamente i metodi per ottenere software
> sicuro;  questo in modo indipendente dal linguaggio.   [es IEC60730]

Seee buona notte.
Il punto e' che non esistono sistemi di test esaustivi. Anzi, piu'
formalizzi e crei norme, piu' e' facile buttarci dentro "bachi"
trasversali.
Specialmente nel mondo embedded alla fine l'unica garanzia (che e' ben
poca cosa, concordo) e' l'esperienza dello sviluppatore, che negli
anni sbattendoci il grugno, ha imparato cosa fare e cosa NON fare e
perche'.
Ed e' una differenza enorme, vista tante volte.

Mi capita di trovare bachi in codice che gira da DECENNI, in ogni
possibile condizione. Eppure ne trovo ancora.
C'e' sempre quella condizione in piu' ... solo chi ha abbastanza
esperienza sa che il baco e' sempre in agguato e non abbassa MAI la
guardia.
Di sicuro chi ha esperienza non si affida ciecamente ai risultati di
un test, ma anzi ne inventa di nuovi e va oltre le norme e le regole.

> ma se anche fosse, la correttezza formale non garantisce affatto la
> correttezza funzionale.

Vero, ma aiuta e non poco.

> rendere accessibile ai concorrenti tutta quella tecnologia costosa e
> vitale ?     non avverra' mai.

E' ben per quello che i problemi continuano ad esistere.

C'ya
STeve
lowcost
2010-02-07 17:35:13 UTC
Permalink
Il 07/02/2010 1.05, STeve ha scritto:
> E' da poco che lavori vero ? :-)

magari, LOL.
al contrario, ho lavorato a sufficienza per questa vita ed ho smesso da
tempo: complimenti per la tua splendida perspicacia.

> Si vede che non ci hai ancora sbattuto il naso :-)

bravo, due tiri, due centri: ci ho sbattuto una ventina di anni fa.
e inizio a pensare che la tua presunzione possa compromettere
gravemente le tue valutazioni.

>> eppure esistono intorno a noi apparecchi safety critical che funzionano
>> bene, senza farsi notare, senza difetti, senza causare danni o perdita
>> di vite umane;
>
> Non significa che non ci siano bachi.

credi dunque che non possano esistere software senza bachi ?

>> normative, che definiscono esattamente i metodi per ottenere software
>> sicuro; questo in modo indipendente dal linguaggio. [es IEC60730]
>
> Seee buona notte.

e buongiorno anche a te, STeve : oggi e' una bella giornata.

> Il punto e' che non esistono sistemi di test esaustivi. Anzi, piu'
> formalizzi e crei norme, piu' e' facile buttarci dentro "bachi"
> trasversali.
> Specialmente nel mondo embedded alla fine l'unica garanzia (che e' ben
> poca cosa, concordo) e' l'esperienza dello sviluppatore, che negli
> anni sbattendoci il grugno, ha imparato cosa fare e cosa NON fare e
> perche'.
> Ed e' una differenza enorme, vista tante volte.

qui devo ammettere (e con piacere) che hai perfettamente ragione.

> Mi capita di trovare bachi in codice che gira da DECENNI, in ogni
> possibile condizione. Eppure ne trovo ancora.

come definisci un baco che non ha effetti negativi e non si manifesta ?

> C'e' sempre quella condizione in piu' ... solo chi ha abbastanza
> esperienza sa che il baco e' sempre in agguato e non abbassa MAI la
> guardia.
> Di sicuro chi ha esperienza non si affida ciecamente ai risultati di
> un test, ma anzi ne inventa di nuovi e va oltre le norme e le regole.

mai affidato ciecamente a nessuno, nemmeno ai compilatori e alle
librerie scritte da voialtri.

>> ma se anche fosse, la correttezza formale non garantisce affatto la
>> correttezza funzionale.
>
> Vero, ma aiuta e non poco.

certo, aiuta, ma e' quel poco che manca che ti frega sempre, vero ?

>> rendere accessibile ai concorrenti tutta quella tecnologia costosa e
>> vitale ? non avverra' mai.
>
> E' ben per quello che i problemi continuano ad esistere.

queste sono scuse: i problemi esistono a causa di progettisti che non
sono all' altezza della situazione; per un produttore che ha investito
pesantemente, e' un suicidio regalare al mondo il suo knowhow:
semplicemente non puo' farlo.


saluti
--
lowcost
STeve
2010-02-07 22:03:11 UTC
Permalink
On Feb 7, 11:35 am, lowcost <***@invalid.com> wrote:
> > E' da poco che lavori vero ? :-)
> magari, LOL.
[...]
> bravo, due tiri, due centri:  ci ho sbattuto una ventina di anni fa.
> e inizio a pensare che la tua presunzione possa compromettere
> gravemente le tue valutazioni.

Beh, valuta questo allora.
Uno che lavora da tanto e ha "sbattuto il muso" su questi problemi,
che salta fuori con frasi tipo " basta che la funzione sia testata
perche' il sistema sia senza difetti" o "ci sono apparati critici che
non hanno problemi" mi pone parecchi dubbi sulle capacita' tecniche di
tale persona.
Ci facevi decisamente una migliore figura dicendo che eri un novello.

> > Non significa che non ci siano bachi.
> credi dunque che non possano esistere software senza bachi ?

Sono un non credente di natura. Non "credo" in nulla, tantomeno che
esistano software senza bachi.
Puo' esistere un limite al campo di esistenza di un SW che limita la
possibilita' di situazioni critiche, cosi' da avere meno probabilita'
di avere problemi SW. E' quello che si fa in embedded, si creano
policy di uso di strumenti, si limita l'interfaccia e si guida
l'utente il piu' possibile.
Ma scrivere un SW certicato al 100% senza bachi e' da ingenui totali o
commerciali.
IMHO i piu' pericolosi sono gli ingenui, i commerciali sanno di
vendere fuffa.

> e buongiorno anche a te, STeve :  oggi e' una bella giornata.

Anche qui. Ma e' un caso, non e' un SW che determina il bello o
cattivo tempo.

> qui devo ammettere (e con piacere) che hai perfettamente ragione.

Smentendoti cosi' ulteriormente :-)
Una persona con un minimo di esperienza di sviluppo SW non se ne esce
con certe affermazioni :-)

> > Mi capita di trovare bachi in codice che gira da DECENNI, in ogni
> > possibile condizione. Eppure ne trovo ancora.
> come definisci un baco che non ha effetti negativi e non si manifesta ?

Un baco "dormiente", ma la tua definizione e' inesatta.
Un baco HA per definizione effetti negativi, ovvero effetti non
previsti nel progetto del sistema.
Ergo un baco o si manifesta (e quindi HA effetti negativi) o non si
manifesta, ergo e' come se non ci fosse fino a quando si verificano le
condizioni giuste, e quindi non ha nessun effetto.

> mai affidato ciecamente a nessuno, nemmeno ai compilatori e alle
> librerie scritte da voialtri.

Sei un mio cliente ?

> > Vero, ma aiuta e non poco.
> certo, aiuta, ma e' quel poco che manca che ti frega sempre, vero ?

????

> queste sono scuse:  i problemi esistono a causa di progettisti che non
> sono all' altezza della situazione;

E' quello che ho detto.

>  per un produttore che ha investito
> pesantemente, e' un suicidio regalare al mondo il suo knowhow:
> semplicemente non puo' farlo.

C'e' modo e modo.
Il tuo lavoro non lo regali via di certo, ma puoi mettere in share la
tua esperienza.

C'ya
STeve
Luca Menegotto
2010-02-08 07:07:44 UTC
Permalink
STeve wrote:

> Sono un non credente di natura. Non "credo" in nulla, tantomeno che
> esistano software senza bachi.

Allora credi che non esistano software senza bachi!

Fratello!!

:-D


--
Ciao!
Luca
STeve
2010-02-08 15:03:47 UTC
Permalink
On Feb 8, 1:07 am, "Luca Menegotto" <***@CAVAMIyahoo.it>
wrote:
> Allora credi che non esistano software senza bachi!
> Fratello!!

:-) Ma ho gia' detto che "non credo", "so" che non esistono SW senza
bachi.
Ne sto avendo la prova proprio ora ... non senti le mega bestemmione
in Klingoniano stretto che sto inventando questo cazzo di lunedi'
mattina pure con la neve cosi' non si puo' andare in giro per calmare
i nervi ? :-)

Si', ocio che oggi e' giornata no, anzi, settimana no .. maro', mi
prendo le ferie dopo questa settimana !!!

:-)

C'ya
STeve
Alessandro Riolo
2010-02-08 17:51:30 UTC
Permalink
On 8 Feb, 07:07, "Luca Menegotto" <***@CAVAMIyahoo.it> wrote:
> Allora credi che non esistano software senza bachi!

In realtà l'uso del verbo "credere" è corretto, infatti i bachi
esistono solo se ci credi. Se non mi credi, prova a chiedere a
qualcuno a Microsoft, IBM vel similia, gli puoi portare tutte le prove
che vuoi, ma a meno che qualche sacerdote di grado gerarchico più
elevato nelle loro organizzazione ecclesiastiche non gli confermi che
quello che il cliente "erroneamente" ritiene sia un baco in uno dei
loro prodotti miracolosi, puoi letteralmente puntargli una lupara in
testa, preferirà il martirio piuttosto che ammetterlo. Al più sarà una
feature by design, divine design ovviamente ..

--
ale
http://ale.riolo.co.uk
lowcost
2010-02-08 19:19:02 UTC
Permalink
Il 07/02/2010 23.03, STeve ha scritto:
> Beh, valuta questo allora.
> Uno che lavora da tanto e ha "sbattuto il muso" su questi problemi,
> che salta fuori con frasi tipo " basta che la funzione sia testata
> perche' il sistema sia senza difetti" o "ci sono apparati critici che
> non hanno problemi" mi pone parecchi dubbi sulle capacita' tecniche di
> tale persona.

complimenti !
il virgolettato che riporti non corrisponde a quello che ho scritto.

io ho scritto che "se ogni singola funzione viene testata al 100%, con
tutte le possibili combinazioni di dati in ingresso, il baco non puo'
scappare" , per rimarcare che "non e' del tutto vero" che "Program
testing can be used to [...], but never to show their absence!".

e il fatto incontrovertibile che "esistono intorno a noi apparecchi
safety critical che funzionano bene, senza farsi notare, senza difetti,
senza causare danni o perdita di vite umane" e' la dimostrazione che e'
possibile scrivere software senza difetti, "costruito sulla base di
normative, che definiscono esattamente i metodi per ottenere software
sicuro" ; "in modo indipendente dal linguaggio" nel senso che non sono
necessari linguaggi specializzati.

> Ci facevi decisamente una migliore figura dicendo che eri un novello.

ma perche' dovrei dire le bugie ?

> Sono un non credente di natura. Non "credo" in nulla, tantomeno che
> esistano software senza bachi.

beh, se scrivi software, stai ammettendo che tutti i tuoi software sono
bacati.

> Puo' esistere un limite al campo di esistenza di un SW che limita la
> possibilita' di situazioni critiche, cosi' da avere meno probabilita'
> di avere problemi SW. E' quello che si fa in embedded, si creano
> policy di uso di strumenti, si limita l'interfaccia e si guida
> l'utente il piu' possibile.
> Ma scrivere un SW certicato al 100% senza bachi e' da ingenui totali o
> commerciali.

forse non sai che esistono software certificati: e' un organismo
notificato indipendente (ed ente omologante) che lo analizza e lo
certifica.

> IMHO i piu' pericolosi sono gli ingenui, i commerciali sanno di
> vendere fuffa.

devi avere qualche problema con i novelli_ingenui e con i commerciali.

>> e buongiorno anche a te, STeve : oggi e' una bella giornata.
>
> Anche qui. Ma e' un caso, non e' un SW che determina il bello o
> cattivo tempo.

io credo che potrebbe farlo, ma nel senso del benessere, non del tempo
atmosferico.

>> qui devo ammettere (e con piacere) che hai perfettamente ragione.
>
> Smentendoti cosi' ulteriormente :-)
> Una persona con un minimo di esperienza di sviluppo SW non se ne esce
> con certe affermazioni :-)

e questa tua, e' una di quelle affermazioni ?

>>> Mi capita di trovare bachi in codice che gira da DECENNI, in ogni
>>> possibile condizione. Eppure ne trovo ancora.
>> come definisci un baco che non ha effetti negativi e non si manifesta ?
>
> Un baco "dormiente", ma la tua definizione e' inesatta.
> Un baco HA per definizione effetti negativi, ovvero effetti non
> previsti nel progetto del sistema.

per definizione di chi ?

> Ergo un baco o si manifesta (e quindi HA effetti negativi) o non si
> manifesta, ergo e' come se non ci fosse fino a quando si verificano le
> condizioni giuste, e quindi non ha nessun effetto.

"e' come se non ci fosse" e' diverso da "non c'e' ".
un software pieno zeppo di bachi "dormienti" (nessun effetto negativo)
e' completamente diverso da un software senza bachi, non credi ?

>> mai affidato ciecamente a nessuno, nemmeno ai compilatori e alle
>> librerie scritte da voialtri.
>
> Sei un mio cliente ?

direi di no, e a questo punto non vorrei esserlo.

>>> Vero, ma aiuta e non poco.
>> certo, aiuta, ma e' quel poco che manca che ti frega sempre, vero ?
>
> ????

"aiuta e non poco" = aiuta tanto = tanto ma non tutto = manca poco.

>> queste sono scuse: i problemi esistono a causa di progettisti che non
>> sono all' altezza della situazione;
>
> E' quello che ho detto.

tu hai detto che "l'unica garanzia [...] e' l'esperienza dello
sviluppatore" , che "solo chi ha abbastanza esperienza sa che il baco
e' sempre in agguato e non abbassa MAI la guardia" , che "chi ha
esperienza non si affida ciecamente ai risultati di un test" , e che,
nonostante tutto questo, non esistono software senza bachi; insomma
dici che non esistono progettisti all' altezza della situazione.

io invece dico che un buon progettista (si, ne esistono) ha gli
strumenti per scrivere software senza bachi.

> Il tuo lavoro non lo regali via di certo, ma puoi mettere in share la
> tua esperienza.

se per "tua" intendi la "mia", ci ho provato qualche volta, ma spesso
l'interlocutore non capisce, ed ho la sgradevolissima sensazione di
essere inadeguato.


saluti
--
lowcost
Luca Menegotto
2010-02-08 19:59:05 UTC
Permalink
lowcost wrote:

> e il fatto incontrovertibile che "esistono intorno a noi apparecchi
> safety critical che funzionano bene, senza farsi notare, senza
> difetti, senza causare danni o perdita di vite umane" e' la
> dimostrazione che e' possibile scrivere software senza difetti,

No. Vuol dire solo che, fortunatamente, non si sono mai verificate le
condizioni perce' l'errore si manifesti. Per fortuna.

> forse non sai che esistono software certificati: e' un organismo
> notificato indipendente (ed ente omologante) che lo analizza e lo
> certifica.

Boni, quelli, se son tutti come quello (francese) che ho visto io.

:-D

> io invece dico che un buon progettista (si, ne esistono) ha gli
> strumenti per scrivere software senza bachi.

La mia - discreta - esperienza dice che i software assolutamente senza
buchi non esistono. A meno che tu non scriva "Hello world",
all'aumentare della complessità e della dimensione del software la
probabilità di presenza di buchi aumenta in modo geometrico, e per un
ovvio motivo: non è possibile fisicamente testare tutte le condizioni
che si possono verificare.


--
Ciao!
Luca
STeve
2010-02-08 21:32:41 UTC
Permalink
On Feb 8, 1:19 pm, lowcost <***@invalid.com> wrote:
> il virgolettato che riporti non corrisponde a quello che ho scritto.

Non ho riportato paro paro quello che hai detto ma il senso.

> io ho scritto che "se ogni singola funzione viene testata al 100%, con

Cosa che non e' possibile fare con qualsiasi funzione e anche cosi'
non tiene conto delle necessita' del sistema, che puo' dare o
richiedere valori che la funzione non e' progettata per fare.
Ovvero, il fatto che una funzione sia testata per ogni possibile
condizione (cosa gia' non applicabile nel mondo reale) non implica la
funzione sia esente da bachi. Guarda che non si parla solo di bachi a
livello formale.
UNa funzione puo' essere formalmente corretta e contenere bachi di
progettazione.
Sempre bacata rimane.

Ovvero quel test, come gia' detto, non garantisce la funzione sia
esente da bachi.

> e il fatto incontrovertibile che "esistono intorno a noi apparecchi
> safety critical che funzionano bene, senza farsi notare, senza difetti,

Provo a rispiegare.
Il fatto che non si manifestino bachi non e' assolutamente prova
della loro assenza.
Si adottano policy di uso e limiti nell'interfaccia per "ridurre" il
campo di funzionamento, limitando cosi' la possibilita' che il SW
operi in zone non testate o critiche. Ma devi sempre assumere il SW
possa avere problemi.

> senza causare danni o perdita di vite umane" e' la dimostrazione che e'

Tanto per rimanere nel tema del post, ad esempio la Prius (uno dei
modelli incriminati) e' in giro da un bel po' di anni e solo ora salta
fuori questo "problema".
Problema, nota bene, che non e' pandemico. Ovvero di proprietari di
Prius che hanno sperimentato il problema, ce ne saranno una decina si
e no su "milioni" di vetture.
Fino a un paio di settimane fa saresti stato uno dei tanti a dire che
"il SW delle Prius non ha bachi" ... e invece.
La soluzione finora adottata da Toyota e' di cambiare il pedale
dell'acceleratore, ma non perche' sia un problema "meccanico".
Cambiano quello per dare un migliore feedback al sensore controllato
dal pedale.
La modifica consiste nel montare una molla extra per garantire un
migliore feedback .. ovvero agiscono sulle condizioni di contorno, non
cambiano il SW.

> possibile scrivere software senza difetti, "costruito sulla base di
> normative, che definiscono esattamente i metodi per ottenere software
> sicuro" ;  "in modo indipendente dal linguaggio" nel senso che non sono
> necessari linguaggi specializzati.

Questa, perdonami, ma e' la tipica frase di un commerciale.
La realta' se ne fotte dei regolamenti e normative, ovvero ci sono
sempre troppe variabili e incognite perche' una normativa "garantisca"
una qualsiasi cosa.
E ci lavoro ogni giorno con normative. C'e' sempre spazio per
interpretazione.
Prendi una normativa, prendi 3 persone e avrai 3 interpretazioni.

> beh, se scrivi software, stai ammettendo che tutti i tuoi software sono
> bacati.

Scrivo software da 25 anni e non sono cosi' stupido o arrogante
(spesso le due cose vanno di pari passo) da dire che non commetto mai
errori.
Si', mi capita di inserire bachi nel codice, come TUTTI su questo
pianeta.
E spendo un bel po' di tempo per cercarli e risolverli.
Non esiste l'essere perfetto e superiore, nemmeno se segue alla
lettera qualche normativa di qualita'.
E nella mia carriera non ho mai (MAI) trovato qualcuno che non facesse
errori.
Mai.

> forse non sai che esistono software certificati:  e' un organismo
> notificato indipendente (ed ente omologante) che lo analizza e lo
> certifica.

Come no.
Hai mai omologato qualche sw ? Io si', spesso. Lasciamo perdere va',
che gli enti che devono certificare sono fatti da esseri umani, mica
da superuomini.
Hai idea delle volte che un SW certificato nella realta' non
funziona ?
E' pratica comune in tutto il mondo (ho certificato in tutto il mondo)
avere codici diversi, uno certificato e uno che funziona davvero.
Tra il dire e il fare c'e' di mezzo .. di tutto :)

> devi avere qualche problema con i novelli_ingenui e con i commerciali.

Indubbiamente. Mai fatto mistero.

> > Un baco HA per definizione effetti negativi, ovvero effetti non
> > previsti nel progetto del sistema.
> per definizione di chi ?

Evidentemente non la tua.
Per te i bachi sono una feature ? O un problema ?
Per me e tutti quelli che conosco (nel nostro campo lavorativo), un
baco e' un problema, un comportamento non previsto e deleterio.
Un difetto, un problema.

Se per ne non e' cosi', mi dai gentilmente la tua definizione di
baco ?

> "e' come se non ci fosse"  e' diverso da  "non c'e' ".

Uhm ok ... e allora ?

> un software pieno zeppo di bachi "dormienti" (nessun effetto negativo)
> e' completamente diverso da un software senza bachi, non credi ?

Concordo, ma rimane il fatto che un SW con bachi dormienti NON e'
esente da bachi, ovvero non puoi assumere sia "sicuro".
C'e' il rischio il baco si manifesti, in genere quando meno te lo
aspetti, per definizione (mia, contento ?).

> > Sei un mio cliente ?
> direi di no, e a questo punto non vorrei esserlo.

Ditto. Di clienti come te che vivono nel mondo dei sogni ne faccio a
meno, ne ho gia' troppi :-)
Noi si lavora nella realta' e si risolvono problemi reali, non
nascondendosi dietro un dito o una definizione.
Niente fuffaware dalle mie parti e abbastanza umilta' da ammettere che
si sbaglia.

> > ????
> "aiuta e non poco" = aiuta tanto = tanto ma non tutto = manca poco.

Non mi torna il significato rispetto la discussione .. va beh, lasa'
sta'

> tu hai detto che "l'unica garanzia [...] e' l'esperienza dello
[...]
> nonostante tutto questo, non esistono software senza bachi;  insomma
> dici che non esistono progettisti all' altezza della situazione.

Per nulla.
Ho detto che l'unica garanzia (condizione necessaria MA NON
sufficiente) e' l'esperienza e bravura del progettista.
Non ho assolutamente detto che non esistono progettisti all'altezza
della situazione.
Se applichi le normative come interpreti quello che scrivo, stiamo
freschi.

> io invece dico che un buon progettista (si, ne esistono) ha gli
> strumenti per scrivere software senza bachi.

Sicuramente sono troppo attento alla realta', non ho mai, MAI,
riscontrato quanto tu dici.
Anche perche' nel mondo reale servono risultati non in tempo infinito.
Puoi avere tutti gli strumenti del mondo, ma in genere manca sempre il
tempo.
Avendo strumenti adatti, specifiche chiare e tempo infinito, ammetto
che FORSE si potrebbe produrre un SW senza bachi.
Ma anche solo avere UNA delle tre condizioni soddisfatte (nel mondo
reale, non in quello immaginario) e' un terno al lotto.
Ergo produrre SW senza bachi lo ritengo altamente improbabile.

> se per "tua" intendi la "mia", ci ho provato qualche volta, ma spesso
> l'interlocutore non capisce, ed ho la sgradevolissima sensazione di
> essere inadeguato.

Andiamo bene :)

C'ya
STeve
Luca Menegotto
2010-02-09 06:57:35 UTC
Permalink
STeve wrote:

> La realta' se ne fotte dei regolamenti e normative, ovvero ci sono
> sempre troppe variabili e incognite perche' una normativa "garantisca"
> una qualsiasi cosa.

Aggiungo. Vi sono numerosi tentativi di normare il particolare,
soprattutto in Italia.
Il risultato è peggiore del male che si tenta di curare.

> Ho detto che l'unica garanzia (condizione necessaria MA NON
> sufficiente) e' l'esperienza e bravura del progettista.

In effetti anche qui concordo (sono preoccupato, Steve!). La brvura del
progettista sta nell'esperienza. Non è che sappia cosa fare per non
avere problemi, sa cosa NON fare per non averne.

> Avendo strumenti adatti, specifiche chiare e tempo infinito, ammetto
> che FORSE si potrebbe produrre un SW senza bachi.

Poi le specifiche cambiano in corso d'opera, il software deve essere
pronto per ieri, scopri buchi negli strumenti che usi (che a loro volta
possono averne)...

Cose già viste.


--
Ciao!
Luca
lowcost
2010-02-09 22:41:54 UTC
Permalink
Il 08/02/2010 22.32, STeve ha scritto:
> On Feb 8, 1:19 pm, lowcost<***@invalid.com> wrote:
>> io ho scritto che "se ogni singola funzione viene testata al 100%, con
>
> Cosa che non e' possibile fare con qualsiasi funzione e anche cosi'
> non tiene conto delle necessita' del sistema, che puo' dare o
> richiedere valori che la funzione non e' progettata per fare.
_____________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ma allora non era testata per il 100% ?

> Ovvero, il fatto che una funzione sia testata per ogni possibile
> condizione (cosa gia' non applicabile nel mondo reale) non implica la
> funzione sia esente da bachi. Guarda che non si parla solo di bachi a
> livello formale.

quali bachi vi possono essere, dopo il test 100% ?

> UNa funzione puo' essere formalmente corretta e contenere bachi di
> progettazione.
> Sempre bacata rimane.

e come ha superato il test ?

> Ovvero quel test, come gia' detto, non garantisce la funzione sia
> esente da bachi.

lo hai detto N volte: una funzione testata con TUTTE le possibili
condizioni di ingresso, puo' manifestare un baco con una ulteriore e
diversa condizione di ingresso.
mi hai quasi convinto.

> Si adottano policy di uso e limiti nell'interfaccia per "ridurre" il
> campo di funzionamento, limitando cosi' la possibilita' che il SW
> operi in zone non testate o critiche.
___________^^^^^^^^^^^^^^^^^^^^^^^^^^^


> Tanto per rimanere nel tema del post, ad esempio la Prius (uno dei
> modelli incriminati) e' in giro da un bel po' di anni e solo ora salta
> fuori questo "problema".
> Problema, nota bene, che non e' pandemico. Ovvero di proprietari di
> Prius che hanno sperimentato il problema, ce ne saranno una decina si
> e no su "milioni" di vetture.

8 milioni di richiami in totale, 2 milioni in europa; la Toyota ha
ricevuto più di duemila reclami per acceleratori mal funzionanti; le
prius prodotte in totale sono poco piu' di 1 milione.

> Fino a un paio di settimane fa saresti stato uno dei tanti a dire che
> "il SW delle Prius non ha bachi" ... e invece.

e invece no; parla per te.

> La soluzione finora adottata da Toyota e' di cambiare il pedale
> dell'acceleratore, ma non perche' sia un problema "meccanico".

non resta incastrato meccanicamente ?

> Cambiano quello per dare un migliore feedback al sensore controllato
> dal pedale.

migliore feedback con una molla ?

> La modifica consiste nel montare una molla extra per garantire un
> migliore feedback .. ovvero agiscono sulle condizioni di contorno, non
> cambiano il SW.

non lo cambiano ?
lasciano la priorita' all' acceleratore ?

> La realta' se ne fotte dei regolamenti e normative, ovvero ci sono
> sempre troppe variabili e incognite perche' una normativa "garantisca"
> una qualsiasi cosa.
> E ci lavoro ogni giorno con normative. C'e' sempre spazio per
> interpretazione.
> Prendi una normativa, prendi 3 persone e avrai 3 interpretazioni.

ma l' interpretazione deve essere accettata dall' ente omologante.

> Scrivo software da 25 anni e non sono cosi' stupido o arrogante
> (spesso le due cose vanno di pari passo) da dire che non commetto mai
> errori.
> Si', mi capita di inserire bachi nel codice, come TUTTI su questo
> pianeta.
> E spendo un bel po' di tempo per cercarli e risolverli.
> Non esiste l'essere perfetto e superiore, nemmeno se segue alla
> lettera qualche normativa di qualita'.
> E nella mia carriera non ho mai (MAI) trovato qualcuno che non facesse
> errori.
> Mai.

dicevi ? ah si, non sei arrogante.

> Hai mai omologato qualche sw ? Io si', spesso. Lasciamo perdere va',

si, ho omologato qualche sw, spesso; perche' lasciamo perdere ?

> che gli enti che devono certificare sono fatti da esseri umani, mica
> da superuomini.
> Hai idea delle volte che un SW certificato nella realta' non
> funziona ?
> E' pratica comune in tutto il mondo (ho certificato in tutto il mondo)
> avere codici diversi, uno certificato e uno che funziona davvero.
> Tra il dire e il fare c'e' di mezzo .. di tutto :)

questa si commenta da sola.

> Per te i bachi sono una feature ? O un problema ?
> Per me e tutti quelli che conosco (nel nostro campo lavorativo), un
> baco e' un problema, un comportamento non previsto e deleterio.
> Un difetto, un problema.
>
> Se per ne non e' cosi', mi dai gentilmente la tua definizione di
> baco ?

la stessa cosa, ma ci metterei anche quelli che "e' come se non ci
fosse" ; da qualche parte sono usciti, possono essere rimossi.

> Ditto. Di clienti come te che vivono nel mondo dei sogni ne faccio a
> meno, ne ho gia' troppi :-)
> Noi si lavora nella realta' e si risolvono problemi reali, non
> nascondendosi dietro un dito o una definizione.
> Niente fuffaware dalle mie parti e abbastanza umilta' da ammettere che
> si sbaglia.

dicevi ? ah si, non sei arrogante.


saluti
--
lowcost
STeve
2010-02-09 23:09:25 UTC
Permalink
On Feb 9, 4:41 pm, lowcost <***@invalid.com> wrote:
> dicevi ?     ah si, non sei arrogante.

Stavo quasi per rispondere civilmente, ma poi mi sono detto, perche'
devo sprecare tempo con un cazzone ?
Fanculo.
PLONK
STeve
2010-02-09 23:12:21 UTC
Permalink
On Feb 9, 4:41 pm, lowcost <***@invalid.com> wrote:
> dicevi ?     ah si, non sei arrogante.

Si' hai ragione. Colpa mia di non aver individuato il tipo subito e di
voler discutere seriamente.
Rimedio subito
PLONK
Marcoxxx
2010-02-09 09:43:05 UTC
Permalink
lowcost ha scritto:


> io ho scritto che "se ogni singola funzione viene testata al 100%, con
> tutte le possibili combinazioni di dati in ingresso, il baco non puo'
> scappare" , per rimarcare che "non e' del tutto vero" che "Program
> testing can be used to [...], but never to show their absence!".

Mi spieghi una cosa, visto che dici che hai anche avuto un'azienda
tua e che ti occupavi di embedded.

Io con l' embedded ci ho lavorato poco ma

la seguente semplicissima funzione come la testeresti ?

float somma(float a, float b)
{
return a+b;
}

*per ogni* valore di a e di b ? E se fossero double invece che
float ? Sempre per ogni valore ?

Poi, visto che si parlava di controllo dell' hardware saprati cosa può
accadere in termini di sincoronizzazione quando hai 10 task
diversi in multithreading, magari interrompibili da qualche interrupt
generato dall'hardware. E saprai cosa puo' accadere
se la temperatura dell' hardware sale oltre certi limiti o se per qualche
motivo, il sistema viene esposto a qualche radiazione (hint: fatto
realmente capitato a me al mio primo progetto. Il progetto era un
simulatore motociclistico, il quale doveva montare, tra le altre cose, un
motore meccanico che simulava le vibrazioni della moto: nel momento in cui
accendevi tale motore meccanico, questo generava un campo elettromagnetico
che ammazzava la LAN dedicata su cui dovevano viaggare i dati verso alcuni
sottosistemi [ad esempio verso il sottosistema acustico che doveva
simulare il rumore della moto]).

Saprai certamente che se anche hai testato esaustivamente tutte le
funzioni di ciascun singolo thread, la velocita' relativa di esecuzione
dei thread puo' introdurre malfunzionamenti di vario genere.

Come le testi le interazioni tra i task in multithreading ?

Certo esistono delle tecniche di programmazione in multithreading, ma
io per qualche anno mi sono posto il problema di come testare in modo
"formale" il sistema, senza riuscire a trovare una risposta
[SNIP]

> forse non sai che esistono software certificati: e' un organismo
> notificato indipendente (ed ente omologante) che lo analizza e lo
> certifica.

Io ho letto le normative CENELEC a suo tempo (molto tempo fa, per cui
magari ricordo male). A me non pareva che ci fosse
*niente* che potesse evitare bugs (tra l'altro si parlava di diverse
"categorie" di software a seconda della durata continuativa che doveva
sopportare e della "probabilita' di malfunzionamenti" che doveva essere
evitata; se non sbaglio al massimo ti certificava che il tuo sofware
rientrava nella "categoria X" dove categoria X significava che il tuo
software era in grado di funzionare per N ore con una probabilita' di
malfunzionamenti < epsilon, non ti certificava che il software era "esente
da malfunzionamenti".

Se poi ti interessa, le aziende "non embedded" il software lo certificano
anche dopo che ha passato i test funzionali che progetto io (e che non
sono ne' esaustivi ne' particolarmente 'stressanti')

> io invece dico che un buon progettista (si, ne esistono) ha gli
> strumenti per scrivere software senza bachi.

E io dico, senza tema di smentita, che chiunque affermi seriamente quanto
sopra, di informatica non ha mai capito una mazza nella vita, nemmeno se
ha avuto 300 aziende ognuna delle qualli gli ha fruttato 800 miliardi di
euro al microsecondo.

Anzi, personalmente ho come l'impressione che uno possa
avere aziende che gli fruttano molti soldi, solo se di informatica non
capisce propriamente tanto.


Ciao,
Marco

--

questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ***@newsland.it
lowcost
2010-02-09 22:41:33 UTC
Permalink
Il 09/02/2010 10.43, Marcoxxx ha scritto:
> la seguente semplicissima funzione come la testeresti ?
>
> float somma(float a, float b)
> {
> return a+b;
> }
>
> *per ogni* valore di a e di b ? E se fossero double invece che
> float ? Sempre per ogni valore ?

se la usi in funzioni di sicurezza, si.
se puo' tranquillizzarti, non sei obbligato a farlo a manina.

> Saprai certamente che se anche hai testato esaustivamente tutte le
> funzioni di ciascun singolo thread, la velocita' relativa di esecuzione
> dei thread puo' introdurre malfunzionamenti di vario genere.

solo se non hai previsto un meccanismo di controllo (testato); credo
che safeRTOS, per dirne uno, lo faccia.

> *niente* che potesse evitare bugs (tra l'altro si parlava di diverse
> "categorie" di software a seconda della durata continuativa che doveva
> sopportare e della "probabilita' di malfunzionamenti" che doveva essere
> evitata; se non sbaglio al massimo ti certificava che il tuo sofware
> rientrava nella "categoria X" dove categoria X significava che il tuo
> software era in grado di funzionare per N ore con una probabilita' di
> malfunzionamenti< epsilon, non ti certificava che il software era "esente
> da malfunzionamenti".

ti riferisci ai livelli SIL ? ci sono altre normative che definiscono
il numero di guasti indipendenti che possono avvenire senza
compromettere il funzionamento sicuro.

> E io dico, senza tema di smentita, che chiunque affermi seriamente quanto
> sopra, di informatica non ha mai capito una mazza nella vita, nemmeno se

ti sei spiegato benissimo.


saluti
--
lowcost
rootkit
2010-02-07 22:43:15 UTC
Permalink
Il Sun, 07 Feb 2010 18:35:13 +0100, lowcost ha scritto:



> come definisci un baco che non ha effetti negativi e non si manifesta ?

una mina vagante.
Renaissance
2010-02-08 07:23:53 UTC
Permalink
lowcost ha scritto:

>> E' da poco che lavori vero ? :-)

> magari, LOL.
> al contrario, ho lavorato a sufficienza per questa vita ed ho smesso da
> tempo: complimenti per la tua splendida perspicacia.

>> Si vede che non ci hai ancora sbattuto il naso :-)

> bravo, due tiri, due centri: ci ho sbattuto una ventina di anni fa.
> e inizio a pensare che la tua presunzione possa compromettere
> gravemente le tue valutazioni.

Guarda che Steve lavora nell'embedded da un po', e quindi parla con
cognizione di causa.

bye G.L.
--
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen
lowcost
2010-02-08 19:24:07 UTC
Permalink
Il 08/02/2010 8.23, Renaissance ha scritto:
> lowcost ha scritto:
>
>> magari, LOL.
>> al contrario, ho lavorato a sufficienza per questa vita ed ho smesso da
>> tempo: complimenti per la tua splendida perspicacia.
>
>> bravo, due tiri, due centri: ci ho sbattuto una ventina di anni fa.
>> e inizio a pensare che la tua presunzione possa compromettere
>> gravemente le tue valutazioni.
>
> Guarda che Steve lavora nell'embedded da un po', e quindi parla con
> cognizione di causa.

ok, non conosco STeve e non mi interessa fare a chi ce l' ha ...

ho lavorato nell' embedded per 22 anni, dei quali gli ultimi 14 su
prodotti omologati failsafe (con HW e SW di sicurezza, per applicazioni
safety critical); poi ho venduto la fabbrichetta e mi sono pensionato.

forse STeve e' un espertone, ma un pochino ne capisco anch' io:
altrimenti, non si spiegano i risultati numerici ed economici.


saluti
--
lowcost
Renaissance
2010-02-09 07:43:50 UTC
Permalink
lowcost ha scritto:

>> Guarda che Steve lavora nell'embedded da un po', e quindi parla con
>> cognizione di causa.

> ok, non conosco STeve e non mi interessa fare a chi ce l' ha ...

Beh, se scrivi:

> al contrario, ho lavorato a sufficienza per questa vita ed ho smesso
> da tempo:

E non mi sembra che farti notare che parli con una persona "che ha
competenza *tecnica* sul campo sia giocare a chi c'e' l'ha piu' lungo.
Forse attribuisci agli altri le tue intenzioni, a mo' di specchio
riflesso, chissa'... (*)

> ho lavorato nell' embedded per 22 anni, dei quali gli ultimi 14 su
> prodotti omologati failsafe (con HW e SW di sicurezza, per
> applicazioni safety critical); poi ho venduto la fabbrichetta e mi
> sono pensionato.

Ok, ok, come dire: se vendo le macchinette del caffe', mi posso
ritenere un profondo conoscitore dei piu' reconditi particolari
tecnici delle medesime? Il punto e' sapere di che tipo di esperienza
parli. Di sviluppo sul campo in prima linea? Non sembra, da quel che
affermi nei vari post...

> forse STeve e' un espertone, ma un pochino ne capisco anch' io:
> altrimenti, non si spiegano i risultati numerici ed economici.

Vedi (*)

bye G.L.
--
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen
lowcost
2010-02-09 17:25:37 UTC
Permalink
Il 09/02/2010 8.43, Renaissance ha scritto:
> lowcost ha scritto:
>> ok, non conosco STeve e non mi interessa fare a chi ce l' ha ...

se non hai capito, questa e' la prefazione ai dati personali seguenti,
che avrei preferito non pubblicare, e non accadra' piu'.

>> al contrario, ho lavorato a sufficienza per questa vita ed ho smesso
>> da tempo:

e chiaramente, questa era la risposta a:

>>> E' da poco che lavori vero ? :-)

> Ok, ok, come dire: se vendo le macchinette del caffe', mi posso
> ritenere un profondo conoscitore dei piu' reconditi particolari
> tecnici delle medesime?

mai fatto il venditore.


saluti
--
lowcost
Renaissance
2010-02-11 15:31:31 UTC
Permalink
lowcost wrote:

> mai fatto il venditore.

A costo di provocare, anticipo una risposta che non hai dato: immagino
neanche lo sviluppatore. Perlomeno, non in modo professionale.

bye G.L.
--
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen
lowcost
2010-02-11 21:55:47 UTC
Permalink
Il 11/02/2010 16.31, Renaissance ha scritto:
> A costo di provocare, anticipo una risposta che non hai dato: immagino
> neanche lo sviluppatore. Perlomeno, non in modo professionale.

immagino che hai senz' altro ragione tu, Renaissance.
non ho mai scritto una riga di software: sono un troll.


ti saluto
--
lowcost
Renaissance
2010-02-12 06:57:31 UTC
Permalink
lowcost ha scritto:

>> A costo di provocare, anticipo una risposta che non hai dato: immagino
>> neanche lo sviluppatore. Perlomeno, non in modo professionale.

> immagino che hai senz' altro ragione tu, Renaissance.

Questo lo puoi sapere solo tu. Altri, lo possono solo immaginare.

bye G.L.
--
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen
Capoccetta
2010-02-12 07:33:14 UTC
Permalink
On 12 Feb, 07:57, Renaissance <***@tiscali.it> wrote:
> lowcost ha scritto:
>
> >> A costo di provocare, anticipo una risposta che non hai dato: immagino
> >> neanche lo sviluppatore. Perlomeno, non in modo professionale.
> > immagino che hai senz' altro ragione tu, Renaissance.
>
> Questo lo puoi sapere solo tu. Altri, lo possono solo immaginare.
>
In realtà io avevo già letto "lowcost" su un altro NG,
it.hobby.elettronica.digitale, e mi era sembrato competente e garbato,
di sicuro non è un "troll"; secondo me c'è stato qualche malinteso.
lowcost
2010-02-12 14:58:46 UTC
Permalink
Il 12/02/2010 8.33, Capoccetta ha scritto:
> In realtà io avevo già letto "lowcost" ...

la ringrazio, messer Capoccetta, ma non si esponga al rogo per me:
a questo punto preferisco prendermi del troll e salutare la compagnia.


di nuovo
--
lowcost
STeve
2010-02-12 16:45:33 UTC
Permalink
On Feb 12, 1:33 am, Capoccetta <***@tiscali.it> wrote:

> di sicuro non è un "troll"; secondo me c'è stato qualche malinteso.

Concordo. Non necessariamente e' un troll. IMHO ne guadagnerebbe di
piu' a dichiarsi tale.
Non concordo sul malinteso.

Uno che esordisce con cose che chiunque abbia un minimo, dico MINIMO,
di esperienza in sviluppo SW oltre "Hello World" sa essere mere utopie
e che per "supportare" quanto afferma spande merda e offende
gratuitamente ("non vorrei essere tuo cliente") solo perche' da
persona onesta quale sono affermo che chiunque (io per primo) commette
errori, beh a ME una bella impressione non fa.
Chi dice di non fare MAI errori e di avere successi qui e la' sempre e
comunque, per la MIA esperienza, e' uno spandimerda e un fanfarone.
Di sicuro non una persona seria e degna di discuterci seriamente.

Aggiungici che non ha il coraggio nemmeno di lasciare un'email per
contatto ... proprio una bella presentazione non c'e' che dire.
A dargli del troll gli fai un complimento.

C'ya
STeve
Capoccetta
2010-02-12 17:03:37 UTC
Permalink
On 12 Feb, 17:45, STeve <***@gmail.com> wrote:
> On Feb 12, 1:33 am, Capoccetta <***@tiscali.it> wrote:
>
> > di sicuro non è un "troll"; secondo me c'è stato qualche malinteso.
>
> Concordo. Non necessariamente e' un troll. IMHO ne guadagnerebbe di
> piu' a dichiarsi tale.
> Non concordo sul malinteso.
>
> Uno che esordisce con cose che chiunque abbia un minimo, dico MINIMO,
> di esperienza in sviluppo SW oltre "Hello World" sa essere mere utopie

Bò, io ho interpretato diversamente i suoi messaggi ma francamente non
ho voglia di mettermi a fare l'esegesi degli scritti di un poster che
forse non ci segue neanche più. Di sicuro le applicazioni safety
critical esistono e anche i software (per caso o per rispetto di
qualche normativa) senza bachi. Robina tipo questa ad esempio:

http://www.pilz.it/products/control_communication/pss/index.it.jsp

dubito che possa arrivare in mano al cliente con bachi.
STeve
2010-02-12 17:13:58 UTC
Permalink
On Feb 12, 11:03 am, Capoccetta <***@tiscali.it> wrote:

> forse non ci segue neanche più. Di sicuro le applicazioni safety
> critical esistono e anche i software (per caso o per rispetto di

Certo che esistono, sono solo un pochino piu' dubbioso siano LA
soluzione ASSOLUTA.

> dubito che possa arrivare in mano al cliente con bachi.

La pagina e' pubblicita' alla fine.
Davvero pensi un commerciale ti venga a dire che possono anche solo
lontanamente esistere problemi ?
Ovvio che ti dicono che tutto e' controllato 4000 volte da il signor
Turing in persona, appositamente risorto per loro.
I problemi saranno tenuti ben nascosti al pubblico.

Si' lo so, sono dannatamente cinico.
Ne ho viste abbastanza da credere ancora a quello che dice un
commerciale.
Renaissance
2010-02-12 20:13:19 UTC
Permalink
STeve ha scritto:

>> dubito che possa arrivare in mano al cliente con bachi.

> La pagina e' pubblicita' alla fine.
> Davvero pensi un commerciale ti venga a dire che possono anche solo
> lontanamente esistere problemi ?
> Ovvio che ti dicono che tutto e' controllato 4000 volte da il signor
> Turing in persona, appositamente risorto per loro.
> I problemi saranno tenuti ben nascosti al pubblico.

> Si' lo so, sono dannatamente cinico.
> Ne ho viste abbastanza da credere ancora a quello che dice un
> commerciale.

E questa e' la summa.

bye G.L.
--
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen
equinozio
2010-02-10 00:14:41 UTC
Permalink
> ho lavorato nell' embedded per 22 anni, dei quali gli ultimi 14 su
> prodotti omologati failsafe (con HW e SW di sicurezza, per applicazioni
> safety critical);  poi ho venduto la fabbrichetta e mi sono pensionato.

WOW, ma allora TU mi insegni che i failsafe non sono affatto privi di
bug o malfunzionamenti, ma solo che sono progettati in modo di essere
tolleranti agli stessi.

In effetti, la dimostrazione più convincente che non esistono modi
sicuri di progettare sistemi complessi è che "shit happens"
continuamente ed in ogni settore, anche il più controllato e sicuro :

< http://www.computerworld.com/s/article/9011691/Air_Force_Raptors_cancel_mission_after_software_glitch?nlid=8&source=NLT_PM
>
rootkit
2010-02-07 10:48:36 UTC
Permalink
Il Sat, 06 Feb 2010 22:41:09 +0100, lowcost ha scritto:


>> "Program testing can be used to show the presence of bugs, but never to
>> show their absence!" (Dijkstra)"
>
> sembra molto logico, ma non e' del tutto vero: se ogni singola funzione
> viene testata al 100%, con tutte le possibili combinazioni di dati in
> ingresso, il baco non puo' scappare;

hai idea di cosa hai scritto qui sopra?
praticamente secondo te i test case per la funzione:

void print(String s);

dovrebbero includere tutte le possibili combinazioni di caratteri in s.
ti sembra abbia un senso?


> eppure esistono intorno a noi apparecchi safety critical che funzionano
> bene, senza farsi notare, senza difetti, senza causare danni o perdita
> di vite umane;

senza difetti *conosciuti*.
è fondamentale mantenere il punto di vista critico specie nel software
che ha applicazioni mission critical / safety critical. tant'è che le
procedure di qualità che tu stesso hai citato prevedono delle verifiche
di autocontrollo, cioè ammettono che possano essere sbagliate in modo non
previsto a priori.
la qualità del software va vista come un limite della funzione "sviluppo"
che tende alla qualità totale.
ispas
2010-02-07 13:13:12 UTC
Permalink
On 6 Feb, 22:41, lowcost <***@invalid.com> wrote:
> sembra molto logico, ma non e' del tutto vero: se ogni singola funzione
> viene testata al 100%, con tutte le possibili combinazioni di dati in
> ingresso, il baco non puo' scappare;  se pero' ci si affida ad un test
> funzionale complessivo e incompleto..

Sbagliato. Il sistema derivato non può essere più corretto di quel
"sistema" che lo ha progettato, ovvero l'uomo.
E l'uomo non è infallibile... :-) Puoi verificare la perfetta
rispondenza ai requisiti, anche con metodi formali (se li usi, cosa
certamente limitata a certi ambiti). Ma se i requisiti sono sbagliati,
non c'è nulla da fare.
Quando le macchine si autoprogetteranno, allora forse il margine di
errore si ridurrà a zero.
Capoccetta
2010-02-07 13:27:47 UTC
Permalink
"ispas" <***@interfree.it> ha scritto nel messaggio Quando le macchine si
autoprogetteranno, allora forse il margine di
errore si ridurrà a zero.

"Tutte le macchine al potere, gli uomini a pane e acqua"
Capoccetta
2010-02-07 13:48:31 UTC
Permalink
"Capoccetta" <***@tiscali.it> ha scritto nel messaggio
news:4b6ebfd5$0$1108$***@reader4.news.tin.it...
>
> "ispas" <***@interfree.it> ha scritto nel messaggio Quando le macchine
> si autoprogetteranno, allora forse il margine di
> errore si ridurrà a zero.
>
> "Tutte le macchine al potere, gli uomini a pane e acqua"

A proposito:

http://motori.corriere.it/motori/varie/10_febbraio_06/shelley-auto-robot-pollina_570e7b76-1337-11df-aca8-00144f02aabe.shtml
ispas
2010-02-07 14:10:58 UTC
Permalink
On 7 Feb, 14:48, "Capoccetta" <***@tiscali.it> wrote:
> http://motori.corriere.it/motori/varie/10_febbraio_06/shelley-auto-ro...

Bè, da qualche anno c'è già la Darpa Grand Challenge:
http://en.wikipedia.org/wiki/DARPA_Grand_Challenge

Uno o due anni fa simulava la guida in strade normali (Urban
challenge), con altri veicoli, semafori, ecc., non in una strada
desolata sulla montagna.
Non che quest'ultima sia una prova facile, ma mi impressiona di più
l'altra gara.
Curioso che abbia vinto un progetto in parte della GM, che poi è
fallita. Ma si vede che hanno preferito i Suv 6000 cc come tecnologia
"di punta".... :-)))
Alessandro Riolo
2010-02-08 17:39:49 UTC
Permalink
On 7 Feb, 14:10, ispas <***@interfree.it> wrote:
> Bè, da qualche anno c'è già la  Darpa Grand Challenge:http://en.wikipedia.org/wiki/DARPA_Grand_Challenge

Ho visto un documentario sull'edizione del 2005 (credo CNN o BBC), uno
spettacolo.

--
ale
http://ale.riolo.co.uk
ispas
2010-02-08 15:00:22 UTC
Permalink
On 7 Feb, 14:13, ispas <***@interfree.it> wrote:
> Sbagliato. Il sistema derivato non può essere più corretto di quel
> "sistema" che lo ha progettato, ovvero l'uomo.
> E l'uomo non è infallibile... :-)

In verità anche questo in generale è sbagliato. Prendiamo la
precisione dimensionale. Un uomo può fare oggetti con una precisione
del decimo di millimetro, e non continuativa (oggi lavora meglio,
domani peggio).
Però c'è stata una evoluzione che ha portato a costruire macchine
utensili con precisione centinaia, migliaia di volte maggiore, e
assolutamente costante. Ovvero, da un "sistema" di relativamente
scarsa precisione sono uscite macchine molto più precise.
Dopo 50-60 anni di studio e realizzazione di software, c'è stata
un'evoluzione simile, in questo caso nell'aumento della affidabilità/
riduzione dei bugs? Non mi risulta. Forse in qualche settore molto
particolare, ma non certo nella produzione di software
"normale".Dipende ancora tutto dalla capacità ed esperienza dello
sviluppatore.
equinozio
2010-02-05 10:02:35 UTC
Permalink
> http://www.edn.com/blog/1690000169/post/630052463.html?nid=3351&rid=3...
>
> un pò tecnico ma interessante, anche i commenti dei lettori

WOW, la scoperta dell'acqua calda : "There simply is no systematic
approach to ensuring the quality of an integrated hardware/software
system.", e finalmente.

E comunque, nel caso in questione, credo che bisognerebbe
semplicemente RESISTERE alla tentazione di scrivere troppe righe di
codice tra la pressione del pedale ed il servo della farfalla del
carburatore (o quel che è).
Luca Menegotto
2010-02-05 10:36:36 UTC
Permalink
Capoccetta wrote:

> un pò tecnico ma interessante, anche i commenti dei lettori

(non ho letto i commenti, desculpe)

E' interessante questo passaggio:

"How much better for everyone if it were a principle of civil law that
when it is found that damage has been inflicted by a failure, all of
the diagnostic information determined by the vendor and by independent
parties must be placed in the public domain, and may not be used to
assess or assign damages. "

E' interessante perche' corrisponde esattamente a come viene condotta
un'indagine quando si parla di incidenti aeronautici.

--
Ciao!
Luca
STeve
2010-02-08 23:11:17 UTC
Permalink
Un altro paio di link.
Il primo e' interessante .. mostra la solita reazione di chi non
mastica tecnologia.
I soliti "erano meglio le auto quando erano solo meccaniche" (http://
alturl.com/w4kn), dimenticandosi di tutto quello che il mercato ora
richiede ad un auto.
NUove tecnologie, meno inquinamento, maggiore autonomia, maggiore
facilita' di diagnosi di problemi, problemi diversi dalle vecchie
tecnologie ma maggiori benefici in generale.
Ma al primo problema, c'e' sempre il solito ignorante che deve fare
demagogia e parlare di cose che non sa.
Se dessimo retta a questi trogloditi saremmo ancora con il calesse ..
anzi forse nemmeno quello.

Il secondo (http://alturl.com/i47v) e' un po' piu' sul tecnico.

C'ya
STeve
Luca Menegotto
2010-02-09 07:00:41 UTC
Permalink
STeve wrote:

> I soliti "erano meglio le auto quando erano solo meccaniche" (http://
> alturl.com/w4kn), dimenticandosi di tutto quello che il mercato ora
> richiede ad un auto.

Beh, io ho un amico che ama andare a fare fuori strada nel deserto. Per
lui, i fuori strada erano meglio quando erano integralmente meccanici:
"se mi si ferma nel deserto, in un motore meccanico so dove mettere le
mani, in uno gestito dall'elettronica non so nemmeno da dove iniziare".
:-D

Detto questo, ci sono ance le vie di mezzo. Oggi nelle auto si è
passati IMHO TROPPO dall'altra parte, aggiungendo serie di gadgets che
non servono assolutamente a nulla, se non a dire "quanto 'so fico io".

--
Ciao!
Luca
STeve
2010-02-09 17:07:56 UTC
Permalink
On Feb 9, 1:00 am, "Luca Menegotto" <***@CAVAMIyahoo.it>
wrote:

> Detto questo, ci sono ance le vie di mezzo. Oggi nelle auto si è
> passati IMHO TROPPO dall'altra parte, aggiungendo serie di gadgets che
> non servono assolutamente a nulla, se non a dire "quanto 'so fico io".

Non confondere !
C'mon, un'analisi un pochino piu' seria.
Si sta discutendo di modifiche strutturali, non di gadget.

Hai idea "il peso" e "il costo" solo dei cavi in un'auto
tradizionale ?
E la loro affidabilita' ??
Molta della tecnologia ora sotto "processo" dai puri e duri, e' nata
per ridurre il peso, e quindi costi e consumi, dei cavi e aumentare la
sicurezza, aggiungendo capacita' di diagnostica prima semplicemente
impossibili.
Se prima c'erano km di cavi in un'auto, ora ce ne sono molto ma molto
meno. Ma un cavo deve servire piu' funzioni, cosa che non e' possibile
fare senza elettronica.

Un esempio .. la mia fida Bodmobile e' "vecchia", del 97, quindi non
cosi' piena di "inutili gadgets elettronici" come dici tu.
Un paio d'anni fa sono iniziati strani problemi.
Accendevo le luci e partivano i tergicristalli, saltavano fusibili,
ecc.

Semplicemente un mazzo di cavi nel portellone si erano spelati e
facevano dei cortocircuiti random.
Ho rischiato di rimanere a piedi o avere un incendio a bordo.
Per trovare e sistemare il problema ho speso 500$ perche' hanno dovuto
smontare mezza macchina solo per "trovare" il problema.
La "vecchia" tecnologia ha messo in pericolo me, l'auto e mi e'
costata un botto.

Con la diagnostica disponibile su nuovi modelli il sistema di bordo
avrebbe identificato subito il problema.
Problema che poi non sussiste perche' non passano piu' blocchi di cavi
in spazi ristretti oggi come oggi, solo un cavo che puo' essere reso
piu' robusto e affidabile.
Gadget inutili ?

Ha senso ridurre peso e costi in carrozzeria e altre parti per
lasciare il resto cosi' ?
E ridurre i consumi implica avere sistemi con capacita' di feedback,
cosa non possibile se non in modo molto limitato, senza elettronica.
Non e' un caso se le prime applicazioni elettroniche in un auto erano
proprio nel motore.

Insomma, vuoi un'auto che inquina meno, che consuma meno, che pesa
meno, che sia piu' affidabile usando una tecnologia vecchia che
impedisce quanto sopra ?
Mi chiami queste cose "gadget inutile" ??

E anche avere anche maggiori funzionalita', come il GPS, non lo vedo
come "gadget inutile". Magari e' inutile per chi fa 5km al giorno nel
paesello, per chi ogni tanto deve andare in posti sconosciuti e' una
manna.

Insomma, quello che tu giudichi "inutile e roba da fico" non e' detto
lo sia in assoluto.
Altrimenti specifica cosa giudichi inutile e discutiamone.

C'ya
STeve
Alessandro Riolo
2010-02-09 17:25:34 UTC
Permalink
On 9 Feb, 17:07, STeve <***@gmail.com> wrote:
> Hai idea "il peso" e "il costo" solo dei cavi in un'auto
> tradizionale ?

Fino a non molti anni fa, per quelli là che fino a poco fa non
vendevano auto a casa tua, il facevano a Trapani e provincia, casa per
casa, perlopiù casalinghe :)

C'era un imprenditore locale che aveva questo contratto per centinaia
di milioni di Euro, ed oltre che negli stabilimenti, non so come (mi
si tratta di cose di almeno 3 lustri fa), i cavi finivano a casa di
persone, che si passavano il tempo ad assemblarli, e venivano pagate a
cottimo (sapevo anche quanto, non ricordo sinceramente, ma non era
molto, anzi). Diverse madri di miei amici di infanzia ci campavano la
famiglia, specialmente quando c'erano periodi di crisi nel settore
edilizio.

--
ale
http://ale.riolo.co.uk
ispas
2010-02-09 17:43:23 UTC
Permalink
On 9 Feb, 18:07, STeve <***@gmail.com> wrote:
> Hai idea "il peso" e "il costo" solo dei cavi in un'auto
> tradizionale ?
> E la loro affidabilita' ??
> Molta della tecnologia ora sotto "processo" dai puri e duri, e' nata
> per ridurre il peso, e quindi costi e consumi, dei cavi e aumentare la
> sicurezza, aggiungendo capacita' di diagnostica prima semplicemente
> impossibili.
> Se prima c'erano km di cavi in un'auto, ora ce ne sono molto ma molto
> meno. Ma un cavo deve servire piu' funzioni, cosa che non e' possibile
> fare senza elettronica.

Concordo assolutamente. Qui non si parla dello specchietto elettrico,
o dell'alzacristalli, o del sedile con massaggio (!).
Ma di tutti gli apparecchi impossibili, o complicatissimi, senza
l'elettronica (*), come i cambi robotizzati, l'ABS, l'alimentazione
senza carburatore, ecc.

(*) in effetti qualche esemplare di ABS solo meccanico/idraulico credo
l'abbiano costruito, ma era uno dei primi modelli.
Luca Menegotto
2010-02-09 19:44:50 UTC
Permalink
STeve wrote:

> Accendevo le luci e partivano i tergicristalli, saltavano fusibili,
> ecc.

Vabbe', Ste, ciascuno ha le sue cose da raccontare.
La mia vecchia Avensis mi ha portato a casa e da li non ha più voluto
saperne di ripartire. Motivo? tutte e tre le centraline in blocco.
Soluzione, sostituzione integrale.

Alla faccia di chi dice che i buchi non esistono! ;-)

> Per trovare e sistemare il problema ho speso 500$ perche' hanno dovuto
> smontare mezza macchina solo per "trovare" il problema.

Posso consolarti?

Personaggio con cui faccio due chiacchiere dal barbiere, titolare di
una BMW serie 7 di 6 mesi.

La domenica prima decide di andare a fare una gita a Bolzano. Arriva,
parcheggia, e quando è ora di ripartire (indovina??) morta!

Han dovuto recuperarla col carro attrezzi il giorno dopo!

> Gadget inutili ?

I gadget inutili sono quelli che NON SERVONO! Caspita, a te serve un
tergivetro che si aziona da solo? o lo specchietto retrovisore che si
scurisce da solo? o tutta la serie di altre troiate che complicano
inutilmente il sistema auto?

> E anche avere anche maggiori funzionalita', come il GPS, non lo vedo
> come "gadget inutile". Magari e' inutile per chi fa 5km al giorno nel
> paesello, per chi ogni tanto deve andare in posti sconosciuti e' una
> manna.

Ne avrei da dire, sui sistemi GPS... Mai aggiornati, ogni tanto
decidono di farti fare il giro del globo da qui a li. E non ti sto
parlando del mio cessetto da 200 euro, ti parlo di quello integrato
nell'A6 Audi!


--
Ciao!
Luca
STeve
2010-02-09 21:24:24 UTC
Permalink
On Feb 9, 1:44 pm, "Luca Menegotto" <***@CAVAMIyahoo.it>
wrote:
> saperne di ripartire. Motivo? tutte e tre le centraline in blocco.
> Soluzione, sostituzione integrale.

Quello e' semmai un altro discorso, l'assistenza e manutenzione.

> Alla faccia di chi dice che i buchi non esistono! ;-)
Beh non dirlo a me !!! :-)

> I gadget inutili sono quelli che NON SERVONO! Caspita, a te serve un
> tergivetro che si aziona da solo? o lo specchietto retrovisore che si

Ma non e' di quelli che si parla ! Dai !
Quelli del link che ho postato non si lamentano dello specchietto
retrovisore LCD (che IMHO apporta comunque dei miglioramenti :-) ) ma
della tecnologia alla base del concetto di auto !

> scurisce da solo? o tutta la serie di altre troiate che complicano
> inutilmente il sistema auto?

In genere sono circuiti che in comune hanno solo l'alimentazione.

> Ne avrei da dire, sui sistemi GPS... Mai aggiornati, ogni tanto
> decidono di farti fare il giro del globo da qui a li.

Sei tu che non li sai usare :-)
La mia Betty mi ha tirato fuori tante di quelle volte da posti
infami :-)

Ciao
STeve
Luca Menegotto
2010-02-10 14:59:28 UTC
Permalink
STeve wrote:

> Sei tu che non li sai usare :-)

Caspita, più di dirgli "sono qui, voglio andare li", che devo fare??

Ah, forse non glie l'ho chiesto con sufficiente cortesia... :-D

--
Ciao!
Luca
equinozio
2010-02-10 00:30:16 UTC
Permalink
> Ne avrei da dire, sui sistemi GPS... Mai aggiornati, ogni tanto
> decidono di farti fare il giro del globo da qui a li. E non ti sto
> parlando del mio cessetto da 200 euro, ti parlo di quello integrato
> nell'A6 Audi!

E perchè quello dell'A6 dovrebbe essere migliore di quello che la
gente compra e riconosce come il migliore ? Quello integrato è frutto
di una trattativa tra aziende, il mio amico TomTom è frutto della
competizione e di giri me ne fa fare ben pochi.
Luca Menegotto
2010-02-10 15:01:45 UTC
Permalink
equinozio wrote:

> E perchè quello dell'A6 dovrebbe essere migliore di quello che la
> gente compra e riconosce come il migliore ?

Ma non costa due lire.

Il mio principio era: non è che il fatto di spendere un millino o più
cambi la situazione.

> Quello integrato è frutto
> di una trattativa tra aziende, il mio amico TomTom è frutto della
> competizione e di giri me ne fa fare ben pochi.

A parte il fatto che pure il tuo amico TomTom mi ha fatto fare qualche
strano giro, è vero, non vanno male; però, io ho raggiunto la
conclusione che dipenda dalle zone e da come viene preparata la
cartografia. Cartografia (tutta, eh?) che è sempre abbastanza indietro
rispetto al reale.

--
Ciao!
Luca
Sentenza
2010-02-10 15:38:30 UTC
Permalink
On 2010-02-10, Luca Menegotto <***@CAVAMIyahoo.it> wrote:

> A parte il fatto che pure il tuo amico TomTom mi ha fatto fare qualche
> strano giro, è vero, non vanno male; però, io ho raggiunto la
> conclusione che dipenda dalle zone e da come viene preparata la
> cartografia. Cartografia (tutta, eh?) che è sempre abbastanza indietro
> rispetto al reale.

La cartografia ma soprattutto gli ALGORITMI. Ho avuto (ce l'ho ancora,
ora lo uso solo per girare a piedi) un Mio che a cinquecento metri
dalla rampa d'ingresso della Roma-Fiumicino insisteva per farmi tornare
indietro di chilometri sulla Portuense per farmela prendere dall'inizio.
Rampa che ovviamente era perfettamente sulla mappa, tanto che quando
caparbiamente mi ci sono diretto comunque arrivato praticamente davanti
alla stessa ha finalmente realizzato "Ah ma qui c'è la rampa di ingresso!
Sali!". Ben svegliato neh :)
equinozio
2010-02-10 15:55:02 UTC
Permalink
> Il mio principio era: non è che il fatto di spendere un millino o più
> cambi la situazione.

Perchè, tu metti in ralazione costo e qualità ? Nel software ?? Ma no
dai non ci credo !

> cartografia. Cartografia (tutta, eh?) che è sempre abbastanza indietro
> rispetto al reale.

Mi hai fatto venire in mente un mio giro in un paesino del sud...
arrivo ed il tom tom mi dice di girare a destra, io metto pure la
freccia, guardo, ma la strada non c'è : la mappa dice che c'è una
bella strada larga nella realtà c'è un palazzo di 3 piani.. e la
storia si ripete alemno altre 2 volte, al punto che cominciavo a
pensare ad una anomalia ed a cercare il gatto di matrix..

Comuqnue poi sono venuto a sapere che effettivamente la strada c'era,
40 anni fa. Poi però qualcuno ha deciso che gli serviva un
appartamentino e l'ha chiusa : l'ha privatizzata ! Come sia stato
possibile io non lo so e non lo volgio sapere, fatto sta che credo che
anche il comune avrebbe qualche difficoltà a spiegarlo... quindi sulle
mappe il paese è pieno di strade dritte, e nelle realtà ci sono solo
pochi vicoletti.
Valentina
2010-02-09 22:05:52 UTC
Permalink
On 09/02/2010 17:07, STeve wrote:
> On Feb 9, 1:00 am, "Luca Menegotto"<***@CAVAMIyahoo.it>
> wrote:
>
>> Detto questo, ci sono ance le vie di mezzo. Oggi nelle auto si è
>> passati IMHO TROPPO dall'altra parte, aggiungendo serie di gadgets che
>> non servono assolutamente a nulla, se non a dire "quanto 'so fico io".
>
> Non confondere !
> C'mon, un'analisi un pochino piu' seria.
> Si sta discutendo di modifiche strutturali, non di gadget.
>
> Hai idea "il peso" e "il costo" solo dei cavi in un'auto
> tradizionale ?
> E la loro affidabilita' ??
> Molta della tecnologia ora sotto "processo" dai puri e duri, e' nata
> per ridurre il peso, e quindi costi e consumi, dei cavi e aumentare la
> sicurezza, aggiungendo capacita' di diagnostica prima semplicemente
> impossibili.
> Se prima c'erano km di cavi in un'auto, ora ce ne sono molto ma molto
> meno. Ma un cavo deve servire piu' funzioni, cosa che non e' possibile
> fare senza elettronica.

Bah sara`. Fatto sta che e` risaputo che la vecchia Fiat UNO consumava
molto meno di tante auto moderne...
equinozio
2010-02-10 00:23:58 UTC
Permalink
> Bah sara`. Fatto sta che e` risaputo che la vecchia Fiat UNO consumava
> molto meno di tante auto moderne...

He, si... si stava meglio quando si stava peggio.

Ma anche no !

Link ? Dati ? Chi lo dice ? Chi lo ha verificato ? Paragonata a quale
macchina ? Con che prestazioni ? E perchè di grazia il fire della uno
dovrebbe consumare meno del fire della punto ? Dobbiamo credere al si
dice ? Si fa presto a dire pirla.. poi però...
Sentenza
2010-02-10 08:50:56 UTC
Permalink
On 2010-02-10, equinozio <***@gmail.com> wrote:

> E perchè di grazia il fire della uno dovrebbe consumare meno
> del fire della punto ?

Ah, questa è facile: perché cambiano le normative di omologazione.
Per riuscire a rientrare nei parametri di emissione sempre più
restrittivi, si finisce a far lavorare i motori in modo "meno"
efficiente rispetto a quello che farebbero potendo puntare solo
all'efficienza fregandosene completamente delle emissioni.
ispas
2010-02-10 12:03:31 UTC
Permalink
On 10 Feb, 09:50, Sentenza <***@STACEPPAosteriafuoriporta.net>
wrote:
> Ah, questa facile: perch cambiano le normative di omologazione.
> Per riuscire a rientrare nei parametri di emissione sempre pi
> restrittivi, si finisce a far lavorare i motori in modo "meno"
> efficiente rispetto a quello che farebbero potendo puntare solo
> all'efficienza fregandosene completamente delle emissioni.

Hmmm... Un motore che avesse il rendimento 100% non avrebbe emissioni
collaterali, a parte CO2.
Quindi quel che dici è vero solo se si valuta esclusivamente
l'emissione di CO2. Il che sembra effettivamente la normativa (o moda)
corrente. Parliamo comunque di minime differenze in più o meno.
Sentenza
2010-02-10 12:55:37 UTC
Permalink
On 2010-02-10, ispas <***@interfree.it> wrote:

> Hmmm... Un motore che avesse il rendimento 100% non avrebbe emissioni
> collaterali, a parte CO2.

Se escludiamo il piccolo dettaglio che un motore con il rendimento del 100%
non può esistere :-)

> Quindi quel che dici è vero solo se si valuta esclusivamente
> l'emissione di CO2. Il che sembra effettivamente la normativa (o moda)
> corrente. Parliamo comunque di minime differenze in più o meno.

No, c'è anche il paradosso dell'ossido di azoto, che è prodotto proporzionalmente
alla temperatura e quindi velocità del motore... e quindi è prodotto di più
quando il motore lavora meglio!

Poi in realtà c'è una questione molto banale: visto che ogni motore reale appunto
produce emissioni per il fatto di esistere, per abbatterle si piazza un altro
bel tappo sulla marmitta che le converta in qualcos'altro. Ed un motore con
un tappo in più deve faticare di più perchè deve spingere i gas anche attraverso
questo :(
ispas
2010-02-10 14:49:08 UTC
Permalink
On 10 Feb, 13:55, Sentenza <***@STACEPPAosteriafuoriporta.net>
wrote:

E con ciò? Si vuole dire solo che più aumenti il rendimento, meno
emetti inquinanti in generale (esclusa CO2, ineliminabile).

> No, c'è anche il paradosso dell'ossido di azoto, che è prodotto proporzionalmente
> alla temperatura e quindi velocità del motore... e quindi è prodotto di più
> quando il motore lavora meglio!

Se per "meglio" intendi ad alto rendimento/basso consumo, allora non è
vero. Come detto, più il motore si avvicina al 100% meno emette
sostanze estranee, non ci sono santi. Naturalmente se ti riferisci al
sistema auto, e vuoi che stia nel punto di consumo minimo andando a
150 in autostrada direi che non ci siamo... :-)) (magari con i
finestrini spalancati :-))))

> Poi in realtà c'è una questione molto banale: visto che ogni motore reale appunto
> produce emissioni per il fatto di esistere, per abbatterle si piazza un altro
> bel tappo sulla marmitta che le converta in qualcos'altro. Ed un motore con
> un tappo in più deve faticare di più perchè deve spingere i gas anche attraverso
> questo :(

Notoriamente i motori automobilistici sono tra quelli con il peggior
rendimento tra i motori termici. Quindi non è vero, in generale, che
per esistere deve inquinare in quella maniera. Potrebbe essere
progettato apposta per veri bassi consumi, e puoi stare assolutamente
certo che avrebbe inquinanti molto molto inferiori.
Certo se vuoi l'utilitaria da 140-150 all'ora (come il 90% di oggi)
diventano discorsi senza senso.
E' chiaro che si devono impostare equilibri del tutto artificiosi.
Sentenza
2010-02-10 15:27:50 UTC
Permalink
On 2010-02-10, ispas <***@interfree.it> wrote:

> E con ciò? Si vuole dire solo che più aumenti il rendimento, meno
> emetti inquinanti in generale (esclusa CO2, ineliminabile).

No, non "in generale", solo meno idrocarburi incombusti. Ma "tutto il
resto" che sta nel carburante (additivi, antidetonanti, cazzi vari) "non"
prendono intrinsecamente parte alla reazione, se non per il fatto di
essere casualmente lì quando succede. E quella è tutta roba che poi viene
buttata fuori.

> Se per "meglio" intendi ad alto rendimento/basso consumo, allora non è
> vero. Come detto, più il motore si avvicina al 100% meno emette
> sostanze estranee, non ci sono santi. Naturalmente se ti riferisci al
> sistema auto, e vuoi che stia nel punto di consumo minimo andando a
> 150 in autostrada direi che non ci siamo... :-)) (magari con i
> finestrini spalancati :-))))

Ma guarda che il punto di consumo minimo per un motore di grossa cilindrata
è "proprio" andando a 150 in autostrada, con la marcia più alta, quando
deve fornire il minimo di energia indispensabile per "appoggiarsi"
all'elevata inerzia del veicolo. E però, è proprio in questa situazione
che l'emissione di NO è la più elevata. Al contrario, consuma di più
a bassa velocità in città, quando deve fornire una spinta in termini di
energia più consistente in una marcia più bassa - e qui invece emette
meno NO.
Insomma: "Efficienza della combustione" e "consumo di carburante" sono
due parametri che, in un motore reale, intrinsecamente non hanno alcuna
relazione tra loro, se non passando "indirettamente" per qualche altra cosa
(le condizioni di funzionamento, appunto).

Detto in soldoni: l'efficienza della "combustione", in sè, conta ben
poco in questo caso - quello che conta è rendimento del "complesso motore".
In effetti, possiamo dire che i motori attuali euro-stocavolo hanno
l'efficienza della "combustione" migliore in assoluto, visto che il sistema
forza perennemente il rapporto stechiometrico ideale della miscela - ma
se poi per ridurre forzosamente le emissioni mi riduci la potenza erogata
dal motore, ne consegue che per fare lo stesso lavoro il motore dovrà
*erogare di più*, e quindi *consumare di più*. Se aumenti l'efficienza
della "singola" combustione del 5%, ma poi riduci la potenza complessiva
del 10%... per fare lo stesso lavoro dovrò fare il 10% di combustioni
in più, rimangiandomi tutto il guadagno di prima e mettendoci gli
interessi!

> Notoriamente i motori automobilistici sono tra quelli con il peggior
> rendimento tra i motori termici. Quindi non è vero, in generale, che
> per esistere deve inquinare in quella maniera. Potrebbe essere
> progettato apposta per veri bassi consumi, e puoi stare assolutamente
> certo che avrebbe inquinanti molto molto inferiori.
> Certo se vuoi l'utilitaria da 140-150 all'ora (come il 90% di oggi)
> diventano discorsi senza senso.
> E' chiaro che si devono impostare equilibri del tutto artificiosi.

Beh c'è il particolare che un veicolo deve pure, come dire, "servire
a qualcosa". Ovvero, se fai un'utilitaria che ha emissioni zero, ma per
farlo deve andare al massimo a quaranta all'ora... a cosa diavolo
serve???
ispas
2010-02-10 17:17:28 UTC
Permalink
> No, non "in generale", solo meno idrocarburi incombusti. Ma "tutto il
> resto" che sta nel carburante (additivi, antidetonanti, cazzi vari) "non"
> prendono intrinsecamente parte alla reazione, se non per il fatto di
> essere casualmente lì quando succede. E quella è tutta roba che poi viene
> buttata fuori.

Gli additivi, antidetonanti, ecc. ci stanno per le caratteristiche
imperfette della coppia motore-carburante, rispetto all'obiettivo del
minor consumo (antidenotanti per la benzina; zolfo nel gasolio, che
poi è una impurità; lubrificante nei motori 2 tempi, ecc.). Voglio
dire, più migliori il processo di combustione meno "zozzerie" devi
aggiungere. Poi sono d'accordo che la combustione perfetta è un limite
superiore teorico.

> Ma guarda che il punto di consumo minimo per un motore di grossa cilindrata
> è "proprio" andando a 150 in autostrada, con la marcia più alta, quando
> deve fornire il minimo di energia indispensabile per "appoggiarsi"
> all'elevata inerzia del veicolo. E però, è proprio in questa situazione
> che l'emissione di NO è la più elevata. Al contrario, consuma di più
> a bassa velocità in città, quando deve fornire una spinta in termini di
> energia più consistente in una marcia più bassa - e qui invece emette
> meno NO.

No. Il punto (numero di giri) di consumo minimo è intrinseco al
motore, non all'auto. E' poi il rapporto corrente sul cambio che fa
coincidere una certa velocità al punto di consumo minimo. In città
consuma di più perchè più spesso è costretto a stare fuori del punto
di minimo, a causa dei continui rallentamenti ed accelerazioni. Tra
l'altro il punto di minimo di solito non coincide con il punto di
massima coppia, se ben ricordo.

> Beh c'è il particolare che un veicolo deve pure, come dire, "servire
> a qualcosa". Ovvero, se fai un'utilitaria che ha emissioni zero, ma per
> farlo deve andare al massimo a quaranta all'ora... a cosa diavolo
> serve???

L'utilità non ha assolutamente niente a che vedere con la velocità. A
parte le Ferrari di F1 ;-) Che me ne faccio di un'auto da 150 km/h se
vado a passo d'uomo in mezzo al traffico, oppure ogni 100 m c'è un
semaforo od altro intoppo??
Quel che dici dimostra perchè è difficile diminuire in modo
consistente i consumi delle auto. In realtà, a parte le chiacchere, il
basso consumo non interessa a nessuno, se costringe a ridurre in modo
consistente certe prestazioni del tutto superflue, come la velocità
massima.
Net_Byt
2010-02-10 19:30:32 UTC
Permalink
Sentenza wrote:

-SNIP-

> Beh c'è il particolare che un veicolo deve pure, come dire, "servire
> a qualcosa". Ovvero, se fai un'utilitaria che ha emissioni zero, ma
> per farlo deve andare al massimo a quaranta all'ora... a cosa diavolo
> serve???

40 all'ora sono pure troppi in certe città ! e non parlo solo delle grandi
città: i poveri sfortunati costretti ad attraversare Padova al mattino se li
sognano 40 km orari :-(
Net_Byt
2010-02-10 19:34:29 UTC
Permalink
Sentenza wrote:

> Ah, questa è facile: perché cambiano le normative di omologazione.
> Per riuscire a rientrare nei parametri di emissione sempre più
> restrittivi, si finisce a far lavorare i motori in modo "meno"
> efficiente rispetto a quello che farebbero potendo puntare solo
> all'efficienza fregandosene completamente delle emissioni.

e inoltre (mediamente) le automobili pesano sempre di più, per via
dell'isolamento al rumore sia interno che esterno, i sedili e gli interni
sempre più 'voluminosi', i condizionatori installati (mediamente) su
tantisime macchine, i pneumatici di larghezza (mediamente) maggiore, ecc ecc
. fonte quattroruote, ha dedicato un articolo proprio a questo argomento
diversi mesi fa.
Luca Menegotto
2010-02-10 15:04:34 UTC
Permalink
Valentina wrote:

> Bah sara`. Fatto sta che e` risaputo che la vecchia Fiat UNO
> consumava molto meno di tante auto moderne...

Io l'ho avuta, la Uno.

45 cavalli 45, faceva 16 con un litro. Grosso modo quel che fai oggi
con una Grande Punto, che di cavalli ne fa un'ottantina.

Occhio, Valenti', che quel che conta non è il consumo assoluto, ma il
consumo specifico.

--
Ciao!
Luca
tirzanello
2010-02-09 05:19:31 UTC
Permalink
On Feb 9, 8:32 am, STeve <***@gmail.com> wrote:

> Ovvero quel test, come gia' detto, non garantisce la funzione sia
> esente da bachi.
[...]
> Il fatto che non si manifestino bachi non e' assolutamente  prova
> della loro assenza.


e mi permetto d'aggiungere che i bachi possono anche essere
concettuali!!!
E alle volte un bug puo' essere considerato una feature, ed essere
anche apprezzato ;-) Per alcuni alle volte, cose dall'apparenza
troppo perfetta puzzano! Una failure a determinate condizioni puo'
anche essere apprezzata, talvolta!
Alessandro Riolo
2010-02-11 10:08:49 UTC
Permalink
On 5 Feb, 07:30, Capoccetta <***@tiscali.it> wrote:
> ...e l'affidabilità del software:
>
> http://www.edn.com/blog/1690000169/post/630052463.html?nid=3351&rid=3...
>
> un pò tecnico ma interessante, anche i commenti dei lettori

BTW, tutta questa storia mi ha ricordato una cosa: la mia KIA Sportage
2000 cc, che da qualche tempo usa mio fratello a Pisa, presenta un
problema simile quando si tenta di frenare durante una manovra a
velocità molto ridotta (ad esempio curvando a tutto sterzo mentre si
tenta un'inversione in una strada a carreggiata ridotta, o quando si
curva per parcheggiare). La prima volta ho veramente rischiato di
andare ad impattare con un muro, mi sono salvato soltanto con il freno
a mano, dopo un po ho imparato che per fare quel tipo di manovra
bisogna fare come se si fosse a mare, si deve dare soltanto quella
spinta per completare come se i freni non esistessero, e comunque
tenersi sempre pronti ad usare il freno a mano.

Il problema è certamente nell'elettronica, se l'impianto frenante
fosse totalmente meccanico/pneumatico una cosa del genere non potrebbe
succedere.

--
ale
http://ale.riolo.co.uk
Valentina
2010-02-11 20:51:08 UTC
Permalink
On 11/02/2010 10:08, Alessandro Riolo wrote:
> On 5 Feb, 07:30, Capoccetta<***@tiscali.it> wrote:
>> ...e l'affidabilità del software:
>>
>> http://www.edn.com/blog/1690000169/post/630052463.html?nid=3351&rid=3...
>>
>> un pò tecnico ma interessante, anche i commenti dei lettori
>
> BTW, tutta questa storia mi ha ricordato una cosa: la mia KIA Sportage
> 2000 cc, che da qualche tempo usa mio fratello a Pisa, presenta un
> problema simile quando si tenta di frenare durante una manovra a
> velocità molto ridotta (ad esempio curvando a tutto sterzo mentre si
> tenta un'inversione in una strada a carreggiata ridotta, o quando si
> curva per parcheggiare). La prima volta ho veramente rischiato di
> andare ad impattare con un muro, mi sono salvato soltanto con il freno
> a mano, dopo un po ho imparato che per fare quel tipo di manovra
> bisogna fare come se si fosse a mare, si deve dare soltanto quella
> spinta per completare come se i freni non esistessero, e comunque
> tenersi sempre pronti ad usare il freno a mano.
>
> Il problema è certamente nell'elettronica, se l'impianto frenante
> fosse totalmente meccanico/pneumatico una cosa del genere non potrebbe
> succedere.

Le tanto bistrattate FIAT questo problema non l'hanno.
Quando comprare l'auto, comprate italiano, almeno sostenete la nostra
economia e non l'economia dei paesi stranieri.
PaF
2010-02-11 21:36:37 UTC
Permalink
Il Thu, 11 Feb 2010 20:51:08 +0000, Valentina ha scritto:


> Le tanto bistrattate FIAT questo problema non l'hanno.
> Quando comprare l'auto, comprate italiano, almeno sostenete la nostra
> economia e non l'economia dei paesi stranieri.

Ma per favore, Fiat che produce le auto in Polonia e chiude Termini
Imerese, quella stessa Fiat che ha aperto gli stabilimenti al sud grazie
alla cassa del mezzogiorno ma che "non ha mai avuto un euro dallo Stato".

PaF
Sentenza
2010-02-12 08:12:31 UTC
Permalink
On 2010-02-11, Valentina <***@gmail.com> wrote:

> Le tanto bistrattate FIAT questo problema non l'hanno.

Infatti, alle FIAT invece dei freni si rompeva il piantone dello sterzo ;-)))))
Luca Menegotto
2010-02-12 08:40:06 UTC
Permalink
Valentina wrote:

> Le tanto bistrattate FIAT questo problema non l'hanno.
> Quando comprare l'auto, comprate italiano, almeno sostenete la nostra
> economia e non l'economia dei paesi stranieri.

Le tanto bistrattate FIAT ora sono vetture belle e decentemente
affidabili, solo 5 anni fa erano un terno al lotto.

I problemi erano sia hardware che software (un'auto in casa segnalava
problemi che non c'erano, consiglio del meccanico: normale, ignorate la
segnalazione).

D'altra parte, non ricordi "Fix It Again Tom"??

Detto questo. Perché dovrei comprare Fiat quando l'obiettivo di Fiat è
di produrre sempre più all'estero? in fondo già oggi molte vetture del
gruppo che arrivano in Italia sono costruite in Polonia, in Turchia, in
Francia, e alcune pare verranno costruite addirittura in USA (gli alti
di gamma, in sinergia con i modelli Chrisler).

--
Ciao!
Luca
STeve
2010-02-12 16:13:38 UTC
Permalink
On Feb 12, 2:40 am, "Luca Menegotto" <***@CAVAMIyahoo.it>
wrote:

> Detto questo. Perché dovrei comprare Fiat quando l'obiettivo di Fiat è
> di produrre sempre più all'estero?

Il problema oggi come oggi non e' piu' quello di comprare "italiano" o
"tedesco" o "giapponese", ecc. ecc.
Solo un ingenuo ignorante puo' pensare che Fiat sia ormai solo roba
italiana, o Ford solo roba USA, o GM o Toyota solo roba giapponese e
via dicendo.
Ogni casa automobilistica produce ormai in tutto il mondo.
Macchine fatte in Messico sono vendute in USA e Europa con marchi di
tutto il mondo.
Toyota, Honda, hanno piu' stabilimenti in USA e Europa che Giappone e
via dicendo.

Quello che si deve guardare oggi come oggi e' qualita' vs. prezzo e in
un mercato agguerrito come quello dell'auto se non adotti determinati
standard qualitativi sei fuori.
Fiat ha aumentato un pochino la qualita' anche se ha sempre contato su
altre politiche per non affondare, tipo sovvenzionamenti statali.
Se non fosse stata supportata (!!!) dallo stato Fiat sarebbe fallita
almeno 30 anni fa.
Certo che se Fiat vuole vendere all'estero deve avere roba di
qualita'.
Altro che la mia 127 che a momenti perdeva il motore (si erano svitate
le viti di supporto) :-) Quella e' roba del passato.

Di sicuro Fiat ne ha cosi' da correre per arrivare a standard
qualitativi che altri hanno da decenni, a prezzi inferiori.

> Francia, e alcune pare verranno costruite addirittura in USA (gli alti
> di gamma, in sinergia con i modelli Chrisler).

Mah .. io e molti altri in USA siamo alquanto scettici su questa
operazione.
Non ho idea di quello che saltera' fuori, SE saltera' fuori e non ho
idea se il mercato USA reagira' positivamente a questa cosa.
Fiat appunto non ha una gran bella nomea qui, aggiungici il fatto che
Fiat e' entrata per "salvare" Chrisler, una azienda che ha sempre
fatto auto non particolarmente di qualita' (altra bella nomea).
Due falliti che si mettono insieme difficilmente ne escono
vincitori ...

C'ya
STeve
Alessandro Riolo
2010-02-12 09:31:00 UTC
Permalink
On 11 Feb, 20:51, Valentina <***@gmail.com> wrote:
> Le tanto bistrattate FIAT questo problema non l'hanno.
> Quando comprare l'auto, comprate italiano, almeno sostenete la nostra
> economia e non l'economia dei paesi stranieri.

LOL ..
Mai avuto problemi a guidare FIAT di altri. BTW, sono le uniche auto
che mi abbiano mai lasciato a piedi in autostrada. 4 volte. Mai avuto
un problema serio con tutte le altre auto che ho guidato (perlopiù
Suzuki, Kia, Opel e Renault), anche in viaggi di oltre 10 mila KM
(i.e. questo andata, ritorno e giri vari: <http://maps.google.co.uk/
maps/ms?
doflg=ptk&ie=UTF8&msa=0&msid=114632994573007245155.00047f63d11cabde2742f&ll=38.651198,24.257813&spn=24.638498,39.506836&z=5>).

--
ale
http://ale.riolo.co.uk
Continua a leggere su narkive:
Loading...