6 luglio 2015

Intervista a Franco (nextime) Lanza su Devuan, il fork di Debian senza systemd



Grazie all'intercessione di +Alessandro Renzi nonché all'aiuto della community di +Marco's Box   che si è data da fare per preparare le domande quest'oggi abbiamo il piacere di intervistare Franco (nextime) Lanza, membro fondatore del team di Devuan, il fork di Debian Linux che si prefigge di fornire una versione di Debian senza systemd.
Scopriamo di più su questa distro e sul perché per alcuni utenti è importante poter avere la massima flessibilità e non legarsi a stretto filo con systemd.
Buona lettura e mi raccomando, non dimenticatevi di lasciare un commento in calce all'articolo oppure nelle discussioni collegate su Google+ e Facebook



1) Chi siete e come vi è venuto in mente di realizzare il progetto?
Il gruppo iniziale che ha dato vita al progetto, quello che va sotto il nome “Veteran Unix Admins”, e’ un collettivo formato da sistemisti ed informatici per lo più’ italiani che da alcuni anni si incontra, con lo scopo dichiarato di allietarsi tra simili, in un forum privato.

Il nome del gruppo proviene da qui: http://www.infoworld.com/article/2623488/unix/nine-traits-of-the-veteran-unix-admin.html

Da questo un piccolo gruppo di persone (qualche decina sul migliaio abbondante di membri che conta il gruppo), tutti sistemisti o comunque professionisti, alcuni dei quali anche Debian Developers, tutti utenti Debian, hanno deciso di avanzare prima l’ipotesi di un fork tramite il sito debianfork.org, e successivamente di procedere al fork vero e proprio lanciando il progetto Devuan.

Oggigiorno al gruppo iniziale si sono aggiunti altri sviluppatori, contributori o semplici sostenitori esterni che, chi piu’ chi meno, hanno preso parte allo sviluppo attivo del progetto.


2) Cosa non vi piace di systemd?
Non ci piace continuare a doverne parlare, questa continua connotazione “anti-systemd” ci va davvero stretta, Devuan non e’ un progetto “anti-systemd”, certo, systemd è stata se vogliamo “la goccia che fa traboccare il vaso”, ma il progetto va ben oltre il semplice antagonismo a systemd, sebbene la sua eliminazione sia il primo traguardo che ci siamo prefissati.

Se proprio devo rispondere alla domanda così come è posta, ad ogni modo, devo dire che non esiste una risposta uguale per tutti, i motivi per cui alle persone non piace systemd sono molti, alcuni anche opinabili per carità, ma non siamo tutti uguali in questo. Posso rispondere quindi per lo più a titolo personale a riguardo.

Personalmente iniziai ad usare Debian nel lontano ‘96, e, quando scelsi di usare Linux e Debian in particolare, li scelsi perché seguivano la filosofia UNIX e, grazie al sistema GNU, anche i principi di sviluppo KISS, a mio avviso due dei principali ingredienti, insieme alla filosofia del software libero, che hanno poi nel tempo permesso a GNU/Linux di divenire quello che è oggi, il primo sistema operativo in assoluto al mondo per diffusione, ed in particolare il dominatore incontrastato in ambiente server ed embedded.

Oggi l’introduzione di systemd fa venire meno queste due caratteristiche, il sistema diventa “meno UNIX” e “meno KISS”. Non è che non mi piaccia systemd in pratica, è che io ho scelto di usare un sistema diverso, e non voglio che mi sia imposto di cambiare per qualcosa che non ritengo essere una evoluzione positiva ma, al contrario, ritengo essere un’involuzione.

La nuova generazione di sviluppatori, di cui Poettering fa parte, sembra aver perso la memoria storica del perché UNIX ha determinate caratteristiche e del perché sono state fatte determinate scelte implementative che, superficialmente, a volte possono sembrare inferiori, ma che sul lungo periodo hanno ampiamente dimostrato di essere la via corretta. Forse è anche colpa “nostra”, dove per “noi” intendo “la vecchia generazione” di informatici, che non abbiamo saputo tramandare questa memoria storica, ma al di la di chi abbia la colpa, questo fa si che la storia si ripeta e si compiano di nuovo errori che erano già stati ampiamente risolti nel passato, e systemd rappresenta, per me, uno di questi errori. O meglio molti di questi errori in una volta sola.

A questo poi aggiungiamo anche che la forte interdipendenza dei componenti di systemd nel suo insieme, oltre che la dimensione stessa del solo componente di init, fanno si che il sistema finale abbia un footprint in memoria maggiore, e questo se da un lato in molti sistemi puo’ essere ignorato, in alcuni ambienti e’ un problema, di conseguenza il potenziale parco di utilizzo di una distro che utilizza systemd si riduce sensibilmente.


3) Perché affermate che systemd non è unix se in realtà è composto da vari moduli?
Un sistema UNIX ha tante caratteristiche, tra le quali la modularità. Ma questa da sola NON è sufficiente, oltre alla modularità è necessaria l’indipendenza.

In un tipico sistema UNIX troviamo tanti piccoli componenti che svolgono un compito solo e lo svolgono al meglio, e tentano di farlo nella maniera più indipendente possibile dagli altri componenti presenti nel sistema.

Questo, a sua volta, permette di dare reale potere al sistemista, che è in grado di “piegare”, “addomesticare” il sistema alle proprie esigenze, scegliendo in prima persona il mix di componenti più adatti allo specifico compito che dovrà svolgere la macchina che sta amministrando.

Systemd è si modulare, ma i suoi moduli sono tutti strettamente legati fra loro e, per svolgere appieno il loro compito, necessitano anche anche molti componenti esterni si leghino a systemd. Questo rende la modularità di systemd solo apparente, perché l’insieme dei suoi moduli si comporta poi a tutti gli effetti come un monolite che leva al sistemista la libertà di adattare al proprio uso il sistema, e, al contrario, occorre che sia il sistemista ad adattarsi alle scelte operate dagli sviluppatori di systemd, che possono essere più o meno valide, ma sicuramente non possono essere in nessun caso “universali” e adatte a tutti gli use case.


4) Systemd, così come tutti i grandi progetti, ha bisogno di un po' di tempo per stabilizzarsi. Se fosse perfetto lo usereste?
Se ci fate caso fino ad ora non ho mai parlato dei problemi di gioventù di systemd ne dei suoi bug.

Certo, systemd ha molti bug attualmente, alcuni peraltro abbastanza ridicoli, altri per scelte sbagliate “imposte dall'alto”. E non solo, c’e’ anche un certo atteggiamento da parte del gruppo di persone che ne porta avanti lo sviluppo che tende a rispondere troppo spesso con un “WONTFIX” o un “NOTABUG” quando si fanno notare certe scelte di sviluppo che sono oggettivamente opinabili proponendo delle soluzioni o delle patch.

Ma nessuno di questi e’ il reale problema di systemd. Anche qualora questo fosse per ipotesi del tutto esente da bug e perfettamente stabilizzato, e anche ammettendo che l’atteggiamento degli sviluppatori di systemd divenisse più collaborativo, non cambierebbe nulla.

Ciò che è sbagliato in systemd sono i concetti e la filosofia di base, e l’unico modo per correggere questo genere di problemi è quello di non usare systemd.


5) Cosa rispondete a quelli che dicono che siete solo dei vecchi retrogradi che non accettano le innovazioni?
Risponderei citando Henry Spencer:  "Those who do not understand Unix are condemned to reinvent it, poorly."
E aggiungerei: noi siamo assolutamente favorevoli all’innovazione. Siamo però selettivi e vogliamo solo le innovazioni positive, non quelle che consideriamo regressioni.


6) Perché nessuno si è messo a implementare qualcosa di meglio di systemd che includa alcune feature interessanti in modo da combattere systemd?
Non posso rispondere a questa domanda per il semplice fatto che parte da una affermazione falsa.

Ad oggi esistono diversi init alternativi al buon vecchio sysvinit i quali, in parte, affrontano alcuni dei problemi che systemd tenta di risolvere, come, giusto per citarne solamente uno che mi piace molto, OpenRC, ma non e’ certo l’unico.

Esistono poi diversi altri progetti, esterni e slegati dal sistema di init, che affrontano altri dei problemi che systemd vuole affrontare, come daemontools per la gestione dei servizi, sempre per citarne uno solo, ma anche alcuni nati in seno a devuan come vdev, che si propone di sostituire udev (che a proposito, se fosse rimasto esterno a systemd non avrebbe avuto bisogno di essere sostituito), loginkit, che si propone di sostituire systemd-logind, calzetta, che si propone di offrire in maniera KISS le api sd_notify introdotte da systemd.

Ci sono poi una classe di problemi che “non sono problemi” e che quindi non necessitano alcuna risoluzione, come i log con journald, che sono una pessima soluzione a un problema inesistente e non va certo risolto.

E ancora c'è un’altra classe di soluzione di systemd che, per noi, non sono soluzioni ma volontà di mettere in mano i sistemi a “operai dell’informatica” invece che a sistemisti (senza offesa per gli operai), come ad esempio l’integrazione con cgroups o molto altro che era fattibile anche prima, solo che prima occorreva un sistemista con un pò di testa sulle spalle e un pò di buon caro vecchio scripting per fare le cose, oggi “systemd sa’ come è meglio farle per te”. Peccato che quel che è meglio per systemd non sempre è meglio per i miei scopi.

La verità è che systemd introduce si qualche piccola innovazione positiva, ma di contro introduce anche moltissime scelte pessime, e anche le poche soluzioni innovative realmente presenti in systemd sono state comunque implementate in un pessimo modo, contrario al buon senso.


7) Pensate di farcela a gestire il carico di lavoro necessario a mantenere una distro? Avete mai preso in considerazione di prendere altre distro come base e nel caso di passare agli rpm (che poi sarebbero lo standard)?
Rispondo prima all’ultima parte della domanda, e lo faccio con una domanda a mia volta: da quando rpm è diventato standard?

Nel mondo linux non esiste una forma di pacchettizzazione standard, ci sono vari formati, alcuni più diffusi e altri meno. Non so quale dei due tra rpm e deb sia più diffuso sinceramente, ma sicuramente i deb se non sono i più diffusi, sono i secondi più diffusi in assoluto.

Non abbiamo mai pensato di passare a rpm o di prendere altre distro come base, tutti noi in Devuan proveniamo da lunghi anni in Debian, consideriamo quindi Devuan la naturale evoluzione di Debian dopo che questa ha smesso di essere il “sistema universale” ed e’ rapidamente cambiata con l’introduzione di systemd e non solo.

Se qualcuno vorrà avere a disposizione una distro rpm based o comunque basata su altro diverso da Devuan e senza systemd, potrà seguire il nostro esempio e forkare a sua volta, ma non è nostro compito questo.

Pensiamo di farcela a gestire il carico di lavoro necessario? No, non pensiamo di farcela. Ne siamo assolutamente certi.


8) Che ne pensate del progetto Debian LTS che estende il supporto per la oldstable con dei backport?
Il progetto LTS di perse’ è valido e permette una maggiore penetrazione e affidabilità a Debian in ambienti professionali di un certo tipo. Probabilmente anche Devuan proporrà un progetto simile.

Ma mi chiedo, come mai dobbiamo parlare di Debian? non sarebbe meglio parlare di Devuan?


9) Cosa fareste nel caso in cui logind diventasse una dipendenza necessaria per tutti i DE?
Non credo che questo succederà mai, esistono altri OS UNIX e POSIX oltre a Linux (che è uno UNIX-like, non uno UNIX ufficiale, ma che possiamo considerare tale ai nostri fini), e systemd-logind su questi non gira. Ci sarà quindi sempre la possibilità di patchare i sorgenti per evitarlo. E comunque abbiamo loginkit che prima o poi sarà maturo, qualora ce ne fosse proprio bisogno.


10) Nonostante i numerosi tentativi di includerlo KDBUS non fa parte del kernel vanilla, credete che le obiezioni di Linus Torvalds siano leggittime e che l'attuale versione del daemon DBUS spende buona parte del suo tempo in userspace a reimpallarsi GObject invece di fare il suo lavoro e andrebbe semplificata o ritenete che si sbagli e che DBUS sia il modo giusto di fare IPC?
Entriamo in un argomento molto controverso. Un numero rilevante di persone che orbitano attorno al progetto Devuan sembra considerare KDBUS il male fatto codice.

Personalmente ho una visione un po’ diversa, e ritengo che al momento attuale le critiche di Linus siano sacrosante e corrette, ma ritengo al contempo che si arriverà alla sua integrazione nel Kernel, è solo questione di tempo, i sostenitori di KDBUS alla fine arriveranno a farne una implementazione con uno standard qualitativo sufficiente per l’inclusione nel Kernel e troveranno altre motivazioni più valide della sola velocità di esecuzione che è stata così fortemente criticata da Linus.

Tuttavia non ritengo questo un problema perchè sono convinto che in nessun caso KDBUS diverrà obbligatorio nel kernel, quindi se non lo si vuole sarà sufficiente non abilitarlo.

Ritengo anzi che KDBUS potrebbe addirittura finire con l’aggiungere al kernel anche qualche funzionalita’ valida che potrebbe eventualmente permettere di essere anche riutilizzata per aggiungere ulteriori interfacce diverse da DBUS nel kernel stesso, sfruttando il codice di backend che sostiene KDBUS, favorendo quindi anche sistemi non basati su systemd. Ma sottolineo che questo è un parere del tutto personale e controcorrente rispetto a tante voci che sento gravitare in questo momento intorno al progetto Devuan.


11) Secondo te quali sono i capisaldi che devono e dovranno sempre essere mantenuti nel futuro di Linux? E quali sono i punti dolenti e meno efficaci che dovrebbero essere abbandonati e smussati?
I capisaldi, a mio avviso, sono, qui in ordine sparso:
  • rimanere software libero (nessun dubbio su questo)
  • osservanza delle filosofie UNIX e degli standard POSIX ed eventualmente successivi nel segno della continuità con questi.
  • filosofia KISS 
  • varietà’ ed eterogeneità
Occorre abbandonare il tentativo di unificazione estrema e di eccessiva omogeneità, l’eterogeneità e l’ecosistema vario e complesso sono stati e saranno sempre il vero caposaldo fondante del successo odierno di GNU/Linux, per chi si ricordasse ancora cosa sia, vorrei lanciare un piccolo ricordo a “La cattedrale e il bazar” di Eric S. Raymond, sempre molto attuale.

Occorre smussare la volontà di essere “desktop first”, perchè un eccessiva focalizzazione a un determinato ambiente va, gioco forza, a scapito degli altri ambienti, e un punto di forza molto importante in GNU/Linux e’ stato sempre quello di essere estremamente malleabile e adattabile agli ambienti più disparati.

Se posso permettermi, alle risposte di cui sopra, vorrei aggiungere una piccola nota finale.

Mi piacerebbe moltissimo se in futuro si parlasse di più di Devuan, del progetto, dei nostri obiettivi, di quel che stiamo facendo e di quel che abbiamo fatto, e meno di systemd e del perchè noi non lo usiamo.

Molto codice è stato già scritto e molta infrastruttura tecnica e sociale è già stata costruita, e molto altro abbiamo nella nostra lista “TODO”, ridurre il progetto Devuan solo a “siamo quelli senza systemd” e’ davvero scalfire solo la superficie di ci che vogliamo rappresentare e che ci poniamo come obiettivo finale, che non è quello di eliminare systemd, ma è quello di riportare in prima linea la comunità e le sue esigenze, i tecnici, i sistemisti, le persone che sanno dove mettere le mani in un sistema per adattarlo alle proprie esigenze che, fino ad oggi, si è sempre potuta avvalere di quello che io considero il miglior OS sulla piazza, mentre tutti gli altri si facevano guidare dagli sviluppatori di Microsoft o di altre aziende, e che, a causa anche ma non solo di systemd, oggi vede messa in pericolo questa possibilità e si sente schiacciata a dover diventare mera utilizzatrice di cose preconfezionate per esigenze commerciali di terzi, perdendo il primato e la proprietà effettiva del proprio sistema.

Siamo sistemisti, siamo sviluppatori, siamo informatici, ma prima di tutto siamo persone che conoscono a fondo il proprio sistema e i propri scopi, e vogliamo continuare a poter scegliere cosa deve e cosa non deve girare sui nostri sistemi, quali siano le soluzioni più adatte per raggiungere i nostri obiettivi, vogliamo essere liberi eventualmente anche di sbagliare ed imparare dai nostri errori.

Devuan fondamentalmente è un progetto di libertà.
Franco (nextime) Lanza

37 commenti:

  1. Non riesco a comprendere quanto possa essere preso sul serio un progetto come questo. Se systemd è la goccia che ha fatto traboccare il vaso, cosa aveva riempito il vaso prima di allora?

    Come mai se il problema non è systemd sul vostro sito si legge chiaramente "We want freedom of choice, we want Init Freedom!"?

    Su che userbase può contare ad oggi Devuan?

    RispondiElimina
  2. Franz H. Blake6 luglio 2015 19:12

    Ognuno è libero di impiegare il tempo come vuole. Ma a me il discorso pare più un "siamo informatici abituati da anni a gestire le cose così e non ci piace imparare qualcosa di nuovo" che una reale critica. Mi dimostrino che le cose che facevano prima non possono essere fatte o non possono essere fatte in tempi comparabili, e darò loro ragione.

    RispondiElimina
  3. Regà, smettete di pensare come se il vostro modo di usare il pc fosse l'unico possibile.
    C'è gente che con ste cose ci LAVORA (ovvero può mangiare a fine mese grazie a) in ambienti dove il fatto che le cose rimangano stabili è molto più importante di risparmiare 2ms di tempo di boot.

    Tanto per fare un esempio, magari non lo sai, ma esiste un software chiamato fail2ban, che è un tool fondamentale per bannare chi cerca di farti bruteforce sul server, per fare il suo lavoro legge i log in /var/log/.
    Ecco, una volta che la distro ti switcha a systemd questo software smette di funzionare perchè i log sono diventati binari.

    Ma qui rimaniamo nel banale, per fare un esempio più serio, linux è usato anche in ambienti più critici, al punto che è importantissimo verificare il codice in modo molto più serio (audit), questa operazione richiede tantissimo tempo e soldi.
    Una volta che un software è stato approvato non può essere cambiato, neanche per un aggiornamento minimo, se poi aggiungere un altro software all'insieme, invece che richiedere l'audit solo di questo, richiede l'aggiornamento e quindi l'audit di mezzo sistema perchè systemd non è in grado di rispettare le interfacce esistenti e richiede la dipendenza quando prima non c'era neanche bisogno di una dipendenza dall'init mi are EVIDENTE che la cosa non vada bene.

    Quindi prima di dire assurdità a caso prova tu per primo a metterti nei panni degli altri...

    RispondiElimina
  4. Ad esempio prova a dirmi con sicurezza al 100% cosa si avviera' al prossimo boot e in quale ordine.

    Poi essere accusati di essere pigri e non voler imparare qualcosa di nuovo quando per fare quel che stiamo facendo occorre un lavoro ENORME e, per poter rimuovere systemd ed eventualmente sostituirne alcune parti occorre prima di tutto studiarselo a fondo ben oltre il mero utilizzo, direi proprio che dire che non vogliamo imparare cose nuove sia la critica piu' stupida in assoluto che ci puo' essere rivolta.

    RispondiElimina
  5. Franz H. Blake7 luglio 2015 09:44

    Forse non sai che nessuno ti vieta di usare syslog. Non c'è scritto da nessuna parte che journald blocca ogni altro logger di sistema. Non è imbarazzante lavorare col computer e non sapere una cosa simile?
    Inoltre, da quando in qua si aggiorna un server ogni volta che esce software aggiornato? Fai audit con versione systemd 200 su debian 7 (esempio) e lo rifai su debian 8 con systemd 300, due anni dopo.

    RispondiElimina
  6. Non basta mettere dei Want= o After= negli script di systemd per creare un ordine che vuoi tu e che sia perenne?
    Sul cosa, systemd controlla se un processo non parte e nel caso riprova, quindi IMHO hai maggiore certezza su cosa si avvierà.

    RispondiElimina
  7. questo NON risponde alla mia domanda che era dimmi con sicurezza al 100% cosa verra' avviato e in che ordine. HINT: con systemd NON puoi.

    RispondiElimina
  8. A parte il fatto che se guardi il caso di fail2ban fa poco più di un grep con conta occorrenze quindi volgarmente un grep | wc -l cosa che potrebbe fare comunque solo che invece che usare la logica del grep dovrebbe usarne un'altra. Comunque se non erro ci sono progetti già per ovviare a questo problema, inoltre si può abilitare syslog su quasi tutti i programmi server.

    RispondiElimina
  9. Quello che te chiami volgare non lo è affatto, anzi, è proprio il bello della filosofia UNIX, metti insieme tanti piccoli programmi per fargli fare una cosa più complessa.
    Inoltre essendo questi programmi molto piccoli e semplici, dopo qualcosa come 30 di debug li puoi ritenere virtualmente a prova di bomba, funzionano punto e basta, non si romperanno mai, a grep gli puoi mandare in input i peggio exploit senza problemi.
    Fanno una cosa e la fanno al meglio possibile, usando algoritmi allo stato dell'arte per quella cosa.

    Te invece adesso dici:
    No, buttiamo via la semplicità, lo stato dell'arte, 30 anni di debug per riscrivere da zero un'altra cosa che non è lo stato dell'arte, ci vorranno anni prima che lo diventi, se mai lo diventerà, non è testato in modo così solido, ci vorranno anni prima che lo diventi e non è semplice, ma un blocco unico che è ancora più difficile da testare e debuggare, per raggiungere lo stesso livello di tempo ce ne vorrà anche il doppio, perchè invece di fare solo una cosa bene finisce per farne tante male, forse ti è sfuggita nell'articolo la citazione di Henry Spencer:

    "Chi non capisce UNIX è condannato a reinventarlo, male."

    Stiamo parlando esattamente di questo, allora prova a farti una domanda, hai capito UNIX?

    Poi se te vuoi usare le cose fatte male, ok, no problem, ma spiegami perchè vuoi a tutti i costi costringere anche tutti gli altri a farlo.

    (sulla cosa del si può abilitare syslog rispondo sotto)

    RispondiElimina
  10. Non è proprio così, journald PER ORA, ti consente di passare i messaggi anche a syslog, ma devono comunque passare per journald, il quale è talmente scritto bene che è cosa comunque che si perda messaggi per strada.

    Già qui ci sono motivi sufficienti per non usarlo, ma andiamo avanti:
    come al solito la memoria storica ha durata molto breve, in passato c'erano molte più cose che systemd consentiva di fare, poi un bel giorno Poettering si sveglia più contento del solito e decide che ne taglia una, poi un'altra, poi un'altra ancora, perchè loro sono i Masters of the Universe e sanno cosa serve a te.

    Loro possono decidere di tagliare questa possibilità in qualunque momento, perchè dovrei fidarmi di gente che ha già dimostrato ampiamente di essere inaffidabile?

    Come se non bastasse qualche dev di systemd ha gia detto che syslog non avrà più ragione di esistere quando journald avrà il supporto al forwarding dei log via rete.

    Tutto questo è assolutamente inaccettabile.

    Sull'altra cosa non ti rispondo nemmeno, non esistono solo server, non hai idea di cosa stai parlando, lascia perdere.

    Ma soprattutto, come ho già chiesto sopra, perchè accidenti devi essere te a dire cosa devono usare tutti gli altri?
    Vuoi usare le cose fatte male? Fallo, ma non andare a dire agli altri cosa devono fare solo perchè te non capisci che ci possono essere anche esigenze diverse dalle tue.

    RispondiElimina
  11. Franz H. Blake7 luglio 2015 13:01

    systemctl is-enabled? non ti dice se ciò che ti serve è "enabled"? L'ordine, l'ordine gerarchico viene mantenuto per fare in modo che ogni servizio si avvi quando le sue dipendenze sono avviate, gli altri si possono avviare nel primo tempo utile grazia alla parallelizzazione.

    RispondiElimina
  12. Franz H. Blake7 luglio 2015 13:07

    Hai prove che journald si perde i file per strada? Il dev ha detto che non avrà più motivo di esistere, e allora? Sta dicendo che non sarà possibile usarlo? Memoria storica ne hai tantissima, dato che le critiche più grandi sono l'esatto opposto, cioè che un progetto che è partito come init ora supporta/sostituisce una marea di "piccoli programmini"/configurazioni. Liberissimo di usare quello che vuoi, basta smetterla di spargere FUD e fingere di essere i migliori dell'universo.

    RispondiElimina
  13. Quindi system.d decide per te. È esattamente questo che non si vuole, lasciar decidere al software (e quindi allo sviluppatore) cose che potrebbero benissimo essere decise dai sistemisti.


    Il punto è che in nome di un over-semplificazione si toglie libertà.

    Ti piacciono le gabbie dorate? Liberissimo, ma non obbligare me a usarle.

    RispondiElimina
  14. Franz H. Blake7 luglio 2015 13:26

    Scusa, io non sono un professionista ma mi sono bastati 5 minuti di ricerca per trovare l'opzione after nei service file. Dato che un sistemista non formatta ogni giorno, si modifica i file dei servizi che gli interessa avviare dopo altri e inserisce altre dipendenze.

    RispondiElimina
  15. ... che NON ti garantisce comunque si poter sapere programmaticamente l'ordine al prossimo boot.

    RispondiElimina
  16. Franz H. Blake7 luglio 2015 13:31

    Sì se sai quanti e quali file di service avvi al boot e inserisci gerarchicamente after in ogni file.

    RispondiElimina
  17. Non e' proprio cosi' e ci sono state gia' diverse dimostrazioni in proposito, ma non intendo divulgarmi qui ancora a parlare di questo sinceramente.

    Il punto e' che non importa quanto sia fattibile una configurazione o meno, il punto e' che comunque sia se io voglio farmi un sistema su misura perche' conosco esattamente le mie esigenze e i miei obiettivi, posso arrivare a quel risultato molto facilmente con un sistema atomico e granulare, mentre con un sistema modulare ma i cui componenti sono strettamemte legati fra loro sara' sempre e comunque meno personalizzato per il compito che si vuol svolgere. Ci sono casi ad esempio in cui usando un semplice rc.init script come shell script al posto di qualsiasi init, o comuqnue un sysvinit ben configurato, si ottiene un boot molto piu' veloce e un memory footprint molto piu' basso, ci sono ambienti, come il deeply embedded, dove avere journal per i log e' eresia per via delle elevate risorse che richiede, ci sono situazioni in cui avere il journal e' semplicemente inadatto ( se si corrompe non basta nemmeno riavviare il servizio per risolvere il problema ) e duplicare i log con journal + syslog e' comunque uno spreco di risorse.

    Nessuno dice che systemd sia il male assoluto, o almeno io certo non lo dico, ma anche affermare che sia la panacea di tutti i mali e che sia adatto a tutti gli usi sempre e comunque e' semplicemente una cosa stupida, e pertanto la sua imposizione a tutti e' altrettanto stupida.

    Anyway, noi non obblighiamo nessuno a pensarla come noi, anzi, ci piace che il mondo sia vario e ci sia possibilita' di scelta per tutti, al di la dei motivi di tale scelta, senza che nessuno si permetta di stabilire motivazioni di comodo ( sono vecchi e non hanno voglia di cambiare, nulla di piu' falso! ) semplicemente perche' la pensa diversamente.

    Vi piace devuan? bene! non vi piace? bene lo stesso, ma rispettate il nostro pensiero e il nostro lavoro.

    RispondiElimina
  18. Ho parlato di messaggi, non di file, cerca pure nel bug tracker di systemd (sempre che non li abbiano cancellati completamente per farsi belli).

    SI sta dicendo che non sarà possibile usarlo, perchè il fatto di poter usare syslog quando journald è attivo è una possibilità che ti concedono i dev di systemd, l'ho già spiegato prima, se non leggi non posso farci niente.

    Nessuno si finge niente, ma per favore non avere la pretesa di andare andare ad insegnare agli altri il loro lavoro quando palesemente (e a quanto leggo sopra, dichiaratamente) non lo conosci, perchè poi passi te per quello che finge di essere il migliore dell'universo.

    RispondiElimina
  19. Franz H. Blake7 luglio 2015 13:45

    Splendido discorso, perfettamente d'accordo. Infatti io non ho notato né migliori tempi di boot né semplificazione, mi trovavo benissimo con demoni e rc.init, e infatti non reputo systemd né la salvezza del mondo, né il male assoluto.
    Devuan, probabilmente farete un ottimo lavoro, ma per una distro che non punta solo a rimpiazzare systemd, le 7 vole (SETTE) che citate systemd e il simbolo "init freedom" vi qualifica solo come un ammirevole gruppo di sviluppatori che ha puntato solo su systemd=male assoluto.

    RispondiElimina
  20. Franz H. Blake7 luglio 2015 13:52

    E chi si permette. Ma sono supposizioni e basta. Sul wiki di Arch ad esempio si dice che i processi di breve durata spesso non vengono loggati, ma da anche la soluzione. Per il resto, mi spiace ma non vedo quello che dici. Hanno introdotto network, e io uso networkmanager, hanno introdotto ntp e io posso tranquillamente usare quello che voglio. Magari quando conquisteranno il mondo vi darò ragione.
    Ma c'è anche da dire che l'immobilismo devastante in cui è caduta la community GNU/Linux è imbarazzante per chi una volta era un precursore. Stiamo criticando ogni cosa, dbus faceva schifo, kdbus ancora di più, x.org era meglio di wayland, qualsiasi altro init è meglio di systemd, gnome 2 > 3, pulseaudio è il male. Insomma, fate pace con voi stessi. O fate come Franco Lanza, fatevi la vostra distro.

    RispondiElimina
  21. Franz H. Blake7 luglio 2015 15:17

    Innanzitutto la risposta è sì, una distro di oggi funziona meglio di una di dieci anni fa, e questo lo so perché usavo linux anche 10 anni fa. I problemi ci sono ancora, dipendono dalle stesse cose da cui dipendevano allora (driver principalmente), ma ad esempio pulseaudio è un'innovazione che sarebbe imbarazzante non ci fosse. In secondo luogo: ma perché dovrei prendere Arch e levargli systemd? Se non voglio systemd passo a gentoo. E' come chi si lamenta delle scelte di Ubuntu, a me molte cose non piacciono, è per questo che non la uso. Stesso discorso, non vado a usare KaosX criticando il loro approccio KDE-centrico, non vado a usare Fedora se non mi piace systemd e pulseaudio. Il bello è che posso scegliere di usare Slackware, Gentoo, Lunar linux, e persino LFS. Concludendo, Gnome è un prodotto RH, così come systemd. O lo forki o non puoi aspettarti che tutti i dev facciano quello che vuoi tu solo perché piace a te. La libertà non è univoca, non siete obbligati a usare quello che i dev vogliono, non dovete obbligare i dev a fare come voi volete. Altrimenti fork e meno chiacchiere.

    RispondiElimina
  22. stai confondendo la dichiarazione di un goal di breve termine con una (ancora mancante, lo ammetto, la parte "sito" e "comunicazione" per noi arrivano dopo, siamo tecnici) progettazione di lungo termine. Non siamo bravi nella comunicazione, ci occupiamo di altro, ma se segui meglio il progetto leggendo dove il codice risiede (wiki dei vari progetti sul nostro gitlab, chiedi sul nostro canale irc etc) scoprirai che c'e' molto molto molto di piu' di quel che dive il sito che e' straminimale e poco curato.

    Poi si, molti si avvicinano a noi per via di systemd, ed e' innegabile che quella e' stata la rottura e cio' che ha caratterizzato l'inizio di devuan, ma questo non significa che noi si sia solo "leviamo systemd"

    RispondiElimina
  23. "Altrimenti fork e meno chiacchiere".
    Che e' esattamente quel che abbiamo fatto noi con Devuan.

    RispondiElimina
  24. Franz H. Blake7 luglio 2015 23:50

    Esattamente ma: 1) non siete stati in grado in questo sede di spiegare razionalmente cosa vi da fastidio di systemd; 2) il riferimento era al commento precedente, che lamenta come tutte le principali distro abbiano abbracciato systemd.

    RispondiElimina
  25. Sarebbe bastato semplicemente supportare diversi sistemi di init da parte di debian.

    RispondiElimina
  26. Sbagli su due cose. La prima, costringere tutti gli altri a farlo. Io e nel dettaglio debian non costringe nessuno, non ti piace systemd? Vai su gentoo che supporta altri sistemi di init in maniera ufficiale. Forka come han fatto loro, ma non dire che non puoi ottenere i stessi risultati solo per il sistema di init perché è un'eresia (era la seconda).
    Cose fatte male o bene, sono molto relative per me non funziona bene nessun sistema di proxy perché non supportano con basso footprint come dicevate una query sql e quindi mi sono scritto il mio non per questo gli altri sistemi di proxaggio sono il male ultimo. Io cerco di esser concreto e non battermi a spada tratta dicendo sempre "ma non è come lo voglio io".
    Poi se vogliamo entrare nel dettaglio io sono uno di quelli che dice che systemd è secondo me più veloce di altri sistemi di init, che il journalctl mi va bene così e che uso syslog per remotizzare i log su file di testo così da centralizzarli anche quindi non vedo questi problemoni ma capisco chi ce li ha, per tale ragione debian doveva fornire a mio modesto modo di vedere tutti i sistemi di init possibili e non forzare systemd anche in fase di installazione, sarebbe rimasta così il vero "sistema universale" cosa che ancora oggi non è.

    RispondiElimina
  27. E usa altro invece di gnome3 no? Ma è unq responsabilità di arch o debian se gnome3 richiede systemd per funzionare come si deve? Quando si passerà a Wayland sarà colpa delle distribuzioni se kde e gnome richiederanno Wayland per funzionare? Posso capire il discorso accanimento Wayland vs MIR (neanche più di tanto ma ok ci sta), ma Systemd vs Qualsiasi_COSA_MI_PASSA_PER_LA_TESTA no dai è esagerato.

    RispondiElimina
  28. Purtroppo non e' cosi' semplice, systemd e' molto piu' invasivo del solo init e invade gran parte del sistema base ( e ha una linea chiaramente espansionistica ), di fatto se si sceglie di supportare systemd si finisce con l'obbligare ad avere almeno alcune sue parti in una distro compilata.

    E poi appunto non si tratta solo di systemd anche se e' il primo target, ma di una linea di sviluppo tutta orientata a una omogeneizzazione dell'ambiente che si ripercuote su un espellere i "border line" usecase che fa si che si perda sia la "unixeness" sia la "kissness" ma soprattutto l'universalita' del sistema.

    RispondiElimina
  29. Franz: 1) cosa non ci va di systemd lo abbiamo spiegato molte volte negli ultimi mesi in sedi piu' adatte, e le ragioni razionali ci sono e le ho spiegate anche qui in parte. Se non ti stanno bene come spiegazioni e' un tuo legittimo parere e mi sta bene, ma io voglio passare oltre systemd e pensare allo sviluppo della nostra distro.
    2) certo, ma e' di fatto una cosa che ci siamo sentiti dire un sacco di volte quando cercavamo di lavorare "dentro" debian: "non vi piaciono le nostre scelte? forkate!". Poi abbiamo forkato e ci criticano perche' abbiamo forkato.

    RispondiElimina
  30. Marco Pirazzoli8 luglio 2015 20:39

    Celebrando @Franco Lanza (che conosco "virtualmente" da abbastanza tempo), systemd merda.

    RispondiElimina
  31. Ma ti pagano per fare il troll oppure e' vocazione? "razionalmente" parlando si legge solo gente che insiste in modo anche aggressivo a chiedere le stesse domane e rifiutare qualsiasi risposta. Buona vita occhio alla bile! noi forkare si forka e come

    RispondiElimina
  32. Franz H. Blake8 luglio 2015 21:23

    Magari mi pagassero. No, sto solo chiacchierando con una parte della comunità Linux le cui scelte trovo essere retrograde e reazionarie. A te pagano per venire a scrivere critiche poco costruttive sulla presunta reputazione altrui?

    RispondiElimina
  33. Franz H. Blake8 luglio 2015 21:30

    E io ti e vi auguro sinceramente di raggiungere i vostri obbiettivi. È un diritto forkare se si è certi che quello che si ottiene è meglio del precedente. Magari darete alla comunità quello che RH per voi ha fallito a dare, un init nuovo, moderno, senza che sfrutti appieno l'informatica di oggi.

    RispondiElimina
  34. Io con linux ci lavoro e ci faccio campare la famiglia, e sono anch'io della 'old school' avendo, ormai quasi 27 anni di lavoro come sistemista sul groppone . Sono, anche, da 13 anni titolare di un'azienda di informatica che realizza software per automazioni industriali basate principalmente su linux e non ho trovato systemd il 'male assoluto'. Io ed il mio team ci abbiamo 'porconato' qualche mese, ma poi, studiato meglio l'oggetto siamo riusciti a fargli fare tutto quello che a noi serviva. Ho già detto che systemd è immaturo e spesso in molte sue parti è scritto in maniera che definirla confusionaria è puro eufemismo (mi ha sorpreso molto l'implementazione su debian stable, questo si) ma non è affatto monolitico e anzi nella creazione di 'distro' dedicate come quelle che realizziamo per i controller dei nostri clienti semplifica di molto il lavoro, rendendo il tutto molto più omogeneo.Non entro in merito nelle considerazioni filosofiche tipo 'Keep it Simple, Stupid' e relativi commi ma nel bene e nel male ora il presente per chi fa dell'ambiente linux business si chiama systemd anche data l'implementazione che ne fa Redhat nel suo sistema Enterprise (che influenza e 'impone' gli standard).. linux, comunque, è open source e nessuno vieta a nessuno di farne 'quello che si vuole' ma per favore, caro Franco, no ergerti come portatore assoluto di verità, ritenendo che le tue/vostre esigenze siano quelle di 'tutti'...
    Poi il discorso 'E ancora c'è un’altra classe di soluzione di systemd che, per noi, non sono soluzioni ma volontà di mettere in mano i sistemi a “operai dell’informatica” invece che a sistemisti (senza offesa per gli operai), come ad esempio l’integrazione con cgroups o molto altro che era fattibile anche prima, solo che prima occorreva un sistemista con un pò di testa sulle spalle e un pò di buon caro vecchio scripting per fare le cose, oggi “systemd sa’ come è meglio farle per te' lo trovo di un'arroganza disarmante fatto da chi probabilmente crede di avere una conoscenza superiore dei sistemi informatici e una particolare 'illuminazione' divina, non conoscendo che anche systemd, volendo fa le cose che gli 'dici di fare' utilizzando il caro e vecchio scripting fatto da un sistemista che ha un po' di testa ( e che sopratutto sa dove mettere le mani sulla tastiera).

    RispondiElimina
  35. A mio parere ben venga in tempi rapidi Devuan, toglie da Debian i vecchi brontoloni :D

    RispondiElimina
  36. scienzedellevanghe9 luglio 2015 23:54

    «ma per favore, caro Franco, no ergerti come portatore assoluto di
    verità, ritenendo che le tue/vostre esigenze siano quelle di 'tutti'...»

    Ma veramente è l'esatto opposto. Il problema è che è proprio systemd ad essere proposto come "la verità assoluta" ed a causa di un sistema molto stretto di dipendenze rende la vita è estremamente complicata per chi vuole farne a meno.
    Per questo motivo hanno forkato, non certo per imporre a te la loro distro.

    RispondiElimina

Licenza
Licenza Creative Commons

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported. Questo blog non rappresenta una testata giornalistica, in quanto viene aggiornato senza alcuna periodicità. Non può, pertanto, considerarsi un prodotto editoriale, ai sensi della legge n. 62 del 7/03/2001

Disclaimer immagini

Le immagini utilizzate in questo blog appartengono ai loro rispettivi autori e sono utilizzati per scopi educativi, personali e senza scopo di lucro. Ogni eventuale violazione del copyright non è intenzionale, ma se si riconosce un'immagine protetta da copyright, fatemelo sapere qui, e sarò lieto di aggiungere i credits o modificarla o rimuoverla.

Disclaimer images

Images used on this blog belong to their respective authors and are used for educational, personal and no profit purposes. Any eventual copyright infringement is not intentional, but if you recognize a copyrighted image, please let me know here, and I'll happily provide to add the right credits or modify or remove it.