<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> 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.<br>
<br>
</span>Questa cosa che non esistono alternative a systemd, non la sto capendo.<br>
Fino a 4 mesi fa Red Hat, sui suoi sistemi miliardari, faceva girare upstart.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>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).</div><div><br></div><div>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<br></div><div><br></div><div>Ora non voglio fare il gufo, ma credo che canonical stia commettendo lo stesso errore con mir.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Io sto facendo notare che siamo già a tanto così dal punto di non ritorno dove, se dovessimo o volessimo fermarlo, non potremmo.<br>
Non mi piace questa situazione. È pericolosa, e non era necessaria.<br></blockquote><div><br></div><div>Ma no dai. </div><div><br></div><div>Stiamo parlando di un sistema di init (e non è mica l'unico in circolazione, ce ne sono tanti), non di un mutuo.</div><div><br></div><div>Se le cose andranno male verrà cambiato alla velocità della luce.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> E non sarà l'ultima. Alla fine, come sempre, sopravvive sempre il software migliore.<br>
</span>Applicare "survival of the fittest" all'open source è tristissimo e quanto di più sbagliato riesca a immaginare.<br>
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.<br>
systemd, nelle sue politiche di sviluppo, minaccia precisamente questo. "Migliore" non c'entra di striscio.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> Solo che il problema non è solo di systemd, ma di chi sviluppa il software di alto livello non trovi?<br></span>Corretto.<br>
E infatti GNOME si è beccato la sua bella dose di critiche in proposito.<br>
Ma non ha alcun senso prendersela con GNOME che adopera una funzionalità di systemd disponibile.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> Da sempre esistono programmatori che decidono di non supportare la libreria/componente sistema/framework X per usare Y.<br>> Vedi non parlo neppure di un init, basta anche solo una libreria per obbligarti a cambiamenti radicali.<br>
</span>Di nuovo: scope.<br>
Una libreria ha un raggio d'azione definibile.<br>
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.<br>
E transizioni.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Con systemd non puoi, perché il suo scope è troppo vasto.<br>
"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.<br>
Non saranno possibili transizioni non suicide.<br>
E questo per nessuna ragione.<br></blockquote><div><br></div><div>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).</div><div><br></div><div>Il problema è che chi si oppone, mi pare di capire, non vuole queste funzionalità in toto.<br></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Niente di quel che hai detto su rootless xorg è lontanamente rilevante a quanto sopra.<br>
Ti ripeto: Wayland è figo, no? Passiamo a Wayland.<br>
Ma non dobbiamo suicidarci nel passaggio, quindi XWayland assieme a Wayland per retrocompatibilità con le app non gestibili su Wayland.<br>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>In sostanza: se è sempre gradita la retrocompatibilità, la compatibilità inversa non è sempre (in alcuni casi mai) stata possibile.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> Ripeto, sono opinioni, che purtroppo avranno sempre meno peso in assenza di alternative valide. No, restare ancora con init non è una di esse.<br>
</span>Lo sai che era una delle opzioni del ballot Debian, giusto?<br></blockquote><div><br></div><div>Certo! E il TC ha deciso.</div><div><br></div><div>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).</div><div><br></div><div>Non è già un passo in avanti?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Non appena Ubuntu ci switcha, *userò* systemd.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Ti ho già detto che systemd è tecnicamente superiore.<br>
Non vuol dire che non debba essere preoccupato dalle ripercussioni complessive sul mondo FOSS sulle scelte, *non* tecniche del progetto.<br></blockquote><div><br></div><div>E ci sta tutto.</div><div><br></div><div>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.</div><div><br></div><div>Sono fiducioso a prescindere da systemd o meno.</div></div><div><br></div><div>Goodnight :P</div><div><br></div>-- <br><div dir="ltr"><span style="font-size:12.8000001907349px">| /</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">| \Byte - Andrea Briganti</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Blog: </span><a href="http://kbyte.snowpenguin.org/" style="font-size:12.8000001907349px" target="_blank">http://kbyte.snowpenguin.org</a><br></div>
</div></div>