12 risposte a “Devuan: rilasciata la versione 3.0 della distribuzione libera da systemd”

1. 

   kalos_nerd

   5 Giugno 2020

   Penso sarebbe stato ancora più funzionale includere il lavoro di devuan in debian, dando agli utenti la possibilità di scegliere il sistema di init (e altro, collegato a systemd) da usare, in perfetto stile debian.
   Cosa che non escludo possa succedere.

2. 

   Samael

   6 Giugno 2020

   No, non sbagli, il concetto è esattamente quello. Solo che mentre prima la situazione era chiara a tutti con il loro “abbiamo scelto systemd”, adesso per far contenti certi utenti hanno preferito dire la stessa cosa di prima ma in maniera più “politichese”. Così, quelli svegli che l’hanno capito subito, si sono fatti due risate e hanno continuato come se niente fosse. I boccaloni invece hanno festeggiato credendo che Debian abbia fatto marcia indietro, sebbene non sia così.

   Onestamente Debian è l’esatto esempio di come non andrebbe gestita una distribuzione. Mozioni, votazioni, burocrazia a non finire e finte prese di posizione come questa, solo perché la leadership non ha le pa**e per ammettere che sono state fatte delle scelte, magari impopolari (e dai numeri di chi ha forkato non sembra proprio) ma comunque scelte.

3. 

   Shiba

   7 Giugno 2020

   Più realisticamente parlando: chi all’interno di Debian voleva sbarazzarsi di qualunque cosa non fosse systemd, ha fallito col botto.

4. 

   JustATiredMan

   7 Giugno 2020

   Ha ragione Samael, in Debian non c’è più alternativa. Se non vuoi o non ti occorre systemd, Debian non è più una distribuzione su cui puoi fare affidamento.

5. 

   JustATiredMan

   7 Giugno 2020

   Ne dubito molto si potrà scegliere un diverso init. Oramai systemd è diventato qualcosa oltre a un “init system”. E’ così invasivo che di fatto quasi tutti i pacchetti ne sono dipendenti. Già da quando systemd sè “magnato” dbus e udev l’ha reso di fatto indispensabile a Gnome che manco parte piu senza. Non conosco la situazione di Kde, ma mi sa che siamo li. Frà poco assimilerà anche la gestione delle home, e anche il kernel potrà diventare un modulo (sostituibile) di systemd…. Ogni resistenza è futile 😀 😀

6. 

   Shiba

   8 Giugno 2020

   all’atto pratico c’è vita oltre systemd in Debian?

   Sì. nginx-common in sid, giusto per fare un esempio:
   
/etc/init.d/nginx
[...]
/lib/systemd/system/nginx.service

   Questo era ciò che si voleva eradicare, e questo è il buco nell’acqua che hanno fatto. Manovre di questo tipo funzionano se ti chiami Fedora, su Debian non attacca.

7. 

   Shiba

   8 Giugno 2020

   Tutto un giorno verrà deprecato, appena le persone che mantengono un determinato componente perdono interesse. Debian per fortuna è un progetto fatto di persone, non è un’azienda e non ha una leadership che impone, quindi finché qualcuno sarà interessato a mantenere un certo livello di supporto, l’init in stile sysv continuerà a rimanere in vita.
   Viste le dimensioni e l’importanza del progetto Debian, probabilmente si tratta del più grande esempio di democrazia che abbiamo nel mondo GNU/Linux (e probabilmente nell’informatica in generale?). Di questo dobbiamo farne un vanto.

8. 

   Shiba

   8 Giugno 2020

   L’infrastruttura c’è eccome ed è usabile (wiki debian org/Init):

   In jessie and stretch, the default init system is systemd, but switching to sysvinit is supported.
   Since jessie, only systemd is fully supported; sysvinit is mostly supported, but Debian packages are not required to provide sysvinit start scripts

   Tra le altre cose, questo nega in toto che “ufficialmente esista solo systemd”.

   Navigare a vista? Debian, come la quasi totalità delle distro, è un calderone di software sviluppato da terzi con un solo scopo: fornire un sistema stabile il più completo possibile. No, imporre una direzione non è tra i loro fini. Sono 27 anni che Debian dimostra come un progetto possa essere democratico e non solo funzionare bene, ma allo stesso tempo avere un discreto successo. Può non piacere per gusti personali (io ad esempio non sono un utente Debian se non come ultima risorsa), ma non si possono negare i fatti: non è un progetto della domenica nato l’altro giorno, il metodo funziona.

9. 

   Shiba

   8 Giugno 2020

   […]but switching to sysvinit is supported.

   E questo è esattamente quello che ti sto dicendo io 😀
   Non andiamo da nessuna parte se continui a ignorare le parti che non ti interessano.

   Lo scopo di Devuan è più specifico: fornire supporto completo a sysvinit. Faccio ancora fatica a capire per quale motivo abbiano deciso di forkare l’intera distribuzione piuttosto che creare un repo per qualche decina di pacchetti e un media d’installazione. Progetto loro, liberi di fare come preferiscono.

   La direzione di Debian è quella che ti ho scritto sopra: fornire un sistema stabile. Questa è la sua identità a cui è sempre rimasto fedele nell’arco di decenni ed è questa identità che lo rende uno dei sistemi operativi favoriti in ambito server. I componenti per raggiungere questo scopo per forza di cose sono scelti in base all’occasione; systemd stesso, tra le altre più o meno valide motivazioni, è stato scelto come default per evitare rogne con un upstream (prevalentemente desktop) che faceva affidamento su componenti all’epoca non disponibili altrove. Questo è navigare a vista e non c’è niente di sbagliato dal momento che è ciò che permette a Debian di raggiungere il suo scopo.

10. 

    Shiba

    8 Giugno 2020

    EDIT: è un papiro lo so, non ho il dono della sintesi.

    Quindi non c’è un pieno supporto a niente che non sia systemd e non c’è obbligo nel fornire script per qualcosa di diverso da systemd.

    Mai negato neanche lontanamente questo, ma ti ricordo che ciò che sostenevi tu era che Debian nemmeno funziona con sysvinit. Ciò che dicono gli sviluppatori di Debian invece (e che è scritto nero su bianco, per quanto ti ostini a negarlo) è che sysvinit è supportato come sistema di init per la distribuzione. Non è richiesto che tutti i pacchetti forniscano uno script di avvio e non escludo che molti pacchetti abbiano come dipendenza “forte” componenti legate a systemd; ad esempio non posso aspettarmi di veder funzionare GNOME con sysvinit, ma se ho bisogno di un server nginix da usare con sysvinit, posso affidarmi a Debian. E stando a quella pagina e allo stralcio della lista di file che ti ho incollato prima, è un caso d’uso supportato.
    Al contrario puoi notare la differenza con la frase subito successiva, dove affermano esplicitamente che runit è pacchettizzato, ma non è supportato come sistema di init.

    “fornire un sistema stabile” è la natura di qualunque pezzo di software.

    Volevo specificare meglio questa parte, ma non sapevo come metterla giù senza rendere la discussione un macello, bene quindi che l’hai sottolineato. Stabile non significa solamente che non si rompa, significa anche fornire una base immutabile (=stabile) a livello API/ABI, pur continuando a garantire un adeguato livello di sicurezza. Per chiunque stia leggendo questa conversazione e non sia avvezzo alla terminologia, in soldoni significa che se io terza parte ho sviluppato un software nel 2017 con l’intento di supportare Debian 9, posso aspettarmi di vederlo funzionare su quella versione di Debian fino al 2022, senza bisogno che ci metta mano. Non sono molte le distribuzioni (credo nessuna se consideriamo solo le distribuzioni senza un’azienda alle spalle) che possono contare in anni un supporto di questo tipo.

11. 

    Shiba

    8 Giugno 2020

    Dici che non lo neghi, ma poi lo neghi due righe dopo.

    Ti ho anche fatto l’esempio: GNOME no, nginx sì. Dal momento che affermi che mi contraddico, immagino non avrai problemi ad incollarmi dove ho negato che systemd sia l’unico init pienamente supportato.

    NO. Ciò che è scritto su quel testo è che sysvinit è MOSTLY supported e che NON è obbligatorio il supporto lato applicativo.

    Che è esattamente quello che sto dicendo io. Ma dal momento che insisti con la tua tesi campata in aria che Debian non funzioni con sysvinit, guarda con i tuoi stessi occhi:

    i imgur com/sl8W1v9.png

    Non è semantica, è comprensione del testo. C’è scritto chiaramente che il passaggio da parte dell’utente a sysvinit (e di conseguenza l’avvio del sistema con esso, mi sembra scontato) è supportato, lo screenshot conferma solo ciò che era ovvio fin da subito. Puoi arrabbiarti finché ti pare, questo non fa assumere alle parole il significato che vuoi tu.

    Se tu sviluppi un software su Fedora 32 al day one, esso funzionerà senza problemi anche nel giorno del suo EOL.

    Sì, per 13 mesi, non 5 anni. Non che ci sia niente di male, le due distribuzioni hanno scopi diversi. E finché siamo in argomento, su Fedora non è neppure scontato che un modulo che compili al day one con dkms funzioni fino all’ultimo giorno, dal momento che hanno l’abitudine di aggiornare il kernel alle major release superiori (es. Fedora 31 ha incominciato col 5.3 e al momento ha il 5.6).

12. 

    Silvestro Gastone

    13 Dicembre 2020

    […] Mi ricordano certi politici italiani della prima repubblica che riempivano il parlamento e le interviste di discorsi vuoti per non scontentare nessuno, mentre intanto si andava avanti alla giornata in attesa delle prossime elezioni.

    Anche ora, Samael, uguali a quelli di prima. Nulla è cambiato.