[Verdebinario] [Hacklab-Cosenza] Linux Day

[Kbyte]

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

Che non è adatto a qualsiasi caso d'uso è ovvio. Ma chi lo è? Ci sarà
sempre un caso d'uso non adeguato a prescindere di qualsiasi scelta.
Ricorda che per le alternative mi riferisco a un set ristretto di
funzionalità di systemd che ho indicato più volte e che sarebbero
graditissime se vi fosse un altro sistema che le fornisce.

E non diciamo che è "impossibile" avere un'alternativa, basta vedere
uselessd: è già qualcosa di parzialmente pronto (si lo so forkato da
systemd, può anche apparire qualcosa di totalmente diverso) e bisognerà
vedere quanto sarà realmente usabile, cosa offrirà e soprattutto tra quando.

Volontà. Io credo che il vero problema è la volontà di avere un'alternativa.



> 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.
> [omissis]
> Viviamo nell'epoca dei grandi shift del dektop Linux, che purtroppo
> arrivano in un momento di progressiva perdita di rilevanza del desktop
> stesso.
>

Si. Indubbiamente. E a mio parere la concorrenza tra due proposte
concorrenti potrà solo portare vantaggi nel lungo periodo se tutto andrà
per il meglio.


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

Verissimo. Ma ripeto: se per esempio esistesse qualcosa che funziona meglio
di logind (consolekit purtroppo è morto), secondo te gli upstream non
inizierebbero ad usarlo?


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

Quando vi fu il cambio delle libc il numero di programmi affetti fu pauroso
e alcuni programmi non più attivamente sviluppati impiegarono molto tempo
per essere aggiornati o scomparvero del tutto. Ma parliamo di ere fa.
Programmavo ancora in c++ all'epoca :P


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

E sono d'accordo con te che è esagerato, però alcune delle features "di
troppo" che hai elencato io credo che debbano essere presenti in un gestore
di servizi nel 2014. Una via di mezzo sarebbe perfetta, in attesa che
arrivi mi "godo" le features che già sono implementate.


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

Tutte le soluzioni modulari si basano su un "core minimo" non
reimplementabile. Forse solo Hurd aveva in testa uno sviluppo totalmente
modulare. Ma la frase più interessante è questa:


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

Quando vuoi sviluppare il tuo init system farai le tue scelte. E se gli
sviluppatori di più alto livello le ritengono apprezzabili, oltre a
supportare quelle degli altri, supporterà anche le tue. Non è la prima
volta che capita e chi progetta oggi software di una certa dimensione in
realtà modularizza (se non è pazzo a.k.a. leggi devs gnome) il proprio
codice per tenersi aperte tante strade.

Per esempio Kde utilizzerà a pieno systemd, ma chi vorrà potrà farlo girare
senza alcun obbligo e con l'init che preferisce.

Io amo Kde, anche se anche qui in lista qualcuno lo disprezza aspramente
con ragioni a mio avviso ingiustificate, perché ha creato un framework di
librerie e dei sotto sistemi pensando a qualsiasi evenienza, comprese
quelle di girare sotto windows (https://windows.kde.org/).

Il vero problema in tutto questo marasma è Gnome, che detto tra noi, per me
se ne fotte altamente dell'utenza non oggi con systemd, ma da quando ha
introdotto la  "stupid mode"  rendendo difficile la vita anche agli
sviluppatori di applicazioni "native" gnome. (infatti la quasi totalità
delle applicazioni di GNOME utilizzano prevalentemente le GTK e gvfs senza
toccare altro).

Succede che se vuoi un nuovo event system, devi forkarti tutto systemd (e
> se non sei Linux, devi pure reimplementarti kdbus).
>

Due note. La prima è che se qualcosa viene inglobata nel kernel, non
capisco perché si debba reimplementare la ruota. La seconda è che il
discorso "e se non sei Linux" lascia un po' il tempo che trova, perché
altri in altri SO, compresi BSD e derivati, se ne fregano altamente di fare
un pensiero analogo quando si tratta di utilizzare proprie funzionalità non
replicabili su Linux.

Anche qui la responsabilità ricade su chi scrive il software. Apache ha i
moduli mpm per sfruttare le caratteristiche native di Linux, quelle di BSD
e persino di Windows. Ora non so se gnome ha deciso di droppare BSD, ma
dubito che la colpa sia di systemd.


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

Che Gnome sia pessimo sotto questo aspetto siamo concordi.

Se a gran parte della comunità non sta bene e non si può forkare si può
benissimo passare ad altro. Io non uso più Gnome da ere ormai, salvo
qualche sporadica applicazione GTK non legata al DE. Però mi roderebbe non
poco sapere che a KDE vengono inibite alcune funzionalità interessanti
opzionali, pur garantendo piena compatibilità, per colpa della diatriba
Gnome/Systemd.


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

Sono pienamente d'accordo con l'ultima parte del periodo, quanto dici è un
pericolo reale, ma lo sono molto meno con la parte iniziale. Da
sviluppatore software so per certo che nel lungo periodo nessuna scelta è
per sempre. Nessuna.

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

A me non piace Ian Jackson proprio perché ritengo che il suo modo di fare
non aiuta Debian e non aiuta soprattutto la sua causa.


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

Si, però avrebbe aperto un caso unico Debian: cercare di dettare le linee
guida agli upstream riguardo lo sviluppo del proprio software. e qui
arriviamo alla tua ultima frase:


> No. Le GR sono irrilevanti, per me. Come ti ho già detto non si tratta
> della transizione sysv -> systemd.
>

Qui sbagli. perché nella "democrazia" di debian questi GR sono più
rilevanti di qualsiasi transizione perché governerà i futuri principi  di
Debian. Ognuna delle quattro scelte proposte aprirà scenari politici molto
pesanti con possibili impatti consistenti su come abbiamo vissuto fin oggi
Debian.

Nei vari gradi di colore, si inizia con la possibilità di sovvertire le
decisioni del TC, alla possibilità di imporre linee di sviluppo, al totale
abbandono alle scelte dell'upstream, fino a terminare con la necessità di
regolamentare il meccanismo dei GR per evitare proposte come quella fatta
da Ian Jackson (se passasse la quarta opzione).

In sostanza appassionanti esercizi democratici di una comunità libera.

-- 
| /
| \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/89a04994/attachment-0001.html>