Migrazione da Bitbucket a Codeberg

Negli ultimi mesi abbiamo migrato i repository precedentemente ospitati su Bitbucket verso Codeberg.

La scelta non è stata dettata da limiti tecnici, ma da considerazioni più ampie legate a modello, trasparenza e controllo dei dati.

Le principali motivazioni della migrazione sono:

• privacy e trasparenza. Codeberg è una piattaforma gestita da una organizzazione no-profit europea, basata su software open source come Gitea. Questo garantisce un modello più leggibile e verificabile rispetto a soluzioni proprietarie centralizzate;
• allineamento con i nostri valori. Preferiamo strumenti con un modello orientato agli utenti e alla sostenibilità del servizio, piuttosto che alla sola massimizzazione commerciale; inoltre cerchiamo di ridurre le dipendenze dal fornitore ed i vincoli tecnologici;
• sovranità digitale. La possibilità di utilizzare un'infrastruttura europea, sotto giurisdizione europea, è un elemento rilevante per la gestione dei dati.

Codeberg offre un ambiente più essenziale rispetto a Bitbucket. Tuttavia, per il nostro contesto, questi aspetti non rappresentano un limite significativo. 

Migrazione tecnica

Dal punto di vista operativo, la migrazione è stata semplice:

bash
git clone --mirror <bitbucket-repo>
cd <repo>.git
git push --mirror <codeberg-repo>

Le attività accessorie hanno riguardato principalmente: la ricreazione delle issue (quando necessario), l'adattamento delle pipeline CI/CD, l'aggiornamento della documentazione.

Presenza su GitHub

Per alcune tipologie di progetto, in particolare quelle che richiedono maggiore visibilità e networking nella comunità internazionale, manteniamo una presenza su GitHub. In questi casi, la scelta della piattaforma è guidata da esigenze di diffusione e collaborazione più ampia.

Documentazione Facile

La documentazione relativa al nostro software Facile è stata spostata sul sito aziendale ed è consultabile all'indirizzo:  https://eosdev.it/wiki/facile/.

Usare una porta locale per una stampante condivisa

Succede che Windows "veda" una stampante condivisa in rete, ma fallisca quando si prova ad aggiungerla.

Una soluzione pratica è impostarla come stampante locale usando una porta locale che punta alla condivisione, ad esempio:

\\192.168.1.10\NomeStampante

In questo modo il PC usa il driver installato localmente e si limita a inviare i lavori alla stampante condivisa, evitando parte dei problemi legati a driver remoti, permessi e meccanismi automatici di installazione.

È un modo più diretto e, spesso, più stabile per usare una stampante condivisa, soprattutto in piccole reti senza dominio.

Unica attenzione: meglio usare un IP fisso o una prenotazione DHCP, altrimenti la porta smetterà di funzionare se l'indirizzo del PC cambia.

Italian C++ Meetup con Bjarne Stroustrup - Oltre il codice, filosofia e retroscena del C++ secondo Stroustrup

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.

Ricordo che è possibile visionare alla fonte i contenuti su Youtube. Inoltre sul sito ufficiale dell'autore è disponibile un documento tecnico (Concept-based Generic Programming in C++) che approfondisce i concetti introdotti nella conferenza seguendone abbastanza da vicino la "linea narrativa".

---

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.

Il terminale in oggetto era il Blit (di cui parte della documentazione tecnica è tuttora disponibile).

 

L'episodio viene raccontato anche da Rob Pike.

---

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.

Italian C++ Meetup con Bjarne Stroustrup

I Dipartimenti di Ingegneria dell'Informazione dell'Università di Pisa e dell'Università di Firenze, insieme all'Italian C++ Community hanno organizzato un fantastico incontro con il professor Bjarne Stroustrup, il creatore del linguaggio C++.

L'intero evento è stato coinvolgente: interessante l'approfondimento tecnico sul Concept-based Generic Programming e non meno stimolante la seconda parte, in cui i partecipanti hanno potuto porre domande in libertà.

Il video completo dell'evento è disponibile su YouTube.

Naturalmente, il tema della programmazione assistita dall'IA è stato oggetto di diverse domande. Credo di poter riassumere abbastanza fedelmente il punto di vista di Bjarne Stroustrup in alcuni punti.

Nelle applicazioni che richiedono alta affidabilità, alte prestazioni ed un alto grado di manutenibilità, è necessaria molta prudenza. Gli LLM possono certamente aiutare e non c'è motivo di dubitare di chi dice di trarne beneficio; tuttavia, gli attuali tassi di errore fanno sì che non ci si possa affidare troppo al codice generato. Questo può essere prodotto molto rapidamente, ma deve, comunque, essere revisionato con grande attenzione. Le persone, in generale, non sono particolarmente brave a revisionare codice con il livello di cura necessario: anche per questo i sistemi di tipi, uno degli argomenti della prima parte della conferenza, restano fondamentali.

C'è poi un aspetto organizzativo non secondario: gli sviluppatori esperti potrebbero non voler passare il proprio tempo a revisionare grandi quantità di codice generato. Alcuni preferirebbero persino andare in pensione piuttosto che essere spostati da un ruolo di progettazione ad uno prevalentemente di revisione.

Il messaggio generale non è un rifiuto dell'IA, ma un invito alla cautela. Usare strumenti come Copilot (ed ancora di più strumenti più generali come Claude) richiede una notevole esperienza. In altri ambiti l'IA può essere più appropriata, ma il punto centrale è distinguere il contesto: non tutto il software ha lo stesso livello di rischio e non tutte le conseguenze di un errore sono uguali.

---

Un altro aspetto importante riguarda l'impatto dell'IA sull'apprendimento e sulla capacità di ragionare criticamente. Secondo Stroustrup esistono già studi che indicano come l'uso dell'IA per produrre rapidamente risposte od elaborati possa ridurre l'apprendimento effettivo: si ricorda meno, si comprende meno, perché imparare richiede sforzo, tempo ed anche una certa fatica.

Ha poi citato un rischio ulteriore, ancora non sufficientemente dimostrato ma plausibile: gli studenti più preparati potrebbero riuscire a usare bene l'IA, mentre quelli più deboli potrebbero usarla come una stampella. In questo caso l'IA finirebbe non per ridurre, ma per ampliare le differenze tra le persone.

---

Sul codice generato dall'IA, Stroustrup distingue ancora una volta tra domini diversi. L'IA può produrre buon codice per problemi già risolti molte volte ed affrontati in modo convenzionale. Il problema nasce invece nei settori di cui si occupa più spesso: software critico, spesso basato su conoscenze specialistiche, non sempre presenti nei dati di addestramento ed in cui un errore può causare gravi danni.

Inoltre, quando si cerca di promuovere modi nuovi e migliori di programmare, l'IA tende a riprodurre ciò che è statisticamente più presente nel materiale di addestramento: il "buon vecchio modo", per esempio array C, puntatori... tecniche tradizionali invece delle soluzioni più moderne e sicure. Anche qui, il suo punto non è che l'IA sia inutile, ma che nel dominio che gli interessa di più ci siano fondate ragioni di preoccupazione. Come ha sintetizzato lui stesso: l'IA è artificiale, non intelligente.

---

Una domanda particolarmente interessante ha riguardato il futuro dei linguaggi di programmazione: se il codice fosse sempre più letto dagli esseri umani ma scritto dall'IA, la chiarezza diventerebbe più importante dell'espressività? L'IA potrebbe scrivere direttamente in una rappresentazione intermedia, più vicina alla macchina?

Stroustrup ha contestato anzitutto la premessa: non è convinto che la maggior parte del codice sarà scritta dall'IA; nondimeno ha affermato come l'espressione diretta delle idee sia utile sia per gli esseri umani sia per l'IA. Non vede quindi, in linea di principio, alcun problema nel fatto che un'IA possa generare direttamente una rappresentazione intermedia.

Il punto che, però, non si può saltare, è il controllo dei tipi. Per Stroustrup i tipi sono assolutamente essenziali. L'idea di affidarsi a rappresentazioni ambigue od a sistemi di tipi troppo semplificati è, secondo lui, sbagliata per affidabilità, manutenibilità e prestazioni.

---

In chiusura, Stroustrup ha ribadito ciò che considera ancora centrale in C++: la rappresentazione diretta delle idee nel codice, in una forma che consenta di fare cose nuove e di farle in modo efficiente. Il punto non è solo la performance, ma l'equilibrio tra affidabilità, manutenibilità, prestazioni ed espressività.

In futuri post riporteremo ulteriori domande e risposte che hanno toccato altri argomenti interessanti e curiosi.

Parlare per capirsi o per impressionare?

Spesso mi ritrovo ad usare inutili termini od oscuri acronimi inglesi. Immancabilmente, poi, mi sento in colpa.

Ci sono volte in cui è impossibile farne a meno (davvero?), tuttavia, in genere, il problema risiede in:

• una mescolanza di pigrizia e prolungata esposizione ad ambienti popolati da tecnici informatici, brillanti project manager (volutamente in inglese) e consulenti di ogni sorta (il mondo è tanto bello);
• desiderio di circondarsi di un'aura di competenze o modernità.

Sì, oggi siamo polemici per cui ecco una lista di parole da sostituire con l'equivalente italiano.

Tecnici

Bug → errore, difetto. Purtroppo ci cado sempre.

Crash → blocco, arresto. 

Custom (ed assai peggio customizzato) → personalizzato, su misura.

File → vedi lo specifico articolo. 

Log → registro. 

Release → versione.

Repository→ archivio. Anche se repo fa tanto sviluppatore professionista.

Storage → memoria (o memoria di massa), archiviazione.

Ticket→ segnalazione o richiesta di assistenza. Purtroppo nei momenti di crisi, quelli nei quali siamo più fragili ed esposti, ci ritroviamo ad utilizzare CRM con case/ticket/issue da segnalare/aprire finendo così profondamente condizionati dal termine inglese.

Workflow → flusso di lavoro. È più frequente costruire una frase per poter utilizzare questo termine piuttosto che averne effettivamente bisogno!

Consulenti, manager (lato sensu) e project manager

Best practice → buone pratiche, procedure collaudate, metodologie (metodologie!) collaudate.

Brainstorming → confronto di idee.

Budget → stanziamento o disponibilità economica. È un'equivalenza completa, perciò utilizzare questo termine è peccato ancor più grave.

Call → non offenderò l'intelligenza del lettore proponendo alternative.

Deadline → una scadenza senza fatale (dead) e senza via di uscita?

Follow-up → seguito, riscontro.

Meeting → la cara (si fa per dire), vecchia (ed inutile) riunione.

Performance → prestazioni. 

Update → aggiornamento.

Value proposition → vedi l'articolo dedicato.

Tutti

Content creator → proprio perché ormai tutti siamo creatori di contenuti, è del tutto inutile volersi dare un tono usando la formula inglese.

Fake news → notizie false. No, ormai anche i bambini delle elementari dicono fake news, quindi non sembrerete più intelligenti usandolo anche voi.

Feedback → questa è una parola interessante perché, sebbene possa esser tradotta fedelmente, la scelta migliore dipende dal contesto. Quindi commento, riscontro, opinione, valutazione, reazione; in ambito tecnico retroazione o risposta.

Follower → certo seguace ricorda una setta, ma cosa ci impedisce di usare iscritto?

Hashtag → quando ci si riferisce al carattere (`#`) possiamo chiamarlo filetto (anche se ci prenderanno in giro), più in generale etichetta va benissimo (purtroppo non ha mai attecchito).

Like → mi piace.

Rovesciamento del punto di vista

Non sono da trascurare neanche quelle parole che, pur essendo italiane, sono uscite dal limbo per la loro assonanza con l'equivalente inglese "di moda".

Si tratta di parole abusate ed irritanti, tutte caratterizzate da "inflazione semantica". Utilizzarle ci riduce al livello di un puffo: "Grande Puffo vorrei puffare il puffo che mi puffa quando puffo..." solo con 'assertività', 'resilienza' (o simili) al posto di `puff*`! 

Assertività → devo ancora imbattermi in un corso di formazione nel quale non se ne faccia uso. Parole come fermezza, gentilezza, capacità di farsi valere, chiarezza sono state soppiantate perché troppo "vecchie".

Iconico → il marketing, moderno demonio, vorrebbe conferire un'aura di sacralità (vedi icona) a cose e persone effimere definendole iconiche. Le scarpe, una serie TV,  una padella di penne al salmone... non sono iconiche; possono, tuttavia, essere emblematiche, simboliche, rappresentative, fantasmagoriche, leggendarie... Correttamente, invece, parliamo di "segno iconico" riferendoci a qualcosa che mantiene una relazione di somiglianza con l'oggetto significato (come nei casi di una mappa od un'icona del desktop).  

Resilienza → viene dal latino ed ha sempre trovato posto in ambito fisico/tecnico e psicologico/sociale, tuttavia il continuo uso, esteso al linguaggio comune, la rende abusata ed insopportabile. Guai a dire forza d'animo, adattabilità, tenacia, equilibrio... no solo resilienza; flessibilità, capacità di adattamento, tolleranza ai guasti, robustezza ed affidabilità... termini aboliti per suonare più tecnici e positivi (davvero?).

 

---

La competenza non si misura dalla quantità di parole solenni che riusciamo ad infilare in una frase, ma da quante ne possiamo togliere senza perdere precisione.

Linux ed il codice generato dai LLM

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`).

CSF - Invito a visitare il nostro spazio espositivo