Forum libero

Scritto da: ::1
> Io sono dell'opinione opposta, systemd ha grossi vantaggi proprio per i sysadmin;

Onestamente non ne vedo. Non sono un sysadmin ma tutti i sysadmin che conosco sono, in genere, fortemente contrari a Systemd con qualche voce fuori dal coro.

> è chiaro che deve ancora dimostrare di essere affidabile e stabile per anni e anni e anni,

Quindi sei d'accordo che è sbagliato metterlo in produzione già da subito. Se l'avessero messo _come opzione_ non ci sarebbero stati problemi, invece non solo per molte distro non è affatto un'opzione, ma è addirittura richiesto se vuoi usare determinati componenti (come Gnome)... e sarà sempre peggio perché Systemd è _progettato_ per essere usato quasi come libreria e quindi per diventare una dipendenza fondamentale per sempre più sistemi.

> ma c'è da dire che le features di base (unit file, process monitor, journald) non hanno problemi, tant'è che i server centos/redhat non esplodono e sono ancora considerati rock-solid.

Non ne sono sicuro. Su cosa basi questa tua affermazione? Sul mero (presunto) fatto che ancora nessuno ha ownato un server CentOS/redhat? Magari hai anche ragione, ma la mia esperienza mi dice che un sistema complesso è in genere il primo motivo per cui un sistema finisce per fallire.

> L'unico appunto sono forse i binary log, ma basta cambiare un flag e tornano testuali.

Finché non decideranno che quella flag non serve più per via degli "innegabili vantaggi dei binary log". Magari ti faranno sparire l'opzione da una release all'altra e tu potrai solo inghiottire e chiudere la bocca... tanto è più o meno stata questa la politica adottata fin'ora circa Systemd.
"Non ti piace? Cazzi tuoi. Noi andiamo avanti per questa strada, se vuoi forka... ah... e good luck with that... visto che ora Gnome dipende da noi e in futuro sempre più sistemi e sottosistemi dipenderanno da noi".

Non so... a te sembra una politica/modo di fare accettabile nel mondo opensource? A me sembra una politica piuttosto aggressiva e poco "user-friendly". E, nota, è stata più o meno la stessa politica usata con pulseaudio... guardacaso l'autore è lo stesso.

> Per quanto riguarda la filosofia unix, sono tutte minchiate davanti ai problemi da risolvere,

Continui a parlare di "problemi da risolvere"... io ripeto... non ne vedo (forse perché non sono un sysadmin) e non capisco perché non si possano risolvere con delle modifiche all'init attuale anziché buttare via tutto per passare ad un sistema monolitico che includerà un po' tutto quello che ora invece è delegato a vari sottosistemi indipendenti e testati da decenni di uso in ambiente ostile.

La filosofia unix non è una minchiata, deriva da decenni di esperienza e ha dimostrato di essere ottimale in termini di modularità e sicurezza. Se per esempio wget si rompe... basta aggiustare wget. Nessun riavvio necessario, nessuna necessità di ricompilazione di niente a parte wget, tutti i programmi che usano wget in background ora automagicamente useranno quello nuovo. Se poi wget non ti piace puoi facilmente crearne un sostituto senza dover cambiare niente altro nel tuo sistema.

Da un punto di vista della sicurezza di un sistema... più piccolo e semplice è e meno problemi provoca... e la sicurezza in un SO dovrebbe essere prioritaria rispetto a tutte le altre considerazioni, soprattutto se si tratta di server (ma anche a casa mia pretendo che i miei computer siano il più possibile sicuri, di quello che succede a casa altrui non mi interessa nulla).

Quando hai a che fare con un minestrone di migliaia di righe di codice, magari scritte in un linguaggio error-prone come C/C++, scritte da decine di persone diverse con altrettanti stili di programmazione diversi finisce quasi certamente nel disastro.

> e sysv ha un approccio peggiore al problema di gestire i demoni.

Mah, sarà anche peggiore, ma ha funzionato per decenni... ed essendo pure semplice i bugfix che ha necessitato negli anni si contano sulle dita di una mano.
Possiamo fare le stesse considerazioni su Systemd? No.
Possiamo ragionevolmente prevedere che Systemd si comporterà altrettanto bene? No, anzi, tutte le premesse fanno pensare che non sarà così.

> Il problema di systemd è l'integrazione di gnome e come sia diventato una sua dipendenza, rendendo necessario anche solo installare systemd (senza che sia l'init di sistema) per poter usare il desktop.

Questo in realtà non riguarda solo Gnome. Systemd vuole essere un po' tutto e perciò è normale che gli altri sistemi comincino a richiederlo come dipendenza. Systemd sembra più una sorta di trojan che piano piano si espande all'intero sistema rendendoti impossibile far funzionare il tuo sistema in modo indipendente da esso che un init-system.

Negli anni vedrai che sempre più sistemi e sottosistemi DOVRANNO avere Systemd come dipendenza... prova a quel punto a proporre qualcosa di diverso... come potresti fare? Immagina che Systemd si riveli essere una cattiva scelta... come lo sostituisci se tutto il resto di Linux dipenderà da esso?

Cambiare init oggi è facile... domani, con Systemd, potrebbe non essere così semplice.

> Il problema degli aggiornamenti di systemd invece non esiste, finora sono stati retrocompatibili dal punto di vista di interfacce binarie (dbus), rendendo possibile l'uso del sistema dopo un update senza "urgenza" di riavviare (systemctl & co. continuano a funzionare).

Bé, speriamo tu abbia ragione, i miei server non li voglio riavviare ogni volta che qualcuno a RedHat starnutisce.