Newsgroup: it.comp.os.dibattiti
Titolo: [rant] Linux embedded? No grazie

situazione:
la mia azienda produce apparati per tlc. più o meno l'apparato su cui 
lavoro io (microwave relay per connettività point-to-point PDH + 
Ethernet 10/100/1000), che chiameremo A, ha sempre venduto 
discretamente ed è sempre stato apprezzato dai clienti. Tuttavia 
essendo in giro dal 2001 dimostra i suoi anni, nonostante le 
successive evoluzioni; noi di R&D avevamo già in fase avanzata la 
progettazione di una nuova generazione di apparati, quando a sorpresa, 
un annetto e mezzo fa, ci siamo fusi con dei finlandesi, che avevano 
pronto un nuovo apparato atto allo stesso scopo, che chiameremo B.
ora B era "quasi pronto" nel senso che era inutilizzabile e stapieno 
di bachi. ci facciamo spedire prototipi di apparato, incominciamo a 
testarlo, troviamo problemi a manetta, codice bloated, instabilità 
complessiva etc. va beh, iniziamo a riportare i problemi, nel 
frattempo i finlandesi fanno outsourcing di dipendenti softwareisti, 
sicchè ogni 2 mesi cambiano i nostri interlocutori e bisogna 
ricominciare da capo. L'app. A nel frattempo va in maintenance 
perpetua, ma B non è pronto ad essere venduto. Ogni pezzo di codice 
atto a una certa funzione è sviluppato da una persona diversa ed ogni 
pezzo si incastra con l'altro alla pene di levriero.
Cosa cambia in B rispetto ad A? A è su piattaforma PowerPC; ha una 
flash memory di 16 mega su cui viene caricato un applicativo 
monolitico di circa 6 mega (altri 6 mega sono usati per il backup 
dell'applicativo che era precedentemente installato, e il resto è 
libero); sull'apparato gira VxWorks, un demone ftp, una seriale in 
ascolto, una doppia porta Ethernet per la connettività di supervisione 
degli installatori, e poca altra roba. L'apparato A è modulare: 4 
schede hot-replaceable, di cui una con funzioni di Controller generale 
dell'apparato, ciascuna board ha con la sua FPGA che viene programmata 
dall'applicativo monolitico di prima ad ogni reboot. Risultato? 
robusto come una roccia. uptime e MTBF stimato dalle installazioni sul 
campo paurosi.
passiamo a B: stessa medesima piattaforma PowerPC, modulare anche esso 
(6 moduli), ogni modulo ha 60 megabyte di flash, l'applicativo che 
viene installato occupa 23 mega e viene replicato su ogni scheda, 
anche nelle parti di codice che non servono a nulla su quella scheda 
(questo perchè non esiste una vera scheda che faccia da Controller), 
ci gira Linux per ppc con busybox, attualmente alla versione 
2.6.15qualcosa, ci sono tonnellate di servizi inutili (5 serventi ftp, 
ssh, telnet, interprete perl, webserver, yadayadayada) per 4 
interfacce di supervisione. Risultato: kernel panic ad ogni hot-
replace delle schede (e anche senza far niente a volte), traffico 
perso, installazione di nuover versioni dell'applicativo che 
falliscono il 90% delle volte (non è una iperbole) -- e te credo, con 
tutto quel pò pò di software da caricare ogni volta -- e altro che non 
sto a tediarvi. inoltre, come ho già detto, codice super-bloated: ogni 
baco segnalato ci mette 4 mesi ad essere risolto.
a valle di tutto, l'apparato B non è ancora pronto ad essere venduto e 
nonostante tutto sti deficienti di finlandesi, che sono convinti di 
avere fatto un buon prodotto, continuano ad aggiungere carne al fuoco 
con evoluzioni successive del software e supporto ad ulteriori schede 
(es. board per interfaccia STM-1, board per connessioni proprietarie 
alle BTS, etc...).
so già che mi si risponderà che non è un problema di linux di per se; 
sono d'accordo, difatti è un problema dei deficienti che pensano che 
linux sia bello ovunque ma poi non lo sanno programmare.

 linux sia bello ovunque ma poi non lo sanno programmare.
e allora datti da fare
-- 
Pandozy vede tutto
    _   _
  O'|,=,/'O
    (0 0)
ooO--(_)--Ooo

capitan harlock ha scritto:

attualmente ho sotto le mani un problema molto simile al tuo. Quello che
penso è che certi sviluppatori possano usare qualsiasi s.o. ma il
risultato non cambierà.
Dopotutto la risposta ai tuoi problemi te la sei già data: design
hardware e software penoso. Per il resto 23 mg di linux embedded sono
tanti, anche se non penso arrverai facilmente ai 6 di vxworks. Tra s.o.
e binari fpga probabilmente puoi scendere ad una dozzina di mega.

 
Mi hai tolto le parole di bocca.
Anche perchè da noi la situazione è esattamente capovolta, da quando 
abbiamo deciso di passare ad arm9 con linux a bordo abbiamo cominciato a 
vedere la luce e a sentire musiche celestiali: un paradiso.
Ciao.

capitan harlock ha scritto:

A parte le questioni tecniche , la dirigenza che pensa ?
Ha trovato/proposto soluzioni ?

capitan harlock ha scritto:

A parte le questioni tecniche , la dirigenza che pensa ?
Ha trovato/proposto soluzioni ?

 linux sia bello ovunque ma poi non lo sanno programmare.
Scrivo io che è noto non abbia particolari simpatie per Linux.
Senza leggere la parte in cui descrivevi i problemi specifici del device
B, si capiva che qualcosa non andava. Avete un problema di gestione del
progetto grosso come una casa. E non c'è Linux che tenga.
Io credo che quelle persone, se anche avessero usato come base altro,
avrebbero scritto un cesso. 
Se mi sbaglio, mi sarei aspettato un post *preciso* sul perchè
sviluppare su Linux sarebbe stato molto più difficile che su VxWorks.
Cosa che può benissimo essere, veh. Ma io da voi vedo un problema
grossino a monte.
-- 
-riko

On 26 Set, 10:39, 
r...@despammed.com
 (Enrico Franchi) wrote:

Io nutro simpatie per linux, ma per il resto quoto e sottoscrivo.
Raffaele