In caso di file con nomi non validi presenti in cartelle protette (come `/usr/local/bin`), l'interfaccia grafica (GUI) spesso fallisce.
La soluzione più rapida ed efficace consiste nell'utilizzare il terminale per identificare ed eliminare il file tramite il suo inode (l'ID di sistema), ignorando il nome corrotto.
Procedura con privilegi di amministratore:
identificare l'inode:
cd /usr/local/bin ls -li
(annotare il numero identificativo nella prima colonna, ad esempio `1234567`);
rimuovere il file:
sudo find . -inum 1234567 -delete
Il file viene rimosso in modo sicuro senza interferire con gli altri elementi della directory.
In questa seconda parte (qui la prima parte) riporto alcune domande e risposte che toccano le radici dell'informatica, il design, la sicurezza e l'educazione.
Il confronto tra concepts ed interfacce virtuali porta Stroustrup a una preferenza chiara: vorrebbe vedere un approccio concepts first.
L'idea è partire dai requisiti che un tipo deve soddisfare, cioè dal comportamento e dalle operazioni richieste, e solo dopo definire o scegliere tipi che rispettino quei vincoli. Per l'utilizzatore non dovrebbe essere importante sapere se qualcosa sia una classe, una gerarchia con funzioni virtuali od altro: se soddisfa i vincoli espressi dal concept, allora è sufficiente.
Ha però precisato che non si tratta di un processo puramente astratto ed unidirezionale. Per costruire un buon concept spesso serve partire da uno o più tipi concreti, così da capire quali requisiti siano davvero necessari.
Le interfacce virtuali non scompaiono: restano utili quando servono vincoli ulteriori, per esempio legati ad ABI stabili o a forme specifiche di polimorfismo a tempo di esecuzione. Dove possibile, Stroustrup sembra preferire che il progetto parta dai concetti e dai vincoli semantici, non dalla meccanica dell'implementazione.
Sul rapporto tra concepts, interfacce e meccanismi di adesione alle astrazioni in C++, merita anche Opting into Concepts di Barry Revzin, che confronta ereditarietà, specializzazione di template, CRTP e funzioni libere/membro dal punto di vista di esplicità, intrusività e controllo degli errori.
Parlando dei Bell Labs, Stroustrup ha descritto quell'ambiente come un luogo straordinario, unico al mondo e ha osservato che oggi non esiste più nulla di simile. Il centro di ricerca in informatica contava, ad un dato momento, circa sessanta persone, tra cui quattro membri della National Academy of Engineering: una concentrazione impressionante di talento, competenza e conoscenza.
Uno degli aspetti che ricorda con più piacere era l'apertura dell'ambiente: si poteva entrare nell'ufficio di qualcuno e discutere direttamente con un esperto mondiale del tema che interessava in quel momento. Molto del suo lavoro, racconta, è stato fatto sulle lavagne di altre persone.
Ha ricordato, per esempio, di avere avuto come vicino Alfred Aho, uno degli autori del Dragon Book sui compilatori: se aveva bisogno di sapere qualcosa sui compilatori, poteva semplicemente parlare con uno dei massimi esperti al mondo. Anche Dennis Ritchie era, per un certo periodo, poco distante da lui lungo il corridoio.
Stroustrup ha poi espresso rammarico per la fine dei Bell Labs così come li aveva conosciuti: secondo lui fu una grande perdita di talento e competenze, qualcosa che non sarebbe dovuto accadere.
Tra gli aneddoti, ha ricordato un episodio con Rob Pike e Ken Thompson, che prepararono una dimostrazione per Arno Penzias, allora alla guida della ricerca dei Bell Labs e premio Nobel. Lo accompagnarono attraverso i corridoi per mostrargli grafica, giochi e tecnologie sperimentali. Una volta arrivati davanti al terminale finale, Penzias si aspettava di vedere qualche complesso calcolo od una simulazione scientifica. Invece, vide un'immagine di se stesso ripreso di spalle mentre entrava nella stanza.
L'episodio serve a Stroustrup per descrivere il clima del posto: un ambiente molto collegiale, in cui si poteva anche scherzare con persone di altissimo livello, purché con rispetto. Era un luogo che aiutava le persone a crescere. Arrivando lì, racconta, bastava leggere i nomi sulle porte per pensare di dover fare qualcosa di davvero notevole per meritare di appartenere a quel gruppo. La sindrome dell'impostore, conclude, non era affatto rara.
NdA: in un mondo dominato da terminali solo testo, la capacità di visualizzare flussi video digitalizzati / bitmap complesse in tempo reale rendeva tangibile il potere della nuova tecnologia grafica in
modo personale ed immediato.
Di fronte all'ipotesi di riprogettare il C++ "con il senno di poi", Stroustrup ha richiamato il classico "problema della macchina del tempo". È facile, oggi, immaginare consigli da dare al passato; molto più difficile è capire se, all'epoca, quei consigli sarebbero stati davvero utilizzabili.
Il punto centrale è che molte scelte di C e C++ furono condizionate dai limiti tecnici del tempo. Stroustrup ricorda di aver iniziato a lavorare su una macchina con 128 KB di memoria dati; Dennis Ritchie, per il primo C, aveva a disposizione ancora meno: circa 48 KB di memoria totale. Con vincoli di questo tipo, anche la complessità del parser, dell'analisi statica e delle regole del linguaggio doveva essere contenuta.
Una delle cose che Stroustrup avrebbe voluto migliorare è la sintassi. La famosa sintassi inside out di C e C++ (vedi, per esempio, The Clockwise/Spiral Rule) deriva anche dal fatto che Ritchie non voleva inserire due analizzatori sintattici separati nella memoria disponibile: per questo espressioni e dichiarazioni finirono per condividere parte della grammatica. È una scelta che da allora ha reso possibile scrivere dichiarazioni molto complesse, ma anche difficili da leggere; Stroustrup osserva, con una certa ironia, che non bisognerebbe essere troppo orgogliosi di saper scrivere una funzione che restituisce un puntatore a funzione senza usare un `typedef`.
C'è però una cosa che, secondo lui, avrebbe potuto capire e implementare anche allora... se qualcuno gliel'avesse spiegata nel modo giusto: i `concepts`.
Secondo Stroustrup, i `template` senza vincoli rendono il linguaggio più complicato, più difficile da usare e persino più difficile da implementare, perché i controlli devono essere distribuiti "ovunque". Se qualcuno fosse tornato indietro nel tempo, nel periodo in cui lavorava sui template, e gli avesse spiegato chiaramente l'idea di funzioni valutate a tempo di compilazione che prendono tipi come argomenti, probabilmente sarebbe stato difficile convincerlo subito, ma aveva già le conoscenze necessarie per comprenderla.
In questo senso, i concept sono una delle poche cose per cui una macchina del tempo avrebbe davvero aiutato: introdurli prima avrebbe semplificato l'implementazione dei template e si sarebbe adattato meglio al suo modo di pensare.
Sul tema delle critiche di Linus Torvalds al C++, Stroustrup ha risposto in modo piuttosto netto. Anzitutto ha ricordato, con una punta di ironia, che oggi Torvalds scrive anche codice C++.
Poi ha contestualizzato le critiche storiche: quando Torvalds espresse le sue posizioni più dure, nel 1996, anche Stroustrup non riteneva il compilatore C++ di GCC sufficientemente maturo. Se la critica fosse stata "quel compilatore non è all'altezza per scrivere un sistema operativo", Stroustrup avrebbe potuto concordare.
Il problema è che la critica andava oltre lo strumento specifico e diventava un giudizio sul linguaggio e sulle persone che lo usavano. Su questo Stroustrup non è d'accordo: C++ non era il linguaggio più facile né il più economico da adottare e non aveva un grande apparato di marketing a sostenerlo. Eppure è arrivato ad avere milioni di utenti. Non è plausibile, osserva, pensare che fossero tutti stupidi.
In sintesi, Stroustrup distingue tra una critica tecnica, che può essere fondata, per esempio sulla qualità degli strumenti disponibili in un certo periodo ed una critica generalizzata al linguaggio ed alla comunità, che considera semplicemente sbagliata.
Il tema della sicurezza ha portato anche all'invito del governo statunitense, nel 2024, ad abbandonare il C++ per ragioni di sicurezza. Stroustrup ha osservato che quella posizione si è già fatta più specifica e meno semplicistica. Non si tratterebbe più di una condanna generica di "C/C++", ma di un'analisi più dettagliata delle pratiche che causano problemi.
Secondo Stroustrup, molte delle operazioni pericolose attribuite a C++ non sono necessarie nel C++ moderno: se si scrive codice "in stile C", si ereditano anche molti dei problemi tipici del C, come buffer overflow e violazioni di memoria. Inoltre, osserva che spesso i dati citati sulla sicurezza mescolano C e C++, mentre analisi più attente mostrerebbero che una parte molto rilevante dei problemi riguarda C o C++ scritto in stile C.
Il punto, quindi, non è negare l'esistenza dei problemi, ma distinguerne le cause. Per Stroustrup, la risposta non dovrebbe essere abbandonare C++, ma eliminare progressivamente le pratiche insicure: profili più restrittivi del linguaggio, librerie hardened, controlli sugli accessi fuori range e strumenti migliori possono ridurre molto il rischio.
Ha citato anche il fatto che oggi esistono librerie hardened disponibili da realtà come Google, Apple e Microsoft, che possono introdurre controlli aggiuntivi, per esempio sui limiti degli array o dei container. Qui emerge un altro problema: molte di queste soluzioni, quando rilevano una violazione, terminano il programma.
Per alcune applicazioni questo è accettabile: in un grande data center, se un processo termina, il carico può essere spostato altrove. Nei sistemi embedded, real time o safety critical la situazione è diversa. Se un singolo processore controlla qualcosa di vitale, non si può semplicemente terminare il programma al primo errore.
Stroustrup cita l'esempio di un controller dell'ossigeno in un sistema subacqueo: se c'è una violazione di un'asserzione, terminare il software potrebbe essere l'errore fatale. In questi contesti servono strategie di gestione dell'errore più sofisticate: contenere il problema, portare il sistema in uno stato sicuro, ripristinare o reinizializzare dove possibile.
Il tema centrale, ancora una volta, è che non tutti i domini sono uguali. La sicurezza del software non si ottiene solo cambiando linguaggio, ma capendo quali errori si vogliono prevenire, quali vincoli ha il sistema e quale comportamento è accettabile quando qualcosa va storto.
Alla domanda se sia preoccupante che molti studenti di informatica inizino con Python e possano non arrivare mai ad usare un linguaggio compilato, Stroustrup ha risposto di sì: secondo lui è un problema reale.
Il rischio è che molti studenti si abituino a pensare che efficienza, manutenibilità, garanzie e comprensione di ciò che accade "sotto" siano problemi di qualcun altro. Python può essere uno strumento utile, ma sotto Python serve comunque qualcuno che costruisca sistemi efficienti. Se si usa Python direttamente, invece di usarlo come interfaccia verso codice più efficiente scritto per esempio in C++, i costi in termini di prestazioni ed energia possono diventare molto elevati.
Stroustrup osserva anche che chi inizia solo con Python spesso incontra difficoltà quando arriva ad algoritmi, strutture dati e programmazione di sistema: nei programmi Python di grandi dimensioni emergono problemi seri di manutenibilità.
Più in generale la questione riguarda l'educazione informatica. Secondo Stroustrup è un errore trattare computer science, informatica applicata ed alfabetizzazione digitale come se fossero la stessa cosa. Chi deve costruire sistemi safety critical od infrastrutture fondamentali ha bisogno di una formazione diversa da chi deve sviluppare piccole applicazioni web. Non dovrebbero avere lo stesso curriculum, gli stessi esercizi, né gli stessi criteri di valutazione.
Per rispondere al problema, Stroustrup propone quindi di distinguere meglio i percorsi formativi. Vorrebbe vedere informatici con una mentalità ingegneristica, formati su linguaggi compilati, sistemi, costruzione di software, manutenibilità, prestazioni, affidabilità e processi per garantirle.
In questo quadro colloca anche il suo lavoro su C++: non come alternativa diretta a Python, ma come linguaggio pensato per ingegneri ben formati che devono costruire software efficiente, affidabile e mantenibile.
La comunità del kernel Linux, con Linus Torvalds in prima linea, ha stabilito una posizione chiara circa l'uso dell'intelligenza artificiale nella scrittura del codice: AI Coding Assistants.
In modo pragmatico, gli strumenti di IA non vengono vietati, sarebbe poco realistico farlo; vengono considerati un aiuto al pari di altri già presenti nel flusso di lavoro. Quello che conterà davvero non è l'origine del codice, ma la sua qualità.
Il punto centrale della decisione è il rifiuto esplicito del cosiddetto AI slop, cioè codice generato automaticamente ed inserito senza una reale comprensione o revisione. In altre parole, non è accettabile copiare ed incollare ciò che produce una macchina senza verificarlo a fondo.
Viene ribadito un principio già fondamentale nello sviluppo del kernel: la responsabilità è sempre e comunque umana. Chi invia una modifica deve conoscerla, capirla e risponderne, indipendentemente dal fatto che sia stata scritta interamente a mano o con l'aiuto dell'IA. Se ci sono errori, problemi o vulnerabilità, è lo sviluppatore a doverne rendere conto.
Per mantenere trasparenza, è stato anche concordato che l'uso dell'intelligenza artificiale debba essere dichiarato esplicitamente nei contributi, attraverso appositi riferimenti (`Assisted-by`).
Usare una tastiera US è spesso la scelta più naturale per programmare.
Tuttavia scrivere testo in italiano (od in altre lingue) diventa rapidamente scomodo. La compose key di Linux risolve il problema in modo sorprendentemente elegante offrendo sequenze logiche di tasti al posto di codici mnemonici arbitrari.
Abbiamo raccolto in un unico documento alcune regole, i pattern ricorrenti, le sequenze più utili e la tabella completa:
Sei seduto al terminale ed hai appena digitato un lungo e complesso comando. Premi Invio.
ERRORE.
La rabbia ti assale.
Situazione familiare? Bene, la vera arte dello smanettone non è digitare correttamente al primo colpo, bensì far sembrare di riuscirci, sfruttando la cronologia di Bash e confondendo, quando opportuno, eventuali spettatori.
Senza pretendere di scrivere una guida definitiva ed implorando il perdono dei veri maghi della tastiera, ecco qualche suggerimento ricavato da (ahimè) qualche anno di esperienza.
Livello base: le freccette
Quanto segue è per i principianti che hanno ancora la dignità di usare una tastiera fisica.
il richiamo (↑): hai appena digitato cd /usr/bin/pippo/pluto ed hai dimenticato /local/ nel mezzo. Non ridigitarlo! Premi 'freccia su'. Il comando riappare (!). Premi ancora per riesumare ulteriori errori imbarazzanti;
il richiamo eccessivo (↓): sei andato troppo indietro ed hai trovato un comando del 1973. Premi 'freccia giù' per tornare alla realtà e non affrontare il tuo passato.
(si, lo so, tutto questo è imbarazzante... ma si deve pur cominciare)
Livello intermedio: l'investigatore di basso rango (Ctrl+R)
Ti ricordi solo una vaga parola chiave del tuo comando.
Premi Ctrl R. Compare un enigmatico (reverse-i-search).
Inizia a digitare, diciamo che vuoi trovare un vecchio comando git. Digiti "gi" e Bash ti mostra la corrispondenza più recente.
Non è quella giusta? Continua a premere Ctrl R.
È come cambiare senza posa il canale TV: scorri velocemente tra la programmazione della tua cronologia finché non trovi il tuo vecchio film preferito. In realtà trovi solo git push --force che non avresti mai dovuto usare.
Individuato quanto cercavi, premi Invio per eseguirlo di nuovo (possibilmente, prima, correggendolo).
Livello pro: sapersi affermare (!)
Se vuoi dimostrare di essere un vero hacker della shell, devi padroneggiare il carattere più prepotente di tutti: il pungolo esclamativo ! (no, questa volta nessun rimando a Wikipedia :-).
Sequenza
Obiettivo
!!
Ripete l'ultimo, comando. Perfetto per una situazione tipo sudo !! quando avevi scordato di non poter far qualcosa senza il permesso.
!n
Richiama il comando numero n nella cronologia (server un history preliminare perché nessun essere umano normale ricorda questi numeri).
!git
Rifai l'ultima cosa che ho fatto con git (utile per "incasinare" un repository già sull'orlo del collasso).
!$
Dammi solo l'ultimo ARGOMENTO usato (scorciatoia: ESC + .). Perfetto se hai appena copiato un file su /usr/local/bin/il-file-con-il-nome-impossibile ed ora vuoi semplicemente farci un ls.
Se invece non vuoi affermarti, ricordati almeno del bonus mobilità: cd - è l'equivalente del tasto "canale precedente" sul telecomando e permette lo swapping selvaggio fra due directory (per i pignoli, bisogna dire che `-` non fa parte dell'espansione della cronologia di Bash; si tratta invece di un argomento specifico del comando `cd` che ripesca il contenuto della variabile ambientale $OLDPWD... e sti c :).
Livello finale: analisi post mortem
fc (fix command) apre l'ultimo comando (od uno specifico) nel tuo editor di testo predefinito (speriamo non sia vi/vim, altrimenti rischi di rimanerci intrappolato per l'eternità senza ricordare l'arcana sequenza per uscire).
A questo punto puoi modificarlo in modo esteso prima di eseguirlo.
Una importante nota a margine: se hai aperto il comando nell'editor e ti rendi conto che la sua eventuale esecuzione scatenerà l'Apocalisse, NON uscire come se nulla fosse!
Vai all'inizio della riga ed aggiungi il sacro sigillo del non-comando (`#`). Ora (stai sereno) puoi salvare ed uscire senza... evocare i Cavalieri.
Rendiamo disponibili, nel nostro repository su GitHub, gli script per utilizzare una versione aggiornata di GCC e/o CLANG su una Slackwarestable (si tratta comunque di POSIX script, quindi ragionevolmente compatibili con altre distribuzioni).
L'installazione, conformemente al Filesystem Hierarchy Standard, avviene nella directory/opt. In genere questa è una buona scelta per i compilatori dal momento che permette:
di evitare interferenze con /usr/bin/gcc e /usr/bin/clang;
di non sovrascrivere librerie già installate con la distribuzione Linux;
di effettuare semplici scelte a livello di utente (export PATH=/opt/gcc-XX.Y.Z/bin:$PATH);
Su alcune configurazioni Linux, eseguire il comando:
> fstrim -v /
può causare un crash del kernel immediato, accompagnato dal messaggio `Killed` e da una traccia nel log (`dmesg`) simile a questa:
RIP: 0010:0x0
Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
Call Trace: raid10_make_request+0xbf1/0xd20 ...
Il problema si verifica anche su altri mount point e non è legato a mancanza di memoria o corruzione del filesystem.
Causa
Il problema è causato da un bug noto nel driver md/raid10 del kernel Linux: quando viene eseguito un comando TRIM (come `fstrim`) su un volume configurato in RAID 10 software, il kernel tenta di accedere ad un puntatore funzione nullo, provocando un kernel panic.
Questa anomalia è stata segnalata anche in altre distribuzioni (es. Ubuntu, bug #2117395) e si verifica su filesystem ext4 montati sopra array RAID 10.
Perché succede
Il supporto TRIM (discard) non è sempre correttamente implementato nel livello RAID 10 software. Il kernel presume l'esistenza di una funzione per gestire l'operazione `REQ_OP_DISCARD`, ma questa non è definita in alcune configurazioni. Il risultato è un accesso a indirizzo nullo (0x0) e il crash del sistema.
Soluzioni consigliate
Non usare, momentaneamente, `fstrim` su RAID 10.
Rimuovere l'opzione `discard` da `/etc/fstab` per evitare TRIM automatici:
Se utilizzi Slackware e hai aggiornato il kernel, c'è un passaggio fondamentale da non dimenticare: eseguire `lilo`. Questo comando aggiorna il bootloader con le informazioni del nuovo kernel. Dimenticarlo significa molto probabilmente ritrovarsi con un sistema che non si avvia più correttamente.
Cosa succede se dimentichi lilo
Slackware, a differenza di altre distribuzioni, non aggiorna automaticamente il bootloader dopo l'installazione di un nuovo kernel. Se dimentichi di eseguire `lilo`, potresti riscontrare:
errori all'avvio, come "kernel not found";
sistema che continua a caricare il vecchio kernel (se ancora presente);
blocco totale all'avvio, con la necessità di intervenire manualmente.
Niente panico: è possibile ripristinare il sistema con pochi passaggi, utilizzando il disco di installazione di Slackware o una live USB.
.jpg)
.png)
Usare una tastiera US è spesso la scelta più naturale per programmare.
