Come Nitrux sta cambiando lo scenario Linux tradizionale [Intervista]

Potresti aver sentito parlare di Nitrux Linux. È apparso su It's FOSS un paio di anni fa.

Molte persone l'hanno considerata semplicemente un'altra distribuzione basata su Ubuntu con un piccolo cambiamento di tema. E' così sbagliato!

In questa intervista con il fondatore di Nitrux Uri Herrera, scoprirai perché Nitrux non è solo un'altra distribuzione Linux e come sta aggiungendo una nuova dimensione alla scena Linux con strumenti innovativi come il gestore del sistema operativo ZNX, MAUI per lo sviluppo rapido di app desktop e mobili e altro ancora. .

IF: Poche persone conoscono l'origine del progetto Nitrux. Potresti per favore fornire dettagli su come sei passato da una società di progettazione a una società di hardware a una distribuzione Linux?

Uri Herrera: Nitrux è stata fondata nel 2012 da me (Uri Herrera) come Nitrux S.A. in Messico. All'epoca frequentavo il college e studiavo Graphic Design, quindi la maggior parte dei miei primi lavori era legata a quello. Ho creato il tema delle icone Nitrux, il tema delle icone Compass, il tema delle icone Flattr, il tema delle icone ZERO, il tema delle icone Dots, un pacchetto di temi per KDE 4 chiamato Nitrux KDE Suite, un paio di temi GTK ispirati a MIUI 4 insieme a molti mockup per applicazioni GUI e altri bundle che espandono i temi delle icone, tutti sono disponibili su DeviantArt.

Nel 2013 ho incontrato Haashir Mohammed, che si è unito a me, e ha creato molte applicazioni basate sul web per Nitrux come Typer.IM, nDisk e Muire. Typer.IM era un servizio di messaggistica istantanea con condivisione di file p2p e utilizzava WebRTC per le chiamate, sia audio che video. nDisk era un servizio di archiviazione cloud e potevi accedervi con WebDav dal tuo desktop. Muire era un costruttore di siti Web come Weebly e potevi creare, salvare ed esportare i siti Web che creavi al suo interno.

Nel corso del 2013 e del 2014 abbiamo deciso di entrare nel settore dell'hardware. Abbiamo prototipato un computer di piccole dimensioni che avrebbe eseguito una distribuzione Linux, quindi il sistema operativo Nitrux (che chiamiamo Nitrux) ha avuto origine da questa decisione. Inizialmente abbiamo chiamato questo piccolo computer QtBox perché intendevamo utilizzare Plasma 4 nella nostra distribuzione. Tuttavia, in seguito lo abbiamo cambiato in NXQ per evitare eventuali problemi con il nome e anche perché era strettamente legato al nostro marchio (NX). Nel 2014 sono stato invitato a unirmi anche al neonato KDE VDG, questo è stato il mio primo contributo a un progetto più ampio al di fuori di Nitrux, quindi dopo aver accettato, ho creato il tema dell'icona Breeze e il nuovo logo Plasma. Nel 2015, dopo aver partecipato a un incontro di KDE a Randa, in Svizzera, ho aggiornato anche il tema Breeze Plasma, che è in uso da allora.

Abbiamo quindi deciso di rilasciare Nitrux per x64 nel 2015; tuttavia, a causa di cambiamenti in Ubuntu (su cui era basato Nitrux) abbiamo interrotto lo sviluppo di quella versione a causa di un grave problema che abbiamo avuto con systemd e NetworkManager. Pochi mesi dopo abbiamo deciso di interrompere la produzione dell'NXQ e di interrompere qualsiasi piano per un nuovo modello in arrivo che era in lavorazione a causa dell'improvviso aumento di popolarità di mini-pc Android simili.

Fu solo nel 2017, due anni dopo l’interruzione dello sviluppo del sistema operativo Nitrux, che il sistema operativo Nitrux venne resuscitato. Anche Nitrux S.A. è stata ristrutturata con un nome diverso, Nitrux Latinoamericana S.C.

Un nuovo sviluppatore, Alexis Zubieta, si è unito a me e insieme abbiamo stabilito nuovi obiettivi, una nuova visione e un'intenzione originale per la distribuzione, abbiamo progettato e sviluppato Nomad Desktop, che chiamiamo livello di personalizzazione per Plasma 5. quell'anno, abbiamo iniziato a lavorare su un negozio di software per il sistema operativo Nitrux chiamato NX Software Center, inizialmente utilizzando Snaps (all'epoca non esisteva un frontend grafico per Snaps sul desktop, il nostro era il primo) quindi aggiungendo il supporto per AppImages e infine passando completamente all'utilizzo esclusivo di AppImages.

All'inizio del 2018 Haashir aveva lasciato Nitrux per continuare i suoi studi, quindi Alexis e io abbiamo cercato altri sviluppatori, il primo ad unirsi è stato Luis Lavaire e poi Camilo Higuita. A metà del 2018 si è unito a noi un altro sviluppatore, Anupam Basak. Nel corso del 2018 abbiamo iniziato a sviluppare MauiKit e ZNX (in maiuscolo znx). Alla fine del 2018, abbiamo iniziato a distribuire sia con il sistema operativo Nitrux utilizzando ZNX per la prima volta nella versione 1.1.0, sia con l'inclusione delle applicazioni MauiKit o Maui Apps in Plasma Mobile dopo Akademy 2018.

Nel 2019 abbiamo presentato VMetal un paio di settimane prima di partecipare ad Akademy 2019.

IF: Raccontaci qualcosa sulla distribuzione Nitrux Linux? Su cosa si basa?

Uri: La risposta breve è che Nitrux è costruito utilizzando i sorgenti di Ubuntu poiché utilizziamo alcuni dei loro strumenti nelle nostre immagini ISO come Casper o initramfs-tools. Tuttavia, non è basato su Ubuntu in alcun modo significativo come avveniva negli anni precedenti.

La risposta lunga è che non si basa su di esso poiché abbiamo apportato molte modifiche e intendiamo fare molto di più, ad esempio, in Nitrux, il gestore dei pacchetti non è parte integrante della distribuzione e dell'esperienza utente prevista. È un dato di fatto, nella build di sviluppo di Nitrux (che alla fine diventerà la nuova versione Stable), né APT né dpkg sono presenti poiché l'idea è quella di utilizzare AppImages per gestire il software e ZNX per manipolare il sistema operativo. Includiamo Homebrew come mezzo per colmare la lacuna in cui un programma potrebbe non essere disponibile come AppImage, ma Homebrew gestisce solo il software che installa e nient'altro.

Un altro esempio del motivo per cui Nitrux non è Ubuntu è che, ad esempio, potresti potenzialmente avere un'AppImage per utilizzare Pacman su Nitrux e questo, ovviamente, non significherebbe che Nitrux è basato su Arch. Inoltre, intendiamo rimuovere Systemd e (successivamente) modificare l'FHS in Nitrux. Abbiamo anche una ISO di Nitrux perfettamente funzionante che non utilizza Systemd né ha APT o dpkg, e c'è solo un problema che ci impedisce di rilasciarla.

In altre parole, non puoi aggiungere un PPA o un repository a Ubuntu e trasformarlo in Nitrux. Puoi aggiungere la nostra grafica (anch'essa realizzata da zero), ma quella non è Nitrux, ne è una parte (una parte superficiale), ma non è quella. Per dirla in un altro modo, avremmo potuto usare LFS o Gentoo, e avremmo comunque apportato le stesse modifiche, avremmo sviluppato gli stessi strumenti, il nostro stesso software, ecc. Per come la vediamo noi, ad esempio, è che non pensiamo che dovremmo concentrarci su cose come dover compilare tutto per rendere la nostra distribuzione “degna” di definirsi “indipendente” quando possiamo concentrare tempo e sforzi su altre cose più incentrate sull'utente. Sebbene disponiamo della nostra infrastruttura, dei nostri strumenti e utilizziamo un CI per generare le cose di cui abbiamo bisogno, come AppImages e i nostri ISO.

Quindi, come diciamo, “se ti aspetti che Nitrux sia “solo” un tema Ubuntu +, non è affatto quello che otterrai. Non è quello che stiamo facendo o intendiamo fare”.

IF: Cosa ti ha spinto a creare "un'altra distribuzione Linux"? Cosa rende unico Nitrux Linux?

Uri: Nitrux è una distribuzione unica nel contesto di come funzionano i tradizionali sistemi Linux desktop. Nitrux non è stato costruito attorno all'idea di utilizzare un gestore di pacchetti, che fosse APT, Pacman, DNF, Zypper, ecc., ma invece di utilizzare un formato di applicazione portatile. La ragione di ciò è che vogliamo che Nitrux sia un sistema convergente, non limitato solo a un desktop o un telefono ma che venga utilizzato anche per altri dispositivi integrati; IoT, TV, Infotainment, Elettrodomestici, ecc. L'uso di ZNX è proprio quello di avere un metodo per gestire in modo efficiente il sistema operativo e non occuparsi di alcun pacchetto, lo stesso con AppImages.

In realtà, il modo in cui funziona Nitrux è più strettamente legato a un sistema operativo mobile come Android, ad esempio, con Android, installi le app utilizzando un APK, il file APK contiene il programma e le sue dipendenze al suo interno non è necessario installare un altro APK tanto meno usare un gestore di pacchetti. Ottieni il file APK, installalo ed esegui il programma, e questa è la stessa idea con AppImage; ottieni AppImage, gli dai i permessi eseguibili e lo esegui.

Quando si tratta di gestire il sistema operativo, quando un dispositivo Android riceve un aggiornamento di solito è con il meccanismo OTA integrato, il produttore rilascia un aggiornamento, il telefono verifica che questo aggiornamento lo scarichi e lo installi riavviando ed entrando in modalità di ripristino e aggiornando l'immagine del sistema. Con Nitrux, la distribuzione è racchiusa in un file ISO (simile al file system.img di Android). ZNX esegue quindi un aggiornamento transazionale dell'ISO; non è coinvolto alcun gestore di pacchetti in questo processo (e nemmeno il riavvio per il ripristino). Potresti anche, letteralmente, copiare e incollare diversi file ISO Nitrux e avresti una versione nuova o vecchia della distribuzione.

Come le ROM Android, dove il sistema operativo è contenuto in un singolo file (system.img), anche Nitrux è autonomo come un singolo file (ISO).

Un'altra caratteristica di Nitrux è VMetal. VMetal è, come suggerisce il nome, una funzionalità di virtualizzazione integrata in Nitrux. VMetal funziona utilizzando le seguenti tecnologie: QEMU, KVM, VFIO, estensioni di virtualizzazione della CPU come Intel VT-d, VT-x o AMD-V, Vi e IOMMU.

Con Nitrux preferiamo mantenerlo semplice. Il sistema operativo è un singolo file (ISO); i nuovi programmi vengono aggiunti in un unico file (AppImage), i sistemi operativi utilizzati da VMetal sono file individuali (file IMG grezzi).

Poi abbiamo MauiKit in cui le applicazioni sono convergenti in base alla progettazione, una base di codice che funziona in Linux, Android, Plasma Mobile, Windows. Attualmente abbiamo 7 applicazioni create con MauiKit: Index, VVave, Nota, Station, Buho, Pix e Dialer. Tutti vedono lo sviluppo attivo e il framework e le applicazioni sono ospitati su https://invent.kde.org poiché alcuni di essi sono inclusi in Plasma Mobile per impostazione predefinita. Molti miglioramenti sono arrivati dal feedback che riceviamo dagli utenti che testano le applicazioni. Abbiamo un gruppo pubblico a cui gli utenti possono unirsi per fornire feedback qui.

Quindi è tutta una questione di portabilità.

IF: Raccontaci di più su ZNX? Nonostante il concetto interessante, perché non è diventato più popolare?

Uri: ZNX è un gestore del sistema operativo. Gestisce la durata dei sistemi operativi distribuiti con esso. ZNX non è un programma di installazione, un contenitore, un programma per eseguire il flashing di USB (non sostituisce "dd" o qualcosa di simile) o un software di virtualizzazione. Ciò che fa ZNX sono installazioni frugali. “Un'installazione frugale occupa solo una cartella in una partizione e il resto della partizione può essere utilizzato per qualsiasi altra cosa. Altre distribuzioni Linux, per esempio." Nel frattempo, le distribuzioni Linux tradizionali eseguono un'installazione completa, "Un'installazione completa è dove Linux occupa un'intera partizione e in quella partizione vedrai le cartelle /bin, /sbin, /opt, /etc/, /sys, /proc, /tmp, /dev, /usr, /run, /lib e altro."

Ad esempio, i gestori di pacchetti che funzionano utilizzando binari precompilati installano il software estraendo un archivio (deb, rpm, tar, ecc.) e posizionando il contenuto di quell'archivio nei percorsi corrispondenti nel filesystem e mantenendo un indice di dove quelli vengono individuati i file, anche i gestori di pacchetti basati sul codice sorgente fanno lo stesso, ad eccezione dell'estrazione di un archivio. Un programma di installazione come Ubiquity, Calamares (KPM Core), Anaconda e ogni altro programma di installazione funziona allo stesso modo, estraggono il contenuto del file SquashFS all'interno dell'ISO e posizionano il contenuto su una partizione del dispositivo di archiviazione.

Quindi, a questo proposito, ZNX è simile ad AppImage. Per installare un'AppImage, non usi un gestore di pacchetti; l'AppImage non viene estratta, dovresti semplicemente eseguirla. Lo stesso vale per ZNX, ecco perché non ci riferiamo a ZNX che "installa" un sistema operativo; usiamo invece la parola distribuire. Poiché ZNX non estrae il file SquashFS dall'ISO, avvia direttamente l'ISO e i dati vengono conservati sul dispositivo di archiviazione utilizzando OverlayFS. ZNX copia quindi l'ISO solo in una directory nel dispositivo di archiviazione (STORE).

Ancora una volta, rispetto ad Android, quando l'utente ripristina un dispositivo alle impostazioni di fabbrica, i dati dell'utente vengono cancellati. Tuttavia, il sistema operativo non viene reinstallato in nessun momento, anche ZNX lo fa, può rimuovere i dati dell'utente dall'overlay, reimpostando così il sistema operativo senza alcuna necessità di reinstallare il sistema operativo. Tuttavia, a differenza di Android, dove non esiste un modo semplice per eseguire il downgrade, ZNX consente all'utente di ripristinare una versione precedente del sistema operativo. Quando si tratta di aggiornamenti, ZNX li esegue in modo transazionale, eseguendo aggiornamenti delta sui file ISO, in modo da risparmiare tempo e larghezza di banda.

ZNX può anche ripristinare la partizione ESP e sfrutta anche la gestione del bootloader. Se un ISO è presente nella directory STORE, verrà visualizzato automaticamente nel menu di avvio ZNX; se non lo è, non lo farà. Anche ZNX è indipendente da init e utilizza GRUB per avviare gli ISO.

ZNX è, in realtà, piuttosto semplice.

Credo che uno dei motivi per cui ZNX non è diventato più popolare è che, poiché tutti sono così abituati al concetto di gestori di pacchetti e installatori, ZNX è loro estraneo. ZNX sta agli installatori del sistema operativo come AppImage sta ai gestori di pacchetti. Ci sono stati casi in cui le persone chiamavano ZNX addirittura un "sistema di avvio proprietario" quando ciò era semplicemente sbagliato. Può darsi che ZNX rappresenti una svolta così radicale rispetto al modo in cui funzionano le distribuzioni Linux tradizionali, soprattutto nel desktop, che l'idea alla base non è compresa anche se stiamo utilizzando un modello già esistente (e funzionante).

Molte persone sembrano anche pensare che, a causa della specializzazione di Nitrux in AppImages, ZNX non consentirebbe loro di utilizzare un gestore di pacchetti se un'altra distribuzione oltre a noi lo usasse. Anche questo non è corretto, poiché abbiamo ISO del sistema operativo elementare e KDE Neon che possono essere distribuiti con ZNX dove il gestore dei pacchetti è perfettamente funzionante e, a parte il fatto di non avere un programma di installazione, non c'è differenza rispetto all'installazione utilizzando i relativi programmi di installazione.

Un altro motivo per cui credo che ZNX non sia popolare è che ZNX esegue le sue operazioni in modo automatizzato, ad esempio il partizionamento non è gestito dall'utente ma da ZNX, non c'è creazione dell'utente, selezione della lingua, selezione della tastiera, fuso orario la selezione in quanto un installatore tradizionalmente li gestisce. Principalmente perché, ancora una volta, come in Android, tutta la configurazione viene eseguita dal sistema operativo avviato e mai durante l'installazione perché non è prevista alcuna installazione. Quindi, ancora una volta, una deviazione piuttosto significativa dal modo in cui funzionano le tradizionali distribuzioni Linux desktop.

Da questi cambiamenti significativi portati da ZNX è che tutti si aspettano di installare i sistemi operativi in una configurazione multi-boot tradizionale, ad esempio una partizione per Ubuntu, un'altra per Fedora, un'altra per openSUSE, un'altra per Arch e così via. Questo non è il caso di ZNX, poiché l'idea è di avere solo una partizione in cui si trova ciascun file ISO (ovvero ciascun sistema operativo) e quindi selezionare quale avviare nel menu di avvio ZNX. Quindi una partizione, con ciascun sistema operativo in una directory separata all'interno di STORE, con i propri dati all'interno della struttura di directory corrispondente, a questo proposito ZNX è in qualche modo simile al gestore di pacchetti Nix nel modo in cui Nix memorizza i dati di ciascun programma nella sua struttura di directory.

L'unico requisito rigido che ZNX ha attualmente è che i file ISO debbano supportare EFI e l'unica limitazione è la mancanza di supporto per Secure Boot. Tuttavia, anche in questo caso, siamo completamente aperti a chiunque contribuisca con codice che abiliti il supporto del BIOS legacy e il supporto dell'avvio sicuro.

ZNX non è affatto difficile da usare. Tuttavia, trarrebbe vantaggio da una GUI migliore, quindi potrebbe anche darsi che le persone nuove trovino difficoltà a causa di ciò, sebbene la GUI ZNX esista, ecco perché stiamo invece lavorando per integrarla nel nostro centro software.

Alcune persone sembravano anche pensare che ZNX fosse un'alternativa Docker; su quello, non sono sicuro del perché? Suppongo che da parte nostra utilizziamo il termine "distribuzione".

Sicuramente ZNX ha avuto problemi, principalmente perché AppImage non funzionava come previsto, poiché è così che la distribuiamo. Tuttavia, abbiamo già risolto praticamente tutti questi problemi e funziona ovunque abbiamo effettuato i test.

Recentemente abbiamo anche rivelato che il motivo per cui abbiamo sempre detto che la nostra ISO non poteva essere flashata su una USB non era un problema correlato a ZNX ma piuttosto a un componente dei nostri strumenti, mkiso. Usiamo mkiso per generare i nostri file ISO; sfortunatamente, mkiso ha creato file ISO che non si avviavano su computer che non erano UEFI classe 3 (Intel 6a generazione+ o AMD Ryzen+). ZNX, tuttavia, consentirebbe l'avvio dell'ISO nei computer più vecchi purché supportino EFI (chipset Intel di seconda generazione o AMD PII/serie 800). Da allora abbiamo corretto mkiso e i nostri file ISO ora possono essere avviati nei computer EFI meno recenti quando vengono flashati su una USB. Forse questo era il motivo per cui alcune persone pensavano che ZNX fosse come un sostituto "dd" o qualcosa come Etcher. Sicuramente, puoi distribuire un sistema operativo su una USB con ZNX e sarebbe una USB avviabile, a questo proposito è simile a programmi come MultiBootUSB o YUMI con l'eccezione che i dati dell'utente vengono archiviati direttamente sul dispositivo utilizzando OverlayFS invece di utilizzare un file poiché ciò significa che non sei limitato allo spazio di archiviazione assegnato al file persistente ma allo spazio libero complessivo del dispositivo di archiviazione.

Tutto sommato è un mix di confusione e incomprensioni che credo sia il motivo per cui ZNX non è popolare.

Che tipo di base di utenti ti rivolgi a Nitrux?

Intendiamo rivolgerci agli utenti che sono stati notevolmente esposti al modo in cui i sistemi operativi mobili si comportano e funzionano.

Hai una forte attenzione su AppImage. Perché?

AppImage fornisce un modo semplice per ottenere software. Scaricalo ed eseguilo. Come prima, è esattamente così che ottieni app sui sistemi operativi mobili. Questa facilità d’uso è ciò che non vediamo l’ora di ottenere. Non c’è dubbio che Flatpak e Snapcraft siano più popolari; hanno il sostegno di due grandi aziende e comunità, quindi è invariabilmente una battaglia ardua.

AppImage è anche indipendente da init, il che è molto importante per noi poiché non abbiamo intenzione di continuare a utilizzare Systemd, il che significa che né Flatpak né Snaps saranno disponibili in Nitrux, non che lo siano nelle nostre attuali ISO. Non ha bisogno né utilizza demoni per funzionare, le AppImage non dipendono da altre AppImage per funzionare, non sono richiesti nemmeno runtime e non è legato al sistema init come menzionato.

Molte persone sembrano pensare anche che ad AppImages manchi una funzionalità sandbox, l'integrazione con il desktop o persino la possibilità di aggiornarle. Non è corretto, AppImages può essere inserito in sandbox con Firejail (programma SUID che riduce il rischio di violazioni della sicurezza limitando l'ambiente di esecuzione di applicazioni non attendibili utilizzando spazi dei nomi Linux). L'integrazione con il desktop può essere eseguita con più programmi come AppImage Daemon, AppImage Launcher o AppImage Desktop Integration (sviluppato da noi). Infine, AppImages può essere aggiornato utilizzando AppImageUpdate, che aggiornerà i file utilizzando aggiornamenti transazionali delta (come fa ZNX), che includiamo tutti per impostazione predefinita.

Penso che l'unico "svantaggio" sia la dimensione dei file in alcuni casi, ma è anche il caso di dove si intende eseguire AppImage?. Ad esempio, un router non avrebbe centinaia di GB di spazio di archiviazione o addirittura dozzine, ma allo stesso tempo non esiste un motivo reale per avere un'AppImage desktop come LibreOffice.

Tuttavia, questo non è un problema su qualsiasi computer desktop o laptop ragionevolmente moderno, che molto probabilmente avrà centinaia se non migliaia di GB o anche sulla maggior parte dei telefoni in cui la memoria interna raggiunge le centinaia e anche quelli che supportano le schede SD hanno accesso. a centinaia di GB.

In tale nota, un'AppImage ha infatti lo scopo di includere ciò di cui il programma ha bisogno per essere in grado di essere eseguito e che non dovrebbe essere nel sistema operativo di destinazione. Ad esempio, l'AppImage di Index (file manager Maui) è di soli 50 MB perché è pensato per essere eseguito su un sistema operativo desktop completo (desktop come nel tipo di sistema e non come nel fattore di forma), mentre se si intendeva AppImage per essere eseguito su un server dovrebbe essere molto più grande poiché il sistema operativo del server non dovrebbe avere alcun software grafico, tanto per cominciare.

Allo stesso tempo, il fatto che AppImage includa tutto ciò di cui ha bisogno è ciò che lo fa funzionare non solo in una particolare distribuzione Linux ma su molte altre.

Sicuramente, ottenere un file casuale da Internet potrebbe non sembrare una buona idea, ma si stanno facendo sforzi per fornire un archivio centralizzato per AppImages come AppImageHub.com.

SE: vedo un paywall durante il download di Nitrux. Perché? Quale (altro) modello di business hai?

Il motivo è relativamente semplice: Nitrux è un business, non un’organizzazione no-profit, e le aziende devono generare entrate per crescere e continuare lo sviluppo. Come per ogni attività commerciale, ci sono delle spese, anche se sviluppiamo software gratuito e open source. Dal pagamento dei nostri server ai nostri stipendi e alle spese di viaggio per partecipare agli eventi legati al FOSS. Pertanto siamo sinceri al riguardo.

Non inseriamo annunci sul nostro sito Web o sul nostro sistema operativo e non inviamo e-mail di marketing, non raccogliamo dati utente, non includiamo software di terze parti, non tormentiamo gli utenti con chiavi di licenza, non addebitiamo alcun costo agli utenti per il supporto di Nitrux. Inoltre, il 99% del nostro lavoro è disponibile sotto forma di codice sorgente o distribuito come AppImage senza alcun costo sulla nostra organizzazione GitHub, oppure è ospitato nell'infrastruttura KDE come nel caso di MauiKit e delle Maui Apps. Contribuiamo anche a monte, come facciamo con KDE con Kirigami e AppImage (il nostro ex sviluppatore, Alexis Zubieta, ha sviluppato libappimage durante il suo periodo con Nitrux e attualmente fa parte del team che sviluppa AppImage e tutto il software correlato).

Direi che alcune persone, tuttavia, sembrano pensare che, poiché stiamo realizzando una distribuzione Linux o poiché sviluppiamo software gratuito e open source, non dovremmo essere costretti a farci pagare per il nostro lavoro perché nessun altro lo fa, o peggio , che non possiamo. Né la FSF né l’OSI vietano la commercializzazione del FOSS, quindi è un argomento non valido, proprio perché la F in FOSS non sta per Gratuito (a costo zero); in realtà sta per Libertà e il nostro software è conforme a questo. Non è una maggioranza, ma succede.

In tutta certezza, comprendiamo che non tutti possono permettersi di pagare, motivo per cui offriamo le build Development e Minimal a costo zero, oltre alla fonte.

Pagando per scaricare l'ISO, gli utenti contribuiscono a pagare i nostri stipendi e la nostra capacità di assumere più persone, creare più software e continuare a perfezionare quello che abbiamo.

Oltre a pagare per accedere al download della ISO Stable, accettiamo anche donazioni tramite PayPal o con crypto, e abbiamo anche una pagina Patreon e Liberapay.

IF: Cerchi volontari, sviluppatori o supporto finanziario di qualsiasi tipo? Qualche messaggio per i lettori?

Uri: Lo siamo sempre. Se qualcuno vuole aiutare, l'aiuto è più che benvenuto. Al momento non abbiamo posizioni aperte poiché abbiamo appena assunto un nuovo sviluppatore, ma speriamo di potercene permettere un altro in futuro.

Nitrux attualmente è composta da 4 membri che presto diventeranno 5:

• Uri Herrera (io)

• Luis Lavaire

• Camilo Higuita

• Anupam Basak

• Ademir Tejada (nuovo)

Lavoriamo tutti a tempo pieno poiché lo sviluppo di tutti i nostri software è il nostro lavoro, ma lavoriamo da remoto poiché siamo tutti in paesi diversi.

Stiamo cercando un sostegno finanziario, come ho già detto, reinvestiremo direttamente quei soldi nello sviluppo di tutto ciò che facciamo.

Tutto quello che posso chiedere ai lettori di It's FOSS è di provare Nitrux e segnalare problemi; è così che possiamo migliorarlo.

Se vuoi essere aggiornato su quello che facciamo, seguici sui social media come Twitter, Instagram e Telegram. Dovresti anche leggere il nostro blog per aggiornamenti più dettagliati. Naturalmente, puoi contribuire al nostro repository GitHub.