Salve a tutti,
Sono un ex analista/programmatore web il quale ha una passione per linux ormai da diversi anni.
Ho usato molte distro linux, il che probabilmente è qualcosa che facciamo un po’ tutti.
Diciamoci la verità, le distro linux, più o meno, fanno tutte le “stesse cose”.
Il mio “distro hopping” era finalizzato più che altro a vedere come quella distro faceva “queste cose”.
Girovagando in questo mondo, ho sempre visto che esistono tantissime distribuzioni linux, ma di italiane ne ho
trovate poche e sono sempre le solite derivate da debian/ubuntu, arch e forse altro.
A questo punto mi sono chiesto il perchè non abbiamo una distro completamente italiana.
In pratica, come esiste Arch che è nata in Canada (pacman), oppure Void Linux che è nata in Spagna (xbps)
e molte altre, perchè non esiste una distro Italiana con il proprio gestore dei pacchetti
scritta completamente da zero ?
Bene, spinto da questo desiderio, ho iniziato a svilupparla.
Sono quasi a metà strada con lo sviluppo del gestore dei pacchetti e del relativo script per costruire i pacchetti
e devo dire che sono soddisfatto di quello che ho fatto al momento.
Già funzionanti invece sono il sistema di init chiamato “Unitd” il quale usa una libreria chiamata “Ulib”.
Tutto scritto da me in C and POSIX shell script. Non voglio altri linguaggi come Python e altro.
Questi sono i link:
Unitd: GitHub - pandom79/Unitd: Unitd init system
Ulib: GitHub - pandom79/Ulib: C library
Vi andrebbe di diventare sviluppatori/manutentori di una distro linux completamente italiana?
Cosa ne pensate?
Saluti
Forse perché non si è sentita la necessità ad averne una italiana?
Perché creare una distro e un gestore di pacchetti comporta uno sforzo notevole (soprattutto per creare e mantenere un repository dei pacchetti nei formato del gestore dei pacchetti) e quasi sempre, non ne vale la pena.
Perché hai creato un nuovo sistema di init e non ti sei appoggiato a qualcosa di esistente come systemd o alternativa?
Perché non in un linguaggio di programmazione compilato più comodo (e recente?) come rust o go o c++ o altro?
Sinceramente no
Mi pare sia un reinventare la ruota senza innovazione o un vantaggio.
E allora quale necessità hanno sentito gli sviluppatori di decine e decine di distro linux nate dopo Slackware o Debian che sono le più longeve e che offrono praticamente tutto? Forse semplicemente perchè essendo programmatori hanno voluto semplicemente scriversi i loro tools seguendo le loro idee di programmazione e usarli anche se a conti fatti fanno tutte le stesse cose ma in maniera diversa.
Questo sforzo notevole che tu dici, come mai gli altri sviluppatori di altri paesi/distro non l’hanno avvertito ? Io sto a quasi metà del lavoro sul gestore dei pacchetti. E’ stato molto più complicato scrivere il sistema di init.
Perchè non sono d’accordo sulla filosofia di systemd. Per me un sistema di init deve solo trattare i processi e niente altro. Systemd fa tutto ed io non sono d’accordo. Per tua informazione Unitd è l’unico sistema di init che offre un accurato monitoraggio dei processi utile sopratutto per i server su cui girano demoni critici.
Perchè per me il C rimane il miglior linguaggio per applicazioni di questo tipo.
Ancora una volta, ti rispondo come nelle precedenti. Cosa ha portato Arch, Void Linux e tantissime altre distribuzioni di svariati paesi che non aveva già Slackware o Debian? Direi niente, se non un modo diverso di fare le stesse cose. Un’eccezione potrebbero essere le distro immutabili, ma a me non piacciono ed aggiungo che con Btrfs o Zfs e i relativi snapshots si puo’ emulare quello che è la loro caratteristica principale.
Quella di avere delle caratteristiche tecniche o funzionali o ux diverse. Tipo essere più semplice(zorin), più facile da gestire per i competenti(archlinux), immutabilità(NixOS), dichiaratività(GuixOS), minimalismo(coreos). L’italianità non mi sembra un buon motivo per sviluppare un sistema operativo da zero.
L’hanno avvertito ma poi hanno deciso che ne valeva la pena. Comunque ne riparliamo quando comincerai a dover fare tanti pacchetti e mantenerli.
Non è una questione di complessità. E questione della quantità di lavoro da fare
Perché non sei partito da qualcosa di esistente come openRC?
La questione paesi è irrilevante. Arch è stato inventato perché le alternative. Void Linux non lo so.
Hai citato tutte cose che, in una distro linux, almeno una, deve esserci obbligatoriamente.
Nel senso che dopo che hai scritto una distro, per forza di cose, potrà risultare difficile o facile, minimale o meno, immutabile o tradizionale e altro ancora.
Per questo motivo ho scritto di voler una distro italiana perchè vorrei che il team fosse Italiano (all’occorrenza reclutare anche persone di altra nazionalità), ma anche per poter dire al mondo linux: “Ehi, ci siamo anche noi!”
Comunque la distro che vorrei sviluppare deve essere facile per i competenti, leggera e veloce, diciamo come Arch Linux o Void linux ma con un doppio rilascio (Fixed and rolling) come OpenSUse (Leap e Tumbleweed) o Slackware (attualmente 15 e current).
Se a questo aggiungi un installer grafico e un tool grafico che gestisce i pacchetti o le unità di Unitd, potrebbe diventare anche facile come Zorin o altro.
Tutte queste distro, le conosco molto bene, soprattutto Void Linux su cui ci ho proprio lavorato.
Su Arch, OpenSuse e attualmente Slackware sono stato e sono un packager.
Prendiamo ad esempio Arch e Void, cosa hanno di diverso? Macroscopicamente parlando, queste distro sono uguali, cio’ che le differenzia, sono i tools e il modo con cui “fanno le cose”.
Ovviamente, Void ha il suo gestore dei pacchetti, il suo modo di creare i pacchetti e il suo sistema di init chiamato “Runit” e altro.
Cio’ significa che, microscopicamente parlando, ovvero “sotto al cofano”, sono molto diverse perchè il team di Void linux, essendo programmatori, hanno voluto sviluppare i loro tools che seguono le loro idee di implementazione.
Tornando a noi, se per te una distro scritta completamente “from scratch” (Package manager, Build script ed eventuale installer e iso maker) con un sistema di init unico nel mondo linux per le features che offre,
ti sembra inutile, allora cosa dovremmo pensare di tantissime distro blasonate come Manjaro, che è praticamente Arch, da cui hanno clonato i repositories semplicemente per allungare i tempi di rilascio per poter testare meglio i pacchetti in quanto Arch è considerata troppo “bleeding edge” e aggiunto qualche tools ?
Clonare i repositories, significa comunque fare manutenzione su un qualcosa che in pratica è un clone!! Seguendo il tuo discorso, queste distro dovrebbero essere inutili, eppure ci sono e ce ne sono tante così, soprattutto debian based. Per quest’ultima poi…se ne vedono di tutti i colori.
Per quest’ultime, sono completamente d’accordo con te, ma io sto scrivendo tutto da zero seguendo quelle che sono le mie idee e, se sarà, quello del team.
Quello che vogliamo sarà una nostra scelta!
Bene, cosa è scattato per quelle distro precedentemente citate per cui poi hanno deciso che ne vale la pena essendo praticamente dei cloni?
Per tua informazione, il sistema base della mia distro è gia scritto e compilato. So molto bene cosa significa.
Non posso fartelo vedere perchè i repositories github del gestore dei pacchetti, build script e pacchetti sono privati e verranno pubblicati solo quando partirà ufficialmente.
No no, fidati che scrivere un sistema di init multithreads in c è complesso soprattutto se quel processo è un certo “PID 1”.
Per curiosità, sei un programmatore C?
Per quanto riguarda i pacchetti, lo sforzo iniziale dovrebbe essere maggiore, perchè aggiornare il build script, nel 90% dei casi è abbastanza veloce come operazione, poi ovviamente c’è il tempo di compilazione da aspettare…gcc richiede almeno un’ora e mezza (sul mio portatile almeno) ma almeno ti riposi nel frattempo.
Per curiosità, hai mai pacchettizzato per qualche distro linux ? Se sì, quale ?
Perchè volevo fortemente un monitoraggio dei processi che su Linux non esiste. L’ho fatto io.
Unitd monitora accuratamente i processi, utile soprattutto per i server su cui girano demoni critici.
Tiene traccia di tutto quello che succede su un processo.
Immagina questo scenario:
Sei un azienda e hai bisogno di un server su cui installare il tuo servizio (Data base, application server e altro).
Adesso, immagina che qualcuno o del codice malevolo (virus) “uccide” il tuo servizio (stiamo viaggiando con la fantasia, ma credimi alle aziende queste cose succedono avendo lavorato in quel settore per 13 anni, ne so qualcosa).
A questo punto, la maggior parte dei sistemi di init faranno ripartire il servizio.
La caratteristica di far ripartire un servizio “Restart” è molto comune fra i sistemi di init su Linux, ma nessuno di questi ti dice che quel servizio è stato “ucciso”. Cio’ significa che tu eseguirai il comando per verificare lo stato e vedi che risulta “In esecuzione” perchè è ripartito, ma non sai che è ripartito a seguito di un KILL signal.
Far ripartire un data base o altro non è così indolore, quel KILL signal sta causando un disservizio all’azienda che è completamente ignara di quello che sta succedendo.
Immagina se quel kill signal viene inviato ogni 5 minuti. Cosa succede?
Sul mio sistema di Init (Unitd), quando verificherai lo stato del processo, vedrai una history su quel processo con tutte le informazioni del caso. Il processo è ripartito? Quale era il suo PID ? Quando tempo è durato? Quale segnale ha ricevuto? Qual era il suo codice di uscita ?
Unitd ti da queste informazioni.
Ad un amministratore di sistema, queste informazioni saranno preziose, in quanto sarà in grado di capire che qualcosa di strano sta succedendo su quel processo e potrà prendere i dovuti provvedimenti.
Nessun sistema di init al momento ti da questa funzionalità, nemmeno Systemd. Forse dopo che hanno visto il mio, lo aggiungeranno ai loro, se non l’hanno già fatto perchè l’ho comunicato alla community circa un anno fa.
Ogni software quando si sviluppa, dovrebbe anche vedere il lato sicurezza che per un sistema di init puo’ essere solo il monitoraggio.
Un’altra volta ancora, quale alternativa sarebbe Arch rispetto a Slackware visto che quest’ultima offre anche il rilascio rolling proprio come Arch con il ramo current? Ancora una volta: i tools utilizzati e di conseguenza un modo diverso di fare le “stesse cose”.
Non hai capito ancora che la questione paese è perchè vorrei che anche l’Italia facesse qualcosa di proprio in questo mondo.
Spero sia chiaro.
Ah, quindi una distro che è praticamente un clone, con tutto lo “sforzo” (come dici tu circa la gestione dei repo) richiesto per gestire dei loro repositories la quale è nata semplicemente per allungare i tempi di rilascio, non è inutile, ed io che sto scrivendo tutto da zero seguendo quelle che sono le mie idee (o di quelle di una eventuale community preferibilmente ialiana) ti sembra inutile…
In pratica, ti stai contraddicendo da solo!
Quale sarebbe stata questa necessità del Team di Manjaro di allungare i tempi di rilascio quando già esistevano altre distro come Fedora e altro che risolvevano il problema del “beeding edge”?
Se non ci arrivi, te lo dico io: perchè in Austria (principalmente perchè è nata lì), hanno voluto creare una loro distro. Nient’altro.
Fedora esiste dal 2003, Manjaro è nato nel 2011!
Se non conosci le distribuzioni non scrivere inesattezze.
Bene, quindi dovresti sapere che quando si lancia una compilazione c’e’ tempo morto durante il quale ci si puo’ riposare…
e tu invece dici che richiede uno sforzo notevole.
Ancora una contraddizione!
Potrei fare la domanda al contrario. Perchè utilizzare tool esterni quando ero perfettamente in grado di scrivere una feature simile, evitando risorse e dipendenze inutili in un sistema base della distro che è stato progettato per essere minimale.
Un semplice gestore dei segnali è stato sufficiente per implementare questa feature.
Scusa, ma è una domanda che non ha senso.
Ma che scrivi!
Ma se Arch fino a qualche mese/anno fa non aveva neanche un installer (tra l’altro quello che esiste adesso non è supportato ufficialmente ma è stato creato dalla community) mentre Slackware ce l’ha da 20 anni! Cio’ significa che su Arch, l’installazione devi farla tutta da riga di comando.
Slackware viene installato in blocco rendendo proprio la vita più semplice circa le dipendenze in quanto è gia tutto lì.
Il suo gestore dei pacchetti è un semplice script, su Arch c’è pacman scritto in C.
Gli slackbuilds sono dei veri script shell molto più facili da scrivere mentre su Arch ci sono i PKGBUILD che richiedono conoscenza delle funzioni che usa.
Me se non conosci, non scrivere inesattezze!
Ringrazio per la domanda a cui risponderei con diversi cappelli
Punto di vista della crescita personale: fallo
Ti consiglio vivamente di fare quello che stai facendo, ovvero, rifare le cose da capo, perché se hai energia per farlo, questa cosa assurda, ovvero capire come pacchettizzare progetti upstream a caso in un proprio formato esoterico, ti costringerà a mettere il naso in una marea di progetti e imparerai una montagna di cose. Questa esperienza ti rimarrà per tutta la vita, a prescindere di qualsiasi cosa capiterà a questo progetto.
Però non farlo per i motivi che hai detto tu
Il mondo è piccolo e non è molto sostenibile desiderare di creare una distribuzione “nata in Italia” solo per dire che sia “made in Italy” o qualcosa del genere di altrettanto nazionalista o campanilista. Questo è un segnale di allarme. Comunque ci sta, ci sono altre sfumature leggermente più sostenibili:
avere una community italofona attiva, per parlare in Italiano (ci sta, come Devuan e openmamba che hanno i core developer italiani, oppure come Debian e Ubuntu che hanno fortissime community italofone)
oppure, avere una distribuzione che copra le “necessità degli italiani” (questa cosa ha senso solo per le scuole, secondo me. Ma c’è già SO.Di.Linux, etc.)
Ricapitolando, prova a contribuire a Devuan, forte community italofona su Telegram:
C’è anche openmamba, molto più esoterica, (non so il suo POV su systemd però) completamente direi gestita da una persona che parla Italiano:
C’è So.Di.Linux, nata in Italia per le scuole in Italia, naturalmente con APT però. Questa non mi aspetto che ti piaccia. Mi aspetto però ti interessi il punto a cui sono arrivati, dopo quanti sforzi, e dopo quanti anni e compromessi, per capire se davvero rifare una cosa orientata a questo, ma da zero, senza APT, aiuterebbe o meno:
C’è anche il meraviglioso progetto FUSS, nato in Italia (che citerei per primo), usato tantissimo, sempre orientato alla scuola, sempre APT, e che meriterebbe contributori. Questo guardalo.
E questo non è un elenco finito, sono solo 4 a caso. Quindi tieni sempre presente XKCD 927
Sulla felicità personale
La vita è breve è ti consiglio comunque, fortemente, di contribuire comunque a qualcosa di già esistente, principalmente perché imparerai comunque un sacco di cose, e raggiungerai comunque i tuoi obiettivi, e se ti annoi il progetto continuerà lo stesso e ti avvantaggerai comunque.
È impossibile impedire ai cantanti di produrre nuove canzoni d’amore, quindi comunque fai quello che ti pare però non ti aspettare che @amreo userà domani la tua distribuzione in produzione ciaau e buon software libero!
Prima mi consigli di fare quello che sto facendo e poi la definisci “assurda”…Mah
Ma se è assurda, allora perchè hai riaperto questa discussione che invece è “ridicola” per quello che sto leggendo.
Fai pace col cervello.
Ma se io sono Italiano e riesco a far partire questo progetto, la distribuzione, secondo te, dove nascerà ? In Giappone !?
Opensuse non è nata in germania con il loro gestore zypper? OpenMandriva e altre, non sono nate in Francia con i loro tools?
Addirittura, per scrivere una cosa del genere mi state dando del nazionalista!
Ma che vi siete fumati in questo forum!!
Non ho bisogno di fare un progetto open source per la “felicità personale”.
Ne ho fatti talmente tanti, che se te li dico, farai fatica a crederci…ma non di quelli open source ma di quelli dove ci vogliono i soldi…ma molti soldi.
ma chi se ne frega!
Comunque, hai riaperto una discussione in cui mi stai semplicemente suggerendo cosa fare e per quali motivi farla.
Ti ringrazierei pure ma è completamente inutile.
Passo e chiudo.
Buona fortuna!
Avere una distro basata su arch che però è più semplice per utenti esperti. Fedora diversamente da arch non ha AUR.
Sì, ma non per ragioni di nazionalità, o quantomeno non solo per questo.
Sì grazie ma la quantità di tempo rilevante è quello della scrittura dei vari file di build/pacchetizzazione per la prima volta, e la successiva manutenzione affinché siano indicate tutte le dipendenze e gli utenti non si lamentino dell’installazione
Per sforzo notevole intendo la scrittura dei vari script di installazione/pacchettizzazione per tutti i pacchetti che intendi fornire, per poi tenergli aggiornati.
Per ridurre la quantità di codice da mantenere, e concentrarsi di più sulle differenze.
Certo. Per semplicità qui intendo la tendenza a non nascondere le cose e sovracomplicarle inutile. Arch è semplice (per i competenti) durante l’installazione in quanto la procedura è ben documentata, e sono circa 10-20 comandi (per quanto mi ricordi).
Ho detto qualcosa sulla pacchettizzazione su arch o slackware?
Comunque non ho altro da dire se non buona fortuna. Non ho capito perché mi devi attaccare a livello personale. Comunque sì, è una cosa per me assurda ma i migliori progetti sono nati da cose apparentemente assurde. Chissà. Ciau!
