[Verdebinario] [Hacklab-Cosenza] Linux Day

[Stefano De Carlo]

Il 22/10/2014 15:04, Kbyte ha scritto:
>
> 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.

>  
>
> La decisione era già nell'aria da tempo, visto che parte degli sviluppatori di upstart sono passati a systemd.

Non ci siamo. upstart era, ed è, un software sotto CLA Canonical.
Una percentuale altissima del codice di upstart, a causa di ciò, è sviluppato da impiegati Canonical.
Se sei impiegato Canonical non "passi a systemd". Lo puoi sviluppare nel tempo libero, ma fai quello che ti dice l'azienda.
E se la lasci, per "passare a systemd", Canonical prende quei soldi e li da a qualcun altro.
La decisione era nell'aria da tempo, ma unicamente per la sua ovvietà economica.

>
> Se non è per merito, per quale ragione viene adottato? Si crede veramente che l'intera comunità del software libero sia talmente influenzata da qualcuno/qualcosa per decidere di adottare un componente così importante senza un reale vantaggio tecnico? Ripeto, si può parlare tecnicamente su ogni sua funzionalità e poi dire "si è utile, no non è utile", ma ogni volta si arriva a sviare il discorso tecnico, che io adorerei affrontare, perché si parla di tecnologia.

A me non interessa il lato tecnico. Chissene, davvero.
systemd è, in quasi ogni aspetto, una soluzione tecnologicamente superiore.

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.
È 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à.
(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?)

>  
> 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.
Che è in numero crescente.
E che non è software *banale*.

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.

È 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.

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.

>  
>
> 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?

Stefanauss.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <https://mailman-mail5.webfaction.com/pipermail/verdebinario/attachments/20141022/08b13649/attachment.html>
-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        signature.asc
Tipo:        application/pgp-signature
Dimensione:  819 bytes
Descrizione: OpenPGP digital signature
URL:         <https://mailman-mail5.webfaction.com/pipermail/verdebinario/attachments/20141022/08b13649/attachment.bin>