Salta al contenuto

Sistemi che ho rilasciato

Questi sono sistemi in produzione costruiti da Gianluca Mazza come ingegnere indipendente — ogni scheda risponde a quale problema risolve, come è stato progettato e cosa è stato rilasciato, con artefatti verificabili (codice, benchmark DOI, pipeline di eval) invece di affermazioni di marketing.

Ogni progetto qui sotto parte dal problema che risolve; architettura, modello di runtime e compromessi vengono dopo — prove che puoi ispezionare, non un elenco di funzionalità.

# active

OpenFatture

Sistema di fatturazione italiana per workflow FatturaPA/SDI, con assistenza AI local-first.

#Python#Ollama#FatturaPA#CLI
PyPIReleases

Problema

Come emetti fatture conformi FatturaPA/SDI con assistenza AI senza affidare i dati aziendali a un altro servizio SaaS in abbonamento?

Progettazione del sistema

Un sistema di fatturazione local-first con conformità FatturaPA/SDI e assistenza AI controllata.

Risultato

Fatture conformi emesse e inviate senza abbonarsi a un SaaS: i dati restano in locale e ogni effetto esterno passa da revisione manuale.

Architettura

  • modello fattura
  • export SDI
  • canale di pagamento
  • assistente AI in locale

Modello di runtime

  • bozza
  • validazione
  • export
  • invio
  • riconciliazione

Strumenti

  • Python
  • Streamlit
  • LND
  • Ollama
  • OpenAI/Anthropic

Affidabilità

  • controllo local-first
  • validazione di conformità
  • revisione manuale prima degli effetti esterni
bozzavalidazioneexportinvioriconciliazione

Vincoli

Compliance e correttezza contabile hanno priorità maggiore rispetto all’azione autonoma.

Compromessi

L’operatività local-first riduce la comodità, ma migliora il controllo sui dati aziendali sensibili.

Evoluzione

Espandere i controlli di workflow, la riconciliazione e l’assistenza AI verificabile.

# active

orka

Runtime agentico in Rust che riceve lavoro da chat e canali HTTP, assegna priorità e instrada verso workflow LLM vincolati con supporto MCP/A2A.

#Rust#MCP#A2A#RAG#WASM

Problema

Le richieste arrivano da chat, email e strumenti interni, ma senza una coda persistente unica non c’è un percorso affidabile dall’input di canale a un workflow LLM tracciato e revisionabile.

Progettazione del sistema

Un runtime agentico che trasforma input di canale in workflow LLM prioritizzati con adapter MCP/A2A, esecuzione in sandbox e confini runtime espliciti.

Risultato

Una coda unica instrada le richieste multi-canale in workflow LLM vincolati con supporto MCP/A2A.

Architettura

  • ingress dei canali
  • scheduler del runtime
  • livello dei tool
  • adapter MCP/A2A

Modello di runtime

  • ricezione
  • classificazione
  • routing
  • esecuzione
  • checkpoint

Strumenti

  • Rust
  • tokio
  • WASM
  • MCP
  • A2A

Affidabilità

  • confini runtime tipizzati
  • esecuzione con priorità
  • separazione dei protocolli
  • workflow interrompibili
ricezioneclassificazioneroutingesecuzionecheckpoint

Vincoli

Il runtime deve restare orientato ai protocolli ed evitare accoppiamento a una singola interfaccia.

Compromessi

Un runtime di basso livello offre più controllo, ma richiede confini di prodotto più netti.

Evoluzione

Rafforzare osservabilità, policy workspace e semantica di esecuzione durevole.

# active

reasoning-kernel

Implementazione di riferimento in Python di un reasoning kernel che separa il testo non fidato del modello dagli effetti autorizzati usando controllo basato su capability e taint tracking.

#Python#Prompt Injection Defense#Capability Security#Taint Tracking#Agent Security

Problema

Gli agenti LLM agiscono su testo non fidato, quindi un prompt injection può scatenare chiamate a tool ed effetti mai autorizzati dall’utente.

Progettazione del sistema

Un reasoning kernel che separa un planner privilegiato dai dati non fidati in quarantena e subordina ogni effetto a capability esplicite e taint tracking.

Risultato

Un’intera classe di effetti da prompt injection eliminata per costruzione, con decisioni auditabili.

Architettura

  • planner privilegiato
  • dati in quarantena
  • token di capability
  • taint tracking
  • effetti sotto audit

Modello di runtime

  • ricezione
  • pianificazione
  • verifica delle capability
  • esecuzione
  • audit

Strumenti

  • Python
  • sicurezza basata su capability
  • taint tracking

Affidabilità

  • effetti subordinati alle capability
  • i dati non fidati non possono fare escalation
  • decisioni auditabili
ricezionepianificazioneverifica delle capabilityesecuzioneaudit

Vincoli

La sicurezza nasce dalla struttura, non dal comportamento del modello: il planner non deve mai agire direttamente sul contenuto non fidato.

Compromessi

La mediazione esplicita delle capability aggiunge codice di supporto, ma rimuove un’intera classe di effetti da prompt injection.

Evoluzione

Ampliare il catalogo delle capability e integrarlo con runtime di tool reali.

# active

emotional-memory

Livello di memoria per sistemi LLM con codifica dello stato affettivo, package PyPI, DOI Zenodo e benchmark riproducibili rispetto a Mem0, LangMem e Letta.

#Python#LLM Memory#Research#PyPI#DOI
PyPIBenchmarksReleases

Problema

Quando un’azienda aggiunge un assistente AI, come verifichi che ciò che ricorda oggi verrà richiamato correttamente dopo il prossimo aggiornamento di modello o software?

Progettazione del sistema

Un livello di memoria orientato alla ricerca, con codifica dello stato affettivo, package PyPI, DOI Zenodo, artefatti benchmark e confronti con framework di memoria esistenti.

Risultato

Un package pubblicato e benchmark riproducibili offrono evidenze ispezionabili prima di affidarsi a un livello di memoria AI in produzione.

Architettura

  • archivio di memoria
  • codifica affettiva
  • runner dei benchmark
  • matrice dei claim

Modello di runtime

  • acquisizione
  • codifica
  • retrieval
  • valutazione
  • pubblicazione degli artefatti

Strumenti

  • Python
  • PyTorch
  • pydantic
  • pytest
  • Zenodo

Affidabilità

  • run di benchmark riproducibili
  • DOI pubblicato
  • release del package coperta da test
acquisizionecodificaretrievalvalutazionepubblicazione degli artefatti

Vincoli

Il linguaggio pubblico deve restare allineato alle evidenze. Claim scientifici più forti richiedono una validazione esterna più ampia.

Compromessi

Il rigore di ricerca ha priorità rispetto alla compatibilità con molti framework o a una superficie funzionale più ampia.

Evoluzione

Espandere la valutazione umana, i test su confondenti semantici e i benchmark longitudinali di memoria.

# active

agentroom

Chat agent-to-agent con crittografia end-to-end su relay self-hosted, progettata perché il relay non possa leggere il contenuto dei messaggi.

#JavaScript#E2E Encrypted#Double Ratchet#A2A#Self-hosted

Problema

Gli agenti che coordinano tra operatori diversi hanno bisogno di un canale privato in cui il relay non possa leggere i messaggi né impersonare un partecipante.

Progettazione del sistema

Un livello di chat agent-to-agent self-hosted con crittografia end-to-end, relay cieco e sicurezza di sessione tramite Double Ratchet.

Risultato

Coordinamento tra agenti su un canale privato self-hosted: nessun attore centrale può leggere o bloccare i messaggi.

Architettura

  • chiavi di identità
  • sessione Double Ratchet
  • relay cieco
  • archivio dei messaggi

Modello di runtime

  • handshake
  • ratchet
  • cifratura
  • relay
  • decifratura

Strumenti

  • JavaScript
  • Double Ratchet
  • relay self-hosted

Affidabilità

  • il relay non legge il testo in chiaro
  • forward secrecy
  • controllo self-hosted
handshakeratchetcifraturarelaydecifratura

Vincoli

Il relay inoltra solo testo cifrato; identità e confidenzialità non devono mai dipendere dalla fiducia nel server.

Compromessi

Gestire un relay proprio aumenta il lavoro operativo ma rimuove un attore centrale che potrebbe leggere o bloccare i messaggi.

Evoluzione

Ampliare il supporto ai client, le sessioni di gruppo e i flussi di recupero delle chiavi.

# active

msg2agent

Livello di trasporto sicuro per messaggi agentici, con crittografia end-to-end, identità DID, relay di consegna, adapter MCP e interoperabilità A2A.

#Go#E2E Encrypted#DID#A2A#MCP
Releases

Problema

I sistemi agentici richiedono un livello di trasporto per messaggi tra confini diversi senza chiavi condivise, fiducia centrale o accesso del relay al testo in chiaro.

Progettazione del sistema

Un livello di protocollo per messaggi agent-to-agent con identità W3C DID, crittografia end-to-end, relay di consegna, supporto MCP connector e interoperabilità A2A.

Risultato

Un pattern di trasporto sicuro per integrazioni agentiche: il relay può consegnare e accodare messaggi, ma il contenuto resta fuori dal suo trust boundary.

Architettura

  • identità DID
  • busta cifrata dei messaggi
  • relay
  • connector MCP
  • adapter A2A

Modello di runtime

  • scoperta dell’agente
  • cifratura
  • firma
  • relay
  • pull della inbox
  • conferma di ricezione

Strumenti

  • Go
  • X25519
  • Ed25519
  • W3C DID
  • OAuth 2.1 + PKCE
  • MCP

Affidabilità

  • consegna store-and-forward
  • inbox offline
  • quote per tenant
  • relay cieco
scoperta dell’agentecifraturafirmarelaypull della inboxconferma di ricezione

Vincoli

Il relay instrada messaggi ma non deve diventare ancora di fiducia per identità o confidenzialità del contenuto.

Compromessi

La proprietà crittografica aumenta la chiarezza del trust ma aggiunge complessità di connector e gestione delle chiavi.

Evoluzione

Ampliare distribuzione dei connector, billing di produzione e percorsi di interoperabilità.

# active

cast

Lavoro su sender Chromecast nativo per LibreWolf e Firefox, con backend openscreen per media casting e screen mirroring Wayland senza tool desktop di terze parti.

#C++#Chromecast#Firefox#Wayland#OpenScreen
Releases

Problema

Il browser casting su Linux dipende spesso da tool desktop esterni o percorsi incompleti, soprattutto quando entra in gioco lo screen mirroring.

Progettazione del sistema

Un percorso Cast sender nativo per LibreWolf e Firefox basato su openscreen, con attenzione a media casting e screen mirroring Wayland.

Risultato

Uno showcase systems-level per integrazione browser: confini di protocollo, percorsi media nativi e vincoli desktop vengono gestiti sotto il livello dell’interfaccia web.

Architettura

  • entrypoint nel browser
  • sender nativo
  • backend openscreen
  • cattura Wayland

Modello di runtime

  • scoperta del device
  • negoziazione della sessione
  • cattura dei media
  • encoding
  • streaming

Strumenti

  • C++
  • OpenScreen
  • Wayland
  • H.264

Affidabilità

  • confine di protocollo nativo
  • nessun sender desktop di terze parti
  • build con tag di release
scoperta del devicenegoziazione della sessionecattura dei mediaencodingstreaming

Vincoli

Il lavoro è sensibile alla piattaforma: display server, codec, browser e comportamento del receiver Cast influenzano l’implementazione.

Compromessi

Un percorso nativo offre più controllo di un wrapper, ma espone compatibilità e manutenzione a livello più basso.

Evoluzione

Rafforzare compatibilità receiver, affidabilità della cattura e packaging path.

# active

semanticbrowser

Browser semantico in Rust per agenti AI che richiedono accesso strutturato a pagine web, stato della pagina e superfici di interazione invece di sole screenshot fragili.

#Rust#AI Agents#Browser#Semantic Web#Automation
Releases

Problema

Gli agenti che operano sul web richiedono stato pagina strutturato e target di interazione, non solo screenshot fragili o dump DOM grezzi.

Progettazione del sistema

Un browser layer in Rust che espone struttura semantica della pagina e superfici di interazione, così i runtime agentici possono ragionare sulla pagina con confini più chiari.

Risultato

Una prova di browser automation centrata su stato ispezionabile: l’agente vede un’interfaccia strutturata, non uno stream visuale opaco.

Architettura

  • runtime del browser
  • estrattore semantico
  • modello dello stato pagina
  • interfaccia per gli agenti

Modello di runtime

  • caricamento della pagina
  • estrazione dello stato
  • selezione del target
  • azione
  • osservazione del risultato

Strumenti

  • Rust
  • estrazione semantica
  • browser automation

Affidabilità

  • stato pagina strutturato
  • target di interazione espliciti
  • confini rivolti agli agenti
caricamento della paginaestrazione dello statoselezione del targetazioneosservazione del risultato

Vincoli

Il browser layer deve preservare abbastanza semantica pagina per gli agenti senza fingere che pagine web arbitrarie siano deterministiche.

Compromessi

Lo stato semantico è più ispezionabile degli screenshot, ma richiede gestione attenta di pagine dinamiche e gap di accessibilità.

Evoluzione

Collegare il modello pagina a trace di eval e policy più sicure per il controllo browser.

# active

xllama

Chat LLM locale e generazione immagini Stable-Diffusion su Xbox Series S|X in UWP development mode, con ONNX Runtime GenAI e DirectML instradati per workload.

#C++#Xbox#Local Inference#ONNX Runtime#UWP
Releases

Problema

L’inferenza LLM locale su hardware consumer vincolato è limitata da memoria, API runtime, packaging e deployment path specifici della piattaforma.

Progettazione del sistema

Un’app di inferenza su Xbox Series S|X in UWP development mode, con ONNX Runtime GenAI e DirectML instradati per workload, per testare esecuzione locale di modelli entro vincoli stretti di piattaforma.

Risultato

Una prova concreta di edge inference: runtime modello, limiti del device e vincoli di packaging sono espliciti invece che nascosti dietro una demo generica.

Architettura

  • shell app UWP
  • ONNX Runtime GenAI
  • DirectML
  • catalogo dei modelli

Modello di runtime

  • download del modello
  • routing per workload
  • esecuzione dell’inferenza
  • streaming dell’output
  • ispezione dei limiti

Strumenti

  • C++
  • UWP
  • ONNX Runtime GenAI
  • DirectML
  • developer mode Xbox

Affidabilità

  • vincoli hardware espliciti
  • esperimento con tag di release
  • percorso di inferenza locale
download del modellorouting per workloadesecuzione dell’inferenzastreaming dell’outputispezione dei limiti

Vincoli

Il progetto è un esperimento, non un’affermazione di prodotto: restrizioni piattaforma e limiti di dimensione modello definiscono il confine utile.

Compromessi

Un device vincolato rende visibili i limiti ingegneristici, ma riduce scelta dei modelli e flessibilità di deployment.

Evoluzione

Misurare su console le nuove build GGUF prima di promuoverle a default del catalogo.

# active

langchain-rag-tutorial

Pipeline RAG documentata con LangChain per confrontare embeddings OpenAI e HuggingFace senza cambiare il resto del retrieval.

#Python#LangChain#RAG#Embeddings#Tutorial

Problema

La qualità del RAG dipende da chunking, embeddings e scelte di retrieval difficili da confrontare senza una baseline documentata.

Progettazione del sistema

Una pipeline RAG di riferimento su LangChain che esegue embeddings OpenAI e HuggingFace sugli stessi documenti e query per un confronto diretto.

Risultato

Una baseline documentata per confrontare le scelte di retrieval prima di investire in una pipeline di produzione.

Architettura

  • acquisizione dei documenti
  • chunking
  • indice di embedding
  • retriever
  • generazione della risposta

Modello di runtime

  • caricamento
  • chunking
  • embedding
  • retrieval
  • generazione

Strumenti

  • Python
  • LangChain
  • embeddings OpenAI
  • embeddings HuggingFace

Affidabilità

  • confronto diretto tra embeddings
  • notebook riproducibile
  • passi di retrieval documentati
caricamentochunkingembeddingretrievalgenerazione

Vincoli

È una baseline didattica, non un servizio di produzione: chiarezza e riproducibilità vengono prima della scala.

Compromessi

Il formato notebook privilegia la leggibilità rispetto al deployment, quindi gli aspetti di produzione restano volutamente fuori scope.

Evoluzione

Aggiungere reranking, set di valutazione e altri backend di embedding.

# active

mcp_python_toolbox

Server MCP per strumenti di sviluppo Python usati da assistenti AI.

#mcp#python#ai-tools#developer-tools#model-context-protocol
Repository

Problema

Volevo un server MCP basato su Python che desse a un assistente AI una toolbox definita per lo sviluppo Python. I metadati del repository supportano un perimetro ristretto: una superficie di integrazione MCP per strumenti di sviluppo, non una dichiarazione su workflow specifici, adozione o prestazioni.

Progettazione del sistema

Mantengo il confine del sistema nel Model Context Protocol. I client degli assistenti si collegano al server, richiedono strumenti orientati allo sviluppo e ricevono risposte tramite l’interfaccia del protocollo. Python è il linguaggio di implementazione. Il focus progettuale è dove passa il confine degli strumenti: ciò che un assistente può invocare lo dichiara il server, non lo improvvisa un’istruzione in chat.

Risultato

Il repository presenta un server MCP in Python per lo sviluppo Python assistito da AI. Dai metadati disponibili posso descrivere il risultato solo a livello di repository: un punto concreto, basato su protocollo, in cui esporre strumenti di sviluppo Python a client di assistenti compatibili.

Architettura

  • confine del server MCP
  • implementazione in Python
  • gestione delle richieste orientata ai tool
  • interfaccia di protocollo rivolta all’assistente

Modello di runtime

  • il client dell’assistente invia una richiesta di tool
  • il server gestisce la richiesta tramite MCP
  • il codice Python implementa la superficie dei tool
  • la risposta torna attraverso il protocollo

Strumenti

  • Python
  • Model Context Protocol
  • GitHub

Affidabilità

  • confine di protocollo esplicito
  • superficie dei tool delimitata
  • nessuna persistenza implicita: il server non tiene stato di sessione
  • gli errori emergono come risposte di protocollo, non come retry silenziosi
  • l’esposizione limitata tiene piccolo il raggio d’azione di una tool call
il client dell’assistente invia una richiesta di toolil server gestisce la richiesta tramite MCPil codice Python implementa la superficie dei toolla risposta torna attraverso il protocollo

Vincoli

I metadati pubblici non descrivono i singoli strumenti, il modello di esecuzione, il livello di persistenza, benchmark o uso in produzione. Per questo mantengo il progetto al livello dell’integrazione e del confine di sistema.

Compromessi

Usare MCP dà un’interfaccia chiara per l’interazione tra assistente e strumenti, ma significa anche che il comportamento utile dipende dalle definizioni degli strumenti implementate dietro quell’interfaccia. Mantenere il perimetro ristretto riduce l’ambiguità, al prezzo di spostare persistenza e valutazione su chi integra la toolbox in un sistema più grande.

Evoluzione

Il prossimo passo tecnico che valuterei è documentare ogni strumento esposto con il relativo contratto di input, le modalità di errore e gli effetti collaterali attesi. Questo renderebbe il server più facile da testare e creerebbe una base per eval riproducibili senza introdurre affermazioni non supportate sul comportamento attuale.

# active

mklang

Un DSL dichiarativo per macchine a stati guidate da LLM.

#llm#dsl#agents#state-machine#python
Repository

Problema

Volevo un confine linguistico ridotto per macchine a stati guidate da LLM: la macchina a stati doveva essere descritta come documento, non nascosta dentro codice imperativo di collegamento. Il repository tratta il documento `.mkl` come programma e l'LLM come runtime, quindi la domanda tecnica principale è come rendere il flusso di controllo agentico abbastanza esplicito da poter essere ispezionato, modificato e versionato.

Progettazione del sistema

Modello il progetto come un DSL dichiarativo intorno alla struttura di una macchina a stati. L'artefatto sorgente è un documento `.mkl`; Python fornisce il livello di implementazione; l'LLM è trattato come il componente runtime che fa avanzare la macchina in base al documento. Questa separazione mantiene distinta la rappresentazione del programma dal livello di esecuzione e rende il repository uno spazio per verificare forma del linguaggio, confini di parsing e responsabilità del runtime.

Risultato

Il repository documenta un approccio per esprimere macchine a stati guidate da LLM come file sorgente. Dai metadati disponibili non dichiaro benchmark, adozione in produzione o supporto esteso a più modelli. Il risultato utile è il vincolo architetturale stesso: un programma può essere rappresentato come documento `.mkl`, mentre il comportamento a runtime resta collegato a un esecutore basato su LLM.

Architettura

  • sorgente dichiarativo per macchina a stati
  • documenti programma `.mkl`
  • livello di implementazione in Python
  • confine runtime basato su LLM

Modello di runtime

  • esecuzione guidata dal documento
  • transizioni di stato mediate dal runtime LLM
  • artefatto programma esplicito
  • flusso di controllo orientato ad agenti

Strumenti

  • repository Python
  • file di linguaggio `.mkl`
  • cronologia sorgente su GitHub
  • pagina pubblica del progetto

Affidabilità

  • documenti programma versionabili
  • struttura della macchina a stati ispezionabile
  • separazione tra sorgente e runtime
  • un diff sul documento programma è un diff sul comportamento
esecuzione guidata dal documentotransizioni di stato mediate dal runtime LLMartefatto programma esplicitoflusso di controllo orientato ad agenti

Vincoli

Mantengo la descrizione entro i metadati del repository: Python, un DSL dichiarativo, documenti `.mkl`, macchine a stati guidate da LLM e l'idea che l'LLM agisca da runtime. Non deduco funzionalità del parser, garanzie di esecuzione, copertura dei modelli o metriche operative non dichiarate.

Compromessi

Un DSL rende più semplice trattare la struttura di controllo come sorgente, ma introduce anche lavoro di progettazione del linguaggio: sintassi, validazione, semantica runtime e segnalazione degli errori devono essere definiti con cura. Mantenere l'LLM come runtime conserva flessibilità, mentre rende il comportamento deterministico e la semantica di recovery aspetti che il sistema circostante deve specificare in modo esplicito.

Evoluzione

Il lavoro successivo naturale è rendere più esplicito il contratto tra documenti `.mkl` e runtime: rappresentazione dello stato, regole di transizione, comportamento di validazione e fixture di test. Finché un documento non può essere rieseguito su una fixture producendo due volte le stesse transizioni, il linguaggio è una forma, non una garanzia.

# active

harbor-kernel

Kernel bare-metal verificato in Rust per Raspberry Pi 4 con task cooperativi, agenti EL0, IPC e MMU W^X

#rust#bare-metal#aarch64#kernel#raspberry-pi#no-std
Repository

Problema

Volevo un piccolo kernel Rust per Raspberry Pi 4 che rendesse visibili i meccanismi principali di un sistema operativo: task cooperativi, esecuzione di agenti in EL0, IPC e permessi di memoria W^X. I metadati del repository indicano un ambito sperimentale bare-metal su AArch64; non dichiaro uso in produzione, adozione o risultati di benchmark.

Progettazione del sistema

Ho strutturato il progetto come kernel bare-metal Rust no_std per AArch64. Il design ruota attorno a un modello di task cooperativi, a un confine EL0 per gli agenti, a primitive IPC e a una configurazione della MMU pensata per applicare permessi W^X. Mantengo espliciti i confini in modo che cambi di privilegio, percorsi di comunicazione e permessi di memoria siano ispezionabili come meccanismi del kernel invece che come comportamento nascosto del runtime.

Risultato

Il risultato è un repository pubblico centrato su una base di kernel Rust verificato per Raspberry Pi 4. L'ambito supportato è l'architettura del kernel descritta nei metadati: esecuzione bare-metal, scheduling cooperativo, agenti EL0, IPC e lavoro sulla MMU W^X. Dove i metadati non forniscono dettagli, considero lo stato sconosciuto invece di dedurlo.

Architettura

  • kernel Rust no_std
  • target AArch64 per Raspberry Pi 4
  • modello di task cooperativi
  • confine agenti EL0
  • primitive IPC
  • configurazione MMU W^X

Modello di runtime

  • contesto di avvio bare-metal
  • scheduling cooperativo
  • esecuzione agenti in modalità utente
  • IPC orientato ai messaggi
  • permessi espliciti dello spazio di indirizzamento

Strumenti

  • Rust
  • no_std
  • AArch64
  • Raspberry Pi 4
  • GitHub

Affidabilità

  • policy di memoria W^X
  • separazione dei privilegi con EL0
  • flusso di controllo cooperativo
  • superficie bare-metal ridotta
  • ambito del kernel orientato alla verifica
contesto di avvio bare-metalscheduling cooperativoesecuzione agenti in modalità utenteIPC orientato ai messaggipermessi espliciti dello spazio di indirizzamento

Vincoli

Questo è un progetto bare-metal per Raspberry Pi 4, quindi il design resta vicino all'hardware e non presume un runtime di sistema operativo ospitato, una libreria standard o un normale modello di processo. I metadati del repository non forniscono copertura dei test, dettagli sulle prove, stato di distribuzione o dati di benchmark.

Compromessi

Rust e no_std tengono l'implementazione lontana dalle assunzioni di un runtime ospitato, ma rendono esplicito il lavoro specifico per l'hardware. Lo scheduling cooperativo è più semplice da ispezionare rispetto alla preemption, ma richiede che i task cedano il controllo in modo intenzionale. I confini W^X ed EL0 supportano obiettivi di isolamento al prezzo di maggiore complessità nella MMU e nella gestione del contesto.

Evoluzione

Se continuassi il progetto, renderei più ispezionabile il percorso di verifica: nominare le invarianti che il kernel dichiara di rispettare, documentare come rieseguire i controlli che le stabiliscono e dichiarare che cosa resta non dimostrato.

Stai progettando un sistema simile?

Raccontami il problema operativo e i vincoli con cui stai lavorando. Bastano due righe per una prima valutazione tecnica.

Scrivimi due righe sul progetto