La via all'OpenSource - UPDATED AGAIN!
Allora, riprendo il discorso iniziato con il precedente post, dato che ho ricevuto diverse mail relative alla cosa. Quasi tutte le mail riportavano piu' o meno le stesse cose. Ma andiamo con ordine.
Come detto nel post precedente, Microsoft ha deciso che il CERN non si qualifica come "istituto didattico" e quindi ha deciso di applicare al nuovo contratto i termini "normali" che si applicano a qualunque azienda che usufruisce dei suoi servizi. Ora, che il CERN sia o no un "istituto didattico" si puo' discutere, ma il fatto che il CERN stesso non si sia messo in testa di discutere la cosa per vie legali mi lascia pensare che sanno benissimo che la definizione non si puo' propriamente applicare e Microsoft e' nel legale nel fare cio'.
Che Microsoft abbia agito in modo intelligente o no e' anche da discutere. Avrebbero potuto tranquillamente rinnovare il contratto precedente agli stessi termini o rivedere i termini in modo piu' vantaggioso, se hanno deciso di non farlo sono problemi loro e sono piu' che sicuro che la cosa sia stata discussa parecchio tra i vari interessati. In ogni caso, la faccenda e' decisa ed e' abbastanza inutile stare li' a discuterne troppo.
Il punto del mio discorso era rispondere alla domanda che mi e' stata domandata: "questo portera' alla nascita di una nuova 'piattaforma ibrida' che permetta di far girare applicazioni Windows su Linux o viceversa?". E la mia opinione e' No, perche' non serve a niente e lo abbiamo gia', e rifare la ruota d'accapo un'altra volta non credo che portera' a nessun vantaggio per nessuno. Inoltre, il CERN ha gia' uno scopo che non e' sviluppare software, lasciamo che facciano il loro lavoro.
Tuttavia, come gia' ho fatto notare precedentemente, ognuno ha le sue opinioni e le sue convinzioni e va bene cosi', e qualcuno ha la necessita' impellente di volere a tutti costi cambiare le mie anche se ho gia' detto piu' di una volta che non me ne frega niente. Una delle cose che mi e' stata fatta ripetutamente notare e' che "...le apparecchiature ... hanno delle esigenze particolari a livello software e probabilmente i vari automatismi di controllo e gestione sono scritti per windows...", quindi virtualizzare non fa risparmiare soldi perche' devono pagare le licenze.
Il che e' corretto... Ma questo mi ha fatto pensare ad un'altra cosa.
Analizziamo bene questa frase: ..le apparecchiature ... hanno delle esigenze particolari a livello software e probabilmente i vari automatismi di controllo e gestione sono scritti per windows... I vari automatismi di controllo e gestione sono scritti per windows.
...Perche'?
Allora, come ripeto spesso e volentieri, Unix esiste dal 1970. Windows esiste da un po' dopo. Anzi parecchio dopo se vogliamo considerare 'Windows' come il Sistema Operativo e non semplicemente una mano di vernice grafica su MS-DOS, possiamo cominciare a parlare di Windows dal 1995 in poi. E dal '95 esisteva anche Linux che io cominciai ad usare a tempo pieno all'epoca. Quindi.... Perche'?
Se effettivamente lo scopo e' risparmiare dei soldi, perche' tutta quella roba e' scritta per Windows? Se e' scritta "in casa" o da software house sotto contratto, perche' non scriverle per Unix (e quindi facili da portare da una versione all'altra) invece di scriverle per Windows che all'epoca non e' che fosse una cosa troppo stabile oltretutto?
Siamo nel 2019 (quasi 20 oramai), quindi sta roba e' stata sviluppata tempo addietro e qualunque idiota al CERN (assumendo che gli "idioti" del cern siano molto piu' intelligenti della media degli idioti altrove) avrebbe dovuto capire al volo che usare un sistema proprietario non era una grande idea, quindi il richiedere un prodotto portabile avrebbe dovuto essere una priorita' nel progetto.
E il CERN non e' affatto da solo nella faccenda.
Durante il week-end mi sono ritrovato a guardare un po' di documentari sulla fabbricazione di varie cose, e la cosa che mi ha lasciato un pelo perplito sono queste fabbriche ultrasofisticate con robots e controlli computerizzati ovunque, ma ogni volta che si vedono dei tecnici controllare o programmare le macchine, quello che salta fuori sullo schermo e' una bella schermata con Windows. Perche'?
L'anno scorso c'e' stato il grande casino con WannaCry e compagnia cantante, ransomware specificamente disegnati per Windows, ed il numero di grosse aziende con decine di migliaia di macchine Windows "non-upgradabili" perche' attaccate a sistemi di produzione o strumentazione ultrasofisticata (ed ultra-costosa) era da capogiro. Ed ovviamente su tutte le pubblicazioni (on ed off-line) i Nerdioti si sprecavano a strillare che "puoi fare lo stesso con 2 dollari e Linux"... Certo, puoi farlo, ed allora perche' non lo hai fatto prima?
Perche', come ho gia' detto, non e' che Linux e' arrivato oggi o ieri, e' qui da almeno una ventina d'anni oramai.
Quindi quale e' il problema? Se Linux e' cosi' bello e fantastico e scrivere programmi per Linux e' tanto una passeggiata, perche' tutta questa roba sembra sempre fatta per Windows? Come mai Windows ha una tale penetrazione in un mercato che NON E' il desktop mentre Linux, che dovrebbe essere avvantaggiato, non e' nemmeno considerabile?
Ora, io non ho mai sviluppato software per sistemi embedded o macchine a controllo numerico o altro quindi non ho alcuna idea al riguardo, quello che posso ipotizzare e' che scrivere software per Windows per quella roba sia molto piu' semplice che farlo per Unix.
E la cosa che mi lascia piu' perplesso e' che nel grande marsma di primedonne isteriche che e' il "mondo" di Linux, nessuno sembra preoccuparsene.
Facciamo un esempio idiota. Quanti MTA esistono per Linux/Unix? Io ne conto almeno 4 senza dover cercare su google. Probabilmente di piu'. Ma se vogliamo qualche cosa che sia paragonabile a quello che fa Exchange... il numero scende a zero. L'unica cosa simile e' Zimbra. E Zimbra non e' gratuito manco per un po'. Anche se si basa su roba che e' OpenSource. Ora, io mi aspetterei che un bel nutrito gruppo di Nerds cominciasse da zero a scrivere qualche cosa di simile che non solo fosse funzionale ma, soprattutto, potesse anche supportare Outlook nativamente. Quello che vedo invece e' che tutti sono li' che si picchiano per forkare distribuzioni perche' la loro distribuzione preferita ha deciso di cambiare il colore del proprio logo o qualche stronzata simile.
E questo, e' il motivo per cui quando leggo cose come "X (con X=grosso ente, societa', comune o chessia) vuole migrare tutto su Linux", penso "no, tu non vuoi farlo, e te ne pentirai".
ADDENDUM
Ivo Gandolfo, che sembra saperne di automazione industriale et similia, mi manda la seguente missiva, che io pubblico in toto:
Ora, quando si parla di sistemi embedded o in generale di "Automazione Industriale", i nomi "principi" o "regnanti" sono Siemens per PLC e KUKA per i robot antropomorfi (per il mercato europeo), Allen-Bradley e ABB (per il mercato USA e affini), Omron e FANUC (per il mercato est-europeo, principalmente Cina e Giappone). Sono altrettanto sicuro che se mai qualcuno leggese mai queste parole aggiungerebbe alla pila altri nomi, ma sicuramente sono minoranze sconosciute ai più, e probabilmente realtà "locali" esportate chissà come, e implementate pure peggio.
Andando a guardare lo storico di queste case si nota che _tutti_ i software di programmazione (o suite che dir si voglia) hanno installer _solo ed esclusivamente_ per DOS/windows (da DOS3.0 per STEP5 di Siemens, fino a Win10 per le ultime incarnazioni). Esistono aborri anche per vecchi OS tipo OS/2 Warp, però giravano su pc con hardware proprietario e non sono durati a lungo (famose sono le "valigette" si Siemens, pc con hardware dedicato per connettersi ai propri PLC).
Quindi a parte piccole eccezioni (ad esempio i pannelli operatore touch screen di Siemens da 7" in sù che hanno un linux molto tarocco al loro interno per costare poco) il tutto ruota sul mondo Microsoft, che sia Win95/Win10 (per lo sviluppo) o un WinCE (per i runtime).
Ah già! i runtime. Che cosa sono? Semplicemente il modo in cui un essere umano colloquia con i PLC/macchinario. Ora, io un giorno mi sono diverito a prendere il progetto compilato e caricato su un pannello operatore, e l'ho aperto con un editor esadecimale. C'erano scritte JAVA praticamente dappertutto. Quindi l'ambiente di sviluppo genera un file JAVA (anche se ha estensioni esoteriche come .rtx o .abc), lo carica sul pannello operatore (via FTP principalmente) e lancia una VM Java. Tutto qui. Ecco spiegato perchè un progetto Siemens di pannello per un pannello TP700 (che ha un linux tarocco sopra) funzioni egregiamente anche se caricato su un TP1500 (che ha una versione tarocca di WinCE, 7.0 credo).
Anche i vari ambienti di sviluppo sono cambiati negli anni. I principali produttori sono passati dal classico C (es. STEP5, RSlinx500) al più comodo JAVA (TIA portal, Studio 5000), si è notato questo dai vari crash che hanno giornalmente le varie suite. Quindi il perchè non facciano anche installer/ambienti di sviluppo anche per linux non si capisce, visto che JAVA e multi-platform per definizione, tantè che lo usano anche per i vari OP.
Il perchè probabilmente come hai notato tu, è la frammentazione che hanno i vari linux, e quindi non abbiano tutta questo/a tempo/voglia di reinventarsi la ruota a ogni soffiar di vento. Inoltre parecchie cose (tipo Siemens WinCC SCADA per citarne uno) utilizzano cose native per windows (tipo IIS per la gestione/publishing web, active directory per l'utenze) che su linux non esistono oppure sono implementate in modo molto esoterico, e che quindi non sarebbero di facile utilizzo nelle loro suite.
Quindi per ricapitolare quasi tutto l'ambiente per domotica/automazione industriale/embedded ruota attorno al mondo windows è perchè:
- Come hai notato tu, il sistema Windows negli anni è diventata una buona piattaforma, peccato che i soggetti non abbiano mai fatto dei "porting" tra le varie evoluzioni (vedi Allen Bradley), e se le hanno fatte falliscono più si che no (vedi Siemens), il che significa che costa molto di meno rifare il progetto da 0 che fare un porting, e quindi ci sono in giro ancora oggi macchine con Win95 o peggio DOS perchè "costa troppo portarlo su piattaforma recente". E quando il macchinario si rompe si sostituisce il tutto in toto perchè oramai ha esaurito il suo ammortamento e quindi è giustificabile rifare tutto. Ai manager non interessa che sia "poco" sicuro. A loro interessa il profitto. Poi se arriva Wannacry e affini il colpevole è sempre il sysadmin, o qualcun'altro, ma mai loro.
- Il sistema linux, sempre come hai notato tu, è troppo frammentato, 9 volte su 10 ci si deve reinventare la ruota, mantenere troppi rami paralleli di sviluppo è troppo costoso (vedi per analogia Win XP, 7 e 10) e dal '90 ad oggi non è che sia stato fatto molto per riunificare il tutto, o comunque mantenere una base "stabile" per tutti (solo Debian da sola con il suo PM "snatura" l'aberatura classica)
- Anche se oramai quasi tutti sono passati dal classico C (e sue evoluzioni) a JAVA, o sono in procinto di farlo, ci si scontra con un fatto ineluttabile: il sistema Windows e il sistema Linux/Unix/MacOS sono mondi esattamente opposti, per i più svariati motivi già elencati da te e non ripeterò. E alle aziende mantenere rami di sviluppo costa assai. E poi la motivazione principe può sempre essere "Se Funziona Quel Tanto Che Basta Soprattutto Non Toccare Che Poi Si Guasta", quindi cambiare perchè? Come hai fatto notare tu una volta quando quel UL voleva "scipparti" la rete perchè non era gestita come in $GuardiamoBelleStelline, sul mercato odierno 8 pc su 10 venduto è con Windows, 1 su 10 è MacOS e 1 (forse) è senza OS oppure ha un Linux tarocco. Quindi io come azienda (che sia Siemens, AB o altre) che interesse ho a fare una suite che funzioni su una piattaforma che è venduta 1/10? nessuna. Mi bastano gli 8/10. E gli altri 2 vanno di VM o affini, visto che oramai la tecnologia c'è (scusa del ca$$o, non giustificabile ma comprensibile dal punto di vista del management).
- Disgressione personale: io sia sui miei pc personali che quello lavorativo ho sia linux che win10 in dual boot. Quando lavoro su linux, ed ho parecchie VM aperte (principalmente VmWare) e molti schermi davanti parecchi miei colleghi e/o clienti e/o concorrenza rimangono sbigottiti del perchè mi ostini a usare "quelle finestre DOS"[cit.].
Io utilizzo linux e VM semplicemente perchè rispetto a win ho una gestione miglione del multi-head, cioè riesco a fargli fare quello che voglio io nel minor tempo possibile (come te insomma). Per tutto il resto (giochi online principalmente) uso windows. Solo perchè ha la gestione migliore di tutto il resto oppure la roba esiste solo per quello, ed emularlo (come hai notato anche tu) è una chiavica pazzesca.
- Quindi la tua prima frase è assolutamente vera (i sistemi dipendono da win*) e la seconda non è che sia più facile sviluppare su win piuttosto che su linux, è che su linux _non esiste nulla_ di quella roba, e quel poco che c'è è fatto da 2 appassionati ed è tutto fatto in java principalmente, linguaggio che non tutti masticano e quei pochi che lo utilizzano sono in un mercato molto di nicchia.
Questo è quanto nel mondo dell'automazione. Se intendi pubblicarlo sul tuo sito sentiti libero di citare questa email come più ti aggrada, e come da te richiesto ti cedo tutti i diritti di utilizzo che ritieni opportuni.
Quindi, che sia Java sotto al coperchio non mi sorprende molto, mi sarebbe sembrato strano se fosse direttamente Assembler o simile, ma quello che mi perplime e' che, come dici tu, "non ci sia niente di quella roba su Linux". Scrivere codice Java o non Java non dovrebbe essere una cosa complicata, far girare una Jvm anche meno. Quindi.... perche'? Mi resta la domanda. Che tutti i programmatori Linux siano troppo occupati a riscrivere d'accapo Systemd o a fare il reverse-engineering di Microsoft Word?
...ed ecco il secondo aggiornamento:
- La programmazione dei PLC e sistemi SCADA in generale seguono IEC 61131-3 standard. Ora, se te lo vai a leggere molto probabilmente esclamerai un "WTF?!? che è sta merda?". Ed è quello che io ho sentito dire praticamente a tutti gli sviluppatori "agili" (come li definisci tu) di nuova generazione. Devi sapere che tutti i programmatori PLC esistenti, la "vecchia guardia anni '60/'70" sono degli elettricisti riciclati oppure gente con lauree dei tempi che all'università o alle scuole superiori si studiavano gli standart che all'epoca erano attuali, e la generazione intermedia (la mia praticamente, anni 80/90) che erano in mezzo alla transizione da linguaggi "vecchi" e i nuovi stile C/Java. La gioventù quelle robe non ne vuole sapere. Mentre per fare un giro di "WHILE.. DO" ora basta una riga di codice, con quel standart bisogna scrivere almeno una 30ina di righe per fare la stessa cosa.
I PLC moderni stanno cominciando a integrare anche linguaggi moderni (stile BASIC, vedi SCL di Siemens) che aiutano, ma sono _MOLTO_ diversi dai linguaggi a più alta astrazione tipo il C, o meglio JAVA, e per un programmatore moderno quei linguaggi sono arcaici e inutilizzabili (comprensibile, ma non giustificabile). Tutto questo te lo può confermare Luca Bertocello, visto che programma Arduino o similari, che al contrario di PLC di fascia alta, implementa un semplice linguaggio C, che a detta di molti è "alieno". Ti faccio un esempio: ho fatto di recente un piccolo banchetto di lavoro, ed ho utilizzato per qualche funzione quei linguaggi "moderni" (alcuni cicli while etc). Quel progetto visto dal mio capo (laureato, ma di 60 anni) "che è sta roba? ma funziona veramente?". Detto questo detto tutto. I vecchi non vogliono aggiornarsi, e i giovani non voglono tornare indietro. Di nuovo idee comprensibili, ma non giustificabili. Ovviamente ognuno ha il suo punto di vista (mi manca poco alla pensione/perchè usare roba cucca e stra-cucca?), ma se facessimo tutti così non si andrebbe avanti (dicevi della stagnazione di linux?)
E perchè viene usato quello standart e non solo linguaggi moderni dirai tu? Semplice: sono più stabili di una pietra tombale egiziana, una Rolls Royce del sistema di automazione. Vedi progetto Apollo con cui siamo andati sulla luna. La regola "Semplce&Stupido" a quanto pare funziona. Mai visto nella mia carriera un PLC fallire per mala programmazione, solo per difetti hardware. Un programma PC, per semplice che sia, quante volte lo hai visto crashare? Ecco, appunto. E di solito, quanti bachi si tira dietro tra una release e l'altra? Ariecco, appunto.
- Perchè gli sviluppatori non si mettono a guardare quelle robe? I motivi sono più disparati:
1) Qualunque azienda quando ti commissiona un'isola di lavoro, o un banchetto in automazione vuole nomi noti e conosciuti, ma soprattutto che garantiscano stabilità (vera o presunta che sia). Se io mi presentassi con la libreria "libnodave" scritta da un Davide tuo omonimo, e per giunta italiano (funziona! e anche bene. Tant'è che alcuni progetti in giro di interfacciamento usano quella libreria che ti accennavo nella mail precedente) FCA, Renault, Skoda etc mi scoppierebbero a ridere in faccia dicendomi "ma perchè non usi WinCC SCADA che funziona e non dà noie?". Motivo principe del perchè nessuno sviluppa. Finchè questi progettini non vengono acquisiti da realtà più grosse nessuno se li fila di striscio (vedi Siemens che ha acquisito anni fà Logo! e che ora ha una buona fetta di mercato).
2) Le varie Case non rilasciano driver di comunicazione, oppure API, oppure standart e definizioni. Devi usare la loro roba (e che di solito costa uno sproposito) e o se lo fanno sono a tecnica "scatola nera". Quindi chiunque lo faccia lo fà per un business futuro (vedi Hilscher che ha una sua serie di prodotti di interfacciamento). E tutto questo è frutto di reverse engeniering. Quindi suppongo che abbiano investito milioni e che ora si aspettino un ritorno. Anche loro (ovviamente) niente progetti pubblici. Motivo principe anche qui.
3) Perchè rifare qualcosa che già esiste una cosa che fà quello che mi serve e funziona? I vecchi la pensano così, e i nuovi idem solo con la scusante dei linguaggi bacucchi. Quindi che si mettano a rifare SystemD o MS Word non inficia più di tanto l'ecosistema. Anche perchè l'ecosistema _non esiste proprio_, a meno che una di queste Case lo crei, ma visto il business dei milioni che girano dubito seriamente lo faranno. E' l'eterna lotta: basta vedere i driver Nvidia, su win funzionano da Dio, e su linux lasciano il tempo che trovano, e le varie reincarnazioni free non sono esattamente dei giolielli della corona ma per quanto ne sò il popolo che ci lavora attorno è abbastanza numeroso. Infatti (quasi) nessuna Casa videoludica si mette a sviluppare giochi per linux, e Valve è una rara eccezione, ma non tutti i capitoli esistono. Quindi senza un ritorno economico (nel corto/lungo periodo, vero o presunto che sia) è controproducente se non perdita totale di tempo.
4) Stiamo sempre parlando di roba che è nata tra gli anni 60 e 70, che già all'epoca era vecchia, infatti basta quello per vedere i disastri dei vari IoT che sono in giro, zero sicurezza. E i programmatori non aiutano. Quella roba è nata per stare offline, staccata da tutto etc.
Ora con l'Industria 4.0 si vuole tutto online&alwayson (che come tu ben sai è preludio al disastro). Scrivere roba in java non è difficile come dici giustamente tu, ma se ci metti uno standart vecchio & bacucco, nato insicuro by desing, le Case non collaborano, i programmatori neanche, non hai ritorno economico, non almeno nel futuro prossimo, mercato molto di nicchia, eccoti la risposta del perchè rifanno SystemD e non un driver per PLC, o un porting su linux della roba. Rifare SystemD ha una certa "notorietà" (almeno, nei changelog), in un driver misconosciuto neanche tanto, almeno se non sei del "giro" (scommetto che non avevi mai sentito parlare del tuo omonimo e della sua libreria . E questo è vero per PLC, CNC, IoT e tutto ciò che riguarda l'automazione/domotica.
Quindi la colpa "principe" è da dare alle varie Case che stanno mantenendo una sorta di Monopolio virtuale sullo stato delle cose (visto che libnodave esiste e funziona significa che come dici tu la roba si può fare, ma non c'è nè la gente nè la voglia di farlo, soprattutto senza un ritorno quasi immediato dell'investimento). E finchè esisterà la "vecchia guardia" la roba sarà sicura (o quasi). Io già ho paura quando subentreranno i vari programmatori "agili" e obbligheranno le varie Case (o lo faranno di loro sponte) a implementare il loro linguaggio preferito nei PLC, e vedremo di nuovo Černobyl' da qualche parte (te lo immagini un PHP su PLC? Brrrrr....). Purtroppo molte Case sono già su questa strada.
Spero di essere stato esaustivo.
...piu' di cosi'...
Davide Bianchi
24/06/2019 09:38
