Stories 04/2025 – Margaret Hamilton (corretto)

Pillole di Bit
Pillole di Bit
Stories 04/2025 - Margaret Hamilton (corretto)
Loading
/

(seconda pubblicazione, per risolvere il problema sulle piattaforme Spreaker, Spotify e Youtube)
Nel 1969 l’uomo mise piede sulla Luna (sì, davvero, chi non ci crede dovrebbe smettere). Tra tutte le persone che lavorarono al progetto, una delle più importanti fu la Direttrice della divisione di Ingegneria del Software, Margaret Hamilton, che con la sua visione dell programmazione molto avanti nel tempo, evitò che la missione fallisse.

Questa puntata extra è uscita per ringraziarvi della generosità che avete dimostrato nel mese di febbraio 2025, con le vostre donazioni. Ne volete un’altra? Contribuite a riempire il grafico a torta che trovate nella barra laterale del sito, se a fine marzo 2025 arriva al 100%, il primo di maggio 2025 arriva la nuova puntata di PdB Stories.

Per leggere lo script fai click su questo testo

Pillole di Bit Stories è un podcast speciale, che esce il primo giorno del mese, come ringraziamento, quando le donazioni superano una certa soglia. Oggi è il primo di Aprile 2025 ed esce perché a Febbraio siete stati davvero molto generosi e ho pensato che fosse dovuto un ringraziamento speciale. E come ringraziarvi, se non con una puntata speciale, diversa dal solito, al di fuori della consueta scaletta?
Grazie, davvero, e buon ascolto di questa puntata dedicata ad una storia dell’informatica
Il 17 agosto 1936, in Indiana nasce Margaret Hamilton, forse il nome vi dice qualcosa, forse no, ma la puntata è qui apposta per raccontarvi una storia, la sua storia che entrerà nelle case delle persone di tutto il mondo con una delle dirette TV più seguite con 900 milioni di telespettatori. E non è il Superbowl.
In quegli anni, una ragazza che voleva studiare materie scientifiche come la matematica, non era molto ben vista, ma suo padre la sostiene e la spinge a fare quello che le piace di più, la passione per i numeri.
Margaret, con grande determinazione, si diploma alla Hancock High School e poi si laurea in matematica all’Earlham College nel 1958.
Durante gli studi conosce suo marito, compagno di vita e avventure professionali.
Dopo la laurea insegna in una scuola superiore, ma la cosa le va un po’ stretta, vuole fare di più e soprattutto vuole lavorare nel settore dell’informatica, all’inizio degli anni 60 in grande espansione.
Per contestualizzare, nel 1958 viene costruito il primo circuito integrato, nel 1960 vengono prodotti i primi chip al silicio e nasce il linguaggio di programmazione Basic.
Nel 1960 Margaret, anzi la dottoressa Margaret Hamilton, si iscrive all’università di Brandeis a Boston per studiare matematica astratta.
Ma quando vede un annuncio al MIT, proprio lui, il Massachusett Institute of Technology, dove si cercavano programmatori per lavorare al sistema anti missilistico SAGE, si candida.
SAGE, acronimo per Semi Automatic Ground Environment è, meglio era, un sistema di controllo dello spazio aereo che, presi i segnali dei radar, li mandava a dei calcolatori sparsi per gli Stati Uniti per creare un sistema di difesa aerea contro attacchi dall’Unione Sovietica. La Guerra Fredda era pervasiva.
Oggi, beh, le cose sono molto diverse, sia a livello tecnologico che politico.
Una brava matematica che non si ferma davanti a niente, molto determinata non può che passare le selezioni ed entrare a far parte del progetto.
Il sistema SAGE si basava su un calcolatore AN/FSQ-7
Qui ci va una parentesi, perché approfondire un po’ sul Army-Navy / Fixed Special eQuipment è d’obbligo.
È il più grande calcolatore discreto mai prodotto, per discreto si intende che usa i dati interi o binari e non valori continui come un sistema elettronico analogico, possiamo definirlo digitale.
Ognuna delle 24 macchine costruite da IBM dal 1955 occupava 2000 metri quadrati, in un campo da calcio ce ne stanno al massimo 3, giusto per farvi un’idea, era composto da 49.000 valvole, consumava 3 megawatt e processava 75.000 istruzioni al secondo.
È stato progettato e costruito proprio per il SAGE e se ne volete vedere uno, lo potete vedere in Wargames, il famoso film, che se non avete visto, bacchettate sulle mani e correte subito a guardarlo.
Se ne volete sapere di più sulle valvole c’è la puntata 15.
Inutile dire che, seppur la guerra sia una cosa oscena da ripudiare, è uno degli eventi un cui l’uomo investe un sacco di soldi ed energie e da questi investimenti escono poi avanzamenti tecnologici e ricadute sulla vita di tutti i giorni, fino a prima, inimmaginabili.
Se ci fate caso lo si vede oggi, non ci sono mai soldi per fare niente per il sociale, per la povertà, per l’ambiente e da un giorno all’altro sono comparti 800 miliardi di Euro in Europa da spendere in armamenti.
Lo vedremo anche con la ricerca spaziale, all’epoca, comunque, parte della Guerra Fredda.
Programmare il calcolatore AN/FSQ7, Q7 per gli amici non è cosa banale, non c’è un linguaggio ad alto livello, come il C o il Basic e un compilatore, ma va tutto scritto in assembly, direttamente in istruzioni macchina, in 0 e 1 o in esadecimale.
Insomma, per chi inizia a programmare uno scalino decisamente alto.
Ma la dottoressa Margaret Hamilton non si scoraggia, abbiamo già visto che non è una persona che si arrende, impara a programmare, lo fa bene e riesce a produrre software affidabile e di alta qualità, questa cosa sarà fondamentale più avanti.
Intanto nel 1961 nasce il programma Apollo, un ambizioso progetto che avrebbe dovuto portare gli uomini a passeggiare sulla Luna.
Il primo che dice che non ci siamo mai stati va a fare la fine che hanno fatto gli astronauti prima di Gagarin, chiaro?
L’obiettivo era riuscire a mettere i piedi sulla luna entro la fine del decennio, tutti sappiamo che nel 1969 la missione ha avuto successo per la prima volta.
Lo hanno visto in diretta 900 milioni di persone.
Quel giorno, a seguire sul posto c’era anche un giovanissimo Piero Angela, inviato dalla RAI.
Il programma ha generato investimenti enormi in ogni ambito tecnologico, affrontare lo spazio era, ed è ancora oggi, una cosa molto complicata.
Nel 1963 Margaret, tramite un laboratorio del MIT, entra come direttrice della divisione dell’ingegneria del software del programma Apollo.
Adesso noi viviamo attorniati dal software, devo dire, spesso software di pessima qualità.
Voi però pensate a un oggetto che doveva partire dalla terra e arrivare sulla Luna, innovativo per l’epoca, dove il software era fondamentale per una buona parte di tutte le fasi della missione, dalla gestione dei motori, alla navigazione alla gestione del supporto vitale.
Il tutto, per entrare in qualche dettaglio tecnico, su un calcolatore, l’AGC Apollo Guidance Computer, che aveva un processore da 2 Mhz, 4 KB di RAM e 72 KB di memoria non volatile.
Pesava 32Kg ed era grande 61x32x17cm
La memoria non volatile, chiamata core rope memory, era una serie di piccole bobine di rame una in fila all’altra, anche usata per i più famosi UNIVAC e UNIVAC2
Era programmato in un linguaggio di programmazione sviluppato al MIT, proprio dal team di Margaret Hamilton, chiamato AGC assembly language.
Forse conoscete la famosa foto con Margaret accanto al listato dell’intero codice stampato su vari blocchi di fogli alti come lei, ma se lo volete leggere, adesso è disponibile su github, il link, insieme a molti altri che ho usato come fonti, è nelle note della puntata.
Per paragone, Il primo Arduino, il Duemilanove aveva meno RAM e ROM del sistema montato su Apollo, ma andava a 16Mhz invece di 2.
L’attuale Arduino Uno R4 minima, un microcontrollore che usiamo per progetti a scuola e a casa, è grande 7×5 cm, pesa pochi grammi, costa 22€ e supera di gran lunga tutte le specifiche del computer montato su Apollo.
Abbiamo portato 3 uomini sulla Luna con un Arduino.
Questa cosa mi fa diventare pazzo.
Ovviamente nello spazio gli stress fisici sono diversi che a casa, una scheda da pochi € non resisterebbe neanche al decollo credo, ma il fatto che adesso per avere più prestazioni dell’epoca ci vadano davvero due spicci, rugged a parte, se ci pensate, è pazzesco.
Ed è più pazzesco con quali prestazioni sono riusciti ad arrivare fino lì. Non è prendere l’autostrada e fare Milano-Mosca. Sono andati sulla Luna, a 384.000 km di distanza, in un posto senza atmosfera.
Torniamo a Margaret Hamilton, per il progetto Apollo dirige centinaia di programmatori per un compito molto complesso, il software deve gestire tutti i parametri del volo, li deve gestire in contemporanea e deve essere anche in grado di gestire eventuali errori del sistema, che possono essere di ogni tipo e inaspettati. Lassù non si può mandare nessuno a riparare le cose che non vanno. Avete mai visto il film Apollo 13?
Durante il progetto Margaret si batte strenuamente per far riconoscere lo sviluppo software come elemento critico dei sistemi complessi, fino a quel periodo era relegato in secondo piano, la parte di maggior importanza era sempre stata data all’hardware.
Diciamo che ha visto il futuro.
Il 20 luglio 1969, il mondo intero era con il fiato sospeso mentre Neil Armstrong e Buzz Aldrin si preparavano ad allunare con il modulo lunare Eagle. Durante la fase di discesa, si verifica un problema tecnico: un radar acceso per errore sovraccarica il computer di bordo, mandandolo in allarme. Vista la poca capacità di calcolo, ogni attività in più da calcolare era un problema.
Questo avrebbe potuto compromettere l’intera missione, ma il software sviluppato dal team di Margaret Hamilton è stato concepito in modo efficace e molto avanzato, rispetto al periodo. Grazie al sistema di gestione degli errori e delle priorità dei processi, il software riesce a gestire il sovraccarico, dando la precedenza alle funzioni critiche per l’allunaggio.
Il computer, gestito dal software, a questo punto il vero punto critico del sistema, invece di bloccarsi o ignorare l’errore, riconosce la situazione critica e decide di ignorare i compiti meno importanti, concentrandosi sulle funzioni essenziali per l’allunaggio. Questo permette ad Armstrong e Aldrin di atterrare sani e salvi sulla superficie lunare, realizzando un sogno che aveva affascinato l’umanità per secoli.
Queste le parole di Margaret Hamilton:
A causa di un errore nella checklist riportata in un manuale, l’interruttore del radar di rendezvous era stato impostato in una posizione sbagliata. Ciò aveva causato l’invio di comandi fuorvianti al computer. Il risultato fu che al computer venne richiesto di svolgere tutte le sue normali operazioni per l’atterraggio, ricevendo anche un carico supplementare di dati spuri da processare, che avevano però consumato il 15% in più delle sue risorse. Il computer (più precisamente, il suo software), riconobbe che gli era stato richiesto di svolgere più task di quanti ne avrebbe dovuti eseguire. Avvisò quindi della situazione con un allarme, che per gli astronauti doveva essere interpretato come “sono sovraccaricato con più task di quelli che dovrei svolgere in questo momento, manterrò attivi solo quelli importanti (ad esempio quelli necessari per l’atterraggio)”. […] Infatti il computer era stato programmato per fare molto più che riconoscere possibili casi di errori. Una serie completa di programmi di ripristino era stata inclusa nel software. L’azione del software, in questo caso, fu di escludere i task a bassa priorità e ripristinare quelli più importanti. Il computer, invece di causare un’interruzione, la impedì. Se il computer non avesse riconosciuto questo problema e avviato le opportune azioni di ripristino, dubito che l’allunaggio dell’Apollo 11 avrebbe avuto successo.
La carriera della dottoressa Margaret Hamilton non finisce con le missioni Apollo, è diventata una delle pioniere della programmazione, ha influenzato il modo di programmare, ha introdotto i concetti innovativi di gestione e prevenzione degli errori e di verifica formale del codice, cose che prima erano ignorate.
Ha ricevuto molti premi per la sua brillante carriera, sia da parte della NASA che dagli Stati Uniti.
Aggiungo una piccola postilla, per tutti quelli che pensano che la ricerca spaziale sia sempre un grande spreco di soldi e basta.
Abbiamo scoperto che per le missioni Apollo abbiamo avuto un balzo avanti nella programmazione del software, software che oggi è pervasivo.
Sulla luna hanno camminato 12 persone, per dovere di cronaca, con le missioni di Apollo 11, 12, 14, 15, 16 e 17, dal 1969 al 1972. Da allora nessun uomo è più andato sulla Luna.
Per fare tutte queste missioni sono stati spesi un sacco di soldi in ricerca, ricerca che è ricaduta sull’uso quotidiano di un sacco di cose. Queste sono alcune invenzioni delle missioni Apollo che usiamo ancora oggi
Le copertine metalliche leggerissime oro da un lato e argento dall’altro che vedete usare in ambulanza per raffreddare o riscaldare i pazienti.
Il cibo sottovuoto
L’idea di progettare solette per le scarpe con capacità di assorbire gli urti
Abiti resistenti al fuoco, li svilupparono dopo che l’equipaggio di Apollo 1 morì arso
La pompa per l’insulina
Le lenti resistenti ai graffi
I sistemi di assorbimento per le vibrazioni oggi usati negli edifici per la resistenza ai terremoti
Il sistema Lasik per tracciare la posizione degli occhi, adesso largamente usato nella chirurgia oculare con il laser
Le celle fotovoltaiche
Le cuffie con microfono senza fili
Tecnologia migliorata sugli pneumatici, in uso ancora oggi
L’asfalto drenante
Il memory foam
I purificatori d’aria
Se volete saperne di più su Apollo e quella volta che l’uomo ha messo piede sulla luna, vi consiglio due contenuti multimediali.
Il primo è solo audio, la puntata 56 di Orazio, podcast del Post con la voce di Matteo Caccia, nel quale una delle due storie verte su Michael Collins, che rimase sul modulo di comando ad aspettare il rientro del modulo di allunaggio.
Il secondo è una puntata del 2019 di Ulisse, condotto da Alberto Angela, che, insieme a Piero Angela, ripercorrono tutto il viaggio per arrivare sulla luna, nel 1969, lo trovate su raiplay.
E a chiusura di tutto questo, è notizia di marzo, che c’è una nuova sonda, allunata con successo, di una agenzia spaziale privata, che sta facendo vari esperimenti e che ha anche parte di una tecnologia italiana a bordo, per la localizzazione sulla luna usando parte dei segnali dei satelliti GPS che usiamo per la localizzazione sulla terra, vi lascio nelle note un video in alta definizione delle ultime fasi con l’allunaggio, una cosa pazzesca.
Pillole di Bit è un podcast gratuito da sempre e disponibile per tutti, se vi piace e reputate che il lavoro di realizzazione abbia del valore economico, potete trasformare questo valore in una donazione, sul sito trovate i link per farlo, con Satispay o Paypal, con quest’ultimo anche in abbonamento mensile, il tutto con la cifra che volete voi.
Se a fine mese la quantità di donazioni raggiunge una certa soglia, mi impegno a fare una puntata extra, per il primo del mese successivo, dedicata ad una storia dell’informatica, per ringraziarvi della generosità.

Il sito è gentilmente hostato da ThirdEye (scrivete a domini AT thirdeye.it), un ottimo servizio che vi consiglio caldamente e il podcast è montato con gioia con PODucer, un software per Mac di Alex Raccuglia

#359 – Cambio la password?

Pillole di Bit
Pillole di Bit
#359 - Cambio la password?
Loading
/

Il mondo si divide in chi predica il cambio regolare di tutte le password, per sicurezza, e chi invece dice che non serve, anzi, ne abbassa la sicurezza e dice che vanno cambiate solo quelle di cui si sa che sono compromesse. Ho fatto un po’ il punto.

Per leggere lo script fai click su questo testo

Nel gruppo del podcast abbiamo avuto, qualche tempo fa, una discussione abbastanza accesa sulla necessità di cambiare regolarmente la password o, meglio, le password, dei vari servizi che usiamo quotidianamente. C’è chi dice che è meglio farlo, c’è chi dice che non serve, tra questi un ente di fama mondiale, il NIST e la ISO 27001. Anche se ho parlato di password già in 7 puntate, ho pensato sia il caso di aggiungere questa ennesima puntata, per andare più a fondo sul cambio password, come e perché.

Questa puntata è stata realizzata grazie alle indispensabili donazioni di generosi ascoltatori
Gli abbonati
Andrea
E le donazioni spot
Alessandro
Andrea
Per sapere come far parte di questo elenco vi rimando al capitolo un po’ più in là nella puntata.
Piccola novità, nella busta dei gadget che vi arriva a casa, da questo mese, troverete un piccolo kit di un dado, casuale in facce, da 4 a 20 e in colori, a seconda di cosa ho nel caricatore della stampante 3D, pronto da piegare e montare.

Prima di iniziare, vi ricordo che potete contattarmi in mille modi, su Bluesky sono francesco.iltucci.com, su Mastodon sono cesco_78 su mastodon.social o pillole dibit su hackyderm.io o via mail a [email protected], trovate tutti i link comodi comodi sull’app dalla quale state ascoltando la puntata o sul sito, rispondo sempre. Il metodo migliore però è il gruppo telegram attivo durante tutta la settimana, dove si parla delle puntate e di tecnologia in generale, siamo davvero tanti, lo trovate a pilloledib.it/telegram

Oggi serve una seconda introduzione per due aggiornamenti e un piccolo rant.
Il primo è che vi devo chiedere scusa per un piccolo pasticcio legato alla puntata su Margaret Hamilton e mi devo lamentare per come vengono diffusi i podcast su alcune piattaforme. Se ascoltate il podcast su Spotify, Spreaker, Youtube o una delle piattaforme che prendono il feed da loro, vi sarete accorti che il file audio non era, anzi, non è ancora, quello corretto.
In pratica ho caricato il file sbagliato quando ho pubblicato la puntata. Alcuni ascoltatori, che ringrazio moltissimo, prima delle 8 del mattino me lo hanno fatto notare per tutte le vie con le quali posso essere contattato, ho pertanto aggiornato in fretta il file sul feed originale.
Il problema è che i tre servizi di cui sopra fanno riferimento al feed, ma copiano il file audio nei loro sistemi e da questi lo diffondono.
Ma, una volta copiato dal feed originale, non lo aggiornano più, anche se questo viene cambiato.
Su spreaker c’è un modo molto complesso per aggiornarlo a mano, sugli altri due no.
Per lasciare tutto pulito l’unica soluzione che ho trovato è che pubblicherò domani una seconda volta la stessa puntata con il file audio giusto, cancello quella sbagliata da tutte le altre piattaforme, attenzione, da Spotify non si può fare neanche quello, e dovrebbe andare tutto a posto. Scusate per il disagio, spero di non caricare mai più un file sbagliato.
Se siete abbonati al feed originale vi troverete la puntata di nuovo da scaricare, la cancellate e via.
Il secondo aggiornamento è che ho ricevuto un commento su spotify sulla puntata degli orologi, non mi arrivano notifiche e l’ho visto, tardi, mentre cercavo di risolvere il problema appena raccontato, ho fatto un errore nel pendolo, il tempo di oscillazione varia a seconda della lunghezza del pendolo e non della sua massa, scusate l’imprecisione.

Se avete ascoltato le vecchie puntate lo sapete già, se no vi faccio un rapido riassunto.
Ogni servizio che usate, che ha un accesso con utente e password, memorizza quest’ultima in modo che sia crittografata, con una funzione matematica detta hash a sola andata. La si codifica con questa funzione e non c’è modo di sapere dalla stringa di hash qual è la password di partenza.
Il controllo della password viene fatto inserendola, questa viene codificata nello stesso modo, se l’hash che risulta è uguale, allora la password è validata.
Ci sono vari modi per codificare le password, non è questa la puntata per approfondire.
Ogni servizio ha il suo bel database con utenti e relativo hash delle password.
Se parliamo di accesso al computer, la password è memorizzata in un file specifico, anche questo codificato, il sistema cambia a seconda del sistema operativo.
Abbiamo tante password, troppe password e le regole sono sempre le stesse.
Devono essere diverse per ogni servizio, devono essere lunghe abbastanza, anche un po’ complicate e, possibilmente salvate in un posto sicuro, come un password manager.
Va bene se sono complicate, va anche bene se sono molto lunghe composte da tre o quattro parole mnemoniche.
Qual è il problema delle password? che possono essere scoperte e quindi usate per accedere in modo illecito a servizi per fare danni.
Accedere al conto bancario, accedere alla VPN aziendale, accedere ad altri servizi per furto di dati, informazioni, attacchi di vario genere.
Come si rubano le password?
Il primo modo è banale, si chiedono alle persone e queste le dicono.
Starete pensando che figurati se capita. Certo che capita, molto spesso.
Ecco, non dite mai le vostre password a nessuno, in nessun caso, neanche al supporto dei vari servizi, neanche all’IT dell’azienda dove lavorate.
Se hanno bisogno la resettano.
Per via dell’hash, non la possono vedere, questo è sicuro.
Se la possono vedere il problema è molto più grande.
Non scrivetele su port-it attaccate a monitor e PC, come non scrivete il PIN del bancomat sul bancomat.
Gli altri modi sono più complessi, perché è necessario accedere in modo fraudolento ai sistemi e portare via i DB con gli hash.
Esistono al mondo degli enormi DB con le corrispondenze di hash e password, anche in base al tipo di codifica che è stata usata.
Se la password è semplice o troppo corta, con le nuove GPU è facile craccare un hash, provando delle tabelle di dizionari e tutte le combinazioni di caratteri possibili
Insomma, se rubano un DB con gli hash, si può dire che la password è compromessa.
Come si fa a sapere che una password è compromessa?
Le aziende che sono state violate hanno l’obbligo di legge di comunicarlo in tempi stretti, informano i propri utenti e ne danno comunicazione pubblica.
Ci sono poi servizi come I have been pwned, che rilanciano queste informazioni.
Lo fanno anche i password manager, sono iscritti a questi servizi e vi notificano se le password che avete salvato sono state compromesse.
Un altro modo palese, mi è successo una volta con l’account steam, entrano con la password nel vostro account e vi arriva la notifica di accesso o di richiesta del secondo fattore.
E se vi rubano quella aziendale?
Anche qui, se la dite a qualcuno, così controlli la mia posta quando sono in ferie, la password è compromessa.
Se cadete in un attacco di phishing, ormai ce ne sono di molto sofisticati, è compromessa.
Secondo me, se perdete il portatile e questo non ha bitlocker, visto che è salvata nel SAM del sistema e tutti sanno con che hash è codificata, si può considerare compromessa.
Se hanno attaccato la vostra azienda, è anche compromessa.
Il problema, potrebbe essere che non tutte le aziende sono così smart da sapere di essere state attaccate, ma con le nuove leggi ci sono controlli obbligatori un po’ più pervasivi.
Cosa succede se ve la rubano?
Possono accedere alla vostra mail dall’esterno, ma con i nuovi sistemi arriva una notifica di accesso, mi è successo dove lavoravo prima, diciamo che lo si scopre subito.
Possono accedere alla vostra VPN, ma in un sistema ben fatto i certificati sono solo sui PC aziendali e la VPN ha anche un secondo fattore di autenticazione, non dovrebbe essere un rischio facilmente sfruttabile.
Potrebbero usarla per accedere alle risorse aziendali usando il vostro PC rubato, ma se la cambiate appena rubato, siete a posto.
Diciamo che ormai, qualunque sia la password, se esce, si sa. Se la dite in giro e non la cambiate siete dei fessi.
Perché si dice che non serve cambiare le password regolarmente e, anzi, è controproducente e non aumenta la sicurezza?
Abbiamo tutti decine e decine di password.
Mettersi lì ogni 90 giorni a cambiarle tutte è un lavoro immane.
Per questo si tende a cambiarle usando una radice fissa e una parte variabile, tipo Soleggiato77, poi Soleggiato78 e così via.
Un attaccante che scopre una password del genere ci mette davvero poco a provare le numerazioni successive. Il cambio diventa inutile.
Cambiare le password con una random di 25 caratteri tutte le volte è un lavoro davvero improbo.
Per questo motivo, le direttive dicono, in modo molto semplice, di scegliere password robuste per ogni servizio, tutte diverse e di cambiare quelle per le quali si sa che sono state probabilmente violate.
Ma attenzione, nessuna legge impone di non cambiarle. Se le volete cambiare, potete farlo, nessuno ve lo vieta.
In Italia, i protocolli dell’AGID, Agenda digitale, invece obbligano il cambio. Lo sappiamo tutti perché scadono le password dello SPID e della CIE, con tedio di molta gente.
Insomma, se il NIST dice che non è necessario un cambio regolare e invece ve lo dice il vostro vicino di scrivania che ha studiato tutt’altro che cybersecurity, io tenderei a fidarmi del NIST.

Questo podcast vive perché io lo produco, lo registro e lo pubblico settimana dopo settimana o quasi. Ma continua ad andare avanti perché la soddisfazione di vedere le notifiche delle donazioni mi spinge a fare sempre nuove puntate, come ringraziamento e impegno nei vostri confronti. Se esce ogni settimana è grazie a voi.
E se donate, compilate il form, vi spedisco anche i gadget, così siamo tutti contenti.
Potete farlo con Satispay, SumUp o Paypal.
Potete partecipare anche usando i link sponsorizzati di Amazon o acquistare la connettività o uno degli altri servizi di Ehiweb, che sponsorizzo con molto piacere da tempo, un gestore di connettività come loro non lo trovate in giro.
Oltre alla connettività per casa FTTH o FTTC, hanno le SIM, posano fibra dedicata per le aziende, fanno servizio VoIP, hanno un supporto spaziale e tutti i loro dipendenti sono assunti a tempo indeterminato.
Provateli, non tornerete più indietro.
E se avete bisogno di un servizio di Hosting, andate da ThridEye, che ospita da anni il sito del podcast, ho fatto la mia scelta e anche qui il livello è altissimo, i contatti sono sul sito.

L’estate si avvicina e iniziano a spuntare le persone su motoveicoli e ciclomotori. La probabilità di vedere un incidente, di conseguenza aumenta. Non porto sfiga, sono i numeri.
Ma questa cosa vale per qualunque incidente traumatico al quale assistente e per il quale vi sentite nelle condizioni di intervenire.
In moto, in auto, una persona che cade da una scala e così via.
Prima regola: non rischiate di farvi male
Seconda regola: non peggiorate la situazione
Terza regola: non pensate che qualcun altro stia chiamando i soccorsi, fate il 112 o il 118, a seconda della regione dove siete.
Torniamo alla seconda regola.
I feriti, in caso di trauma, non vanno mai, mai, mai mossi.
Ripeto, mai.
Anche se stanno bene, anche se parlano, anche se vorrebbero muoversi e inveire contro la controparte.
No.
Con calma, dite loro che verranno mossi solo dai soccorsi, ne va della loro salute e del loro futuro.
Li convincete a stare fermi, in qualunque posizione siano, se vi fanno avvicinare vi avvicinate e tenete loro la testa ferma, in qualunque posizione sia.
Non date da bere, non date da mangiare.
Tenete la testa ferma e state lì con loro, parlate con loro e aspettate i soccorsi.
Non togliete il casco ai motociclisti, non fateglielo togliere.
Se c’è altra gente fate fare loro in modo che eventuali altri veicoli non sopraggiungano.
Se siete al telefono con la centrale dite loro cosa state facendo e seguite le loro direttive.
Muovere un ferito dopo un trauma, anche se può sembrare che stia bene, potrebbe provocare lesioni alla colonna e lei/lui potrebbe perdere l’uso di gambe, braccia o peggio.
Poi magari non succede, ma meglio evitare.
Il tutto non vale ovviamente, se c’è rischio di esplosione o incendio.
In questo caso i feriti vanno estratti in fretta, ma sempre con la regola, terribile, lo so, solo se non mettete a rischio la vostra incolumità.
Perché meglio un ferito che due feriti.
Non è un tip tecnologico, ma è un tip importante, tutte le volte che vedo un incidente, vedo il ferito che cammina e che beve un bicchiere d’acqua offerto dai passanti. Non si fa.
Una volta sono arrivato in ambulanza, macchina distrutta, non trovavamo il conducente ed era al bar a prendere il caffè.
Anche voi, se siete coinvolti, non vi muovete e non fatevi muovere, se non vi tirano fuori le persone dei soccorsi che sanno come si fa, ovviamente se vedete il fuoco, scappate, se potete.

Questa puntata di Pillole di Bit è giunta al termine, vi ricordo che se ne può discutere nel gruppo telegram e che tutti i link e i riferimenti li trovate sull’app di ascolto podcast o sul sito, non serve prendere appunti.
Io sono Francesco e vi do appuntamento a lunedì prossimo per una nuova puntata del podcast che, se siete iscritti al feed o con una qualunque app di ascolto vi arriva automagicamente.
Se volete partecipare alla realizzazione della puntata speciale di Pillole di Bit Stories, andate su pilloledib.it/sostienimi e fate la vostra parte, se a fine mese il cerchio delle donazioni di riempie, realizzerò la puntata speciale.

Grazie per avermi ascoltato

Ciao!

Il sito è gentilmente hostato da ThirdEye (scrivete a domini AT thirdeye.it), un ottimo servizio che vi consiglio caldamente e il podcast è montato con gioia con PODucer, un software per Mac di Alex Raccuglia

#358 – Scheduling della CPU

Pillole di Bit
Pillole di Bit
#358 - Scheduling della CPU
Loading
/

In un calcolatore, la CPU è una e i processi che cercano di avere accesso per fare cose sono moltissimi. Cl va qualcuno che decida chi ha accesso, quando e come vada gestita questa coda. Il sistema operativo gestisce la coda della CPU per rendere il sistema efficiente e reattivo

Per leggere lo script fai click su questo testo

Nella vita di tutti i giorni usiamo, anche senza rendercene conto, due cose, in modo praticamente continuativo: dei processori e dei sistemi operativi che vengono fatti funzionare dai processori. I computer sono un esempio, lo sono gli smartphone o gli smartwatch, ormai lo sono le automobili, soprattutto quelle dotate dei sistemi di intrattenimento più avanzati.
Il sistema operativo, tra le tantissime cose che fa, si occupa di definire quando un processo viene assegnato al processore e quando gli viene tolto, con quali regole e quali modalità.
La cosa non è affatto semplice.

Questa puntata è stata realizzata grazie alle indispensabili donazioni di generosi ascoltatori
Gli abbonati
Giorgio
Ivan

Per sapere come far parte di questo elenco vi rimando al capitolo un po’ più in là nella puntata

Prima di iniziare, vi ricordo che potete contattarmi in mille modi, su Bluesky sono francesco.iltucci.com, su Mastodon sono cesco_78 su mastodon.social o pillole dibit su hackyderm.io o via mail a [email protected], trovate tutti i link comodi comodi sull’app dalla quale state ascoltando la puntata o sul sito, rispondo sempre. Il metodo migliore però è il gruppo telegram attivo durante tutta la settimana, dove si parla delle puntate e di tecnologia in generale, siamo davvero tanti, lo trovate a pilloledib.it/telegram

Prima di iniziare a partire per vedere come funziona un sistema operativo, è necessario sfatare un mito.
Noi siamo abituati, più o meno da sempre, direi da quando c’è Windows, a fare più cose contemporaneamente sul computer.
Scriviamo un testo mentre guardiamo un video, magari la stampante sta elaborando un documento e il compilatore sta lavorando in modo pesante per compilare il codice su cui abbiamo lavorato fino a 10 minuti fa.
Tutto insieme, tutto in contemporanea.
Ebbene, il processore, come l’uomo medio, la donna no, lei ha i superpoteri, può fare una cosa sola per volta.
Sarebbe da dire una cosa per core, ma noi oggi immaginiamo che il nostro computer abbia un solo core, semplifichiamo un po’.
Vi assicuro che in ogni istante di vita di un calcolatore, il suo processore sta facendo una sola cosa per volta, anche se a noi pare che ne stia facendo mille.
Il sistema operativo è addetto a definire quali sono i processi che devono essere assegnati alla CPU, quando, per quanto tempo, quando devono essere rimossi.
Immaginiamo che il processore sia uno sportello delle poste.
Tutti i processi sono le persone che devono andare allo sportello e hanno delle cose da fare.
Il sistema operativo ha il potere di gestire le persone in coda, in questo caso non ci sono i vecchi che si arrabbiano.
Quando un processo ha bisogno dello sportello si mette in coda, lo sportello si libera e il processo inizia a far lavorare lo sportellista.
Per farlo lavorare c’è una fase che si chiama context switch, dove lo sportellista deve essere messo a conoscenza di tutte le informazioni necessarie per il lavoro che deve fare, nella CPU questo equivale a caricare nei registri i dati che sono in memoria o dalle periferiche di input.
A questo punto lo sportellista fa quello che il processo chiede.
Quando ha finito, c’è un nuovo context switch perché si passa al processo successivo in coda.
Se il processo allo sportello ci mette troppo tempo, tutti gli altri processi devono aspettare troppo tempo.
La sensazione per chi sta usando il calcolatore è un rallentamento generale.
Se il processo allo sportello si addormenta mentre lavora con lo sportellista o non trova il bollettino e resta lì e non se ne va, il sistema si blocca.
Ci va un sistema per gestire queste cose.
La gestione dei processi fatta in modo che il processo tiene occupata la CPU per tutto il tempo che le serve, si dice non-preemptive.
La coda gestita in modo che ogni processo viene servito nell’ordine di arrivo si definisce FCFS, First Come, First Served.
Il sistema potrebbe chiedere a tutte le persone in coda, appena arrivano, “tu cosa devi fare e quanto ci metti?”
A questo punto mette come prime persone in coda quelle che hanno operazioni più veloci.
In questo modo il tempo di attesa medio per tutti gli altri si abbassa moltissimo, chi deve fare operazioni lunghe va al fondo e farà aspettare meno persone.
Questo sistema di gestire la coda è chiamato SJF, Shortest Job First.
E se arriva una persona che deve fare un’operazione ancora più corta di quella attualmente allo sportello?
Se l’algoritmo è non preemptive, si mette subito in coda dietro e sarà il prossimo, se l’algoritmo è preemptive, il sistema operativo può decidere di interrompere la persona allo sportello e far passare quella molto veloce appena arrivata, tanto ci mette un attimo.
Poi si può decidere che ogni persona può stare allo sportello per un tempo massimo prefissato, se la tua operazione è lunga, superato quel tempo, raccogli tutti i tuoi documenti, passi al fondo della coda, fai scorrere la coda, quando è di nuovo il tuo turno continui.
Abbiamo risolto il problema di chi ha dei lavori troppo lunghi e di chi si blocca.
Questo modo di lavorare a cerchio si chiama algoritmo Round Robin
Potrebbe succedere che arriva però una persona importante che deve passare prima.
Esistono dei modi per avere delle priorità nella gestione delle code, chi ha priorità più alta passa prima, indipendentemente dalla lunghezza del lavoro che deve fare.
Un dettaglio reale, in un sistema operativo è quasi impossibile sapere in anticipo per quanto tempo ne avrà un processo nel core di un processore, il sistema cercherà di intuire la lunghezza del lavoro di quel processo sulla serie storica.
Dare delle priorità alle persone in coda può generare dei problemi come quell’università dove, al reboot di uno dei loro mainframe si accorsero che c’era un processo a priorità molto bassa che stava aspettando, paziente, in coda, da anni.
Ci sono dei sistemi che aumentano la priorità alle persone in coda man mano che il tempo passa, per garantire loro che prima o poi saranno serviti dal processore.
Esiste anche un altro modo per bloccare un calcolatore, ma con il processore senza processi, a carico zero.
Immaginiamo che alle poste la persona A debba pagare, ma per pagare deve aspettare che la persona B prelevi. La persona B per prelevare deve aspettare che la persona C vada a ritirare la tessera bancomat. La persona C però deve aspettare che la persona A paghi, per liberare lo sportello.
Sono tutti bloccati per un’attività di un’altra persona e nessuno può fare il primo passo.
Questa cosa si chiama stallo e il computer si blocca per starvation, muore di fame.
Vi avevo detto che le cose non sono affatto semplici.
E pensate quando in tutto questo si deve mettere in mezzo che i processi devono gestire input e output, il sistema operativo deve gestire lo swap della memoria e, adesso con le CPU con più core, deve fare in modo che i processi siano pronti da mandare su un certo core, senza che a un certo punto si blocchino perché in attesa di dati di un altro processo che sta lavorando su un altro core.
Come gestiscono le code i tre sistemi operativi più conosciuti?
Windows: Assegna la priorità ai processi e poi usa una modalità preemptive, se arriva un processo con priorità più alta, fa context switch e lo esegue subito.
Linux: funziona come Windows, di base, ma usa un algoritmo di tipo CFS, Completely Fair Scheduler, cerca di mantenere un accesso equo alla CPU per tutti i processi
MacOS: Usa una coda con priorità variabili che sono assegnate a seconda dell’attuale condizione e carico del sistema.
Ovviamente lo switch tra processi assegnati alla CPU avviene ogni pochi millesimi di secondo, per questo noi abbiamo la sensazione che il computer stia facendo molte cose in contemporanea, se sommiamo che adesso le CPU hanno più core, per eseguire davvero più attività in contemporanea, ecco che abbiamo questa sensazione di multitasking reale.

Questo podcast vive perché io lo produco, lo registro e lo pubblico settimana dopo settimana o quasi. Ma continua ad andare avanti perché la soddisfazione di vedere le notifiche delle donazioni mi spinge a fare sempre nuove puntate, come ringraziamento e impegno nei vostri confronti. Se esce ogni settimana è grazie a voi.
E se donate, compilate il form, vi spedisco anche i gadget, così siamo tutti contenti.
Potete farlo con Satispay, SumUp o Paypal.
Potete partecipare anche usando i link sponsorizzati di Amazon o acquistare la connettività o uno degli altri servizi di Ehiweb, che sponsorizzo con molto piacere da tempo, un gestore di connettività come loro non lo trovate in giro.
Oltre alla connettività per casa FTTH o FTTC, hanno le SIM, posano fibra dedicata per le aziende, fanno servizio VoIP, hanno un supporto spaziale e tutti i loro dipendenti sono assunti a tempo indeterminato.
Provateli, non tornerete più indietro.
E se avete bisogno di un servizio di Hosting, andate da ThridEye, che ospita da anni il sito del podcast, ho fatto la mia scelta e anche qui il livello è altissimo, i contatti sono sul sito.

Un problema abbastanza ricorrente è avere un foglio, che sia carta, legno, alluminio o altro materiale e avere dei pezzi rettangolari da tagliare da questo foglio, di misure diverse.
L’obiettivo sarebbe quello di ottimizzare i tagli in modo da avere meno scarto possibile e farci stare più pezzi possibili.
Se abbiamo un foglio di compensato da 100x100cm e vogliamo tagliare 4 quadrati da 50cm, la cosa è facile, a parte il millimetro della lama che viene perso, ma se vogliamo tagliare 6 rettangoli di misure diverse, dobbiamo metterci lì e fare delle prove per vedere se ci stanno tutti e come disporli.
Io ho avuto un problema simile con dei contenitori in un cassetto. Ho un cassetto, dei contenitori da stampare con la stampante 3D e nessuna certezza che ci stiano tutti.
Bene, si apre cutlist optimiser, si mettono tutte le misure ed ecco la lista dei tagli da fare per farci stare tutto, se ci sta.
Sembra magia, ma non lo è
Sembra difficile da spiegare, andate sul sito e scoprirete cosa fa in due minuti, forse meno.
Tenetelo nei vostri preferiti, vi tornerà utile

Questa puntata di Pillole di Bit è giunta al termine, vi ricordo che se ne può discutere nel gruppo telegram e che tutti i link e i riferimenti li trovate sull’app di ascolto podcast o sul sito, non serve prendere appunti.
Io sono Francesco e vi do appuntamento a lunedì prossimo per una nuova puntata del podcast che, se siete iscritti al feed o con una qualunque app di ascolto vi arriva automagicamente.
Se volete partecipare alla realizzazione della puntata speciale di Pillole di Bit Stories, andate su pilloledib.it/sostienimi e fate la vostra parte, se a fine mese il cerchio delle donazioni di riempie, realizzerò la puntata speciale.

Grazie per avermi ascoltato

Ciao!

Il sito è gentilmente hostato da ThirdEye (scrivete a domini AT thirdeye.it), un ottimo servizio che vi consiglio caldamente e il podcast è montato con gioia con PODucer, un software per Mac di Alex Raccuglia