[Verdebinario] [Hacklab-Cosenza] Linux Day

[Kbyte]

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

Sappiamo entrambi che RedHat prima di adottare qualcosa aspetta che sia ben
testata utilizzando fedora e centos come testa di ponte. Systemd come
default in fedora è del 2011, in centos dal 2013, l'adozione in redhat è
stata solo questione di tempo.


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

Canonical ha commesso due errori, uno politico ed uno tecnico. Quello
politico è di non aver voluto realmente coinvolgere le altre distribuzioni
nello sviluppo per via della sua CLA, facendo incavolare diversi
sviluppatori Debian al punto di ragionare ad un fork piuttosto che una
effettiva collaborazione. Quello tecnico è stato di guardare troppo alle
funzionalità care a Ubuntu e meno a quelle degli upstream, che richiedevano
funzionalità più avanzate come l'attivazione dei servizi on demand e simili
(quest'ultimi in parte sviluppati, ma lontani dall'essere funzionanti).

Se Debian e Ubuntu fossero stati uniti nello sviluppo di upstart,
probabilmente systemd non sarebbe neppure esistito o comunque non avrebbe
avuto questa rilevanza, su questo penso che entrambi possiamo concordare :P

Ora non voglio fare il gufo, ma credo che canonical stia commettendo lo
stesso errore con mir.

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

Ma no dai.

Stiamo parlando di un sistema di init (e non è mica l'unico in
circolazione, ce ne sono tanti), non di un mutuo.

Se le cose andranno male verrà cambiato alla velocità della luce.


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

Posso capire le fasi di transizione che sono sempre problematiche, ma
stiamo parlando di un oggetto che offre la quasi totale compatibilità con
sysv, per cui quello che funzionava prima deve poter funzionare anche ora.
Compreso Enlightment o altro software non più sviluppato attivamente.

Per questo io non riesco a percepire la minaccia, ma potrei anche essere
semplicemente troppo pigro e dunque non essere riuscito a trovare un
esempio concreto.

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

Non limitiamo il discorso a solo gnome. Non è la sola che ha iniziato a
utilizzare le possibilità di systemd e anche altri upstream sono già
"pronti". Per esempio nginx ha già pronto il necessario per l'avvio on
demand attraverso l'attivazione socket.

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

Si vero. Io ho fatto il caso di una libreria X, ma ho parlato anche di
componente di sistema. Anche il cambio di Kernel può portare a una qualche
tipo di rivoluzione (ovviamente per i programmi che fanno uso delle
funzionalità del kernel), le libc hanno portato a fasi di transizioni e
mutamenti (qualcuno ricorda il passaggio dalle glibc5 alle glibc6? io si),
dbus ha portato a cambiamenti sostanziali non senza stravolgimenti. E in
tutti questi esempi il raggio di azione è stato forse più pesante del
cambio di init.


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

Il mio forka era per dire che volendo si può sempre fare un qualcosa di più
appetibile (anche ex novo, non forkato), che faccia il necessario e che
allo stesso tempo appaga gli sviluppatori del software che nel 2014
richiedono alcune funzionalità specifiche. Per questo io parlo di mancanza
di alternative, non perché voglio un clone di systemd, ma perché voglio che
alcune funzionalità, soprattutto lato sistemistico, siano presenti in un
sistema moderno (per questo io insisto nel parlare di tecnologia, perché di
tutto il resto poco mi importa).

Il problema è che chi si oppone, mi pare di capire, non vuole queste
funzionalità in toto.

E non è un discorso da frenesia tecnologica, basti pensare che solaris ci
ha pensato già nel 2005 realizzando un sistema molto simile a
launchd/systemd.


> 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 il problema è la retrocompatibilità, systemd è al 99% retrocompatibile
con sysv. Tornando all'esempio di Wayland, arriverà il giorno in cui con
weston non sarà più possibile replicare tutte le funzionalità di wayland
nei vecchi xorg. Un'applicazione scritta per supportare solo il protocollo
wayland non potrà dunque funzionare nei vecchi sistemi.

In sostanza: se è sempre gradita la retrocompatibilità, la compatibilità
inversa non è sempre (in alcuni casi mai) stata possibile.

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

Certo! E il TC ha deciso.

Se avesse deciso il contrario io avrei rispettato tale decisione. Più
interessante ora sono i due GR proposti, uno dei quali propone che
l'upstream di un software possa si richiedere un tipo di init in
particolare, ma quando possibile deve essere garantito il supporto anche
agli altri. (il GR proposto da Ian Jackson nella sua formula originaria non
mi piace, ha il rischio di caricare i mantainers di una mole di lavoro
eccessiva e cerca di imporre agli upstream delle scelte tecnologiche, cosa
mai vista in Debian e probabilmente fuori dal suo statuto).

Non è già un passo in avanti?

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

E ci sta tutto.

Però sono 20/25 anni che periodicamente vi sono questo tipo di
preoccupazioni per i motivi più disparati, eppure siamo ancora qui a
utilizzare Linux e i suoi derivati perché qualsiasi cosa accada la comunità
saprà sempre come correggere i propri sbagli e andare avanti.

Sono fiducioso a prescindere da systemd o meno.

Goodnight :P

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