[Verdebinario] [Hacklab-Cosenza] Linux Day

[Stefano De Carlo]

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

Il mio punto in questo passaggio è che non si può dipingere un contesto dove altri init fino all'altro ieri hanno svolto compiti delicati, mission critical, una situazione "in assenza di alternative [valide]".
Questo, in congiunzione col fatto che sebbene globalmente superiore, systemd non è comunque adatto in *qualsiasi* caso d'uso dove altre alternative esistenti e persino l'incumbent uscente sono un miglior fit, rende "assenza di alternative valide" una brutta rappresentazione dello stato di cose attuale, eccessivamente votata al tuo giudizio tecnico, positivo, di systemd in relazione al tuo use case (come dici tu stesso successivamente).

>  
> Canonical ha commesso due errori, uno politico ed uno tecnico. [...]
> , 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.
>

Sull'analisi delle strategie di Canonical si potrebbero spendere altre decine di mail, e personalmente è uno dei temi che più mi interessano, ma è vero che ci porterebbero proprio fuori focus.

Mi limito a dire che hai ragione sul rapporto causa-conseguenza di certe scelte che hai individuato, ma che questa politica "going it alone" è deliberata e consapevole, applicata con progressiva continuità.

Ed è vero che può essere un errore politico e tecnico. Mir vs Wayland ha il potenziale di essere della categoria di systemd, in quando a punti di non ritorno. Si, sono preoccupato anche qui, ma per forza di cose (esattamente 0-0 in distro che li implementano) è tutto più fumoso che con la situazione di systemd che invece trovo ormai ben definita.

Viviamo nell'epoca dei grandi shift del dektop Linux, che purtroppo arrivano in un momento di progressiva perdita di rilevanza del desktop stesso.


>
> Se le cose andranno male verrà cambiato alla velocità della luce.
> 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.
>

Vedi giù per un'analisi più pragmatica.

>
> Non limitiamo il discorso a solo gnome.

Infatti, ben lungi dal limitarlo! Il fulcro dell'elemento di rischio è quando la rete di hard-dependency sarà troppo interconnessa con gli elementi "not reimplementable indipendently", e ci sono sempre più upstream che si innestano nel feature set di systemd come fai notare.

> [...] E in tutti questi esempi il raggio di azione è stato forse più pesante del cambio di init.

No way. Ma manco vicino.
Confondi la low-levelness del cambiamento con il suo scope.
Ok, cambi la libreria del C. Compito che spaventa. Problemi all'orizzonte, saltano fuori aspetti non previsti in un cambio così grande. Serve gente cazzuta che sappia cosa fa.
Ma rimane una *libreria del C*, una cosa definita (standard, addirittura). Non ti ritrovi dei container hardcoded, un bootloader, o che altro dopo che transizioni da una *libreria del C* ad un'altra *libreria del C*.
Quando ti affidi, scrivi, modifichi una libreria del C sai *cosa* sarà afflito dal cambiamento e si tratta di 1 o 2 livelli di interdipendenza.
Non è quanto accade con systemd. Vedi giù.

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

Ma non io. :P
I miei concern verso systemd sono precisi.

> Se il problema è la retrocompatibilità, systemd è al 99% retrocompatibile con sysv.

Non è alla comptibilità systemd -> sysv a cui mi riferisco, ma a quella di systemd-next -> systemd.
systemd non è solo un init system, ma fornisce
* event system (udevd, presto systemd-udev)
* logind (login manager)
* session manager
* journald (Logging service)
* systemd-networkd (Network Managing)
* terminal switching
* keyboard manager
* dhcp daemon (????)
* timedated
* localed
* hostnamed (hostname naming and resolution)
* timesyncd (time synchronization)
* whatthefuckthislistislongohpleasestopohgodd

AND counting. L'altro mese il team di systemd, nella persona di Lennart, ha chiaramente esposto i piani per arrivare fino al package management.

Non c'è problema in tutto questo, di per sè. Molto del dibattito di pessima qualità su systemd verte su dogmi tipo "Unix Philosophy" senza andare a vedere il merito tecnico (anche se, è indubbio, che si sta passando da un estremo all'altro).

Il problema sta che per le ragioni già abbondantemente esposte *nessuna delle quali valida* siamo nella *evitabile* situazione dove questi componenti sono "not reimplementable indipendently".
Per favore nota che, sebbene systemd sia 80 e passi binari, *non è modulare* in senso significativo. Questi componenti sono quasi tutti legati alle API instabili del demone principale. È il significato di "not reimplementable indipendently".
Che cosa succede quindi quando i software di più alto livello, che come abbiamo già detto stanno già cominciando, fanno affidamento a questi bit "not reimplentable indipendently"? E che cosa succede quando vorremo sviluppare "il prossimo init system"?

Succede che se vuoi un nuovo event system, devi forkarti tutto systemd (e se non sei Linux, devi pure reimplementarti kdbus).
Succede che se sei 3 righe di codice lontano dal non poter avere altro logging system al di fuori di journald su qualsiasi Linux.
Succede che se vuoi GNOME ma non systemd sulla tua distro, devi o reimplementare... *systemd*, o forkare GNOME.
Ma puoi davvero forkare GNOME? Ora come ora è solo logind. Quelle funzionalità di systemd sono lì per essere usate però, e lo saranno.
I desktop finiranno per inserire wrapper alle funzionalità di systemd nei vari libqt-kde o libgnome (perché è questo che i DE fanno), che di conseguenza finiranno per essere usate dalle applicazioni. Magari da quella superfiga e utile che avrà tanti utenti. E molte altre ancora, su cui gli utenti cominceranno a fare affidamento.
Aggiungi un po' di tempo al mix e avrai una rete di hard-dependency che, *anche se il tuo target è su un singolo componente*, ti sarà insostenibile reimplementare. Stiamo viaggiando spediti verso una situazione dove systemd è "l'ultimo della sua specie" per manifeste impossibilità riproduttive.
In futuro, se la politica di sviluppo rimane questa, fornire un'alternativa a systemd comporterà dover farsi carico di tutte le sovrastrutture che si sono indissolubilmente legate ai suoi bit "not reimplementable indipendently", che nel frattempo avrà coinvolto le app.
Dimmi tu che transizione più esserci, lontano da systemd, se per i sistemi diventerà impossibile continuare a utilizzare le applicazioni necessarie durante la transizione.
Una alternativa insostenibile equivale a nessuna alternativa.


 

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

Non è una questione di compatibilità systemd -> systemd-next.

>
> Certo! E il TC ha deciso.
> Se avesse deciso il contrario io avrei rispettato tale decisione.

Rispetto anche io la decisione del TC.
Il processo decisionale di Debian è una delle più belle cose del panorama FOSS, un sistema di governance oggetto di molti studi. Non apprezzo chi come Ian Jackson cerca di macchiare qualcosa che come tutto è perfezionabile, ma che funziona.

Oltretutto so perfettamente che il TC aveva tutti gli elementi, persino quelli che ho portato io, a disposizione, non si tratta di informazioni parziali o paraocchi. Persino tra chi ha votato per systemd c'è chi ha espresso preoccupazioni simili.

Ritengo che abbiano fatto un errore,e valutato male le priorità dei singoli elementi decisionali. Non penso che questo significhi mancare di rispetto alle prerogative del TC.

Sono deluso perché il TC avrebbe potuto, nella mia opinione, mandare un messaggio preciso e fortissimo rimanendo sull'incumbent, ma contemporaneamente eleggendo systemd come la chiara preferenza tecnica. Non implementata unicamente per via delle politiche di gestione del progetto.
Avrei voluto questa wake-up call, difficilmente ignorabile (è Debian dopotutto), indirizzata a systemd: "siete fighi, vi vogliamo, ma non finché pisciate sugli alberi".

>
> Non è già un passo in avanti?
>
No. Le GR sono irrilevanti, per me. Come ti ho già detto non si tratta della transizione sysv -> systemd.


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/9aa21c8d/attachment-0001.bin>