Lo dico chiaro e tondo ora, perché a quanto pare il mio pitch veloce di ieri non è entrato bene in testa a molti: si, il #sistemaoperativo che voglio creare è scritto con tecnologie web vanilla (HTML5, CSS, e #JS) e gira interamente nel #browser. Si, è un po’ una #pazzia per la grandezza del mio scopo, ma per favore non stupitevi e non rabbrividite, perché non sono la prima a pensare qualcosa del genere, e anzi, diverse cose sono già state belle che realizzate… 🦷️
Non so in realtà se qualcuno di quegli pseudo-OS #web si avvicina più ad un normale #OS nel modo in cui vorrei fare io, magari dovrei prendermi del tempo per sfogliare (ma mai leggere, non abbiamo così tanto tempo!!!) meglio il loro codice… perché da un lato già sentimenti contrastanti su questa cosa. Potrei forse semplicemente forkare uno di quei robi open-source, e avrei così forse da fare un po’ meno lavoro con un costo minimo di possibilità perse dal punto di vista dell’utilizzo pratico (che poi spiegherò meglio)… però, avrebbe anche un minor valore come lavoro del mio portfolio rispetto a qualcosa di costruito tutto da zero, e fino ad ora in realtà sembra starsi rivelando un grattacapo gradevole, come non avevo granché fatto prima d’ora. 👽️
In realtà finora non c’è nulla di difficile da #programmare, la vera difficoltà sta nel costruire una buona progettazione senza avere nemmeno un briciolo di conoscenza formale sulla teoria dei sistemi operativi, ma solo andando un po’ a sentimento e con le conoscenze collaterali che, da power user di Linux, Windows, Android e tutto quanto da anni, comunque ho indubbiamente accumulato. Perché appunto, non voglio fare uno di quei simulatori che direttamente funzionano con logica di alto livello, ma vorrei tentare di partire da più in basso per… well, creare tutte le astrazioni in modo più ordinato e funzionale, per poter quindi implementare caratteristiche anche più avanzate che altrimenti sarebbero possibili solo con delle hack (ad esempio, come permetti a delle app di mostrare overlay a schermo intero se tutta la tua logica dei processi ruota attorno al dogma che un processo è la sua finestrella nel DOM con il suo tastino in taskbar?). 🧨️
https://octospacc.altervista.org/wp-content/uploads/2024/04/image-6-960x503.pngQuesto è ciò che ho fatto da stamattina ad ora… ho implementato per iniziare giusto un pizzico di logica di eventi, processi, file system, e poi i primissimi passi per il gestore di finestre, in quello che potrebbe tecnicamente essere considerato un #kernel… si, l’ambiente #desktop è praticamente nel kernel al momento (yikes!), ma dovrò pur andare un passo alla volta. Almeno, sto cercando di strutturare il codice in modo modulare, come strati non direttamente dipendenti tra loro, quindi prima o poi dovrebbe essere facile scambiare componenti core del #sistema come pezzettini! Ganzo comunque avere già qualcosa che a video gira, nonostante la strada per la vera funzionalità è ancora lunga. 🙃️https://octospacc.altervista.org/2024/04/22/os-nel-brauser/
Sono praticamente 36 ore che non posto e lo so che siete in astinenza, ma avevo https://octospacc.altervista.org/2024/03/26/pwtorturaaaa/ di risolvere quel #problema con le #PWA una volta per tutte. E ora, nonostante un’altra frazione di sanità mentale sottrattami dagli spiritelli del silicio, dolori perché sto seduta per ore alla scrivania e tutta storta, e sonno perché ieri sera ho perso un sacco di tempo a debuggare un errore stupidissimo rimanendo sveglia fino alle 2 per poi arrendermi perché stavo veramente morendo, quantomeno ce l’ho fatta… 🤯️
Cercando con estrema #disperazione ieri mattina, mi accorgo di una cosa documentata alla bene e meglio, trovando prima una menzione su MDN ad un permesso webRequestFilterResponse.serviceWorkerScript, che servirebbe a regola per permettere alle #estensioni di intercettare i caricamenti dei Service Worker, e poi un thread bugzilla (#1636629) che pare abbia portato proprio all’introduzione di questa separazione di permessi. Ho scaricato il #codice dimostrativo per il bug, l’ho un attimo sistemato per tenere conto di questa misura di sicurezza poi introdotta e, certo abbastanza, il coso riusciva a fare quello che io volevo dall’inizio, senza ricorrere a bruttissime e fragilissime #hack (che a questo punto io nemmeno divulgo visto che non ho dovuto implementarle, per non sporcarmi la reputazione come developer, che già è molto bassa visto che prediligo il #webdev). 🔮️
A questo punto era quasi solo questione di rifiniture, un po’ creare il popup per le impostazioni della mia #estensione (che però mi ha richiesto diverse ore di design e implementazione fatti in contemporanea, perché volevo farle bene, non buttarci dentro bottoni a cazzo per il gusto di), e un po’ capire come #programmare il worker che gestisce #cache e richieste di rete #offline. Solo che qui ho sclerato perché… inizialmente con il codice preso da Chrome for Developers non andava, e pensavo fosse un problema mio, ma invece sembra proprio colpa loro, le loro demo non vanno proprio in #Firefox (ma non ho testato nemmeno in Chromium)… quindi ho provato quello offerto da MDN, ma anche qui nada, solo che ormai stavo crollando e quindi vado a mimir… stamattina vedo meglio e quest’ultima implementazione in effetti scopro che funziona, ma a me non andava perché, nel modo in cui iniettavo il #ServiceWorker trasformandolo da oggetto a stringa, una variabile che referenziavo non era accessibile nel contesto di esecuzione effettivo dello script, e quindi l’accesso alla cache falliva, ma io non me ne sono accorta subito perché già gli strumenti di #debugging del #browser sono mezzi scassati per questi casi speciali, ma io poi avevo pure un try-catch di mezzo che quindi sopprimeva gli errori alzati dall’interprete… la #pazzia. 😫️ 😩️
C’è un #casino di mezzo con la pubblicazione di #addon per #Mozilla, quindi praticamente ora il mio è in revisione, ma se tutto va bene dovrebbe prossimamente apparire sulla pagina https://addons.mozilla.org/en-US/firefox/addon/offline-caching/; in ogni caso, chi volesse usarlo da subito (come me sul telefono in primis) può scaricare da qui il file firmato da installare a mano. Edit: un’oretta dopo, l’estensione è approvata! 💖️
La dualità del fixare #bug (o, in generale, far funzionare il #software?):
Perdi almeno 1 ora buona appresso ad un #glitch oscurissimo (spoiler: la codifica del testo centra sempre in tutti questi bug, in realtà estremamente stupidi), facendo svariati test e tentando varie opzioni prima sensate, e poi senza senso perché altrimenti non sai nemmeno come continuare. 🤥️
Nel frattempo si è fatto #tardi in culo, ti prepari per andare a #dormire e nel frattempo pensi, ma niente… a metà spegni ormai il PC, finisci di prepararti, e continui a #pensare, e solo a quel punto un’idea ovvia viene in testa. Troppo tardi ormai. 💀️
E poi ancora, perché le #incoerenze non sono mai abbastanza:
Giustamente nel letto ti irrequieti e non prendi #sonno, perché il cervello non prende pace senza vedere il #problema finalmente risolto dopo tutta la #pazzia passata, anche scommettendo che l’#idea appena venuta è giusta al 100%. 🥴
Però prima o poi il sonno lo prendi, e dopo ore arriva la #mattina dopo, in cui la sveglia suona e… pensi “zzzzzzz voglio stare nel lettino ancora, tanto la #rogna in mente l’ho risolta, chi me lo fa fare di ammazzarmi a prima mattina [prima mattina: le 9:30, ndr.]”. 🥹
Insomma, è una #condanna. Non se ne esce. Comunque si, il mio #errore era #stupido: stavo cercando di caricare #file nella galleria cloud di #WordPress tramite la #API REST, ma ricevevo sempre un rest_upload_sideload_error… controllo gli header, tutti giusti; cerco in giro, poca roba che non mi aiuta; provo #minuzie come mettere gli header lowercase, ancora niente; tento di settare a mano content-type parziali o estensioni file arbitrarie, e ovviamente non risolvo. 🤯️
Però, noto che un caricamento da curl, anziché dal mio #codice JS, va a buon fine. Allora, provo a caricare verso un server netcat in entrambi i modi, così da poter vedere al volo i dati della trasmissione #HTTP, e noto una differenza stronzetta: il corpo generato dal mio #server è molto più grosso del peso normale del file… quindi qualcosa lo sta corrompendo E qui, però, mi sono ribloccata. 🤔️
Solo poi, quando ormai avevo chiuso tutto come ho detto, ci ho pensato: ma io, nella parte del #programma che legge i #dati trasmessi dal client, vado a castare tutto ad una stringa; sarà questa la causa? …E, ricordandomi di altri #incidenti simili capitati in #NodeJS, capisco subito che è così. Detto in breve: la #codifica del testo centra sempre e rovina ogni cosa. Se esistesse solo l’ASCII, ecco che castare dati binari a stringhe non causerebbe alcun danno. E invece abbiamo deciso che i #computer devono supportare nella loro codifica migliaia di #caratteri discutibili, come tutti quelli emoji. E io, dopo aver apportato questo #fix, devo ora continuare a programmare. Non. Se. Ne. Esce. 😭️
L’ultimissimo miglioramento che ho in ogni caso poi fatto ad #MBViewer è stato l’aggiunta di una funzione per importare codice #CSS e #JavaScript, per modificare come i post possono essere visualizzati. Entrambi funzionano allo stesso modo, con i relativi parametri URL che accettano sia #URL esterni che data URI. Niente di particolare per gli stili, semplicemente importo nella pagina la qualunque cosa venga data lì, ma per gli #userscripts è stato leggermente più #complicato. 😕️
Il punto sta nel voler evitare che #script essenzialmente non affidabili siano iniettati nel contesto della pagina semplicemente da URL, perché potrebbero fare tante cosine cattive; prima fra tutte, rubare #dati dall’archiviazione del #browser del mio dominio, cosa che è un #problema, perché gli utenti inesperti che aprono la app da #link non andranno a cercare di investigare cosa accade dietro le quinte (e, molto probabilmente, non lo farei realisticamente nemmeno io, seguendo la logica del “i miei siti sono miei e li conosco, sui siti altrui ho le protezioni del browser attive“). E quindi inizio a scendere in un rabbithole… ☠️
#Iframe? Hmm… non so, non è il caso, sarebbero insicuri, ci sono alcuni modi in cui una pagina in frame può fare robe fastidiose. Non può essere assolutamente un’idea, proprio mai (foreshadowing). 🪟️
Trovo un bel po’ di #librerie vecchie che ricompilano codice #JS per rimuovere pericoli, o lo analizzano preventivamente per la presenza di operazioni dannose così che possa non essere mai eseguito… praticamente tutte abbandonate, qualcuna esplicitamente dichiarata insicura e non patchata, e per qualcun’altra lo possiamo dare per scontato. 🐛️
Forse questa libreria più recente, jailed, che sfrutta un iframe assieme ad un Web Worker per creare una sandbox forte e bloccare tutte le #API eccetto alcune che si decidono… No, l’ho provata e non va bene, non si riescono a passare alla sandbox oggetti complessi, tra cui i costruttori, è impossibile far funzionare API tipo quella del DOM. 🚧️
Sarebbe stata un’idea usare qualche reimplementazione del #DOM per NodeJS tramite browserify, tipo Cheerio, ma farla anche solo girare lì dentro è un altro casino allucinante. 🥴️
WASM tecnicamente è una #sandbox a sua volta, e non accede alle API del browser se non con codice colla, quindi magari… teoricamente ok, ma nella pratica non ho trovato nessuna soluzione già bella e pronta che potessi usare per questo specifico scopo. 🕳️
La #pazzia: PyScript… sarebbe quasi già pronto, ma avrei dovuto comunque modificarlo per bloccare tutte le API insicure (rimuovere #codice), e poi richiede 15+ MB di dipendenze di runtime… non ideale. 🗿️
Alla fine ci ho pensato meglio, e sono arrivata alla conclusione che è abbastanza sicuro far girare gli script in un iframe con proprietà src="data:[...]" e sandbox="allow-scripts" (che significa, “blocca tutte le proprietà sensibili eccetto gli script”)… voglio dire, nel visualizzare il contenuto dei siti, già permetto eventuali iframe provenienti dai post, e quelli teoricamente possono già fare quello che vogliono eccetto accedere ai dati della finestra root. Nella pratica, i programmini degli utenti quindi hanno accesso a (quasi) l’intera API JavaScript senza poter fare cose bruttissime. 🎉️
https://octospacc.altervista.org/wp-content/uploads/2024/02/image.pngEcco un esempio di tutto, alla fine: questo URL carica il mio MicroBlog, importa un foglio di #stile che mette questo font buffo, e uno script che colora le parole dei #messaggi in base a come si ripetono man mano (inutile, ma serve giusto per dare idea delle potenzialità)… <a href="https://hub.octt.eu.org/MBViewer/#/siteUrl=https://octospacc.altervista.org|platform=wordpress.org|includeStyle=data:text/css;utf8,@import%20url('https://fonts.googleapis.com/css2?family=Single+Day&display=swap');.MbPost{font-family:'Single%20Day',cursive;}|includeScript=data:text/javascript;utf8,function%20MbViewerFunction(data){const%20dom=new%20DOMParser().parseFromString(data.html,'text/html').body;const%20tokens=dom.textContent.split('%20');const%20words={};for(const%20i%20in%20tokens){const%20word%20=%20tokens[i];if(words[word])words[word]++;else%20words[word]=1;tokens[i]=%60%3Cspan%20style='color:${atob('Iw==')}${[0,'b58900','cb4b16','dc322f','d33682','6c71c4','268bd2','2aa198','859900'][words[word]]};'%3E${word}%3C/span%3E%60}data.html=tokens.join('%20').replaceAll('nn','%3Cbr%3E');for(const%20img%20of%20dom.querySelectorAll('img'))data.html+=img.outerHTML;MbViewerReturn(data)}">https://hub.octt.eu.org/MBViewer/#/siteUrl=https://octospacc.altervista.org|platform=wordpress.org|includeStyle=[...]|includeScript=[...]</a> (il link con tutta quella roba messa inline è una stringa di quasi 1 KB!). Userò tutta la cosa per rendere gli hashtag nel testo meno intrusivi per il mio sito anche lì, oltre che sul dominio originale. 👋️Finisco con dati ancora più tecnici, per chi non ha una vita: con questo #design, ogni #userscript deve provvedere ad esporre una funzione che, tramite la Channel Messaging API, viene richiamata dalla #app per ogni messaggio appena questo viene aggiunto al documento visibile; questa funzione riceve dati utili (per ora, solo l’HTML del contenuto; oltre a dati come l’id del messaggio nel flusso, che non sono granché utili all’utente ma devono essere restituiti alla app) e può rimandare nuovi dati indietro richiamando una funzione che è invece l’applicazione ad esporre allo script. Tutto questo ambaradan permetterebbe agli script di effettuare anche operazioni asincrone, comunque, non per forza di dover agire immediatamente alla chiamata. 🤓️
Tra i giorni passati fino a ieri, ho fatto delle robine #sperimentali su #MBViewer, era questo che dovevo #scrivere… La prima è stata, più che altro perché mi serviva effettivamente da tempo una piccola #app in grado di fare questa cosa, implementare la lettura del formato di esportazione chat in #JSON di #Telegram. Infatti, le #conversazioni da lì possono essere esportate anche in JSON per usi di manipolazione dati futuri, oltre che HTML per consultazione immediata; però, appunto non c’è ufficialmente un modo per leggere una #chat esportata in quel #formato macchina, e la conversione in HTML statico dopo sarebbe facile ma bruttina: avere un lettore con un’interfaccia a bolle classica so già che può tornarmi utile, perché ho qualche dump non-HTML da parte. 📦️
A parte la #scocciatura per interpretare la struttura #dati del testo di Telegram e trasporla in #HTML corretto, non è stato complesso… eccetto che c’è un #problema. Il sistema funziona, ma il #programma tende a soffocare male con dump di troppi #messaggi. Dopo poche migliaia, già subentrano #rogne, con l’uso di RAM della scheda del #browser che arriva a più di 1 GB, e il caricamento, se riesce a finire senza che tutto crashi, è veramente lentissimo. Potrei in teoria risolvere la cosa, ma è veramente una #pazzia, dovrei portare ancora di più la codebase all’assurdo per fargli caricare elementi DOM a mano a mano da una struttura che di base è comunque un singolo file tutto in memoria, perché così è il formato… per ora lascio tutto così, purtroppo nessuno mi paga, quindi nessuno godrà al 100%. 😈️
Tuttavia, questa cosa mi è totalmente nuova dal lato tecnico… intendo, mi è nuovo il fatto che il #GBA quando va in #crash riproduca come #audio il contenuto del suo intero spazio di memoria, come suggerirebbe chi ha creato questo #video. Da brevi #ricerche online non trovo assolutamente nulla, eccetto questa #domanda con #risposta che già conoscevo: https://gaming.stackexchange.com/questions/397106/what-causes-the-glitchy-sound-when-a-gba-cartridge-is-removed. Si, ho sentito tante volte il #suono di #glitch quando una cartuccia non fa più [bene] contatto, ma è sempre stato sempre lo stesso di pochi secondi che si ripete di continuo… eppure, in questo #esperimento si dice che dopo quasi 2 ore si inizia a #sentire il contenuto della ROM della #scheda inserita. Ma quale sarebbe la logica di ciò? Magari sono io che non sto usando i giusti termini per #cercare sul web, non lo so, ma vorrei sapere. Un #aiuto è gradito, non ho il tempo e la pazienza di studiare dettagli così minuti del funzionamento #hardware del #GameBoyAdvance solo per levarmi una #curiosità simile. 😩️