[Verdebinario] [Hacklab-Cosenza] Linux Day

[Kbyte]

>
> Ero ironico ovviamente, per dire che molti utenti neppure se ne sono
> accorti. [...]
>
>  https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
>
> La tua metrica era, dunque, aneddotica. Ne prendo atto.
>

Perché scusa? quel post è di uno degli sviluppatori di archlinux che
spiegava ai propri utenti il perché della sua adozione, a dimostrazione che
non è vero che gli utenti non hanno ancora avuto modo di provarlo e quindi
di lamentarsi.


> Domanda: ha bisogno di fare hijacking di funzionalità low-level decisive
> come event system e login system, per avere questa superiorità tecnica? Di
> rendere insostenibile *rimanere* sugli init attuali per essere loro
> superiore?
> Risposta: no. Eppure sta succedendo.
>

E perché no scusa? Gli sviluppatori stessi del Kernel Linux, per esempio,
preferirebbero che vi sia un'unico gestore per cgroups attivo nel sistema e
systemd svolge perfettamente questo scopo. Poi ripeto, non obbliga nessuno
a usare il proprio sistema di eventi e di login, volendo puoi benissimo,
anche se non puoi disabilitarlo, aggirarlo. Esempio: puoi eseguire tutti
gli script init che vanno dalle operazioni basilari al desktop manager. Ho
usato l'event system? No. Ho usato il login system? No.


> È una cosa buona? Non lo so. A me preoccupa tanto, perché significa dare
> praticamente tutte le tubature del desktop Linux chiavi in mano ad un team
> di sviluppo che ha già una consolidata fama nel non accomodare la diversità.
>

Ecco. In questo mi trovi perfettamente d'accordo.

Parliamo chiaramente: io credo in systemd in quanto oggetto software che ho
provato e che ritengo molto interessante in funzionalità e prestazioni. Ma
di certo non santifico un team di sviluppo. Da qui però a oppormi, in
assenza di alternative, non me la sento proprio. Piuttosto è più sensato
forkare systemd (alcuni ci hanno già provato con scarso successo, in futuro
chissà), ma non cercarlo di fermarlo tout-court.


> (Perchè, voglio dire, siamo tutti d'accordo che se nel futuro systemd si
> dovesse rivelare una scelta inferiore a qualcos'altro, una transizione sia
> possibile da versione a versione di distro come è oggi, giusto?)
>

Non è la prima volta che capita in Linux.

E non sarà l'ultima. Alla fine, come sempre, sopravvive sempre il software
migliore.

Vero, però ce ne vuole a dire che non è modulare e che una buona parte
> delle sue funzionalità non possono essere delegate ad altro (compresi
> script bash). Inoltre parliamo sempre si un software libero, se uno vuole
> può sempre modificarlo a suo piacimento no?
>
> È una cosa vuotissima. Vedi la tabella di prima? Non c'è per le API per i
> servizi e demoni fondamentali la promessa di stabilità ("Reimplementable
> indipendently"). Chi dovesse forkare systemd si troverebbe di fronte
> all'insostenibile compito di questo perenne bersaglio mobile, o alla scelta
> di rendersi istantaneamente incompatibile con tutto il software di alto
> livello che, nel frattempo, sta scegliendo di basarsi su quelle interfacce.
> Così insostenibile che, alla fine dei conti, ci si adegua e basta.
>

Ma io non ti do torto. Affatto.

Solo che il problema non è solo di systemd, ma di chi sviluppa il software
di alto livello non trovi?

Da sempre esistono programmatori che decidono di non supportare la
libreria/componente sistema/framework X per usare Y.

Vedi non parlo neppure di un init, basta anche solo una libreria per
obbligarti a cambiamenti radicali.

Se le API di Xorg venissero trattate come quelle di systemd, scordati i
> layer di compatibilità tipo XWayland. E di conseguenza scordati Wayland,
> perché la transizione sarebbe devastante.
>

Opinioni. L'ultima di release si xorg supporta la possibilità di essere
eseguito rootless attraverso logind (aprendo la strada anche ai vari kdm e
gdm rootless), kde e gnome stanno già eliminando ciò che rimane
dell'abbandonato consolekit in favore di logind. Per usare wayland
attraverso kwin è già ora consigliato systemd e non per "sport", ma perché
si vuole evitare che l'X server e il compositore delle finestre debbano
girare con i privilegi di root solo per governare parte dell'hardware, con
i rischi sulla sicurezza che tutti conosciamo.


È diritto di quei software basarsi in hard-dependency su systemd. E di
> systemd di fare quel che vuole con le sue interfacce.
> La ritengo una strada pericolosa && non necessaria, funzionale solo alla
> vision tentacolare del team systemd.
>

Ripeto, sono opinioni, che purtroppo avranno sempre meno peso in assenza di
alternative valide. No, restare ancora con init non è una di esse.


> Ma magari mi sbaglio e finalmente dopo millenni avremo distribuzioni
> uniformate in tutti quei dettagli non-interessanti. Dopotutto Lennart ha da
> poco detto di voler uniformare anche il package management. Ormai si è
> costruito la potenza di fuoco per riuscirci.
>

Vedi il problema: ti focalizzi troppo sulle persone e poco sulle
possibilità, comprese quelle di realizzare un qualcosa che non sia systemd,
ma che abbia caratteristiche ugualmente succose. E' pacifico che siamo
parlando dell'universo del software libero, ci saranno sempre diversità di
opinioni "politiche" e tecniche, è anche grazie a questo che questo mondo
genera salti tecnologici in avanti (e non mi riferisco a systemd, ma magari
a un suo sostituto "migliore" dal tuo punto di vista).

Per cui il "no" a prescindere in questo ambito non riesco proprio a
capirlo, come sviluppatore, come sistemista e come amante del software
libero.

>
> Io però guardo anche al passato, vi furono le stesse critiche su udev (se
> non più violente in alcuni momenti)
>
> Ma io dovrei tipo dedurre che, se erano esagerate e non argomentate le
> critiche ad udev, ora lo sono quelle a systemd?
>

Ovviamente no. E' per dire che per quante critiche ci possono essere (chi
ti dice poi che le critiche a udev non erano argomentate? Lo erano, a
avevano una visione tecnologica troppo conservativa), il risultato di un
sistema si valuta nel tempo e con l'utilizzo.

-- 
| /
| \Byte - Andrea Briganti
Blog: http://kbyte.snowpenguin.org
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <https://mailman-mail5.webfaction.com/pipermail/verdebinario/attachments/20141022/06dc790e/attachment-0001.html>