[Verdebinario] [Hacklab-Cosenza] Linux Day

[Stefano De Carlo]

Il 22/10/2014 17:39, Kbyte ha scritto:
>
>>
>     La tua metrica era, dunque, aneddotica. Ne prendo atto.
>
>
> Perché scusa?

"Persone che conosco", "un post", "uno sviluppatore", "un forum".
Se ora io metto il link al reasoning di un developer anti-systemd, o mi riferisco ad uno qualsiasi dei rant anti-systemd di qualche hacklabber, che cosa significa, cosa aggiungerebbe?
Oltretutto, nel brano iniziale sostenevi che molti user fossero in qualche modo contenti dello switch, ben diverso da "hanno taciuto, hanno acconsentito".
È tutta aneddotica. Andiamo avanti.

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

Best Practice: usiate un solo gestore di cgroups, grazie, la direzione.
È perfettamente ok se questo gestore è systemd, ed è meraviglioso se sia il migliore in giro.
Non va affatto bene se, invece, le politiche di sviluppo di systemd rendono _concretamente_ impossibile la sopravvivenza di alternative che vogliano offrire anche solo _parte_ delle sue funzionalità, ora e in futuro.

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

A parte che l'idea di non poter disabilitare un software che NON si vuole sul proprio sistema, codice in esecuzione coatta forzata, dovrebbe far accapponare la pelle di qualsiasi sistemista.
Se Xorg ti dicesse che *devi* avere in esecuzione anche la generic implementation di llvmpipe oltre al tuo driver grafico specifico, ti sembrerebbe una cosa sensata? "Ehi, ma tanto lo aggiri dalla config..."
Non c'è *nessuna* ragione per cui journald debba stare li a fare forwarding. A meno che non vuoi far leva su altri elementi del tuo feature set per, alla fine, imporlo per sfinimento. Tipo...

"non obbliga nessuno": non appena kdbus verrà mergiato nel kernel, udev avrà una hard-dependency su systemd, decretando di fatto l'impossibilità di avere udev upstream su sistemi non-systemd.
Questo è stato già annunciato dal team systemd.
Questo arriva dopo che era stato detto che la compatibilità sarebbe stata mantenuta "for a long time". 2 anni non sono un long time, quando parli dell'event system usato da pressoché ogni distribuzione.
Allo stato attuale, qualsiasi distro sarebbe folle a basare il proprio sviluppo sulla garanzia che una data funzionalità rimarrà "delegabile" lontano da systemd. Infatti, non lo sta facendo nessuno.

"Ho usato l'event system? No. Ho usato il login system? No.": certo che li hai usati. udev (event system) sta lì e serve che sia o meno attivo l'offloading agli script bash di init, e come ti ho detto è stato co-optato da systemd. I tuoi script init devono avviare Gnome 3.14+? Hai usato logind.

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

Questa cosa che non esistono alternative a systemd, non la sto capendo.
Fino a 4 mesi fa Red Hat, sui suoi sistemi miliardari, faceva girare upstart.
Canonical ha speso milioni su un sistema di init perfettamente funzionante, dalla quale non aveva alcuna intenzione di switchare ("systemd is hugely invasive, hardly justifiable", Shuttleworth). Lo ha fatto perché un sistema non-systemd è ormai insostenibile.

Io non sto proponendo di fermare systemd.
Io sto facendo notare che siamo già a tanto così dal punto di non ritorno dove, se dovessimo o volessimo fermarlo, non potremmo.
Non mi piace questa situazione. È pericolosa, e non era necessaria.


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

In nessuna delle transizioni che puoi nominare si è trattato di un software così orizzontale e dallo scope così vasto come systemd.
Una eventuale futura transizione lontano da systemd sarà molto più dolorosa, e lo sarà per via delle scelte fatte da systemd, e da chi lo adotta, *oggi*.
Vedi sotto.

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

Applicare "survival of the fittest" all'open source è tristissimo e quanto di più sbagliato riesca a immaginare.
Enlightment campa da 20 anni con una user base ridicola. Èd è possibile perchè il software FOSS permette di creare tante piccole giungle dove ognuno ha il suo fittest.
systemd, nelle sue politiche di sviluppo, minaccia precisamente questo. "Migliore" non c'entra di striscio.

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

Corretto.
E infatti GNOME si è beccato la sua bella dose di critiche in proposito.
Ma non ha alcun senso prendersela con GNOME che adopera una funzionalità di systemd disponibile.
Per me ne ha invece tantissimo far notare il nonsense che vuole systemd far leva sul suo feature set globale e renderla "non reimplentabile indipendentemente", per _nessuna_ ragione.
Ripeto: per svettare in termini di superiorità tecnica non c'era alcun bisogno, per systemd, di rendere parti vitali "non reimplementabili indipendentemente".

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

Di nuovo: scope.
Una libreria ha un raggio d'azione definibile.
Non importa quanto grande, per "scappare" via da quella libreria e garantirti una transizione non assassina (retrocompatibile, anche temporaneamente) ti è sufficiente reimplementare quello scope definito, e più le interfacce sono stabili più il compito è fattibile.
E transizioni.

Con systemd non puoi, perché il suo scope è troppo vasto.
"Forka" non è una risposta se per reimplementare il journal o un event manager devi reimplementarti un init, e con essa qualsiasi componente del sottoinsieme dello scope tu ti stavi affidando.
Non saranno possibili transizioni non suicide.
E questo per nessuna ragione.

>
>     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. [...]

Niente di quel che hai detto su rootless xorg è lontanamente rilevante a quanto sopra.
Ti ripeto: Wayland è figo, no? Passiamo a Wayland.
Ma non dobbiamo suicidarci nel passaggio, quindi XWayland assieme a Wayland per retrocompatibilità con le app non gestibili su Wayland.
Questo è possibile perché le API di xorg sono _stabili_. C'è fiducia, millenaria, che quelli di Xorg non faranno cazzate svegliandosi al mattino cambiando XCB perché gli va.

Se quelli di Xorg trattassero le loro API come le tratta systemd, non sarebbe possibile nessun XWayland.
Di conseguenza, qualsiasi transizione a Wayland non sarebbe in grado di garantire la compatibilità, all'utente, con qualsiasi app.
Un massacro. In comoda forma tabellare.

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

Lo sai che era una delle opzioni del ballot Debian, giusto?

>  
>
> Vedi il problema: ti focalizzi troppo sulle persone

?
Ho menzionato Lennart 1 volta in 4 mail.
Sono dichiarazioni verificabili, e la constatazione che è un obbiettivo alla sua portata altrettanto.

> e poco sulle possibilità, comprese quelle di realizzare un qualcosa che non sia systemd, ma che abbia caratteristiche ugualmente succose. [...] (e non mi riferisco a systemd, ma magari a un suo sostituto "migliore" dal tuo punto di vista).
>

Dovrebbe essere oltremodo chiaro, ormai, che la possibilità di un'alternativa a systemd è l'unica cosa di cui ho parlato, davvero. E mica poco. :)

> Per cui il "no" a prescindere

Non appena Ubuntu ci switcha, *userò* systemd.
Ti ho già detto che systemd è tecnicamente superiore.
Non vuol dire che non debba essere preoccupato dalle ripercussioni complessive sul mondo FOSS sulle scelte, *non* tecniche del progetto.

Stefanauss.

-------------- 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/20141023/f3a7032a/attachment.bin>