- nexa - server-nexa.polito.it

Re: [nexa] Articolo sui LLMs - il punto di vista di un giurista

by 380°

Buongiorno, Guido Vetere <vetere.guido(a)gmail.com> writes: [...] > una mezz'ora per leggerlo da cima a fondo - vi vedo che state facendo > summarization :-)) a me ci vuole di più, non sono ancora riuscito a finirlo, ma pian piano... :-) chiedo scusa nel caso qualcuno dei miei commenti sia già stato affrontato nel paper in oggetto, dal quale è partito questo thread. [...] > e perché, anche abbracciando il realismo, non ci soddisfa il 'disclaimer' > di OpenAI che recita (molto piccolo, ma vabbè): > > "ChatGPT può commettere errori. Ti consigliamo di verificare le > informazioni importanti." ? Perché è drammaticamente fuorviante dire che un LLM "commette errori": errori rispetto a cosa? Rispetto alla veridicità delle informazioni fornite? Mi pare che ci sia un sufficiente consenso tecnico/scientifico sul fatto che _nulla_ si possa dire in merito all'"inerente veridicità" ecc., il contrario l'hai definito "tecnicamente insipiente" [1], a meno che io abbia capito male. Quindi, un 'disclaimer' più adeguato OpenAI (& co.) dovrebbero copiarlo dal famigerrimo "all persons fictitious" disclaimer: --8<---------------cut here---------------start------------->8--- The story, all names, characters, and incidents portrayed in this production are fictitious. No identification with actual persons (living or deceased), places, buildings, and products is intended or should be inferred. --8<---------------cut here---------------end--------------->8--- ...con tutte le varianti divertentissime che si sono succedute nel tempo. Perché l'output degli LLM è semplicemente _fiction_ [2], e come fiction dovrebbe essere trattata anche dal punto di vista /giuriduco/. Ora, oggettivamente importa poco (a me) quali parole sono le più corrette per un simile disclaimer, quale tecnica di "watermaking" o dimesione di font usare; la cosa che io ritengo fondamentale è che _nessuna_ persona possa essere indotta a credere che l'output di un LLM NON sia _fittizio_ (fictitious). E nemmeno importa stabilire una ipotetica "percentuale di fittizitudine" (stima dell'errore), ammesso e non concesso sia possibile calcolarla (sarebbe "tecnicamente insipiente"?). ...in caso contrario sarebbe come _far_ credere (anche attraverso una sofisticata /narrazione/ propagandistica posta in atto all'uopo, a volte partecipata inconsapevolmente) che i fatti siano accaduti esattamente come raccontati nei film o nei romanzi e le persone siano così indotte a giudicarli come fatti corrispondenti al vero. Le persone non devono avere dubbi di dover verificare _altrove_. Il fatto è che _purtroppo_ ben pochi dispongono delle risorse finanziarie e delle conoscenze ad altissimissimo livello della principessa Irina Alexandrovna di Russia, che nel 1934 vinse una causa per diffamazione contro la Metro-Goldwyn-Mayer e ottenne un notevole risarcimento [3] nelle giurisdizioni Inglese e Statunitense (quest'ultima con un accordo extragiudiziale). Non solo l'industria della _fiction_ usa quel disclaimer per levarsi d'impiccio: nel tempo ha affinato un processo definito "negative checking" --8<---------------cut here---------------start------------->8--- Negative checking is a process by which producers of film, television and radio programs will attempt to ensure that the names of fictional characters cannot be confused with real life people. [...] The primary reason for this practice is to prevent any possible legal action for libel which could result. --8<---------------cut here---------------end--------------->8--- (https://en.wikipedia.org/wiki/Negative_checking) ...che immagino costi parecchie risorse. Dopo, però, si dovrebbe anche aprire il vaso di pandora in merito al (presunto?) trattamento dei dati _personali_ che farebbe parte del processo di addestramento degli LLM: per esempio, che tipo di trattamento giuridico occorrerebbe riservare alle aziende che utilizzano il contenuto delle email, delle chat e dei post social _privati_ per il "machine learning" dei nei propri LLM usati per erogare servizi come quelli di OpenAI? [...] Saluti, 380° [1] Messaggio id:CAD3hHB52iop9xiWWOkYCAQ1wWi-NdW=_iaRRn4WJdr2tObQByQ@mail.gmail.com [2] Messaggio id:87bkjwqccs.fsf@xelera.eu [3] https://en.wikipedia.org/wiki/All_persons_fictitious_disclaimer#Origins https://en.wikipedia.org/wiki/Rasputin_and_the_Empress#Lawsuit -- 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>.

May 10, 2024

Re: [nexa] Articolo sui LLMs - il punto di vista di un giurista

by 380°

Buongiorno, Guido Vetere <vetere.guido(a)gmail.com> writes: [...] > diversa (e tecnicamente insipiente) è l'idea che il modello linguistico > debba inerentemente garantire veridicità, correttezza, eccetera. cosa > possiamo accettare come *prova* di queste inerenti capacità? concordo che l'idea sia tecnicamente insipiente questo è il nocciolo _duro_ attorno al quale (credo) il dibattito pubblico, compresi quello giuridico e politico, attorno agli LLM e AI si sta letteralmente /avvitando/ a me pare che la risposta a questa domanda avesse già provato a darla Llull nella sua polemica alla logica Scolastica, cito di nuovo: --8<---------------cut here---------------start------------->8--- Studies on the Ars (Ruiz Simón 1998; Rubio 2008a; Jaulent 2010) show that it addresses the criticism made by Llull to Scholastic logic. [...] this criticism (Jaulent 2010) addresses the fact that demonstration by syllogisms only works through second intentions, that is, it describes relationships within logical propositions and not according to objects in reality, which are conceptualized as first intentions. --8<---------------cut here---------------end--------------->8--- (https://plato.stanford.edu/archives/spr2021/entries/llull/#Ars) > la certificazione del processo di costruzione? suvvia .. appunto: ammesso e non concesso che il processo di build di un LLM possa essere /certificabile/, la certificazione cosa direbbe in merito alla sua capacità di «inerentemente garantire veridicità, correttezza, eccetera»? Nulla. > purtroppo mi sembra di ravvisare un orientamento di questo tipo > nell'AI Act, ma potrei sbagliare, mi smentisca chi può :-) G. non ho idea dei considerando e del portato culturale che ha generato l'AI Act ma a me pare che il dibattito sull'AI sia deragliato. [...] Saluti, 380° -- 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>.

May 10, 2024

Re: [nexa] Oxford shuts down institute run by Elon Musk-backed philosopher | Elon Musk | The Guardian

by 380°

380° <g380(a)biscuolo.net> writes: [...] > Cioè qualcuno è stato davvero in grado di sostenere che un mondo del > genere, infarcito di "feedom officers" stile Stasi, oltre che essere > peggio della morte, rappresenterebbe un "net saving" perché costerebbe > l'1% del prodotto interno lordo (laido?) mondiale? [...] > Terminata l'euforia però penso al sistema di sorveglianza di Venezia, > alle smart-cities, ai continui e incessanti attacchi alla E2EE: stanno > _vincendo_ i progetti propagandati dalle persone come Nick Bostrom? ...oppure sono ingenuo io e in realtà articoli come quello che ho citato di Bostrom sono una sofisticata forma di whistleblowing da parte di persone sufficientemente introdotte nel /circle/, che stanno cercando di "svelare" al mondo l'ethos di coloro che lavorano all'implementare di tali piani, con tanto di "business plan"? [...] Saluti, 380° -- 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>.

May 10, 2024

vi chiedo scusa (was Re: Oxford shuts down....)

by 380°

380° <g380(a)biscuolo.net> writes: [...] > So che in ambito accademico era in uso il cosiddetto "bacio accademico", > ma esiste(va) anche il "calcio nel culo accademico"? O il "vaffanculo > accademico"? NON alle persone, ma alle /idee/ come queste? vi chiedo scusa perché usando il turpiloquio ho mancato di rispetto ai gestori e a tutti gli iscritti alla lista specialmente qui non è oppotuno esprimere in questo modo il proprio disprezzo per certa propaganda [...] Saluti, 380° -- 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>.

May 10, 2024

Re: [nexa] Leibniz e il calcolatore binario (was Re: sul linguaggio...))

by Guido Vetere

sulle fortune e le miserie del 'lullismo' e di varie altre visioni cabalistiche del linguaggio, consiglio la rilettura di Umberto Eco: La ricerca della lingua perfetta nella cultura europea, Roma-Bari, Laterza, 1993 Buona giornata, G. On Thu, 9 May 2024 at 12:20, 380° via nexa <nexa(a)server-nexa.polito.it> wrote: > Buongiorno a tutti, > > grazie infinite a tutti per i preziosissimi riferimenti di _archeologia_ > informatica. > > Daniela Tafani <daniela.tafani(a)unipi.it> writes: > > > Il 08/05/2024 19:35, 380° ha scritto: > >> fino a Leibniz (e oltre?) i numeri e tutta la matematica binaria sono > stati strumenti > >> di... /divinazione/ (o meglio teologia). > > > > L'aspetto impressionante di quel testo di Leibniz è l'idea che il > > calcolo binario possa essere effettuato facilmente con una macchina, > > [...] > > > Assegnando numeri (primi) ai concetti primitivi si può procedere a > > codificare TUTTI i concetti in binario. E usare la macchina per > > calcolare. > > OK, io erroneamente fino a ieri ho pensato che il "prototipo" della > macchina calcolatrice (il computer "primitivo") fosse l'analitycal > engine di Babbage, con il /determinante/ apporto di Menabrea e poi Ada > Lovelace che portarono alla scrittura del primo programma per computer > attorno al 1843 (ho già detto che è stato _parecchio_ prima che Turing > "inventò" la sua macchina teorica). > > Ora invece imparo che no, è stato Leibniz a progettare la prima macchina > di calcolo assimilabile a un computer (per via del fatto che usava il > sistema binario), poco importa quanto programmabile e se effettivamente > programmata. > > Attenzione che la storia delle macchine per il calcolo (manuali e poi > meccaniche) è altra cosa, mi pare: > https://en.wikipedia.org/wiki/Computer#Pre-20th_century > > >> > In merito all'informatica e all'AI scopro anche che: > >> > >> --8<---------------cut here---------------start------------->8--- > >> > >> In the late 13th century Ramon Llull had the ambition to account for all > >> wisdom in every branch of human knowledge of the time. For that purpose > >> he developed a general method or "Ars generalis" based on binary > >> combinations of a number of simple basic principles or categories, for > >> which he has been considered a predecessor of computing science and > >> artificial intelligence. > >> > >> --8<---------------cut here---------------end--------------->8--- > > > > Sì, e con una macchina fisica: > > > > "Llull con la sua Ars combinatoria (secondo la denominazione di > > Leibniz) non solo propose un linguaggio logico al-gebrico per > > rappresentare la conoscenza e generare nuove verità a partire da > > premesse note, ma fornì anche una implementazione, come diremmo oggi, > > del suo modello di calcolo. Llull realizzò infatti una macchina fisica > > costituita da dischi di carta concentrici che, ruotati opportunamente, > > permettevano di combinare in vario modo i concetti rappresentati in > > modo simbolico su di essi mediante lettere" > > In relazione alla Intelligenza Artificiale mi preme sottolineare il > fatto che i concetti sono rappresentati in modo _simbolico_ e che devono > essere combinati, credo che questo sia ontologicamente _opposto_ a > quello che fanno i LLM. > > OK, quindi nel 13mo secolo progettò un sistema logico per _calcolare_ la > verità attraverso la combinazione di concetti simbolici: > > --8<---------------cut here---------------start------------->8--- > > Llull's Art is sometimes recognized as a precursor to computer science > and computation theory. With the discovery in 2001 of his lost > manuscripts, Ars notandi, Ars eleccionis, and Alia ars eleccionis, > together known as Ars Magna (what today would be called a logical system > to discover some sort of truth), > > --8<---------------cut here---------------end--------------->8--- > (https://en.wikipedia.org/wiki/Ramon_Llull#Other_recognition) > > E Lull inventò la relativa macchina... nel 13mo secolo :-D > > Credo che la fonte più esautiva, dal punto di vista divulgativo, in > merito alle /Ars/ lulliane, sia quella di Stanford Encyclopedia of > Philosophy Archive (anche se mancano i riferimenti alle Ars ritrovate > nel 200), dove possiamo trovare come già nel 13mo secolo ci fossero > /intense/ diatribe in merito a _come_ scoprire la verità (sugli > "oggetti" della realtà)... e forse come corollario in merito alle > "proprietà emergenti" di certi sistemi: > > --8<---------------cut here---------------start------------->8--- > > Studies on the Ars (Ruiz Simón 1998; Rubio 2008a; Jaulent 2010) show > that it addresses the criticism made by Llull to Scholastic logic. This > criticism has two great stages: on the one hand, the insufficiency of > the demonstration by syllogisms—the basis of all Scholastic science—to > reveal new truths, because it only explicitly states the relationship > between known facts and evident principles (Ruiz Simón 1998), thus > relegating dialectics (or ars inveniendi), which consists of finding > arguments and counterarguments based on some loci or “places”, to the > domain of opinion. On the other hand, this criticism (Jaulent 2010) > addresses the fact that demonstration by syllogisms only works through > second intentions, that is, it describes relationships within logical > propositions and not according to objects in reality, which are > conceptualized as first intentions. > > --8<---------------cut here---------------end--------------->8--- > (https://plato.stanford.edu/archives/spr2021/entries/llull/#Ars) > > Mi permetto di sottolineare "second intentions" vs "first intentions", > che a me risuona moltissimo con il concetto informatico di "first-class > citizen" [2] > > Quindi in buona sostanza Llull, nel 13mo secolo, aveva già inventato una > macchina per dimostrare che non si puo trovare la verità usando > sillogismi (https://it.wikipedia.org/wiki/Sillogismo)? > > Comunque, a questo punto non mi stupirei se domani venisse trovato > qualche "lost manuscript" sumero che retrodati certi concetti (e > macchine?) di altre manciate di secoli. :-D > > [...] > > Saluti, 380° > > > [1] anche > Ören, T.I. (2001). Advances in Computer and Information Sciences: From > Abacus to Holonic Agents. Special Issue on Artificial Intelligence of > Elektrik (Turkish Journal of Electrical Engineering and Computer > Sciences - Published by TUBITAK - Turkish Science and Technical > Council), 9:1, 63-70 > > > https://web.archive.org/web/20090915033859/http://www.site.uottawa.ca/~oren… > > [2] https://en.wikipedia.org/wiki/First-class_citizen > > -- > 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>. >

May 10, 2024

A State Uses AI to Determine School Funding. Is This the Future or a Cautionary Tale?

by J.C. DE MARTIN

https://www.edweek.org/policy-politics/a-state-uses-ai-to-determine-school-… (messaggio spedito in movimento - scusate brevità ed eventuali refusi)

May 10, 2024

Re: [nexa] Leibniz e il calcolatore binario (was Re: sul linguaggio...))

by Josephine Condemi

Io interessata! Grazie! Il Gio 9 Mag 2024, 23:50 Daniela Tafani <daniela.tafani(a)unipi.it> ha scritto: > Buonasera, 380°, > > Il 09/05/2024 12:20, 380° via nexa ha scritto: > > > In relazione alla Intelligenza Artificiale mi preme sottolineare il > > fatto che i concetti sono rappresentati in modo _simbolico_ e che devono > > essere combinati, credo che questo sia ontologicamente _opposto_ a > > quello che fanno i LLM. > > Settimo Termini ha qualificato l'approccio simbolico come un progetto > scientifico > e quello sub-simbolico come una mera tecnica. > A proposito di storia dell'intelligenza artificiale, nella sua ricchissima > relazione di sabato scorso, Le sette vite dell'intelligenza artificiale, > Settimo Termini ha ripercorso anche molti contributi italiani. > Se qualcuno fosse interessato alla relazione, che non è pubblicata, posso > inviargliela. > > Un saluto, > Daniela

May 9, 2024

Re: [nexa] Leibniz e il calcolatore binario (was Re: sul linguaggio...))

by Daniela Tafani

Buonasera, 380°, Il 09/05/2024 12:20, 380° via nexa ha scritto: > In relazione alla Intelligenza Artificiale mi preme sottolineare il > fatto che i concetti sono rappresentati in modo _simbolico_ e che devono > essere combinati, credo che questo sia ontologicamente _opposto_ a > quello che fanno i LLM. Settimo Termini ha qualificato l'approccio simbolico come un progetto scientifico e quello sub-simbolico come una mera tecnica. A proposito di storia dell'intelligenza artificiale, nella sua ricchissima relazione di sabato scorso, Le sette vite dell'intelligenza artificiale, Settimo Termini ha ripercorso anche molti contributi italiani. Se qualcuno fosse interessato alla relazione, che non è pubblicata, posso inviargliela. Un saluto, Daniela

May 9, 2024

Re: [nexa] "cloud" vs "non-cloud": disquisizioni semitecniche... in liberta' [Era: ...and... We've left the cloud!" - David Heinemeier Hansson / 37signals]

by D. Davide Lamanna

On 5/3/24 15:24, 380° wrote: > [...] >> Il 02/05/24 6:33 PM, Giuseppe Attardi ha scritto: >>> [...] >>> Kamal, da una breve scorsa alla documentazione, è qualcosa tipo >>> Ansible [...] Hanson spiega che Kubernetes è complesso e richiede >>> competenze (appunto come sospettavo), perché è “dichiarativo”. > Iniziamo con un paio di concetti: > > 1. kubernetes è un sistema di gestione dei cluster, piuttosto complesso > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FKub… ; di sistemi di gestione > cluster è piena la storia dell'IT [1], kubernetes non sarà > l'ultimo... e nemmeno il penultimo. La storia dell'IT è piena di tante cose. Alcune di queste hanno preso piede, altre no. Tutte noi della lista Nexa tendenzialmente siamo per l'Open Source. Qualcuno addirittura per il Software Libero. Per usare le tue parole, esistono tanti kernel, Linux non sarà l'ultimo e nemmeno il penultimo. Eppure non so vedere all'orizzonte il prossimo. Il mondo è andato verso questa direzione, con buona pace di sistemi probabilmente migliori come FreeBSD e al netto di tutte le distro-war che possiamo fare (e che fanno sempre piacere ;-) ). Idem con patate per Kubernetes. Essere utilizzati di più, come sai, significa avere maggiore supporto dalla comunità, poter risolvere più facilmente i problemi, avere più documentazione, maggior affidabilità e stabilità, maggiore interoperabilità e integrazione... > La caratteristica di kubernetes, > che lo rende così /complicato/, è che *ingloba* un sacco di altri > servizi che in altri sistemi di gestione dei cluster sono lasciati ad > altri software che i sistemisti devono scegliere, installare e > configurare indipendentemente. Sono moderatamente d'accordo. Anche se più banalmente, secondo me, la difficoltà sta nella configurazione dettagliata di una molteplicità di risorse IT. Il vantaggio è l'uniformità di queste configurazioni, l'opportunità di versionamento delle stesse e la centralizzazione della loro gestione. [...] >> Kubernetes è complesso... perché chi l'ha pensato aveva in mente di >> gestire il workload di Google, su scala worldwide. A quella scala, la >> complessità di kubernetes... è insignificante rispetto >> all'infrastruttura che dovra' gestire. > I sistemi di "cluster management for world sized cloud infrastructure" > sono figli dell'/ideologia/ "pets vs cattle" [2] Non so se si tratti di un'ideologia. Direi più un portato industriale. Si potrebbe forse dire che l'industria è un'ideologia. Rimanendo, però, con i piedi per terra, servono sia i pets che i cattle. Così come serve sia l'artigianato che l'industria. A me piacerebbe avere una casa piena di oggetti di artigianato, purtroppo non posso permettermelo. Mi limito ad alcune cose, sul resto cedo. Penso che valga in generale. > Come se i due insiemi descritti sopra fossero davvero _disgiunti_: sarà > mica una cosa seria? (e infatti kubernetes usa il termine "Pet Sets" > che l'autore dell'articolo sopra contesta... non proprio "rocket > science" diciamo :-D ) Non ho mai sentito dire da nessuno che Kubernetes è rocket science. Al massimo si sente dire che è una "ficata" oppure una "rottura di scatole". :-) > L'ideologia "pets vs cattle" è stata osannata come il "nuovo (cattle) > che avanza sul vecchio (pets)", nonostante sia _evidente_ sia è frutto > di mistificazione su come funzionavano i sistemi "high availability > clusters" già mooolto tempo prima che il _meme_ fosse inventato. > > Il tutto è anche frutto della confusione assordante tra "scale-out" vs > "scale-up", che tra l'altro sono problemi che si incontrano > _regolarmente_ nel ciclo di vita di una infrastruttura IT, che essendo > "fatta di bit" è da decenni che è "nomade". > > Tutto ciò ha portato alla /reificazione/ del concetto che i container > sono _ephemeral_ by nature... tranne che i dati > (https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FKub… ) e le configurazioni > (https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FKub… ) che servono non lo sono > affatto: Non lo so se sia questo che abbia portato alla reificazione dei container. I namespace sono nel kernel di Linux dal 2002 e i cgroups dal 2006. Kubernetes è nato nel 2014. La storia dei container inizia negli anni '80 con chroot e per 3 decenni sono state proposte numerose variazioni sul tema, fino a quella che ha preso piede. Che non è necessariamente la migliore, così come Linux non è il miglior kernel in circolazione. Il fatto che siano effimeri è fondamentale. Tenere separata la computazione dai dati e dalle configurazioni è una buona prassi. Tutto è più pulito e portabile. Gestire questa separazione è sempre stato un problema. Mi pare che Kubernetes ultimamente abbia fatto passi da gigante verso una gestione convincente: snapshot e volume cloning, secrets encryption tramite API e poi i Container Storage Interface che hanno standardizzato il modo in cui i container interagiscono con i sistemi di storage esterni. Stiamo parlando di un sistema con migliaia di contributori, centinaia di migliaia di commit e una vitalità che dopo 10 anni non accenna a diminuire (all'ultimo KubeCon a Parigi eravamo 10.000 persone!). [...] >> Il discorso cambia a scale piu' piccole (Ateneo, ASL, Regione...). A >> queste scale, la complessita' di K8S si sente, forte. E' la stessa scala >> di Hey/Heinemeier e per questo Heinemeier ha premuto "reset": a lui, >> semplicemente, non serviva. Meglio: era sufficiente qualcosa di *MOLTO* >> piu' semplice. >> >> E' un folle? E' un ignorante? Oppure è semplicemente un "realista"? > É un sistemista che ha ben presente lo "use case" di kubernetes e ha > chiaramente capito che a lui proprio non serve. Dopotutto deve /solo/ > erogare 4/5 applicazioni web con backend per i dati, mica fare AWS. Ma infatti, benissimo così. Basta che funzioni. Non è necessario passare a Kubernetes e tanto meno al cloud, se non serve. Allo stesso tempo se a qualcuno serve, il prodotto è lì a disposizione, con una licenza Open Source (Apache License 2.0) compatibile con la GPLv3. > ...poi essendo un bravissimo sviluppatore si diverte anche a reinventare > la ruota (Kamal) perché gli piace fare "il sarto", ma vabbè, ognuno ha > il suo ego :-) Ottimo. Adoro i sarti! :-) > [...] > >>> Appunto, dichiarativo vs procedurale. >>> La differenza sta lì, da una parte fai tutto tu a mano, devi tenere >>> traccia di tutyo e ogni modifica costa quanto ricominciare daccapo. > Questa "una parte" sarebbe Ansible? Ma Ansible è dichiarativo! > > ...ormai "tutto è dichiarativo" :-)... "Infrastrutcture as Code". Ansible è dichiarativo, ma stateless, ossia non mantiene lo stato (come invece fa OpenTofu, ad esempio). Lo stato è ricostruibile implicitamente, ma al prezzo di usare sinapsi umane. Come hai ben descritto nel seguito, l'idempotenza è limitata ai moduli, non al loro assemblamento in una logica di processo, che potrebbe facilmente far incappare in un deadlock. Ci sono le buone prassi per evitarlo e poi c'è l'esperienza che ti aiuta a debuggare le situazioni più ostiche. [...] > --8<---------------cut here---------------start------------->8--- > > Reliable. When carefully written, an Ansible playbook can be idempotent, > to prevent unexpected side effects on the managed systems. It is > possible to write playbooks that are not idempotent. > > --8<---------------cut here---------------end--------------->8--- Esatto. [...] > --8<---------------cut here---------------end--------------->8--- > > La cosa è (ovviamente) risolvibile, come ha dimostrato Damiano, ma c'è > stato bisongo di un processo di _riconciliazione_ tra la dichiarazione e > lo stato, cosa che in un sistema idempotente sarebbe... impensabile > > [...] E' così. Del resto è stata una scelta quella di tenerlo il più possibile leggero, con una curva di apprendimento piatta, e un'apertura a qualsiasi situazione. E di conseguenza a qualsiasi casino... [...] > > [...] > >> Insomma: non c'e' una ricetta magica per tutto. > Sì invece: > > «Purely Functional System Configuration Management» > by Eelco Dolstra and Armijn Hemel, 2007-05-07 > > --8<---------------cut here---------------start------------->8--- > > System configuration management is difficult because systems evolve in > an undisciplined way: packages are upgraded, configuration files are > edited, and so on. The management of existing operating systems is > strongly imperative in nature, since software packages and configuration > data (e.g., /bin and /etc in Unix) can be seen as imperative data > structures: they are updated in-place by system administration > actions. In this paper we present an alternative approach to system > configuration management: a purely functional method, analogous to > languages like Haskell. In this approach, the static parts of a > configuration — software packages, configuration files, control scripts > — are built from pure functions, i.e., the results depend solely on the > specified inputs of the function and are immutable. As a result, > realising a system configuration becomes deterministic and > reproducible. Upgrading to a new configuration is mostly atomic and > doesn’t overwrite anything of the old configuration, thus enabling > rollbacks. We have implemented the purely functional model in a small > but realistic Linuxbased operating system distribution called NixOS. > > --8<---------------cut here---------------end--------------->8--- > (https://urlsand.esvalabs.com/?u=https%3A%2F%2Fedolstra.github.io%2Fpubs%2Fh… ) > > Oggi quei concetti sono implementati in NixOS e Guix System; per i > manifest di packages e servizi il primo usa un _mix_ di Nix - un DSL > funzionale sviluppato ad-hoc - e bash, il secondo usa Guile, un dialetto > di Scheme. > > [...] Ecco su questo vorrei espandere un po'. Sono soluzioni di nicchia, sicuramente interessanti ed eleganti, ma pochissimo utilizzate e quindi l'ecosistema a supporto è limitato. >>> [...kubernetes...] >>> Se cambiano i requisiti, basta cambiare le specifiche e il sistema si >>> riadatta ad esse in modo totalmente automatico. >> Su questo elemento *DISSENTO* fortemente. In *TEORIA* funziona cosi'. >> Nella pratica, dipende assolutamente dall'applicazione che deve >> girarci. > Confermo: la statefulness dei sistemi purtroppo a volte è _embedded_ > nelle applicazioni che sono progettate proprio male [3] Certo. Su questo non si può fare molto di più che odiare i programmatori. :-P [...] >> Tu e AWS volete "vendere" la vostra piattaforma. Heinemeier preferisce >> gestirla per i fatti suoi (perché pensa di sapere quello che fa). >> >> A me piace piu' il suo approccio... > Non è solo una questione di gusti, è che a parità di competenze > l'approccio on-premises costa almeno un ordine di grandezza meno. Ma dipende, in realtà, non generalizzerei. Bisogna farsi bene i conti. Dovrebbe essere questo il mestiere del Product Owner. In ogni caso, la questione dei costi mi interessa fino ad un certo punto. Quanto meno valuterei anche i benefici, che sono soggettivi, come il caso di Heinemeier dimostra. > La questione quindi si "riduce" a: per farselo "da soli" occorre avere > adeguate competenze, se lo facciamo "in cloud" non abbiamo bisogno di > quelle competenze e quindi _risparmiamo_... Non è detto che sia così. L'idea portante dell'IT automation è quella della standardizzazione. Che ci sta, secondo me. Con tutte le riserve di qualsiasi approccio industriale alla tecnologia, ma anche con tutto l'incoraggiamento all'inclusività. Intendo dire che grazie alla standardizzazione in meccanica, anche un pasticcione come me può fare bricolage in casa. Poi per le cose serie (e per i casini inenarrabili che combino) ci sono i professionisti. [...] >>>> Sono, io, "cloud"? >>> Stai gestendo a mano, con l’ausilio di tool, una infrastruttura >>> fornita da altri. >>> Il cloud GARR è basato su OpenStack e Kubernetes, entrambi orchestrati >>> in modo dichiarativo da Canonical Juju. >>> La scelta di una soluzione dichiarativa era quella che consentiva di >>> gestire una piattaforma così sofisticata con solo 5 persone, anziché >>> 50. > Il fine ultimo di tutti questi bei ragionamenti è questo e soltanto > questo: decimare le persone necessarie a far funzionare una > infrastruttura come quelle di GARR o altre organizzazioni pubbliche o > private? > > Tra l'altro i 5 rimasti devono limitarsi a fare 4 click su un "admin > panel". Beh no. Direi che il fine ultimo sarebbe lavorare tutte, lavorare meno. > Figuriamoci se io ho qualcosa contro l'automazione, il mio alter ego ci > lavora per l'automazione, ma non può sempre e _solo_ limitarsi tutto a > _risparmiare_ sugli stipendi. > > Infine, sarà anche che alla fine rimangono in 5 su 50 a gestire una > intrastruttura basata su kubernetes... ma prima o poi le cose cominciano > a non funzionare più con 4 click e allora... parte il _cinema_. > > [...] Giustissimo. Non c'è nulla di magico. E occorre conoscere approfonditamente le soluzioni per evitare casini mondiali. E' anche vero che con la standardizzazione, magari un po' di "bricolage" riusciamo ad ottenerlo anche dai meno tecnici. Il che ci potrebbe consentire di creare comunità più inclusive e orizzontali, non comunità dove pochi smanettoni fanno cose incomprensibili alle più. >> La chiave è l'automazione. Non la modalita' con la quale viene >> implementata. > Non vorrei dire ma per _sviluppare_ le librerie necessarie a rendere > _accessibile_ l'automazione nel "Infrastructure as Code" è necessario > tanto lavoro competente... ma a quello non ci pensa nessuno? > > Le "librerie" di Terraform, Ansible, Puppet, NixOS, Guix crescono sugli > alberi? > > [...] Al momento a finaziarle sono aziende multinazionali turbo-capitaliste (tranne NixOS e Guix, ovviamente). Del resto anche per il Kernel Linux è così. Qui c'è un recente articolo da leggiucchiare sulla scarsa resilienza di progetti trainati dal capitale (e sulle contromisure da prendere): https://www.jeffgeerling.com/blog/2024/corporate-open-source-dead D. (null)

May 9, 2024

Nella Giornata dell'Europa, rilancio 5000 parole per l'Europa

by Marco Fioretti

Buonasera a tutti, Per celebrare questa giornata, rilancio una mia proposta di qualche anno fa: https://mfioretti.substack.com/p/5000-words-for-europe-again (https://mfioretti.substack.com/p/5000-words-for-europe-again) che potrebbe essere ancora piu' utile in un periodo di elezioni mondiali, ulteriori guerre all'orizzonte, e in cui direttive e altre proposte UE sono l'unica reazione/alternativa significativa allo strapotere digitale di USA e Cina. Grazie in anticipo a chi vorra' partecipare e far circolare la proposta. Marco

May 9, 2024