 |
|
|
 |
|
|
|
Nell'azienda per cui lavoro stiamo valutando
l'adozione di Linux in progetti embedded, alla notizia, uno degli attuali fornitori ha scritto
ad un mio collega la seguente lettera:
....
Per quello che riguarda Linux le posso dire che nostri clienti come ... (lunga lista di aziende n.d.r.)
hanno provato ad intraprendere questa strada facendo pero' subito marcia indietro principalmente per i seguenti
motivi:
- mancanza di tools di sviluppo adeguati per lo sviluppo SW professionale/industriale
- utilizzo di una soluzione ibrida e non veramente real-time da non permetterne l'utilizzo in progetti dove il real-time e
il time-critical sono richiesti. Gli stessi Linux Realtime si basano su un'architettura fatta da 2 kernel.
Uno che gestisce gli eventi di basso livello e l'altro che gestisce i classici processi UNIX;
il sotto-sistema di Networking (stack TCP/IP per intenderci) e` schedulato da questo secondo kernel, quindi applicazioni che richiedono prestazioni di networking non trovano certo applicazione.
Addirittura le API ed il debugging sono diversi nei 2 Kernel.
- Difficile portabilita' all'interno della stessa famiglia di microprocessori o su processori diversi.
- maggiore consumo ed esigenze HW come memoria e CPU data la non scalabilita' del sistema operativo.
- troppe varianti ed incompatibilita' tra la miriade di Linux, Linux Embedded e Linux Realtime esistenti e poca fiducia sulla loro duratura presenza sul mercato sia come prodotti di riferimento, sia come assistenza e supporto tecnico sia come societa' di consulenza a cui affidarsi.
- Maggiori costi di gestione per le continue attivita' di consulenza necessarie per personalizzare, manutenere, aggiornare ed integrare nuove funzionalita' che appunto non sono "free" ma vengono lautamente pagate cosi' come estensioni particolari alle quale poi si rimane legati come ad un "sistema chiuso" e non ad un "sistema aperto" come si vuol far credere.
- problemi legali legati all'utilizzo della General Public License (GPL) che regola l'utilizzo di Linux e di tutti i suoi derivati e di come questa produca problemi di Intellectual Properties ai clienti che devono mettere a disposizione della comunita' tutti i sorgenti utilizzati per i progetti che utilizzano Linux.
Tutto questo e' accentuato anche dalle condizioni in cui sitrovano oggi i maggiori "fornitori" di Linux
http://linux.html.it/news.asp?newsid=204
http://www.linuxvalley.it/news/news.php?IdNews=702
http://www.linuxvalley.com/news/news.php?IdNews=804
Come ultimo esempio vorrei riportarle un caso di "vita quotidiana" appena successo in America ad un mio collega.
In August, we won a new design with a startup building a wireless access
point. When they approached us, they had a simple working prototype
running Linux on PPC. They needed a bunch of protocols similar to Tornado for Home Gateway, and
we selected a hardware partner who provided HW and BSP, so we won the business.
They are now 1.5 months into using THG, have made rapid progress
and are very happy with the decision to go with Wind River.
On a recent followup visit, I asked them about why they decided to dump Linux.
They told me:
1) In order to get something working, they had to pull bits of code from
numerous places. They said it was a code fragmentation and version control
nightmare. They wasted lots of time integrating and managing this mess. By
comparison, THG, well, works. They are very happy with the speed of
their development now.
2) As they were developing their access point functions, they started
getting demands from Linux developers to post their code. They realized
that their critical Intellectual Properties was at risk.
Non sto' "sparando" sulla concorrenza, Le ho solo riportato i fatti.
e spero che possano esserLe utili.
...
Non vi sembra che il tono di questa lettera ricordi il FUD diffuso da Micro$oft alcuni anni fa ?
Vi prego di notare i riferimenti al sistema "chiuso" (da che pulpito!), le virgolette attorno alla parola fornitori ed il significato della G di GPL.
|
|
|
|
|
· 