diff --git a/DISTRIBUTING.md b/DISTRIBUTING.md index 1552d8c..438e2db 100644 --- a/DISTRIBUTING.md +++ b/DISTRIBUTING.md @@ -581,3 +581,95 @@ Il 19 ottobre alle 14:36 UTC l'utente ha pubblicato su HN [*The Second Brain Gno **Da non fare.** Chiedere stelle o follow a chi non ha ancora usato l'app; solleciti alle newsletter cinesi (HelloGitHub smaltisce la coda lentamente, un sollecito non la accelera); cambiare il README per un canale (vedi la memoria del progetto); riproporre HN (§10.4). **Metrica di controllo per il 3 novembre**: visite uniche giornaliere sopra 5 per almeno tre giorni, 30 stelle, risposta sulla #46, merge di #16968 e #16969. + +## 11. La porta principale e il bisogno di base (27 ottobre 2026) + +Questa sezione nasce da due indirizzi dati dall'utente il 27 ottobre: (1) la missione è entrare **dentro** le distribuzioni, Ubuntu prima di tutte, le altre mainstream e quelle verticali come Omarchy, invece di inseguire le stelle; (2) gknowledge deve diventare uno strumento generico come il foglio di calcolo, in cui il caso d'uso lo porta il bisogno di chi lo usa. Il §5 copre già Flathub e GNOME Circle e non viene ripetuto qui; il §8 resta il registro dei canali di visibilità. Qui si studiano i canali di **inclusione**: chi decide, con quali regole, in quanto tempo, e cosa manca oggi nel repository. + +### 11.1 La porta principale + +**Il punto di partenza nel repository.** Le dipendenze sono minime: `pyproject.toml` dichiara `dependencies = []`, perché PyGObject arriva dal sistema, e `pypdf` è facoltativo. Esistono già quattro forme di pacchetto. `build-aux/debian/` è una directory `debian/` conforme alla policy (debhelper 14, dh-python, modulo in una directory privata, man page, `copyright` in formato DEP-5, `watch`, `upstream/metadata`), verificata il 13 ottobre in `debian:sid` e "lintian-clean apart from the ITP number still to be filed" (commit `0b933b3`; passi e testi pronti dell'ITP in `docs/packaging/debian.md`). La CI però non la usa: `ci.yml` e `release.yml` costruiscono un `.deb` semplice con `build-aux/deb/build-deb.sh` e `dpkg-deb`, quindi la verifica della directory `debian/` è ferma al 13 ottobre, prima della 0.3.0 e del cambio di ID. `build-aux/snap/snapcraft.yaml` è una bozza dichiarata "DRAFT, untested" (core24, confinamento strict, estensione `gnome`, plug `home`). `build-aux/arch/PKGBUILD` è fermo a `pkgver=0.1.0` con `sha256sums=('SKIP')`. Il manifest Flatpak è su runtime GNOME 51 e non chiede più `--filesystem=home`. L'ITP non è mai stato inviato: la ricerca `wnpp` per "gknowledge" sul BTS non restituisce bug (27 ottobre). Due lacune pesano su quasi tutti i canali: **l'interfaccia non è traducibile** (nessun uso di `gettext` nel codice; è in `TODO.md` e nel ROADMAP come "Planned v0.2") e **il MetaInfo non ha screenshot** (zero tag ``). Infine un dato che conta per le policy sull'AI: **61 degli 83 commit** della storia hanno il trailer `Co-Authored-By: Claude`. + +**Debian.** È la porta che apre le altre, perché Ubuntu, Mint, Pop!_OS e le derivate ereditano l'archivio. La sequenza per chi non è Debian Developer è fissata dalla guida di mentors.debian.net: aprire un ITP sullo pseudo-pacchetto `wnpp` ("the very first step should be to file an "Intent to package""), caricare il pacchetto firmato su mentors, aprire un bug RFS contro `sponsorship-requests`, trovare un Debian Developer che faccia da sponsor e superare la revisione manuale degli ftpmaster nella coda NEW, dove "ftpmaster's opinion is binding" ([mentors](https://mentors.debian.net/intro-maintainers/)). La guida ricorda che Debian non è un repository generico: nell'ITP può arrivare la domanda se il pacchetto serve. I tempi della coda NEW non sono pubblicati in forma leggibile: a marzo 2025 Matthias Urlichs stimava una mediana di circa tre settimane sui ~135 pacchetti in attesa, Timo Röhling una mediana sotto le 48 ore mescolando pacchetti sorgente nuovi e nuovi binari, e a gennaio 2026 un thread su debian-devel sosteneva, per impressione personale, che la coda fosse alla dimensione massima mai registrata ([debian-devel, mar 2025](https://lists.debian.org/debian-devel/2025/03/msg00138.html); [debian-devel, gen 2026](https://lists.debian.org/debian-devel/2026/01/msg00281.html); [grafici di Röhling](https://people.debian.org/~roehling/new-queue/), valori non estraibili). Il precedente più vicino è **Iotas**, app di note GTK 4 in Python: ITP #1041610 aperto il 21 luglio 2023 da Arnaud Ferraris, Debian Developer, primo upload in experimental il 25 luglio 2023; oggi è in forky e sid (2026.8-1) ([ITP #1041610](https://bugs.debian.org/1041610); [sources.debian.org](https://sources.debian.org/src/iotas/)). Apostrophe, citata in `docs/packaging/debian.md`, è mantenuta dal team Debian GNOME (`pkg-gnome-maintainers`, con Jeremy Bícha tra gli uploader) ([control](https://sources.debian.org/src/apostrophe/3.4-3/debian/control/)). Né Alpaca né Newelle né Ollama sono nell'archivio Debian (404 su sources.debian.org il 27 ottobre): **nessun client AI GTK è ancora entrato in Debian**, il che è insieme uno spazio libero e un'incognita sul giudizio dei revisori. Sull'AI la posizione di Debian è ora definita. La GR del 2026 "LLM usage in Debian" (voto dal 15 al 28 agosto 2026, nove opzioni, compresa una che bandiva i contributi LLM tramite il Social Contract e non ha raggiunto la maggioranza 3:1) è stata vinta dall'opzione 5, "Responsible Use of Generative AI": Debian "neither endorses nor prohibits" gli strumenti di AI generativa, i contributi sono giudicati con gli stessi standard di qualità e legali, la dichiarazione è incoraggiata ma non obbligatoria, e il testo non tocca il software upstream ([vote_002](https://www.debian.org/vote/2026/vote_002.en.html)). La GR del 2025 sui modelli AI e le DFSG, che avrebbe escluso da `main` i modelli senza dati di addestramento, è stata ritirata da Mo Zhou l'8 maggio 2025 senza voto ([vote 2025/002](https://www.debian.org/vote/2025/vote_002); [LWN](https://lwn.net/Articles/1020968/)); in ogni caso riguardava i pesi dei modelli, che gknowledge non distribuisce. **Cosa manca:** inviare l'ITP e il messaggio al team GNOME già scritti; rifare la verifica in `debian:sid` con la 0.3.x; valutare un job CI che costruisca il pacchetto sorgente con lintian, così la directory non invecchia. + +**Ubuntu universe.** Non richiede una procedura separata: un pacchetto accettato in Debian unstable entra nella release di sviluppo di Ubuntu con la sincronizzazione automatica, fino al Debian Import Freeze. Il caso Iotas lo mostra nei dati: Launchpad pubblica `iotas 2026.7-1` in universe sia per 26.10 sia per 27.04, con la versione Debian e senza suffisso `ubuntu` ([Launchpad API](https://api.launchpad.net/devel/ubuntu/+archive/primary?ws.op=getPublishedSources&source_name=iotas&exact_match=true)). Le scadenze: per la 26.10 il Debian Import Freeze era il 20 agosto 2026, per la **27.04 "Tenacious T-Rex" è il 25 febbraio 2027**, con uscita il 22 aprile 2027 ([schedule 26.10](https://documentation.ubuntu.com/release-notes/26.10/schedule/); [schedule 27.04](https://documentation.ubuntu.com/release-notes/27.04/schedule/)). Per essere in 27.04 senza chiedere eccezioni, il pacchetto deve superare la coda NEW di Debian entro fine febbraio: con i tempi incerti descritti sopra, l'ITP andrebbe aperto entro novembre. Una volta in universe, gknowledge compare anche nell'App Center di Ubuntu, che gestisce snap e deb (l'annuncio della 26.10 parla di "a more consistent experience for managing snaps and debs") ma **non i Flatpak**, come dice la stessa pagina di Flathub per Ubuntu 23.10 e successive ([Canonical, 15 ott 2026](https://canonical.com/blog/canonical-releases-ubuntu-26-10-stonking-stingray); [Flathub setup](https://flathub.org/setup/Ubuntu)). Per chi apre l'App Center di Ubuntu, quindi, gknowledge può esistere solo come deb dell'archivio o come snap. + +**Ubuntu main e app preinstallate.** È il livello che corrisponde a "Ubuntu adotta gknowledge", e ha due cancelli distinti. Il primo è la **MIR** (Main Inclusion Review), necessaria per passare da universe a main. La lista di controllo del richiedente chiede, tra l'altro, motivazione e assenza di alternative già in main, storia CVE, "a non-trivial test suite", watch file, lintian `--pedantic`, supporto alle traduzioni e un file desktop conforme per le app utente, tutte le dipendenze di runtime in main, e soprattutto un team proprietario: "All packages must have a designated "owning" team" e "The package needs a bug subscriber before it can be promoted to main" ([MIR](https://ubuntu.com/project/docs/MIR/main-inclusion-review/); [reporter template](https://ubuntu.com/project/docs/MIR/mir-reporters-template/)). I tempi sono rimandati a "Service Level Objectives" che non sono riuscito a leggere. Il secondo cancello è il **seed** del desktop, deciso dal Desktop team di Canonical. Il precedente recente sono Ptyxis e Loupe: Ptyxis indicato come "recommended replacement" di GNOME Terminal in un aggiornamento del team del 9 dicembre 2024, annunciato per la 25.10 da Jean Baptiste Lallement a maggio 2025 insieme a Loupe; il 18 agosto 2025 Alessandro Astone scriveva che "ptyxis is seeded in >= questing" e "loupe is in the process of being MIR'd" ([OMG! Ubuntu, 16 mag 2025](https://www.omgubuntu.co.uk/2025/05/ubuntu-25-10-to-include-new-image-viewer-terminal-apps); [ubuntu-desktop, 18 ago 2025](https://lists.snapcraft.io/archives/ubuntu-desktop/2025-August/006370.html)). Erano app del nucleo GNOME che sostituivano app già preinstallate, e il percorso ha richiesto circa dieci mesi. + +Il fatto nuovo è la **roadmap AI di Ubuntu**. Il 27 aprile 2026 Jon Seager (VP Engineering) ha pubblicato "The future of AI in Ubuntu": funzioni "implicite" (sintesi e riconoscimento vocale) ed "esplicite" (flussi agentici per scrivere documenti, diagnosticare problemi, automazioni personali), "bias toward local inference by default", inference snap per i modelli, e la chiusura "Ubuntu is not becoming an AI product, but it can become stronger with thoughtful AI integration" ([Discourse](https://discourse.ubuntu.com/t/the-future-of-ai-in-ubuntu/81130)). Nel thread ha aggiunto che le funzioni arriveranno "as Snaps", in anteprima "on a strictly opt-in basis in 26.10", che le configurazioni predefinite useranno sempre modelli locali, e che Canonical distribuirà codice scritto o co-scritto con AI ([GamingOnLinux, 28 apr 2026](https://www.gamingonlinux.com/2026/04/canonical-clarify-their-ai-plans-for-ubuntu-linux-opt-in-and-easy-to-remove/), che riporta la risposta n. 41). La 26.10, uscita il 15 ottobre, ha consegnato il primo passo: **Myna**, riconoscimento vocale con modelli locali, opt-in, che "as Ubuntu 28.04 LTS approaches, it will be included by default", descritto come "the first step towards a more natural, intent-driven Ubuntu Desktop experience" ([Canonical, 15 ott 2026](https://canonical.com/blog/canonical-releases-ubuntu-26-10-stonking-stingray)). Gli **inference snap** espongono, per alcuni modelli, un'API "OpenAI compliant" su `http://localhost:/`, con l'URL riportato dal comando ` status`; la documentazione ha pagine di integrazione per Open WebUI, OpenClaw, OpenCode, OpenShell, VS Code e JetBrains ([how-to OpenAI API](https://github.com/canonical/inference-snaps/blob/main/docs/how-to/usage/openai-api.md); [documentazione](https://documentation.ubuntu.com/inference-snaps/)). gknowledge parla già questo protocollo con il provider OpenAI-compatibile. **Cosa manca per main, onestamente:** un team Canonical disposto a esserne proprietario, che oggi non c'è; le traduzioni; `pypdf` è in universe (verificato su Launchpad per noble), mentre GTK 4, libadwaita e PyGObject sono in main, quindi la Recommends andrebbe promossa o declassata; una storia di manutenzione più lunga di tre mesi. L'inclusione di default non è un obiettivo del 2027: la strada realistica verso Canonical passa dalla sua roadmap AI (inference snap, snap, agenti) più che dal seed. + +**Snap Store.** È il canale di Ubuntu per le app di terze parti ed è indipendente da Debian. Dal 22 marzo 2024, dopo le truffe con falsi wallet crypto, **ogni nuovo nome di snap passa una revisione manuale**, annunciata come temporanea con risposta "within two working days" ([forum snapcraft](https://forum.snapcraft.io/t/manual-review-of-all-new-snap-name-registrations/39440)). Non ho trovato un annuncio di revoca, e un thread del gennaio 2026 riporta uno snap nuovo fermo in "Manual Review" da tre settimane ([forum](https://forum.snapcraft.io/t/manual-review-pending-for-fmd-server/50154)): la misura sembra ancora attiva. Il plug `home` della bozza si connette automaticamente sulle distribuzioni tradizionali ([home interface](https://snapcraft.io/docs/home-interface)), quindi non richiede eccezioni. Non ho trovato una policy dello Snap Store sul codice generato con AI. **Cosa manca:** costruire e provare la bozza (`grade: devel`, mai costruita), passare a `grade: stable`, registrare il nome, allineare i permessi al flusso con portali già adottato nel Flatpak. + +**Fedora.** Due strade. Il pacchetto RPM richiede una review request su Bugzilla fatta con l'account FAS e, per il primo pacchetto, uno sponsor che aggiunga il richiedente al gruppo `packager`; la sponsorizzazione non è automatica e Fedora suggerisce gli scambi di review ([Package Review Process](https://fedoraproject.org/wiki/PackageReviewProcess); [New Package Process for New Contributors](https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/); la pagina principale della documentazione è dietro Anubis e non l'ho letta per intero). L'altra strada è Flathub: dalla Fedora 38 chi abilita i repository di terze parti vede Flathub senza filtri, con priorità a Fedora Flatpak e RPM ([Changes/UnfilteredFlathub](https://fedoraproject.org/wiki/Changes/UnfilteredFlathub)). La policy di Fedora sui contributi con AI, approvata dal Council a ottobre 2025, li ammette con responsabilità del contributore e dichiarazione quando "the significant part of the contribution is taken from a tool without changes", con trailer `Assisted-by:` ([The Register](https://www.theregister.com/2025/10/23/fedora_agrees_policy_allowing_ai_assisted_code_contribs/); [GamingOnLinux](https://gamingonlinux.com/2025/10/fedora-linux-project-agrees-to-allow-ai-assisted-contributions-with-a-new-policy)); secondo Linuxiac aggiunge che le funzioni AI integrate nei prodotti Fedora devono essere opt-in ("Any AI-powered functionality must be opt-in rather than automatically enabled"), clausola che non ho trovato nelle altre fonti ([Linuxiac](https://linuxiac.com/fedora-opens-the-door-to-ai-tools)). gknowledge sarebbe conforme per costruzione: il provider predefinito è `offline` (`gknowledge/core/project.py:47`). Justin ha già verificato il Flatpak su Fedora 44 (§8.1). + +**AUR e Omarchy.** L'AUR non ha revisione preventiva: chiunque abbia un account carica un PKGBUILD. `gknowledge` non c'è (RPC AUR, 27 ottobre); ci sono `alpaca-ai` (13 voti) e `newelle` (6 voti). Omarchy è un'altra cosa: "a beautiful, fun & agentic Linux distribution by DHH" su Arch e Hyprland, 45.781 stelle, che installa da Arch e da un proprio repository `pkgs.omarchy.org` ([README](https://github.com/basecamp/omarchy); `default/pacman/`). La lista di base `install/omarchy-base.packages` (ultima modifica 25 ottobre 2026) contiene già **`obsidian`**, `nautilus`, `python-gobject` e `libreoffice-fresh`; le app proprie di Omarchy sono scritte in C++ e Qt Quick. Il manuale ha un capitolo AI centrato sugli agenti da terminale: 23 agenti lanciabili (Claude Code, Codex, OpenCode e altri) installati al primo uso con `mise`, un agente predefinito scelto al primo avvio, un pannello in barra con l'uso dei piani, e installer per app desktop come Claude e ChatGPT ([manual/17-ai.md](https://github.com/basecamp/omarchy/blob/quattro/manual/17-ai.md); `bin/omarchy-install-ai-*`). Le scelte le fa il team Basecamp con commit diretti; delle ultime 100 PR chiuse, 78 sono state mergiate (API GitHub, 27 ottobre), quindi il repository accetta contributi esterni, ma non ho trovato criteri scritti per aggiungere un'app ai default. Per Omarchy il punto d'aggancio naturale non è l'app GTK, che su Hyprland funziona ma non è nello stile della distribuzione, bensì **il server MCP**: una knowledge base che gli agenti già presenti possono interrogare, compatibile con il vault Obsidian che Omarchy installa di serie. **Cosa manca:** aggiornare il PKGBUILD alla 0.3.x con checksum veri e pubblicarlo sull'AUR, valutare un pacchetto `gknowledge-mcp` separato, poi proporre a Omarchy una voce nel manuale o nel menu, non un default. + +**elementary AppCenter.** È curato e ha regole incompatibili con lo stato attuale del progetto. Oltre al runtime elementary obbligatorio ("Your Flatpak manifest must use the elementary runtime"; un manifest sul runtime GNOME non compila) e a screenshot con l'aspetto predefinito di elementary, i requisiti vietano l'AI generativa: le app non possono includere codice, packaging, documentazione o grafica generati da AI, e i revisori possono rifiutare ciò che potrebbe contenerne ([publishing requirements](https://docs.elementary.io/develop/appcenter/publishing-requirements); [submission process](https://docs.elementary.io/appcenter/submission-process)). Con 61 commit su 83 co-firmati da Claude, **elementary è fuori portata** e non va tentato. + +**Universal Blue (Bluefin, Bazzite) e Linux Mint.** Passano da Flathub. La documentazione AI di Bluefin indica come "preferred default experience" llmman installato con brew, Goose come interfaccia principale verso i modelli, e "we recommend that users install Alpaca" da Flathub per la chat; cita Newelle solo come esempio di client per l'endpoint OpenAI-compatibile di llmman ([Bluefin AI](https://docs.projectbluefin.io/ai)). Linux Mint 22 mostra nel Software Manager **solo i Flatpak verificati**: quelli non verificati sono nascosti per impostazione predefinita e marcati come sconsigliati se l'utente li abilita ([OMG! Ubuntu, giu 2024](https://www.omgubuntu.co.uk/2024/06/linux-mint-will-hide-unverified-flatpaks); [It's FOSS](https://itsfoss.com/news/linux-mint-22-matrix-flatpak/)). Mint mostra anche i deb di Ubuntu, quindi un gknowledge in universe sarebbe installabile da Mint senza Flathub. Non ho trovato un processo documentato con cui Mint sceglie le app di default. + +**Sequenza consigliata.** Le stime di sforzo sono nostre; i tempi di attesa vengono dalle fonti sopra. + +| # | Passo | Apre | Chi decide | Sforzo nostro | Attesa | Blocchi noti | +|---|---|---|---|---|---|---| +| 1 | **ITP Debian** e messaggio al team Debian GNOME (testi in `docs/packaging/debian.md`), riverifica in `debian:sid` con la 0.3.x, RFS su mentors | Debian, Ubuntu universe e App Center, Mint, Pop!_OS | sponsor DD, ftpmaster | S | settimane–mesi (NEW) | serve uno sponsor; per Ubuntu 27.04 entro il 25 feb 2027 | +| 2 | **gettext**: stringhe traducibili, `po/`, aggancio a un'infrastruttura di traduzione | MIR, Circle, Mint e Ubuntu localizzati; dà uno scopo alle issue di traduzione #32–#40 | noi | M | — | nessuno | +| 3 | **Rilevamento degli inference snap** nelle preferenze (come Ollama nella #46) e proposta di una pagina di integrazione nella documentazione di `canonical/inference-snaps` | rapporto con la roadmap AI di Canonical | noi; maintainer della documentazione | S–M | da verificare | non so se accettano integrazioni di terzi | +| 4 | **AUR**: PKGBUILD 0.3.x con checksum; pacchetto `gknowledge-mcp` | Arch, Omarchy, Manjaro | nessuno (AUR) | S | — | nessuno | +| 5 | **Snap**: costruire e testare la bozza, registrare il nome | Snap Store e App Center sulle LTS già uscite | Canonical (revisione manuale del nome) | M | giorni–settimane | revisione manuale dei nomi | +| 6 | **Screenshot nel MetaInfo** | Flathub, GNOME Software, MIR | noi | S | — | nessuno | +| 7 | **Fedora RPM** dopo Debian, con review swap | Fedora, poi EPEL | sponsor Fedora | M | settimane | sponsor | +| 8 | **Flathub** (§5) quando la policy AI lo consentirà | Fedora, Universal Blue, Mint (solo se verificato), TWIG | revisori Flathub | S (manifest pronto) | 1–6 giorni dopo l'apertura | policy AI di maggio 2026 | +| 9 | **Ubuntu main / seed** | Ubuntu preinstallato | MIR team, Desktop team | L | anni | team proprietario, traduzioni, `pypdf` in universe, storia di manutenzione | +| — | elementary AppCenter | — | — | — | — | divieto di contenuti generati da AI; runtime elementary | + +La conseguenza più importante: per un progetto scritto con l'aiuto di un LLM, **la porta principale di Debian e Ubuntu è oggi più aperta di Flathub**. Debian ha deciso di non vietare l'AI e Canonical ha detto che distribuisce codice co-scritto con AI, mentre Flathub ed elementary la vietano quasi del tutto. Il passo 1 costa poco perché la directory `debian/` esiste già, e conviene partire entro novembre. + +### 11.2 Il bisogno di base + +**Come si sono affermati gli strumenti generici.** Tre casi, scelti perché ognuno ha venduto una primitiva e non un caso d'uso. + +- **VisiCalc (1979).** Dan Bricklin racconta che l'idea gli venne alla Harvard Business School nella primavera del 1978, immaginando una calcolatrice con un "heads-up display" in cui "punch in a few numbers, circle them to get a sum, do some calculations, and answer '10% will be fine!'"; il primo prototipo su Apple II è dell'8 ottobre 1978, e lo schema dei tasti fu disegnato "on the back of a sheet of spreadsheet paper" ([Bricklin, The Idea](http://www.bricklin.com/history/saiidea.htm)). La primitiva era un oggetto che il pubblico conosceva già, il foglio a colonne del ragioniere, con una sola proprietà nuova: il ricalcolo. Il primo annuncio uscì su Byte di maggio 1979, prima che il prodotto fosse annunciato, e secondo Bricklin centrava "accountants, business planners, etc." ([First Advertisements](http://www.bricklin.com/history/firstad.htm)). Ben Rosen, allora analista di Morgan Stanley, scrisse dopo un'anteprima a metà 1979: "Visicalc could some day become the software tail that wags (and sells) the personal computer dog" ([Ben Rosen's Reaction](http://www.bricklin.com/history/rosenletter.htm)). Il Computer History Museum gli attribuisce un aumento significativo delle vendite dell'Apple II ([CHM, Bob Frankston](https://computerhistory.org/profile/bob-frankston/)); le cifre di vendita (700.000 copie in sei anni, fino a un milione) circolano solo in fonti secondarie. Lotus 1-2-3, uscito il 26 gennaio 1983 per l'IBM PC, ripeté lo schema dichiarando nel nome le tre cose che faceva: foglio, grafici, database ([Wikipedia, fonte secondaria](https://en.wikipedia.org/wiki/Lotus_1-2-3)). +- **Dropbox (2007–2008).** Il primo post su Hacker News, "My YC app: Dropbox - Throw away your USB drive" (dhouston, 4 aprile 2007, 104 punti), nominava l'oggetto che sostituiva, non la tecnologia ([HN 8863](https://news.ycombinator.com/item?id=8863)). La primitiva era una cartella che c'è dappertutto: nessun comportamento nuovo da imparare, funziona con le app che l'utente già usa. Il video demo di marzo 2008 su Digg avrebbe portato la lista d'attesa da 5.000 a 75.000 persone in una notte ([Startup Lessons Learned](https://www.slideshare.net/vishaltx/dropbox-startup-lessons-learned-16991502); [Timeline of Dropbox](https://en.wikipedia.org/wiki/Timeline_of_Dropbox); cifra non verificata su fonte primaria). +- **Obsidian (dal 2020).** Ha risolto il conflitto del lock-in facendone il proprio argomento: dati "stored on your device, inaccessible to us", formati aperti contro il lock-in, "100% supported by our users, not investors" ([About](https://obsidian.md/about)). Il CEO Steph Ango lo ha scritto come principio in "File over app" (1 luglio 2023): "if you want to create digital artifacts that last, they must be files you can control", e "In the fullness of time, the files you create are more important than the tools you use to create them" ([stephango.com](https://stephango.com/file-over-app)). + +Lo schema comune ha tre parti. **Un oggetto già noto** (il foglio a colonne, la cartella, il file di testo) con **una sola proprietà nuova** (si ricalcola, si sincronizza, dura). **Il racconto nomina l'oggetto sostituito** ("throw away your USB drive"), non la tecnologia. **Il conflitto di adozione principale è risolto nella struttura del prodotto**, non promesso: VisiCalc non chiedeva di programmare, Dropbox non chiedeva di cambiare app, Obsidian non chiede di fidarsi dell'azienda. + +**La primitiva candidata per gknowledge.** Proposta da discutere: **"una cartella di documenti che risponde citando le fonti, e ti avvisa quando una risposta si basa su un documento cambiato"**. L'oggetto noto è la cartella, o il faldone, che tutti hanno: lo studio legale con normativa e pareri, il gruppo di ingegneria con specifiche e revisioni, lo studente con le fonti della tesi, la famiglia con i documenti di casa. Le proprietà nuove sono due, e il codice le ha già: le citazioni e il controllo delle fonti cambiate (`ChangeDetector` in `gknowledge/core/lint.py`, l'avviso "changed since ingest" nell'interfaccia, il tool MCP `stale_sources`). L'oggetto sostituito da nominare nel racconto è la ricerca a mano nei PDF, o la chat con un'AI che risponde senza dire da dove. Il collegamento con Openapi è diretto: chi lavora su dati certificati vende proprio la seconda proprietà, sapere da dove viene un'informazione e se è ancora valida. Un'osservazione dal registro: il sommario attuale ("A native GNOME knowledge workstation…") descrive la forma del software e non la primitiva, ed è la stessa formula che ha fatto rifiutare la prima scheda Glama come "app GNOME, non server MCP" (§10.5). + +**I conflitti di adozione, con lo stato attuale del codice.** + +| Conflitto | Cosa c'è oggi | Proposta concreta | +|---|---|---| +| **Serve un LLM**: chiave, costo, privacy | provider predefinito `offline` con motore euristico (`project.py:47`); Ollama locale con rilevamento dalla PR #46 (27 ott); endpoint OpenAI-compatibili; piano ChatGPT dell'utente | estendere il rilevamento agli **inference snap** di Ubuntu (URL da ` status`); mostrare sempre dove avviene il calcolo ("tutto su questo computer" oppure il nome del servizio) | +| **Fiducia nelle risposte** | citazioni numerate verso le pagine; provenienza per pagina; avviso sulle fonti cambiate | mostrare per ogni citazione il passaggio della fonte originale, non solo la pagina del wiki; rendere il controllo delle fonti un gesto visibile ("verifica questa risposta") | +| **I primi cinque minuti** | la schermata iniziale offre solo "New Project…" e "Open Project…" (`window.py:121`); tre corpora dimostrativi (`data/demo/chess`, `energy`, `papers`) esistono ma li usa solo lo script di sviluppo `build-aux/dev/seed_demo.py` | un pulsante "Prova con un esempio" che apre uno dei corpora già pronti; trascinamento di file nella finestra (oggi assente) | +| **Dove stanno i documenti** | importazione di file e cartelle; Markdown, testo, PDF, HTML, EPUB; "Apri con" da Nautilus importa nel progetto corrente, ma senza un progetto aperto mostra solo "Open or create a project first" (`app.py`) | parser DOCX e ODT, i formati di studi legali e uffici tecnici; cartella sorvegliata (prevista nel ROADMAP per la v0.3, non implementata); un progetto "Inbox" creato al primo "Apri con" | +| **Lock-in** | wiki in Markdown semplice con wikilink e front matter, compatibile con Obsidian e con git | risolto nel codice; va raccontato come garanzia strutturale, alla maniera di "File over app" | +| **Identità** | "knowledge workstation", "LLM wiki", "MCP server": tre nomi per tre pubblici | usare la primitiva come frase unica nei canali di inclusione (descrizione ITP, MetaInfo, snap, AUR), senza toccare il README (memoria del progetto) | + +L'ordine suggerito segue la logica dei tre casi storici: prima i primi cinque minuti e l'avviso visibile sulle fonti (la proprietà nuova si deve vedere subito), poi DOCX, ODT e cartella sorvegliata (l'oggetto noto deve essere la cartella vera dell'utente), poi gli inference snap (il conflitto LLM risolto nel modo che Ubuntu stessa sta adottando). + +### 11.3 Cosa non è stato verificato + +- I tempi attuali della coda NEW di Debian: i grafici di Röhling non sono leggibili come testo e le stime pubbliche sono aneddotiche. +- I Service Level Objectives della MIR e il ruolo del security team nella revisione. +- La data del freeze di Debian 14 "forky": nessun calendario pubblicato trovato. +- Se la revisione manuale dei nuovi nomi nello Snap Store sia ancora formalmente in vigore, e se lo Snap Store abbia una policy sul codice generato da AI. +- Una policy di Ubuntu (Technical Board) sui contributi con AI: c'è solo la dichiarazione di Seager su Discourse. +- La clausola "opt-in" della policy AI di Fedora, riportata solo da Linuxiac; la pagina ufficiale è protetta da Anubis. +- Come Omarchy e Linux Mint scelgono le app predefinite: nessun criterio scritto trovato. +- Se la documentazione di `canonical/inference-snaps` accetta pagine di integrazione proposte da terzi. +- Le cifre di vendita di VisiCalc e il dato 5.000 → 75.000 di Dropbox, presenti solo in fonti secondarie. + +### 11.4 Fonti + +**Debian.** mentors.debian.net (https://mentors.debian.net/intro-maintainers/); debian-devel marzo 2025 (https://lists.debian.org/debian-devel/2025/03/msg00138.html) e gennaio 2026 (https://lists.debian.org/debian-devel/2026/01/msg00281.html); grafici NEW di Röhling (https://people.debian.org/~roehling/new-queue/); GR 2026/002 "LLM usage in Debian" (https://www.debian.org/vote/2026/vote_002.en.html); GR 2025/002 su AI e DFSG (https://www.debian.org/vote/2025/vote_002; LWN https://lwn.net/Articles/1020968/); ITP Iotas #1041610 (https://bugs.debian.org/1041610); API di sources.debian.org (iotas, apostrophe, alpaca, newelle, ollama, gknowledge); BTS `wnpp`. + +**Ubuntu e Canonical.** Calendari 26.10 e 27.04 (https://documentation.ubuntu.com/release-notes/26.10/schedule/, https://documentation.ubuntu.com/release-notes/27.04/schedule/); API Launchpad (iotas, pypdf, libadwaita-1, pygobject, gtk4); MIR (https://ubuntu.com/project/docs/MIR/main-inclusion-review/, https://ubuntu.com/project/docs/MIR/mir-reporters-template/); ubuntu-desktop 18 agosto 2025 (https://lists.snapcraft.io/archives/ubuntu-desktop/2025-August/006370.html); OMG! Ubuntu su Ptyxis e Loupe (https://www.omgubuntu.co.uk/2025/05/ubuntu-25-10-to-include-new-image-viewer-terminal-apps); "The future of AI in Ubuntu" (https://discourse.ubuntu.com/t/the-future-of-ai-in-ubuntu/81130); GamingOnLinux 28 aprile 2026 (https://www.gamingonlinux.com/2026/04/canonical-clarify-their-ai-plans-for-ubuntu-linux-opt-in-and-easy-to-remove/); annuncio Ubuntu 26.10 (https://canonical.com/blog/canonical-releases-ubuntu-26-10-stonking-stingray); inference snap (https://github.com/canonical/inference-snaps, https://documentation.ubuntu.com/inference-snaps/); Flathub su Ubuntu (https://flathub.org/setup/Ubuntu); Snap Store (https://forum.snapcraft.io/t/manual-review-of-all-new-snap-name-registrations/39440, https://forum.snapcraft.io/t/manual-review-pending-for-fmd-server/50154, https://snapcraft.io/docs/home-interface). + +**Fedora.** PackageReviewProcess (https://fedoraproject.org/wiki/PackageReviewProcess); New Package Process (https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/); UnfilteredFlathub (https://fedoraproject.org/wiki/Changes/UnfilteredFlathub); policy AI (https://www.theregister.com/2025/10/23/fedora_agrees_policy_allowing_ai_assisted_code_contribs/, https://gamingonlinux.com/2025/10/fedora-linux-project-agrees-to-allow-ai-assisted-contributions-with-a-new-policy, https://linuxiac.com/fedora-opens-the-door-to-ai-tools). + +**Arch, Omarchy, elementary, Universal Blue, Mint.** RPC AUR (https://aur.archlinux.org/rpc/v5/); basecamp/omarchy (README, `install/omarchy-base.packages`, `default/pacman/`, `manual/17-ai.md`, `bin/omarchy-install-ai-*`, API delle PR); elementary (https://docs.elementary.io/develop/appcenter/publishing-requirements, https://docs.elementary.io/appcenter/submission-process); Bluefin AI (https://docs.projectbluefin.io/ai); Mint e Flatpak non verificati (https://www.omgubuntu.co.uk/2024/06/linux-mint-will-hide-unverified-flatpaks, https://itsfoss.com/news/linux-mint-22-matrix-flatpak/). + +**Strumenti generici.** Dan Bricklin (http://www.bricklin.com/history/saiidea.htm, http://www.bricklin.com/history/firstad.htm, http://www.bricklin.com/history/rosenletter.htm); CHM (https://computerhistory.org/profile/bob-frankston/); Lotus 1-2-3 (https://en.wikipedia.org/wiki/Lotus_1-2-3); HN 8863 (https://news.ycombinator.com/item?id=8863); Houston, Startup Lessons Learned (https://www.slideshare.net/vishaltx/dropbox-startup-lessons-learned-16991502); Timeline of Dropbox (https://en.wikipedia.org/wiki/Timeline_of_Dropbox); Obsidian About (https://obsidian.md/about); Steph Ango, File over app (https://stephango.com/file-over-app).