June 2021 - nexa - server-nexa.polito.it

Re: [nexa] Why Computing Students Should Contribute to Open Source Software Projects

by 380°

Buongiorno, grazie Stefano per aver condiviso la tua esperienza (e quella di altre università) in merito Stefano Zacchiroli <zack(a)upsilon.cc> writes: [...] > Ci sono poi anche problemi etici da discutere. In particolare si può > argomentare che in questo modo l'università faccia offloading di una > parte delle sue responsabilità didattiche su maintainer di progetti > FOSS non pagati ne formati per questo (che siano volontari o pagati da > altri, il problema resta). Personalmente ritengo possa essere > accettabile perché "in cambio" gli studenti contribuiscono ad un bene > comune (il software commons), ma i ruoli devono essere chiari a tutti > i partecipanti. Molto interessante quello che dici, mi verrebbe da considerare che le università dovrebbero avere come missione quella di contribuire ai commons in tutti i campi di ricerca, quindi non sarebbero tanto gli studenti che hanno qualcosa "in cambio" ma tutto ciò farebbe parte del compito istituzionale dell'università. Sul "rischio di offloading" poi, mi viene da dire che l'università dovrebbe considerare queste attività come un'estensione delle proprie responsabilità didattiche /anche/ nei confronti dei maintainer FOSS (pagati o non) che /a volte/ (spesso) non sono formati per quella parte di "didattica" che io vedo presente in /tutti/ i progetti FOSS... a volte gli "upstream maintainer" stessi avrebbero bisogno di un supporto formativo (tutoring?) per quelle attività per le quali non sono ben preparati (e ce ne sono). Insomma, nel rapporto tra FOSS e università io ci vedo solo un win-win e mi piacerebbe che nel ciclo di vita del software, dal kernel alle web app, le università fossero maggiormente coinvolte, istituzionalmente intendo. Tra l'altro, secondo me non è un caso che il software più innovativo che io vedo in giro [1] viene da lavori universitari, dove alcuni singoli docenti o bravi studenti coordinano il lavoro (anche dopo che sono usciti). > In secondo luogo si pongono spesso problemi di diritti, ad esempio nel > caso di progetti FOSS che richiedono un copyright assignment ad > aziende for-profit come condizione per accettare patch. Faccio stare i > miei studenti alla larga da tali progetti, per evitare che > l'università di fatto regali manodopera a costo zero a privati, ma > questo tipo di verifiche non è particolarmente scalabile. Sì questa è una condizione particolarmente delicata, tuttavia il /grosso/ della differenza la fa /quale/ licenza: copyleft o no. Fossi io il rettore di una università, nel 2021, scriverei nero su bianco che docenti e studenti NON devono collaborare (istituzionalmente ovviamente) a software non copyleft, perché la vera manodopera a costo zero regalata a privati è quella che sviluppa software non copyleft, ovvero software che può essere (ed è) redistribuito in forma proprietaria, modificato o meno, da /chiunque/. Se il software fosse copyleft, invece, il copyright assignment permetterebbe la proprietarizzazione solo al titolare: non è poca cosa ma nel caso fosse evidente un abuso di posizione dominante (o di sfruttamento manodopera gratuito) un fork sarebbe alla portata di "due click". Anche in questo aspetto, ovvero del rapporto tra aziende private e università, mi piacerebbe che quest'ultima fosse il /traino/ di un sano sviluppo di commons (tra cui il software ovviamente)... ma a me pare invece che negli ultimi decenni sia tutta una /rincorsa al contrario/, dove cioè sono le università a cui si chiede di diventare aziende per promuovere "startup spin-off", dove sostanzialmente la PRIVATIZZAZIONE (attraverso marchi, brevetti e copyright... la chiamano proprietà intellettuale... POVERA università!) è sia il mezzo che il fine della propria missione. Io ho il fondato sospetto, invece, che SE (quando?) fosse l'università a CONDURRE lo sviluppo dei commons (tutti), ANCHE invertendo l'assegnazione del copyright :-D, allora «si può sperare che il mondo torni a quote più normali» [...] Saluti, Giovanni. [1] io ho un criterio "mei generis" in mertio al grado di innovazione: GNUnet, Taler, Nix e NixOS, Guix... Plan9 e famiglia: quelli sono innovativi. P.S.: negli anni '70 del secolo scorso il governo USA investì quantità indecenti di denaro pubblico per promuovere nelle università lo sviluppo di software NON copyleft (sostanzialmente licenza MIT), quello che tutt'oggi permette agli USA di essere il mostro che sono, da questo punto di vista. Comunque quelli sono tempi andati, nessuno pensi di ripetere una roba del genere, manco la Cina riuscirebbe nell'intento oggi. Commons, roba antica che ci salverà il futuro. -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

June 23, 2021

Re: [nexa] Why Computing Students Should Contribute to Open Source Software Projects

by VETRO' ANTONIO

Condivido le due problematiche. Condivido (in un altro senso) anche che, nel nostro piccolo del corso di Software Engineering 2 a PoliTO con il collega Torchiano, facciamo sviluppare progetti Open Source su GitHub in gruppi da 5-6 persone, anziché far intervenire gli studenti su progetti esistenti. Così facendo si limano se non eliminano questi due problemi da te citati. Se ne introducono altri, ovviamente, ma di diversa natura. Mi fa piacere leggere dalla tua mail che non sono poche le università che fanno cose simili da tempo. Ciao! A. > Il giorno 23 giu 2021, alle ore 10:18, Stefano Zacchiroli <zack(a)upsilon.cc> ha scritto: > > On Wed, Jun 23, 2021 at 07:52:07AM +0000, VETRO' ANTONIO wrote: >> Bella idea, con annessa struttura del corso che l’autore dell’articolo tiene nella propria università. Pratica da imitare, a mio parere. >> https://cacm.acm.org/magazines/2021/7/253459-why-computing-students-should-… > > ... da imitare, e fortunatamente imitata da molti, compreso Diomidis. Lo > sottolineo qui giusto per mettere in evidenza che questa (buona!) > pratica esiste ormai da più di un decennio in svariate università > europee. Nel mio piccolo tengo dal 2014 un corso di software libero à > Université de Paris che applica questo tipo di approccio pratico con > successo. Essere testimoni, anno dopo anno, della soddisfazione degli > studenti quando la loro prima patch ad un "vero" progetto FOSS viene > accettata è una delle ricompense più belle della mia carriera di > insegnante. > > Il problema a questo punto è far diventare queste esperienze didattiche, > che restano ad oggi sporadiche, la norma nella formazione degli > sviluppatori. Un modo è quello di passare dai curriculum istituzionali > tipo quello ACM citato da Diomidis, non perché siano adottati in toto > dagli atenei (non è così e non sarebbe nemmeno il caso che lo fossero), > ma perché aumenterebbero la visibilità dell'approccio. > > Ci sono poi anche problemi etici da discutere. In particolare si può > argomentare che in questo modo l'università faccia offloading di una > parte delle sue responsabilità didattiche su maintainer di progetti FOSS > non pagati ne formati per questo (che siano volontari o pagati da altri, > il problema resta). Personalmente ritengo possa essere accettabile > perché "in cambio" gli studenti contribuiscono ad un bene comune (il > software commons), ma i ruoli devono essere chiari a tutti i > partecipanti. > > In secondo luogo si pongono spesso problemi di diritti, ad esempio nel > caso di progetti FOSS che richiedono un copyright assignment ad aziende > for-profit come condizione per accettare patch. Faccio stare i miei > studenti alla larga da tali progetti, per evitare che l'università di > fatto regali manodopera a costo zero a privati, ma questo tipo di > verifiche non è particolarmente scalabile. > > Ciao > -- > Stefano Zacchiroli . zack(a)upsilon.cc . upsilon.cc/zack . . o . . . o . o > Computer Science Professor . CTO Software Heritage . . . . . o . . . o o > Former Debian Project Leader & OSI Board Director . . . o o o . . . o . > « the first rule of tautology club is the first rule of tautology club » > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

June 23, 2021

Re: [nexa] Why Computing Students Should Contribute to Open Source Software Projects

by Stefano Zacchiroli

On Wed, Jun 23, 2021 at 07:52:07AM +0000, VETRO' ANTONIO wrote: > Bella idea, con annessa struttura del corso che l’autore dell’articolo tiene nella propria università. Pratica da imitare, a mio parere. > https://cacm.acm.org/magazines/2021/7/253459-why-computing-students-should-… ... da imitare, e fortunatamente imitata da molti, compreso Diomidis. Lo sottolineo qui giusto per mettere in evidenza che questa (buona!) pratica esiste ormai da più di un decennio in svariate università europee. Nel mio piccolo tengo dal 2014 un corso di software libero à Université de Paris che applica questo tipo di approccio pratico con successo. Essere testimoni, anno dopo anno, della soddisfazione degli studenti quando la loro prima patch ad un "vero" progetto FOSS viene accettata è una delle ricompense più belle della mia carriera di insegnante. Il problema a questo punto è far diventare queste esperienze didattiche, che restano ad oggi sporadiche, la norma nella formazione degli sviluppatori. Un modo è quello di passare dai curriculum istituzionali tipo quello ACM citato da Diomidis, non perché siano adottati in toto dagli atenei (non è così e non sarebbe nemmeno il caso che lo fossero), ma perché aumenterebbero la visibilità dell'approccio. Ci sono poi anche problemi etici da discutere. In particolare si può argomentare che in questo modo l'università faccia offloading di una parte delle sue responsabilità didattiche su maintainer di progetti FOSS non pagati ne formati per questo (che siano volontari o pagati da altri, il problema resta). Personalmente ritengo possa essere accettabile perché "in cambio" gli studenti contribuiscono ad un bene comune (il software commons), ma i ruoli devono essere chiari a tutti i partecipanti. In secondo luogo si pongono spesso problemi di diritti, ad esempio nel caso di progetti FOSS che richiedono un copyright assignment ad aziende for-profit come condizione per accettare patch. Faccio stare i miei studenti alla larga da tali progetti, per evitare che l'università di fatto regali manodopera a costo zero a privati, ma questo tipo di verifiche non è particolarmente scalabile. Ciao -- Stefano Zacchiroli . zack(a)upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »

June 23, 2021

Zero Trust e Cloud

by Aldo Pedico

Ciao, un mio articolo su Zero Trust e il Cloud. http://www.teleion.it/wp/wp-content/uploads/2021/06/Aldo-Pedico-Zero-Trust-… aldo

June 23, 2021

Why Computing Students Should Contribute to Open Source Software Projects

by VETRO' ANTONIO

Bella idea, con annessa struttura del corso che l’autore dell’articolo tiene nella propria università. Pratica da imitare, a mio parere. https://cacm.acm.org/magazines/2021/7/253459-why-computing-students-should-… "By contributing to open source projects, students acquire in practice a formidable range of skills, knowledge, and experiences, allowing them to work productively as modern well-rounded developers rather than as the lone-wolf coders portrayed by Hollywood" antonio

June 23, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by D. Davide Lamanna

Grazie, Damiano, davvero interventi illuminanti, i tuoi! On 22/06/21 11:52, Damiano Verzulli wrote: [cut] > È in questo contesto --se ho capito bene-- che la proposta del Governo > di andare verso il cloud USA ("...perche' le migliori tecnologie sono > straniere...") è da valutare con attenzione (IaaS => OK; altro => > parliamone!) Permettimi solo di dissentire su IaaS => Ok a prescindere. Per me l'IaaS in Public Cloud è critico, andrebbe adottato solo se non se ne può davvero fare a meno e SOLO valutando attentamente la criticità dell'information disclosure. IaaS in Private Cloud tutta la vita, tutte le volte che è possibile. [cut] > E quindi, per tornare al punto: No! Non è difficile creare un gruppo di > tecnici in grado di abbracciare questa rivoluzione. E se è difficile... > non è certo per colpa delle competenze tecniche. È, viceversa, un > problema di incapacità di coordinamento. E questo, è un problema che > dovrebbe risolvere qualcuno che è pagato per questo. Non certo noi, > 'tecnici'. Applausi a scena aperta! 0// Dopo che l'abbiamo detto, però, come la risolviamo? Io dico la mia. Abbiamo bisogno che persone non-tecniche si interessino di questa tema e lavorino a fianco dei tecnici per imparare insieme e mettere in pratica nuove modalità di coordinamento. Ao', non-tecnici!!! E a voi che parlo! Ve interessa 'sta cosa?!! Fatevela interessà, perché a noi ce servite!!! :-) E' come con la Cybersecurity: qualcuno dei poco-tecnici o (meglio ancora!) non-tecnici, se na sta occupando sempre di più. E per fortuna! Se non fosse per loro saremmo persi! E stanno implementando meccanismi di governance fatti bene, ma BENE. Proprio perché hanno una mentalità organizzativa che il tecnico NON HA. Punto. E' complementare, non in constrasto. Il tecnico storce il naso perché vorrebbe smanettare, ma il tecnico bravo sa che affidarsi ad un bravo architetto, significa mandare le palle in buca. Altrimenti il suo lavoro sarà poco più che un bell'artigianato da mostrare orgogliosamente ai propri amichettx. Si può vivere felici, molto felici, anche così. Solo che non si risolvono i problemi, così. >> Davanti a cose di questo genere la tentazione di consegnarsi con le >> mani alzate al GAM lock-in è forte. > > Non solo è forte. È già un default. Da molti anni. Esatto! > Ma come è possibile non rendersi conto che tale approccio significa > ammettere la propria incapacità (manageriale) di gestire questo processo? Non lo so come è possibile, ma è quello che avviene. E mi ci faccio il sangue amaro! > Ed è un problema "tecnico"? È un problema di "competenze"? ....oppure è > un problema del _NON_ capire come deve essere fatto un certo > organigramma e quale posto/ruolo debba essere assegnato all'IT ? Esatto. > C'e' molta, _MOLTA_, ignoranza. A livello politico, giornalistico e... > ahime', anche fra tecnici addetti ai lavori.... Quindi comunque un po' di ignoranza anche tra i tecnici c'è. Ma quella si risolve facilmente, non mi preoccupa. E l'altra che vedo problematica. > Chiudo dicendo che mi piacerebbe molto "dibattere" su questi temi (che > _NON_ sono tecnici). E se lo si facesse nel contesto di questo gruppo... > sarebbe un eccellente inizio. Love. D.

June 22, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by Damiano Verzulli

Il 22/06/21 09:38, Guido Vetere ha scritto: > Ci sono un paio di cose che vanno considerate attentamente. > > Anzitutto, ci sono 'funzioni' che sono disponibili solo su ben precisi > cloud, e che nessun team, benché talentuoso e popoloso, potrebbe > implementare sul ferro o su infrastruttura Iaas. > > Ad esempio, alcune funzioni di NLP (Natural Language Processing) > richiedono modelli linguistici neurali così grandi e complessi da > costruire che ben pochi possono permetterseli, basti pensare al famoso > GPT-3 (Microsoft). Molta ricerca in quel settore è indirizzata proprio > verso il gigantismo neurale, perché i GAM sanno che su quel terreno > hanno chiari vantaggi. Concordo (ovviamente!) Ma come dicevo in altri messaggi [1][2], quello che scrivo lo scrivo avendo in mente un ben determinato target (la nostra PA, con focus sulla scala comunale/regionale [scuola ed Univ inclusi]) ed il contesto politico attuale (che --IMHO-- è animato da sani principi, come la centralizzazione delle risorse di calcolo, ma che sembra disorientato ed incapace di "controllare" le tecnologie sottostanti --a partire dalla buzzword "cloud"--). In questo (mio) contesto, il bleeding-edge della AI (cui GPT-3 appartiene) è.... "fuori" :-) [*] > Un altro problema è che i servizi applicativi su cloud (Saas) 'out of > the box' sono spesso fatti bene. Alternative 'on prem' richiederebbero > team e metodi di sviluppo applicativo moderni (DevOps) che non sono > facili da costituire, specie in Paesi arretrati come il nostro. Sono _PARZIALMENTE_ d'accordo (meno del 33%). Certamente i servizi cloud blasonati "...sono fatti bene..." (Gmail, Gsuite, O365, Slack, DropBox & Co., Zoom, etc.) _MA_ 1: la stragrande maggioranza dei servizi "pubblici" (a partire dell'ambiente sanitario, passando per gli enti locali ed atterrando negli Atenei) è fatta _MALE_. Talmente "male" che è difficilissimo migrarli al SaaS "blasonato". Possono certamente migrare al SaaS, ma è' il SaaS dei fornitori "legacy" (si pensi agli hosting di ESSE3 e di UGOV che Cineca offre a tutti gli Atenei [lock-in al 100%]). Si pensi al SaaS dei software di gestione di anagrafe e tributi di molti Comuni (erogati via marketplace Agid dai rispettivi "fornitori" e assolutamente _NON_ interoperabili l'un-l'altro). Si pensi alle... procedure di gestione dei vaccini Covid, dove regna il caos (digitale) piu' totale. È in questo contesto --se ho capito bene-- che la proposta del Governo di andare verso il cloud USA ("...perche' le migliori tecnologie sono straniere...") è da valutare con attenzione (IaaS => OK; altro => parliamone!) Che poi si possa ragionare di allestire una piattaforma di DaD "nazionale" da offrire a tutte le scuole pubbliche e, quindi, con livelli di scalabilità da milioni di utenti concorrenti.... se ne puo' certamente parlare. Ma stiamo parlando di un servizio che "parte da zero". Tecnicamente stiamo parlando.... di una cosa "banale" da progettare (non avendo i (pesanti) lacci che vengono dal passato). 2: non si tratta di contrapporre i modelli "cloud-USA" e quello "on-prem". Perfino GARR si pone problemi nell'allestire piattaforme di calcolo in grado di sostenere work-load "nazionali". Figuriamoci altri player meno tecno-centrici. Il problema --IMHO-- è di contrapporre il modello "cloud-USA" ad un modello "cloud-Italiano" (o "cloud-europeo"), dove la componente "datacenter" è quella che esiste gia' (e che, al piou', puo' essere marginalmente "integrata"). L'idea di costruire un nuovo DC esclusivamente per le esigenze della PA "centrale"... non mi appassiona particolarmente.... ma è comunque "accettabile"; ...ma le mie riserve più forti sono relative a ques'ultimo suo passaggio: 3: "/...//team e metodi di sviluppo applicativo moderni (DevOps) che non sono facili da costituire, specie in Paesi arretrati come il nostro..../". Questo è il punto _CENTRALE_ della questione. Ho passato gli ultimi 18 anni dentro un Ateneo da 40K studenti (come "consulente" che aveva il compito di stare dietro alla parte di calcolo e di networking). Ho un debito di riconoscenza verso CINECA che è difficile da spiegare (ho lavorato in Cineca dal 96 al 2003, ed ho collaborato con CINECA negli anni successivi). Conosco _BENE_ molti miei "colleghi" (= gente che fa il mio stesso lavoro) sparsi in molti altri Atenei del nostro Paese [3]. Ho avuto contatti importanti con i sistemi-informatici delle ASL della mia Regione. Conosco molto bene i primi 5 Comuni per numero di abitanti della mia regione. So come scrivono le gare. So come "gestiscono" l'IT. È il _MIO_ mondo. Mi ci muovo _perfettamente_. ...e non posso non dire che se il nostro Paese è "arretrato" e se oggi è difficile creare un team "/...moderno (DevOps).../", le ragioni che hanno portato a tale situazione sono proprio quelle di una erratissima politica ICT nazionale. In tutti i contesti che ho citato (in _TUTTI_ quei contesti), l'ICT è un "costo da ridurre". _NESSUNO_ (...in _TUTTI_ quei posti) vede l'IT come "investimento a ROI garantito!". O meglio: per i miei interlocutori (ai piani bassi), la cosa appare ovvia.... perche' i nostri occhi vedono banalmente i margini di ottimizzazione ed efficientamento che esistono. Ma i miei interlocutori non solo non hanno potere decisionale... ma addirittura vengono visti come "tecnici da un tot-al-chilo". I loro "manager" non li conoscono; parlano lingue diverse; non si capiscono.... ed il risultato è l'ampliamento del divario fra lo status-quo (tecnologie e competenze ICT che la PA mette in campo) e l'offerta di tecnologia (che evolve a ritmi che alcuni tecnici vedono... ma che il management ignora brutalmente). E quindi? Quindi _NON_ è affatto difficile allestire: 1 - un team di sviluppatori il cui obiettivo è quello di lavorare con tecnologie (open-source) in grado di scalare orizzontalmente sia in ambito "compute" che in ambito "storage", per produrre "container" da deploiare da qualche parte (dove e come, non e' affar loro...) 2 - un team di sistemisti/infrastrutturisti in grado di allestire e mantenere una infrastruttura openstack/kubernetes esattamente simile a quella di GARR-Cloud, che nasce gia' distribuita geograficamente e che è in grado di ospitare sia workload classici (IaaS, grazie ad openstack) sia workload moderni (container orchestrati con kubernetes) 3 - un team di devops in grado di fare inizialmente da "collante" fra i team 1) (...che tipicamente non sanno pacchettizzare la propria APP in un container docker) e 2) (...che tipicamente potrebbero non aver idea dei problemi indotti da scalabilita', affidabilita', etc.) e che, pian pianino.... inizia ad "elevare" tutti verso i nuovi paradigmi (GitOps, CI/CD, unit-testing, etc. etc.) Nel _MIO_ mondo (quello che ho disegnato piu' su...) ho "scovato" persone che potrebbero facilmente entrare a far parte di questi team. In GARR ce ne sono diversi. Negli Atenei ce n'e' piu' di qualcuno. Sul mercato se ne trovano tanti (ordine delle decine, facilmente). Il problema è uno solo: io conosco gli _OPERATIVI_. Quelli in grado _DI_FARE_. Serve qualcuno che abbia la voglia e la possibilita' di mettersi alla guida e "guidare" (non solo "tecnicamente"; anche "amministrativamente"). E quindi, per tornare al punto: No! Non è difficile creare un gruppo di tecnici in grado di abbracciare questa rivoluzione. E se è difficile... non è certo per colpa delle competenze tecniche. È, viceversa, un problema di incapacità di coordinamento. E questo, è un problema che dovrebbe risolvere qualcuno che è pagato per questo. Non certo noi, 'tecnici'. > Davanti a cose di questo genere la tentazione di consegnarsi con le > mani alzate al GAM lock-in è forte. Non solo è forte. È già un default. Da molti anni. Ma come è possibile non rendersi conto che tale approccio significa ammettere la propria incapacità (manageriale) di gestire questo processo? Due Dirigenti di due importanti Atenei mi dissero, anni fa, che loro _NON_ avevano possibilita' di intervento: senza le persone, non avevano la possibilita' di promuvoere/gestire soluzioni "on-prem". Il problema era quello di concorsi (andati deserti) o, in altri casi, di concorsi per posizioni da categorie/livelli economicamente non-appetibili / fuori-mercato. Ed è un problema "tecnico"? È un problema di "competenze"? ....oppure è un problema del _NON_ capire come deve essere fatto un certo organigramma e quale posto/ruolo debba essere assegnato all'IT ? Si tenga conto, infine, che questo problema viene da lontano: 7 anni fa (2014), l'allora dirigente IT di UniPavia lo racconto' chiaramente durante il workshop GARR [4], parlando dei motivi che portarono lui (ripeto: _dirigente_) a mandare la posta all'esterno (Google). Invito tutti a sentire l'intervento di Ferlini, perche' mostra chiaramente che l'obiettivo di un Dirigente non è quello di fare "il bene del Paese". Piuttosto è quello di far funzionare i servizi di cui è responsabile. E qualcuno si sente di dargli torto? io no.... Nello stesso workshop, a quello stesso panel, partecipo' pure Simone Spinelli , ai tempi in forza ad UniPI, che raccontò la propria soluzione (100% on-prem e open-source) [5]. A 7 anni di distanza.... Ferlini è in pensione (da tempo), UniPI ha parzialmente migrato su cloud e Spinelli è andato a lavorare altrove (dove ha ovviamente fatto carriera) [6]. Dunque.... il problema è che i tecnici "non si trovano"? Ne siamo proprio sicuri? > Insomma: arrivo a comprendere l'ignavia tecnica ma non la coscienza di > certi dirigenti, politici e giornalisti. Trattasi di incomprensione? > Trattasi di malafede? Trattasi di collusione? Ultimamente penso molto al Rasoio di Honlon [7]: l'evoluzione frenetica delle tecnologie ICT ha allargato drasticamente il GAP di know-how richiesto alla "politica" per governare i macro-processi di cui stiamo parlando.... e ancor piu' che i politici --IMHO-- i giornalisti fanno una fatica _ENORME_ a comprendere gli aspetti peculiari di questi temi (come puo', un giornalista, inquadrare le conseguenze indotte da una app sviluppata con tecnologie proprietarie e che usa le funzioni di microsoft, rispetto ad una app scritta con tecnologie open-source e deploiabile su cluster kubernetes standard?). C'e' molta, _MOLTA_, ignoranza. A livello politico, giornalistico e... ahime', anche fra tecnici addetti ai lavori.... E se poi un presunto-tecnico arriva a dare consigli (errati) ad un buon politico (che pero' è incompetente nel dominio tecnico), a quel punto accadono dei disastri dai quali è veramente difficile riprendersi (e di queste situazioni, ne potrei narrare a decine...., su scale che vanno da un comunque, ad una ASL, ad un Ateneo... ad un Ministero...) :-( Chiudo dicendo che mi piacerebbe molto "dibattere" su questi temi (che _NON_ sono tecnici). E se lo si facesse nel contesto di questo gruppo... sarebbe un eccellente inizio. Magari se qualcuno conosce Riccardo Luna.... potrebbe proporgli un intervento "ad integrazione" di quello fatto con Colao.... Un caro saluto, DV [1] https://server-nexa.polito.it/pipermail/nexa/2021-May/021611.html [2] https://server-nexa.polito.it/pipermail/nexa/2021-May/021630.html [3] https://www.eventi.garr.it/it/ws20/home/materiali-workshop-2020/presentazio… [4] Ferlini: https://www.garrnews.it/rubriche-interne-12/contributi-video-12/video/24-ou… [5] Spinelli: https://www.garrnews.it/rubriche-interne-12/contributi-video-12/video/19-un… [6] https://www.linkedin.com/in/simone-spinelli-b8887a68/ [7] https://en.wikipedia.org/wiki/Hanlon%27s_razor [*] Avrei diverse osservazioni al riguardo. Vorrei, ad esempio, parlare del workload tipici dell'infrastruttura HPC di Cineca. O di quella di ENI. Vorrei parlare del mondo della ricerca universitaria e di come questa _NON_ riesca ad uscire da vecchi schemi mentali di chi pensa "mi faccio le cose da me, con il mio server da 10K€ sotto la scrivania... perche' io sono bravo, e non posso cedere ai dettagmi di Cineca, o dei miei colleghi di Informatica, di Ingegneria, o chicchessia...". Ma non lo faccio, perche' siamo fuori tema e... l'altra discussione (quella sul cloud) è decisamente piu' importante (short-term) > > > > > > On Tue, 22 Jun 2021 at 08:50, Antonio Iacono <antiac(a)gmail.com > <mailto:antiac@gmail.com>> wrote: > > > La buzzword è "serverless-computing", > > o, come dicono alcuni, "Function as a Service" (FaaS), la sostanza > è la stessa. > > > e servizi di questo genere sono > > presenti sia a catalogo AWS (lambda) che Microsoft (azure > functions). > > Ci si potrebbe chiedere perche' mai un team di sviluppo dovrebbe > > decidere di adottare una soluzione simile... e la risposta non mi è > > chiara. > > Una risposta, fin troppo ovvia, potrebbe essere, "elimini" il > sistemista dal team. > Non dovendoti più preoccupare di infrastruttura, di "hosting", di "app > servers" di sistemi operativi, a cosa ti serve uno specialista in > sistemi? > Qualcuno potrebbe sentenziare: "è il progresso, bellezza", il > sistemista come il ghiacciarolo o il lampionaio. > Peccato che a forza di astrazioni di livello superiore la prossima > volta potrebbe toccare allo sviluppatore web. > Se poi ci metti lo specchietto per le allodole (leggasi CEO), che > paghi solo la funzione/funzionalità solo quando è effettivamente in > esecuzione, il gioco è fatto. > > Antonio > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > -- Damiano Verzulli e-mail: damiano(a)verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html

June 22, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by Antonio Iacono

> Ad esempio, alcune funzioni di NLP (Natural Language Processing) richiedono modelli linguistici neurali così grandi e complessi da costruire che ben pochi possono permetterseli, basti pensare al famoso GPT-3 (Microsoft). Molta ricerca in quel settore è indirizzata proprio verso il gigantismo neurale, perché i GAM sanno che su quel terreno hanno chiari vantaggi. OpenNLP, NLTK, TextBlob, SpaCy, PyTorch-NLP, CogCompNLP, ecc. non credo manchino alternative open. Certo, il problema sono i dati, e vorrei vedere, miliardi di persone che continuamente "cercano", "chattano", "parlano" agli assistenti vocali, ecc. altro che BigData ... Fermo restando che, come ha scritto Stefano, applicazioni della PA che abbisognano di funzioni NLP non è che ce ne siano molte in giro, e comunque creare un "set di dati" solo in italiano non dovrebbe essere un ostacolo insormontabile. Basterebbe dare in pasto a qualcuno dei sistemi lì sopra la legislazione italiana ;) Se poi dovesse servire "insegnare alle macchine come parlano le persone nella vita reale" si potrebbe "donare la voce" al progetto "Common Voice" [1] e usare DeepSpeech Italian [2]. > Un altro problema è che i servizi applicativi su cloud (Saas) 'out of the box' sono spesso fatti bene. Alternative 'on prem' richiederebbero team e metodi di sviluppo applicativo moderni (DevOps) che non sono facili da costituire, specie in Paesi arretrati come il nostro. Inizi anni duemila, Apache era installato nel 60% dei siti, mentre IIS nel 20%, eppure, in Italia, nella PA italiana, c'era ovunque IIS ... Antonio [1] https://commonvoice.mozilla.org/it [2] https://github.com/MozillaItalia/DeepSpeech-Italian-Model/blob/master/DeepS…

June 22, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by Giacomo Tesio

Ciao Damiano, On Mon, 21 Jun 2021 23:23:16 +0200 Damiano Verzulli wrote: > L'aspetto delicato, a mio avviso, è che queste (nuove) dinamiche di > (forte) lock-in partono dagli sviluppatori: sono loro a _chiedere_ di > utilizzare tecnologie "pericolose". d'istinto specificherei "sviluppatori junior", ma purtroppo l'esperienza di uno sviluppatore spesso non è correlata con l'età anagrafica. Ho visto sviluppatori con decenni di esperienza seguire le mode del momento come adolescenti terrorizzati dall'idea di essere "out" e sviluppatori giovanissimi ricchi di sano scetticismo ed idee brillanti ed innovative. > Se fossi io il CIO che ha la responsabilità di un team del > genere.... tendenzialmente cercherei un nuovo team-leader, in > quanto l'attuale evidentemente ignora il termine "vendor-lock-in". > [...] > E per dirgli: "No! State facendo una sciocchezza!" servono > competenze che --tipicamente-- _MANCANO_ sulla linea gerarchica > cui tipicamente rispondono. Oltre a sostituire il team-leader, dovresti sostituire chi l'ha selezionato ed assunto o quanto meno chi l'ha promosso, nonché riconsiderare le competenze dei vari membri del team, come minimo per approntare un piano di formazione adeguato. E questo imporrebbe costi misurabili all'azienda/PA. Il costo di tecnici o team-leader incompetenti invece NON è misurabile. Né direttamente riconducibile ad una decisione di un qualche manager. Per questo non c'è alcun pericolo che un tecnico competente possa diventare CIO, proprio perché capace di dire "No" e più in generale avvezzo a rendere espliciti ed affrontare costi che si preferisce ignorare e nascondere sotto il tappeto. > ogni riferimento al down recente di Fastly [1] è puramente voluto! O al down di Google. O di Microsoft Teams. O di OVH. Il cloud viene spesso propagandato come una soluzione low risk, ma in realta si intende SEMPRE low-personal-risk-for-the-incompetent-manager. Infatti espone SEMPRE chi lo adotta ad un sistematico ed ineludibile incremento degli eventi HILP (high-impact low-probability) di cui non è possibile mitigare i danni proprio a causa del vendor lock-in. E quando questi avvengono (perché AVVENGONO)... chi ne risponde? Nessuno! Così si smantellano infrastrutture pubbliche resilienti e distribuite nella speranza di minimizzare costi/rischi, adottando al loro posto soluzioni fragili e centralizzate fuori dal controllo pubblico. Occhio non vede, cuore non duole, giusto? E sì, sto ancora parlando di informatica. E sì, sto parlando ANCHE di sanità pubblica ed istruzione. Giacomo

June 22, 2021

Re: [nexa] Infrastrutture IT, il dilemma della PA: ferro o nuvole?

by D. Davide Lamanna

>> 2) Cito testualmente: "legarsi mani e piedi a una tecnologia di una >> azienda specifica, sposarne la filosofia di sviluppo, e ritrovarsi in un >> matrimonio dal quale non si può più uscire, con rischi di vario tipo." >> >> A cosa si riferisce? A un Public Cloud? Quindi è la stessa di cui in 1)? >> Oppure? Roba fatta in casa in modo tradizionale (no Cloud)? Mistero. > > No. Non e' "mistero". > > È lo scenario nel quale un team di sviluppo decide di scrivere una > applicazione (...e fin qui tutto bene....). Solo che --a differenza di > quello che era lo standard fino a pochi mesi fa [*], decide di > utilizzare delle librerie prendendole _direttamente_on_line_. Occhio: > intendo che la chiamata alla libreria (chiamate effettuate dalla mia > applicazione) viene fatta ad un qualcosa che sta "su cloud". Intendo che > la mia applicazione _NON_ funzionera' se quella chiamata a quelle > librerie "fallisce" (perche', ad esempio, il cloud-provider ha chiuso il > servizio o c'e' un qualche problema di rete fra la mia APP ed il > cloud-provider [**] > > La buzzword è "serverless-computing", e servizi di questo genere sono > presenti sia a catalogo AWS (lambda) che Microsoft (azure functions). Fatico a rintracciare nel testo dell'articolo un chiaro riferimento al serverless. Nè il giro di parole (che ho riportato testualmente) suggerisce che si stesse parlando di questo. Ciononostante, è stato proficuo che tu abbia introdotto il tema, perché è interessante, innanzi tutto, e perché c'entra con la questione del Cloud. > L'elemento che trascuri è proprio "l'applicazione": l'infrastruttura che > hai descritto puo' essere allestita al 100% con ferro "di proprieta'" e > con tecnologie 100% open-source. > > Ma se poi lo sviluppatore ci mette sopra una applicazione che usa > tecnologie di "serverless-computing".... tu sei "fritto" lo stesso... > > ...sono convinto, pero', che ora lo scenario e' piu' chiaro (almeno a > noi tecnici!). Sicuramente è stato utile. Personalmente concordo con il tuo punto di vista sul serverless. A questo punto, già che ci siamo, aggiungo un ulteriore elemento di riflessione. Anche il serverless si può fare con strumenti open e self-hosted [1]. Quindi mi concince di più la conclusione, che è stata tratta, che stiamo sparando ad una mosca con un cannone. Ma in assoluto il tema meriterebbe qualche approfondimento in più. D. [1] Solo un esempio: https://wiki.openstack.org/wiki/Faas

June 22, 2021