May 2024 - nexa - server-nexa.polito.it

Re: [nexa] il buco è il protocollo SS7 (was "Il buco nella rete telefonica...")

by 380°

Buongiorno, interessante inchiesta, grazie. A nessuno che si occupi di telecominicazioni dovrebbe essere concesso il lusso di _questa_ ignoranza :-) A nessuno che possieda un telefono cellulare dovrebbe essere concesso il lusso di ignorare che quel dispositivo può essere _facilissimamente_ tracciato ormai da qualsiasi "ladro di polli". Le scene dei film nelle quali le spie usano cellulari usa e getta non sono /fantasy/ :-D "J.C. DE MARTIN" <juancarlos.demartin(a)polito.it> writes: [...] > Nonostante gli addetti ai lavori ne siano al corrente da anni, le > vulnerabilità della rete telefonica continuano a non essere mitigate, > permettendo ad attori malevoli di geolocalizzare un’utenza telefonica > nel mondo > > 03.05.24 [...] > continua qui: > https://irpimedia.irpi.eu/setelefonando-reti-telefoniche-telefoni-geolocali… --8<---------------cut here---------------start------------->8--- L’inchiesta in breve * Con qualche migliaio di dollari chiunque può comprare l’accesso alla rete telefonica e diventare titolare di servizi di gestione un tempo pensati solamente per i grandi operatori * Tra questi servizi c’è anche l’accesso ai nodi di rete che comunicano con il protocollo SS7, una serie di istruzioni che facilitano anche il funzionamento di un’utenza telefonica in un Paese estero, nel caso del cosiddetto roaming * Sfruttando in modo illegittimo il protocollo SS7 un dispositivo mobile rischia di essere geolocalizzato ovunque nel mondo: è intorno a questa caratteristica che è sorto negli anni un vero e proprio mercato in cui le società di sorveglianza fanno da padroni * Purtroppo però nessuno sembra voler risolvere il problema: la rete è così configurata in quanto pensata per pochi attori affidabili ma l’accesso a soggetti terzi è aumentato con il tempo * Nonostante il problema sia noto da anni non è chiaro quante compagnie telefoniche adottino misure di sicurezza adeguate e quante svolgano una corretta due diligence sui locatari a cui forniscono l’accesso * L’Agenzia dell’Unione europea per la cybersicurezza collaborerà con gli Stati membri per sensibilizzare su questo tipo di attacchi e garantire che gli operatori di telecomunicazioni adottino misure adeguate per prevenirli. [...] «gli spyware sono solo la punta dell’iceberg della sorveglianza» poiché molte altre vulnerabilità della rete telefonica sono sfruttate impunemente da attori malintenzionati. [...] La possibilità di localizzare un numero di telefono non è dovuta a una vera e propria vulnerabilità informatica ma piuttosto a una questione di fiducia e di design del sistema di interconnessione tra gli operatori telefonici. [...] Il problema non si è risolto nemmeno nel 2012 con l’introduzione del 4G e del protocollo Diameter, che svolge le stesse funzioni di SS7 ma ne eredita anche i problemi. [...] In Italia a monitorare sugli operatori di telecomunicazioni sarà l’Agenzia per la Cybersicurezza Nazionale (Acn) che già se ne occupa nell’ambito del Codice delle comunicazioni elettroniche. Acn ha respinto una richiesta di commento sullo stato della sicurezza degli operatori telefonici italiani, riguardo a eventuali statistiche sul numero di attacchi che sono stati notificati e su quanti operatori hanno introdotto firewall e sistemi per filtrare messaggi SS7 sospetti. --8<---------------cut here---------------end--------------->8--- Eh sì, le "Agenzie" fanno chiacchiere, tante chiacchiere, solo chiacchiere... anzi no _propaganda_ (dobbiamo difenderci dagli stati canaglia!) Intanto /ingenuamente/ mi chiedo se mai qualcuno di quelli pizzicati a fare - o a favorire - sorveglianza _illegale_ siano mai stati condannati anche solo a scrivere 50 volte sulla lavagna "non lo faccio più" :-O Io so solo che per avere una cavolo di SIM _devo_ identificarmi e mi beccherebbero /prima/ di commettere un reato indossando il mio cellulare. Intanto, _tecnicamente_ le cose per il protocollo SS7 stanno male, ma proprio malissimo: https://en.wikipedia.org/wiki/Signalling_System_No._7#Protocol_security_vul… Mentre si stanno spendendo cifre considerevoli per passare al 5G, il protocollo che serve a: --8<---------------cut here---------------start------------->8--- stabilire e terminare le chiamate telefoniche nella maggior parte della rete telefonica pubblica commutata mondiale (PSTN) [...] esegue inoltre la traduzione dei numeri, la portabilità dei numeri locali, la fatturazione prepagata, il servizio SMS (Short Message Service) e altri servizi. --8<---------------cut here---------------end--------------->8--- (https://en.wikipedia.org/wiki/Signalling_System_No._7) e che è stato progettato coi piedi nel 1970 e la cui ultima versione è del 1993, continua ad essere utilizzato come se niente fosse, senza che nessuno ci metta quattro risorse per rimpiazzarlo con uno fatto bene. Sarà un caso... :-D Saluti, 380° P.S.: comunque resta il fatto che, grazie alla triangolazione radio, /qualcuno/ potrà sempre identificare _qualsiasi_ telefono cellulare, considerato che per avere una SIM occorre identificarsi... tranne se sei un criminale. -- 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 3, 2024

Zuckerman v. Meta Platforms, Inc.

by J.C. DE MARTIN

Zuckerman v. Meta Platforms, Inc. A case arguing that Section 230 protects tools that empower people to control what they see on social media. https://knightcolumbia.org/cases/zuckerman-v-meta-platforms-inc On May 1, 2024, the Knight Institute filed a lawsuit on behalf of Ethan Zuckerman—a professor of public policy, communication, and information at the University of Massachusetts Amherst—asking the court to recognize that Section 230 protects the development of tools that empower social media users to control what they see online. Professor Zuckerman would like to release a tool called Unfollow Everything 2.0, a browser extension that would allow Facebook users to automatically unfollow their friends, groups, and pages, and, in doing so, to effectively turn off their newsfeeds, which Facebook algorithmically sorts to drive user engagement. The tool would also enable people to donate their data to an academic research study that explores how this increased control affects user behavior and well-being. Zuckerman hasn’t released the tool, however, out of fear that Meta will sue him if he does so, as it threatened to do when a U.K.-based developer released a similar tool called Unfollow Everything. The lawsuit asks the court to declare that Section 230 immunizes Zuckerman from civil liability for releasing Unfollow Everything 2.0. In the alternative, it asks the court to declare that the tool does not violate Meta’s Terms of Service, the Computer Fraud and Abuse Act, or California’s Computer Data Access and Fraud Act. *Status: *Complaint filed on May 1, 2024. *Case Information: */Zuckerman v. Meta Platforms/, No. 3:24-cv-02596 (N.D. Cal.)*/ /* */PRESS STATEMENT: https://knightcolumbia.org/content/new-lawsuit-seeks-to-wrestle-control-of-… /* */ /* */ /*

May 3, 2024

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

by 380°

Buongiorno, vi chiedo perdono per l'estrema lunghezza di questo messaggio, se non vi interessa approfondire i concetti alla base di kubernetes et al fareste meglio a ignorarmi :-) Damiano Verzulli <damiano(a)verzulli.it> writes: > Cambio oggetto e espando la discussione... perché trovo spunti degni di > approfondimento: chissa' che con questo thread non facciamo --almeno > qui, in lista, con diversi "*NON* addetti ai lavori"-- un po' di > chiarezza... Giusto cercare di fare un po' di chiarezza almeno in questa lista, purtroppo però le cose sono sufficientemente complesse da risultare a volte poco chiare anche agli addetti ai lavori, me per primo sicuramente. > 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://en.wikipedia.org/wiki/Kubernetes; di sistemi di gestione cluster è piena la storia dell'IT [1], kubernetes non sarà l'ultimo... e nemmeno il penultimo. 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. 2. ansible è un sistema di gestione della configurazione (Infrastructure as Code) https://en.wikipedia.org/wiki/Ansible_(software); di sistemi di configuration management è piena la storia dell'IT, ansible non sarà l'ultimo e nemmeno il penultimo :-) > 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] --8<---------------cut here---------------start------------->8--- Pets Servers or server pairs that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed, and “hand fed”. Examples include mainframes, solitary servers, HA loadbalancers/firewalls (active/active or active/passive), database systems designed as master/slave (active/passive), and so on. Cattle Arrays of more than two servers, that are built using automated tools, and are designed for failure, where no one, two, or even three servers are irreplaceable. Typically, during failure events no human intervention is required as the array exhibits attributes of “routing around failures” by restarting failed servers or replicating data through strategies like triple replication or erasure coding. Examples include web server arrays, multi-master datastores such as Cassandra clusters, multiple racks of gear put together in clusters, and just about anything that is load-balanced and multi-master. --8<---------------cut here---------------end--------------->8--- (http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/) 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 ) 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://en.wikipedia.org/wiki/Kubernetes#Storage) e le configurazioni (https://en.wikipedia.org/wiki/Kubernetes#etcd) che servono non lo sono affatto: Comunque: --8<---------------cut here---------------start------------->8--- You don't need Kubernetes when the following four conditions are true: 1 You are deploying a very small number of containers to a very small number of machines (hosts). 2 The number of containers and machines is static and does not scale up or down. 3 Your containers and machines do not fail often. 4 You do not need additional features like persistent storage, LoadBalancing, configuration management, service discovery, autohealing, autoscaling, etc. Or you do need those features but you have very limited requirements and don't mind vendor lock-in. --8<---------------cut here---------------end--------------->8--- (via https://home.robusta.dev/blog/kubernetes-is-complex-because-you-want-comple…) Il punto 4 sopra mi fa rotolare dal ridere, come se "persintent storage" (che è lo standard storage dal 1960), "distributed storage", "load balancing" ecc. non fossero già implementati e usati in produzione da anni prima che fosse "inventato" kubernetes (con autoscaling e _soprattutto_ autohealing che meriterebbero un capitolo a parte). Il punto 3 (Your containers and machines do not fail often) è pura poesia: se i tuoi container falliscono spesso, caro sistemista, hai uun problema e invece di mettere in pista kubernetes per sparare a raffica container che falliscono, sarebbe opportuno fare debugging. Il combinato disposto dei punti 1 e 2 sopra fa sì che sistemi complessi come kubernetes vanno bene solo se l'infrastruttura deve vendere macchine (containers) usa e getta (per te) perché hai tonnellate di ferro che non stai usando e devi in qualche modo riciclare facendolo pagare almeno 10 volte tanto a chi fa fatica a gestirsi la propria infrastruttura IT in autonomia (anche avvalendosi di terzi neh, ma il concetto fondamentale è /autonomia/). > 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. ...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 :-) [...] >> 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". >> Dall’altra hai un sistema dichiarativo, in cui specifichi i requisiti >> e gli obiettivi, e il software che gestisce la piattaforma, determina >> i passi per attuare la soluzione. Come il venerabile CFEngine... in teoria (Promise Theory) :-O ...e Puppet, Salt, Chef; ma in pratica... Il problema irrisolvibile per tutti i sistemi di configuration management per sistemi operativi la cui gestione dei pacchetti _e_ della configurazione è _stateful_ [3] è che è praticamente impossibile ottenere l'idempotenza [4]. Nel caso specifico dei container Docker definiti coi Dockerfiles, l'idempotenza è _doppiamente impossibile_. Nel caso di Ansible: --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--- (https://en.wikipedia.org/wiki/Ansible_(software)#Design_goals) Divertente "it is possible... not idempotent": chiunque ha un po' di esperienza con simili sistemi sa che la promessa di poter ottenere "playbook" (o "manifests") idempotenti è una... _forzatura_ Per fare un esempio semplice su cosa significa idempotenza in una dichiarazione di un "manifest" Puppet (su cui ho esperienza) et al, per installare un pacchetto, nel manifest del sistema devi dichiarare: --8<---------------cut here---------------start------------->8--- package { 'openssh': ensure => installed, name => openssh, [...] } --8<---------------cut here---------------end--------------->8--- (https://www.puppet.com/docs/puppet/7/types/package.html) e poi applicare il manifest al sistema per ottenere il nuovo stato. Se il pacchetto NON lo vuoi, invece, non basta _non inserire_ quella dichiarazione dal manifest di sistema ma devi dichiarare: --8<---------------cut here---------------start------------->8--- package { 'openssh': ensure => absent, name => openssh, [...] } --8<---------------cut here---------------end--------------->8--- e poi *applicare* il manifest al sistema... tranne che magari "openssh" è una dipendenza di altri packages e il manifest non "concilia". [...] > Ed e' finita che oggi, una parte consistente della "mia" > infrastruttura è definita (e gestita) con "terraform" [1], soluzione > di riferimento in ambito dichiarativo: server virtuali, dischi, > segmenti di rete, regole di firewalling e di routing sono tutte > definite "dichiarativamente". Sì ma anche Damiano è incappato in quello che prima o poi succede a tutti coloro che hanno usato simili sistemi dichiarativi /supposti/ idempotenti: la dichiarazione NON coincide con lo stato :-( https://www.garrlab.it/p3_terraform_state/ --8<---------------cut here---------------start------------->8--- Today I discovered a mismatch between the state and the real infrastructure. If not addressed and solved, such a mismatch could cause serious problem to the infrastructure itself (dropping and re-creating three OpenStack instances… and related services!) [...] So, now it’s clear that the image used to build the three VMs were gone, and replaced with a different one, with same name. [...] The bad image ref id (00ece84f-c723-4ea0-a4fb-5555bea06c8d) is tightly associate to the VM at the OpenStack level. The same problem apply to the other two VMs: --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 [...] > Dall'altro lato, mi è chiarissimo il paradigma "imperativo" (hai citato > "ansible"), anche lui ampiamente testato in questi anni. > *NON* concordo sulla tua affermazione: "/...ogni modifica costa quanto > ricominciare daccapo.../". No infatti, secondo me è fuorviante; con Ansible (et al) raramente è necessario "ricominciare daccapo" > Non conosco gli altri strumenti, ma sono sicuro che ansible porta con > se l'idempotenza: applicare un playbook (la lista delle cose da fare, > nella sequenza indicata) su un set di sistemi sui quali, in > precedenza, la stessa ricetta è stata gia' applicata... *NON* produce > conseguenze. Tranne che può succedere che ci siano incongruenze tra la dichiarazione e lo status, come è successo quella vota a Damiano... e allora bisogna riconciliare. [...] > 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://edolstra.github.io/pubs/hotos-final.pdf) 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. [...] >> [...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] > Se a dover essere gestita è una applicazione "classica" (un Wordpress > che richiede un MySQL; un GitLab che richiede millemila prerequisiti; un > applicativo "old-school" che utilizza il file-system come repository di > dati; etc.)... portarlo su kubernets è un bagno di sangue anche GitLab (o analogo) che richiede millemila prerequisiti? Ho in mente decine di applicazioni _webbiche_ che richiedono millemila prerequisiti. [...] > Chiaramente, se ti chiami AWS, Google Microsoft, alla tua scala ti > organizzi solo con applicativi che ricadono nella prima categoria. > Pero', poi, vorrai che anche gli utenti che hanno applicativi della > seconda categoria... appunto, e magari prendono una _virtual machine_ "sul cloud" con attaccato un persistent storage proprietario, un'istanza RDMBS e robe simili e poi ci installano su Ubuntu per farci girare Wordpress o una applicazione PHP custom sviluppata su framework Laravel [...] > 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. 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_... ...tranne poi rendersi conto che dopo 5 anni, non 10, non 20, stai spendendo una fucilata indecente che faresti meglio a spendere per avere le competenze "in casa", anche fornite da terzi, ma con un "technical debt" gestibile, non con uno col quale rischi di fallire da un momento all'altro nel caso il tuo vendor decida di dismettere un servizio essenziale per la tua infrastruttura > sia perché la "vostra" piattaforma offre il suo lato migliore, solo in > condizioni particolarissime, sia, soprattutto, perché soltanto cosi' > Heinemeier resta competitivo a lungo termine. esatto: on-premises is (already!) the new normal :-D [...] >> Quello è semplicemente utilizzo di infrastrutture cloud, altrimenti >> detto IaaS, non è cloud computing nativo, che richiede riprogettare le >> soluzioni in ottica cloud. ammesso e _non_ concesso che l'"ottica cloud" sia quella dei microservices, allora anche quel concetto è ormai obsoleto (anche se difficile da superare) detto in altre parole: le applicazioni ben progettate che girano su sistemi on-premises ben progettati sono di almeno 1 ordine di grandezza più efficienti di quelle "cloud native"; per rimanare solo sul piano di progettazione delle applicazioni: --8<---------------cut here---------------start------------->8--- Replacing method calls and module separations with network invocations and service partitioning within a single, coherent team and application is madness in almost all cases. --8<---------------cut here---------------end--------------->8--- (https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-mic…) > Mi è moltissimo chiaro. Ma mi è altrettanto chiaro che quella > "riprogettazione" --che tu poni come "prerequisito" del cd. > cloud-computing nativo-- *NON* la fa... nessuno. No infatti: continuano (quasi) tutti a usare applicazioni client-server webbiche "tradizionali", come si facevano anche prima dell'hype ...anche perché le applicazioni per essere "cloud native" devono praticamente essere riscritte da sviluppatori competenti, a meno di far su un paciugone di codice SOAP/REST che ci mette 100 volte il tempo che ci metteva prima > Tutti, pero', dicono: "Siamo sul cloud". Se non hanno fatto quella > riprogettazione... come fanno a starci? Prendono una/dieci/cento VM su AWS, ci attaccano storage, database ecc e ci installano Ubuntu con su la loro bella webapp. [...] >>> 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". 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_. [...] > 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? [...] > Mi fermo. Mi sa che ho esagerato :-( Perdonatemi... Ops, mi sa anche io :-/ > [1] https://www.terraform.io/ > [2] https://docs.gitlab.com/ee/user/infrastructure/iac/ > [3] https://www.proxmox.com/en/proxmox-virtual-environment/overview > [4] https://opentofu.org/ > [5] https://registry.terraform.io/providers/bpg/proxmox/latest/docs Grazie mille per questo bel thread! Saluti, 380° [1] kubernetes è basato sulla Promise Theory di Mark Burgess, autore di CFEngine rilasciato la prima volta nel 1993 https://en.wikipedia.org/wiki/CFEngine [2] http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ [3] a volte la statefulness _purtroppo_ è legata a come è progettata (male!) l'applicazione stessa, come nel caso di Nextcloud ad esempio [4] https://en.wikipedia.org/wiki/Idempotence -- 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 3, 2024

"Il buco nella rete telefonica: come una vulnerabilità rende chiunque (potenzialmente) geolocalizzabile"

by J.C. DE MARTIN

Il buco nella rete telefonica: come una vulnerabilità rende chiunque (potenzialmente) geolocalizzabile Nonostante gli addetti ai lavori ne siano al corrente da anni, le vulnerabilità della rete telefonica continuano a non essere mitigate, permettendo ad attori malevoli di geolocalizzare un’utenza telefonica nel mondo 03.05.24 Riccardo Coluccini <https://irpimedia.irpi.eu/autore/riccardo-coluccini/> Nell’oscuro mondo della sorveglianza un segreto di pulcinella si tramanda fin dal 2008 e ciclicamente torna ad affacciarsi nei dibattiti di settore grazie a inchieste giornalistiche e al lavoro di ricercatori di sicurezza. Per localizzare una persona, ovunque essa si trovi nel mondo, potrebbe essere sufficiente conoscerne il numero di telefono. Ciò è possibile perché lo stesso sistema che permette agli operatori telefonici di comunicare tra loro per gestire il roaming – ovvero le comunicazioni tra operatori di diversi Paesi – può essere usato in maniera fraudolenta anche per scopi illegittimi, come sorvegliare o intercettare SMS e telefonate. È per questa ragione che, a marzo del 2023, alcuni operatori telefonici sono stati convocati dalla commissione speciale Pega, istituita dal Parlamento europeo inizialmente per investigare sugli abusi compiuti da almeno tre Stati membri con lo spyware Pegasus, sviluppato dall’azienda israeliana Nso. Nel tempo la commissione aveva espanso il proprio raggio d’azione, monitorando le attività di sorveglianza all’interno dei confini comunitari. [...] continua qui: https://irpimedia.irpi.eu/setelefonando-reti-telefoniche-telefoni-geolocali…

May 3, 2024

Re: [nexa] Economia a mano armata 2024

by benjuade＠murena.io

Grazie di questa preziosa risorsa. Al riguardo approfitto per segnalare due link a corredo: - il dossier di Valori.it "L'intelligenza artificiale va al fronte": https://valori.it/dossier/intelligenza-artificiale-guerra/ - la campagna per mantenere la trasparenza sui flussi degli investimenti bancari nell'ambito militare (legge 185/1990, penso che l'Italia sia l'unico paese al mondo ad avere una tale trasparente legislazione): https://www.bancaetica.it/la-trasparenza-sullexport-delle-armi-e-sulle-banc… B.J. May 2, 2024 at 22:56, "Dario Guarascio via nexa" <nexa(a)server-nexa.polito.it> wrote: > > Segnalo la pubblicazione dell'e-book > 'Economia a mano armata 2024' (a cura di Greenpeace e Sbilanciamoci!), > con un capitolo sul rapporto tra Big Tech e apparato militare statunitense > Qui il link per poter scaricare liberamente l'e-book: > > https://sbilanciamoci.info/fermiamo-la-nostra-corsa-alle-armi/ > > -- > > **Dario Guarascio** > Dipartimento di Economia e Diritto, Sapienza Università di Roma http://www.uniroma1.it/strutture/dipartimenti > Via del Castro Laurenziano n° 9, 00161 Roma > Edificio A (6° piano) -ala B, stanza n° 606 > E-mail: dario.guarascio(a)uniroma1.it > > **Sito web** > italiano - https://sites.google.com/a/uniroma1.it/darioguarascio/ > inglese - https://sites.google.com/a/uniroma1.it/darioguarascio-eng/ > > **Fai crescere le giovani ricercatrici e i giovani ricercatori** > > **con il 5 per mille alla Sapienza** > > Scrivi il codice fiscale dell'Università **80209930587****Cinque per mille https://www.uniroma1.it/it/node/23149 ** >

May 3, 2024

Re: [nexa] The United Nations ditches Big Tech in a bid for security

by alessandro marzocchi

In due non andiamo da nessuna parte ... Comunque, grazie. Cordialità Duccio (Alessandro Marzocchi) Il giorno gio 2 mag 2024 alle ore 17:36 <nexa-request(a)server-nexa.polito.it> ha scritto: > > Message: 4 > Date: Thu, 2 May 2024 17:36:43 +0200 > From: Damiano Verzulli <damiano(a)verzulli.it> > To: nexa(a)server-nexa.polito.it > Subject: Re: [nexa] The United Nations ditches Big Tech in a bid for > security > Message-ID: <7eb3db2c-3d77-40d3-ac6f-4b0b7943080e(a)verzulli.it> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Il 02/05/24 8:24 AM, alessandro marzocchi ha scritto: > > Grazie Damiano, nessuna risposta alla seconda domanda > > *** > > > A tutti domando: una raccolta di firme? Almeno per chiedere ai > > > candidati la loro opinione ed un impegno. > > *** > > ...io potrei pure dedicarci del tempo (a mettere in piedi quello che > serve [per raccogliere queste firme]).... ma resto comunque un banale > tecnico: serve qualcuno che prenda in mano la parte politica e la porti > avanti... E li, io sono totalmente ignorante! > > Quindi... non ti rispondo. Ma se vorrai farlo... ed avrai bisogno di una > spalla tecnica, io potrei pure esserci :-) > > Un caro saluto, > DV > > -- > Damiano Verzulli > e-mail:damiano@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 > >

May 2, 2024

Economia a mano armata 2024

by Dario Guarascio

Segnalo la pubblicazione dell'e-book 'Economia a mano armata 2024' (a cura di Greenpeace e Sbilanciamoci!), con un capitolo sul rapporto tra Big Tech e apparato militare statunitense Qui il link per poter scaricare liberamente l'e-book: https://sbilanciamoci.info/fermiamo-la-nostra-corsa-alle-armi/ -- *Dario Guarascio* Dipartimento di Economia e Diritto, Sapienza Università di Roma <http://www.uniroma1.it/strutture/dipartimenti> Via del Castro Laurenziano n° 9, 00161 Roma Edificio A (6° piano) -ala B, stanza n° 606 E-mail: dario.guarascio(a)uniroma1.it <nome.cognome(a)uniroma1.it> *Sito web* italiano - https://sites.google.com/a/uniroma1.it/darioguarascio/ inglese - https://sites.google.com/a/uniroma1.it/darioguarascio-eng/ -- *Fai crescere le giovani ricercatrici e i giovani ricercatori*** *con il 5 per mille alla Sapienza* Scrivi il codice fiscale dell'Università *80209930587 **Cinque per mille <https://www.uniroma1.it/it/node/23149>*

May 2, 2024

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

by Damiano Verzulli

Cambio oggetto e espando la discussione... perché trovo spunti degni di approfondimento: chissa' che con questo thread non facciamo --almeno qui, in lista, con diversi "*NON* addetti ai lavori"-- un po' di chiarezza... 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”. 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. 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"? A me piace inquadrarlo come qualcuno che si alza e dice: "Il Re è nudo"... e poi va alla macchina da cucire, e prepara uno straccio di vestito (che comunque "copre"). Non è di seta. Na ha lapislazzuli incastonati a griglia. Non ha i bordi valorizzati con merletti ricamati al tombolo. Ma copre. Ed è quello che gli serve. > 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. > Dall’altra hai un sistema dichiarativo, in cui specifichi i requisiti > e gli obiettivi, e il software che gestisce la piattaforma, determina > i passi per attuare la soluzione. Non ho alcuna difficolta' ad ammettere che fino a ~quattro anni fa la distinzione fra questi due paradigmi (dichiarativo vs. procedurale) mi era chiara... solo in teoria. Poi, pero', ho avuto il piacere (e la fortuna) di poter mettere le mani su una infrastruttura cloud, "giocandoci" a piacere. Ed e' finita che oggi, una parte consistente della "mia" infrastruttura è definita (e gestita) con "terraform" [1], soluzione di riferimento in ambito dichiarativo: server virtuali, dischi, segmenti di rete, regole di firewalling e di routing sono tutte definite "dichiarativamente". Ed abbiamo anche sperimentato l'ebrezza di conservare lo "stato" in un'area condivisa (GitLab) affinché piu' persone potessero lavorare sulla stessa infrastruttura... senza pericolo di creare collisioni. Addirittura abbiamo pure testato la possibilita' che fosse GitLab stesso, con le sue pipeline, a "riconciliare" i cambiamenti nei file di definizione (aka: un PUSH con modifiche/aggiunte alle direttive di terraform) sull'infrastruttura di produzione (terraform apply) - [2] Anche ad una scala ridottissima come la mia, i vantaggi di un tale approccio mi sono talmente chiari che oggi la creazione di macchine virtuali (e relativo storage e networking) la faccio esclusivamente con terraform. E tale approccio è possibile anche a scala ridottissima, ed anche in contesti 100% F/OSS (es.: utilizzo di un host proxmox [3], pilotato da terraform o il suo fork, OpenTofu [4]], attraverso il provider specifico [5]. Ho la sensazione forte, pero', che il mio approccio non sia esattamente mainstream... e mi domando come mai [senza trovare una risposta semplice]. Dall'altro lato, mi è chiarissimo il paradigma "imperativo" (hai citato "ansible"), anche lui ampiamente testato in questi anni. *NON* concordo sulla tua affermazione: "/...ogni modifica costa quanto ricominciare daccapo.../". Non conosco gli altri strumenti, ma sono sicuro che ansible porta con se l'idempotenza: applicare un playbook (la lista delle cose da fare, nella sequenza indicata) su un set di sistemi sui quali, in precedenza, la stessa ricetta è stata gia' applicata... *NON* produce conseguenze. Questo mette al riparo lo sviluppatore [...che comunque è meglio che sappia cio' che sta facendo...] dal porsi il problema: "L'avro' gia' fatto?". Semplicemente lui applica le modifiche alla ricetta e la rispara su tutti i target: quelli che erano gia' a posto, resteranno invariati. Quelli che erano disallineati... si allineeranno (ai dettami della ricetta). Fra "dichiarativo" vs. "procedurale", personalmente ho trovato un equilibrio lasciato che l'infrastruttura (IAAS) sia gestita 100% in modo dichiarativo (terraform), mentre tutta la parte applicativa soprastante (setup dell'infrastruttura di containerizzazione e deploy dei container e delle relative dipendenze [storage persistente e networking]) preferisco farla con approccio "procedurale" (ansible). I due approcci, inoltre, possono anche operare in simbiosi: modifica ai file dichiarativi di terraform e, al loro interno, includere il minimo indispensabile per avviare, a fine attivita', un playbook ansible che si occupa del resto. Tutto automaticamente. Insomma: non c'e' una ricetta magica per tutto. E continuano ad esserci contesti che mal si applicano ad entrambi gli approcci. L'ottimale credo sia quello di conoscere (possibilmente in modo almeno sufficiente) entrambi gli approcci, con i principali strumenti che li rendono possibili e poi decidere sulla base delle proprie esigenze. > [...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. Se a dover essere gestita è una applicazione "classica" (un Wordpress che richiede un MySQL; un GitLab che richiede millemila prerequisiti; un applicativo "old-school" che utilizza il file-system come repository di dati; etc.)... portarlo su kubernets è un bagno di sangue: la complessita' aumenta di almeno un ordine di grandezza e la probabilita' che si rompa tutto aumenta allo stesso modo. Usare K8S per far girare OpenSearch, Kafka, una applicazione Node/Python che *NON* utilizza storage persistente.... è un conto. Usare K8S per far girare il 99% del carico di lavoro che trovo negli Atenei, nelle ASL e, scommetto, nelle aziende... è un altro. Chiaramente, se ti chiami AWS, Google Microsoft, alla tua scala ti organizzi solo con applicativi che ricadono nella prima categoria. Pero', poi, vorrai che anche gli utenti che hanno applicativi della seconda categoria... possano venire da te. E tu vuoi fatturarli. Quindi fai un po' di "fumo da cloud" e dici a tutti: "venite da noi, sempre e comunque". E tutti corrono. E tu fatturi. Heinemeier se ne è accorto, ed ha agito di conseguenza. > > I server su cui gira Kamal vanno invece installati a mano (you boot > a Ubuntu server) e magari se li fa installare da un contractor che gli > installa i server nel datacenter (lo spiega nel video). > > Insomma, you get what you pay for. > > Tutt’altra cosa di una infrastruttura cloud scalabile, resiliente e > automatizzata. Ho la sensazione che tu guardi la questione dal lato infrastrutturale (tiro su del ferro, ci metto OpenStack e K8S e metto a disposizione di terzi una meravigliosa piattaforma "scalabile, resiliente e automatizzata"), mentre Heinemeier guarda la questione dal lato applicativo: ho una applicativo relativamente moderno, di cui ho il controllo completo. Posso farlo girare come dico io, dove dico io, al livello di affidabiita' che decido io... ad una frazione del costo che mi costa farla girare su AWS. 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... sia perché la "vostra" piattaforma offre il suo lato migliore, solo in condizioni particolarissime, sia, soprattutto, perché soltanto cosi' Heinemeier resta competitivo a lungo termine. >> Negli ultimi anni, ho visto (molte) persone sostenere che "andavano su >> cloud" perché spostavano il loro wordpress su una VM su AWS... (o su >> Azure). Vedo N Atenei sostenere la tesi che vanno "sul cloud Azure" >> (quello venduto a marchio CRUI...) quando semplicemente spostano le VM >> che prima erano interne, su VPS Azure. >> >> Vedo Atenei sostenere che vanno su cloud... perché "spostano" le VM >> interne sull'infrastruttura VMware che Cineca mette a disposizione su >> catalogo ACN/exAGID. >> > Quello è semplicemente utilizzo di infrastrutture cloud, altrimenti > detto IaaS, non è cloud computing nativo, che richiede riprogettare le > soluzioni in ottica cloud. Mi è moltissimo chiaro. Ma mi è altrettanto chiaro che quella "riprogettazione" --che tu poni come "prerequisito" del cd. cloud-computing nativo-- *NON* la fa... nessuno. Tutti, pero', dicono: "Siamo sul cloud". Se non hanno fatto quella riprogettazione... come fanno a starci? >> >> Poi mi giro... è mi vedo a deploiare --con tool di automazione-- >> applicativi nativamente-cloud (kafka, opensearch, microservizi nodejs >> stateless), sull'infrastruttura GARR-Cloud, facendolo (io) senza >> utilizzare kubernetes (che tu citi), ma operando comunque con container >> (docker), stateless (con persistenze su motori nativi-cloud) e con anche >> livelli non banali di affidabilita'/resilienza (docker-swarm, nomad). >> 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. Per consentire ad un team di 5 persone di operare una infrastruttura la cui complessita', 10 anni fa, richiedeva 50 persone.... *NON* serve l'adozione tout-court di paradigmi dichiarativi. Serve *L'AUTOMAZIONE*. Che poi tale automazione possa avvalersi di soluzioni dichiarative (a-la-terraform) o imperative (a-la-ansible), è un dettaglio. Posso cambiare una singola riga su un file ".tf" di terraform per poi far si che un "terraform apply" produca la distruzione (reale!) di 100 macchine virtuali esistenti [quelle in produzione] e la creazione di 100 *nuove* macchine virtuali. ...e posso cambiare una singola riga in un playbook ansible... per distruggere (o aggiustare, o anche creare) 100 macchine virtuali. La chiave è l'automazione. Non la modalita' con la quale viene implementata. Al limite, l'elemento a corredo (dell'automazione) è tutto lo stack che serve a garantire il pieno controllo su quello che si sta facendo. In una parola: il tracciamento maniacale di quello che si fa, su Git (GitLab, ForgeJo, etc.). Mi fermo. Mi sa che ho esagerato :-( Perdonatemi... Bye, DV [1] https://www.terraform.io/ [2] https://docs.gitlab.com/ee/user/infrastructure/iac/ [3] https://www.proxmox.com/en/proxmox-virtual-environment/overview [4] https://opentofu.org/ [5] https://registry.terraform.io/providers/bpg/proxmox/latest/docs -- Damiano Verzulli e-mail:damiano@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

May 2, 2024

Re: [nexa] "...and... We've left the cloud!" - David Heinemeier Hansson / 37signals

by 380°

Buonasera Damiano, grazie per questi thread sistemistici :-) Damiano Verzulli <damiano(a)verzulli.it> writes: [...] > Di converso, in diversi punti cita sia l'esperienza negativa (costo) con > Suse / Rancher [1], sia il fatto che alla fine ha optato per scriversi > il suo orchestratore (Kamal [2][3]) che poggia su docker (e quindi > container... microservizi... etc) ehrm... «Even Amazon can't make sense of serverless or microservices» https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-mic… --8<---------------cut here---------------start------------->8--- That really sums up so much of the microservices craze that was tearing through the tech industry for a while: IN THEORY. Now the real-world results of all this theory are finally in, and it's clear that in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system. And serverless only makes it worse. [...] In many ways, microservices is a zombie architecture. Another strain of an intellectual contagion that just refuses to die. It's been eating brains since the dark days of J2EE (remote server beans, anyone??) through the WS-Deathstar nonsense, and now in the form of microservices and serverless. [...] But this third wave seems finally to have crested. I wrote an ode to The Majestic Monolith way back in 2016. Kelsey Hightower, one of the leading voices behind Kubernetes, put it beautifully in 2020: "We’re gonna break [the monolith] up and somehow find the engineering discipline we never had in the first place... Now you went from writing bad code to building bad infrastructure. [...] Replacing method calls and module separations with network invocations and service partitioning within a single, coherent team and application is madness in almost all cases. --8<---------------cut here---------------end--------------->8--- «From bad code to bad infrastructure» è stato "un lampo". Altri interessanti suggerimenti qui: https://world.hey.com/dhh/how-to-recover-from-microservices-ce3803cc «How to recover from microservices» > e che è sensibilmente piu' "semplice" di tutto kubernetes (come > biasimarlo?). già: come? :-) > Da qui, mi sorge un dubbio: quando si puo' dire di "utilizzare un > modello cloud"? Piu' in generale: che significato diamo al termine "cloud"? > > La domanda non e' cattiva... eh certo che non è cattiva... è _uguale_ a "che significato diamo al termine intelligenza artificiale"? diciamo che non è _affatto_ "rocket science", OK? :-) ...anche se effettivamente nel 2011 il NIST ha definito le 5 caratteristiche essenziali della "scatola maggggica" contemporanea: https://en.wikipedia.org/wiki/Cloud_computing#Definition ...anche se effettivamente i sistemi operativi time-sharing del 1960 _sono_ cloud computing: https://en.wikipedia.org/wiki/Cloud_computing#History ...il che nel 2012 ha fatto scrivere alla commissione EU che «Cloud computing has a range of defining features (which make a general definition elusive)» [1] (definizione elusiva nello spazio-tempo, n.d.r.) come biasimarli? [...] > Vedo Atenei sostenere che vanno su cloud... perché "spostano" le VM > interne sull'infrastruttura VMware che Cineca mette a disposizione su > catalogo ACN/exAGID. ...annamo bene! (VMware... io sarei _letteralmemte_ terrorizzato!) «Dove vuoi andare oggi?» B-) (cioè: dove /ti illudi/ che ti _portiamo_ oggi?) > Poi mi giro... è mi vedo a deploiare --con tool di automazione-- > applicativi nativamente-cloud (kafka, opensearch, microservizi nodejs > stateless), sull'infrastruttura GARR-Cloud, facendolo (io) senza > utilizzare kubernetes (che tu citi), ma operando comunque con container > (docker), stateless (con persistenze su motori nativi-cloud) e con anche > livelli non banali di affidabilita'/resilienza (docker-swarm, nomad). > Sono, io, "cloud"? nota a latere: tu sapresti fare /esattamente/ tutte quelle cose anche partendo da bare-metal ;-) bello: «il Cloud sono io!» :-) ...o forse stai "solo" facendo il sistemista con strumenti adeguati alle infrastrutture IT odierne? ...forse qualcosa è andato storto negli ultimi 20 anni nei "reparti IT" di organizzazioni grosse e piccole, che tutti si sentono inadeguati a gestire la propria infrastruttura IT e preferiscono farsela gestire da qualcun altro? > Insomma: posso anche capire che l'esperienza di Heinemeier non sia > "accademicamente interessante" (...d'altronde a lui interessa il > business nudo e crudo), pero' sostenere il fatto che non sia "cloud"... > mi pare un pizzico eccessivo. sì ma cos'è cloud? Un sistema IT che ha tutte e 5 le caratteristiche indicate dal NIST? (occhio che la domanda è a triplo tranello :-D ) > Da qui, ripeto, la domanda: secondo coloro che frequentano questo > gruppo... quand'e' che ci si puo' fregiare del titolo "siamo su cloud", > legittimamente? "io me ne fregio" > Io una mezza idea ce l'ho ma... se la applico, il numero di medagliette > che rilascio è *MOLTO* vicino a zero (perché per definirti "cloud", nel > mio mondo, devi partire dalle applicazioni... e non certo da quello che > hai. Risultato: nessuno lo fa...) io ho un'altra domanda: è davvero importante trovare una definizione di "Cloud computing"? > BTW: Scopro solo ora che Heinemeier è il creatore di Ruby on > Rails... [4] he he he... sì è illo, l'azienda per la quale lavora - 37signals (aka Basecamp) - vende applicazioni web programmate in Ruby On Rails, l'ultima è il servizio email (superincompatibile) che si chiama HEY https://en.wikipedia.org/wiki/37signals [...] Saluti, 380° [1] https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0529:FIN:EN… -- 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 2, 2024

Re: [nexa] "...and... We've left the cloud!" - David Heinemeier Hansson / 37signals

by Giuseppe Attardi

May 2, 2024