systemd cosa ne pensate ?

[IngMetallo]

Prendendo spunto dall'intervento di pablyto, apro questa discussione per parlare di systemd :D
Intervengo con un piccolo OT tanto per dire che boycotsysemd.org credo si sia spostato qui without-systemd.org (http://without-systemd.org/wiki/index.php/Main_Page). Tra l'altro, mi farebbe piacere capirci qualcosa in più sulla faccenda e sapere se e come si può fare a meno di systemd (che, a quanto leggo in giro, non pare abbia portato significativi vantaggi all'ultente medio, ad esempio in termi di velocità d'avvio).

Allora per quello che ne so io, tutte le distribuzioni più importanti usando systemd come sistema di init, quindi di alternative ce ne sono poche:

- Gentoo che utilizza OpenRC, ma è difficile da installare
- Devuan che è un fork di Debian con un sistema di init diverso. Al momento non ci sono ancora iso per provarlo.

A me systemd piace abbastanza, mi sembra facile da usare per le mie configurazioni di base e non ho trovato alcuna regressione rispetto al passato; quest'ultima non è una cosa banale, visto i problemi che sta avendo wayland per rimpiazzare xorg.

[ishtar1900]

Guarda, sui forum hanno discusso mesi su systemd, sopratutto sul fatto che addottare questo sistema di init fosse una "marchetta" a redhat , in poco tempo si sono create 2 fazioni che si sono scannate a vicenda adducendo a proprio favore le piu fantasiose ipotesi, oltre naturalmente a obiezioni reali.
Personalmente, se stiamo a discutere in termini teorici, penso che un sistema di init debba limitarsi a fare solo quello, vuoi per semplicità, vuoi perchè poche righe di codice sono piu semplici da aggiornare in caso di bugs. E' piuttosto ovvio che quando integri svariate funzioni aggiuntive, vedi ultime news riguardanti addirittura l'integrazione del boot tramite goomboot, il software diventa complesso, macchinoso, una filosofia di funzionamento che si discosta parecchio da cio che è sempre sta linux, inteso come S.O.
Detto cio, uso da anni Arch, e quando a fine 2012 decisero di passare a systemd come sistema di init di default, ho addottato anch'io questo sistema, e in termini pratici devo ammettere che è piuttosto intuitivo, comodo e funzionale, non ho mai riscontrato problemi irrisolvibili e non ho mai pensato di sostituirlo.

In merito alla domanda se è possibile sostituirlo, su arch è possibile, volendo vi sono varie opportunità https://wiki.archlinux.org/index.php/Init , su debian onestamente non so se tali opzioni sono compatibili

ps:
esiste gia un thread sull'argomento http://www.hwupgrade.it/forum/showthread.php?t=2693391

[IngMetallo]

ps:
esiste gia un thread sull'argomento http://www.hwupgrade.it/forum/showthread.php?t=2693391

Ops me l'ero proprio perso, grazie per la segnalazione ;)

[pablyto]

L'articolo in se non mi sembra particolarmente interessante, ma ho trovato piuttosto stimolante la discussione che si è sviluppata nei commenti:

http://www.miamammausalinux.org/2015/05/ecco-perche-quando-ci-si-approccia-a-systemd-e-bene-rimanere-lucidi-ed-usare-il-cervello/

In particolare, mi trovo vicino a questo commento

E' una mia impressione (e in quanto mia criticabilissima) che le ragioni del passaggio a Systemd siano più dettate da scelte "politiche" che da reali esigenze pragmatiche. Devo anche confessare una certa reticenza a "ristudiare" qualcosa che, fino a ieri maneggiavo "ad occhi chiusi". Per quel che mi riguarda non c' era niente che non funzionasse nell' avvio del sistema. Duro fatica a credere che pochi secondi in meno facciano una differenza sostanziale e che la maggioranza degli utilizzatori debba avviare cosi' tanti processi in più da averne realmente un assoluto bisogno.
Perdonami il tono un po' accalorato. Tu hai tutte le tue ottime ragioni per gradire qualcosa . Io ho le mie ragioni per esserne contrariato. Linux sta sempre più sfuggendo di mano alla comunità per divenire terreno di caccia delle major che sono entrate nello sviluppo. Già adesso alcuni tool sono così complessi da essere inavvicinabili dal singolo o da un Lug. Questo si mi rattrista.

[pabloski]

L'articolo in se non mi sembra particolarmente interessante, ma ho trovato piuttosto stimolante la discussione che si è sviluppata nei commenti:

http://www.miamammausalinux.org/2015/05/ecco-perche-quando-ci-si-approccia-a-systemd-e-bene-rimanere-lucidi-ed-usare-il-cervello/

In particolare, mi trovo vicino a questo commento

Ma infatti Linux come soluzione veramente open e free è morto. Mai provato a mettere le mani nel kernel? 10 anni fa era uno spasso, oggi è un incubo.

Il problema è che questi signori non capiscono che, così facendo, l'intera comunità imploderà. Morti Torvalds, Poettering e soci, chi continuerà lo sviluppo? Sarà veramente possibile formare nuovi professionisti capaci di gestire un simile casino?

Io comincerei già da oggi a pensare ad un nuovo sistema operativo, possibilmente basato su microkernel, visto che ormai l'hardware lo permette.

[pabloski]

https://www.haiku-os.org/ ? :D

no, quello è ibrido ( qualunque cosa questo strano ed inesistente termine possa significare )

certo ha un'architettura 30 anni avanti a linux, mac os x e windows

[ishtar1900]

Kernel MACH è stato in termini pratici un fallimento*, a detta di chi lo sviluppò doveva portare significativi vantaggi in termini di prestazioni, in realtà chi all'epoca appoggiò queste valutazioni dovette ricredersi, escluso ovviamente l'ideatore di minix che del microkernel fece una sorta di ragione di vita, probabilmente perchè riconoscere i limiti di tale architettura andava a ferire il proprio ego. Il fatto che oggi ci siano "macchine" piu performanti, non cambia il giudizio in merito. Il progresso informatico non puo essere l'opposto della legge di Moore, per citare un articolo letto recentemente: "il codice odierno riesce a sprecare piu’ risorse di quante la legge di Moore riesca a produrre"



* intendo ovviamente Server/desktop

[pabloski]

Il microkernel è in termini pratici un fallimento


Non direi. Due esempi notissimi: QNX e L4. Usati in ogni ambito, dall'embedded ai razzi spaziali.


a detta di chi lo sviluppò doveva portare significativi vantaggi in termini di prestazioni


No, i vantaggi li portano in termini di sicurezza, protezione e robustezza. Sono nati per quello.


escluso ovviamente l'ideatore


?? A chi ti riferisci? Il concetto di microkernel gira da decenni nel mondo della ricerca sui sistemi operativi ed è stato plasmato in tanti modi da tantissimi ricercatori.

Se parli di Tanenbaum, beh, lui è un sostenitore dei microkernel ma non ne è nè l'ideatore nè il maggior rappresentate. Liedtke è sicuramente quello che ha trasformato il mondo dei microkernel.


probabilmente perchè riconoscere i limiti di tale architettura andava a ferire il proprio ego.


Dovresti chiarire su questo punto. Di che limiti parli? Se parliamo di raw performance, gli stessi sostenitori del microkernel lo riconoscono Se prendi il libro di Tanenbaum c'è scritto a caratteri cubitali. Come ho detto, il microkernel non nasce per fornire prestazioni superiori, ma per essere più sicuro.


Il fatto che oggi ci siano "macchine" piu performanti, non cambia il giudizio in merito.


Non è questione di performance dell'hardware ma di architettura. Oggi c'è l'IOMMU ( per fare un esempio ). Questo consente di mappare lo spazio dei registri di una periferica hardware nello spazio d'indirizzamento di un processo user-mode. Questo significa che i driver non devono più passare per il kernel per comunicare con l'hardware sotto il loro controllo. E questo elimina uno dei maggiori colli di problemi di performance per i microkernel.


Il progresso informatico non puo essere l'opposto della legge di Moore, per citare un articolo letto recentemente: "il codice odierno riesce a sprecare piu’ risorse di quante la legge di Moore riesca a produrre"

Questo è un discorso di ingegneria del software e riguarda tutto il software prodotto industrialmente. Semplicemente si preferisce ridurre il tempo uomo necessario per sviluppare il software, pagando come prezzo un maggiore tempo macchina nell'esecuzione dello stesso.

E il problema si acuisce man mano che il software diventa più complesso. Il che vuol dire che un kernel monolitico è maggiormente soggetto a questo problema rispetto ad un microkernel ( che è stato ideato anche per meglio gestire la complessità ).

[pabloski]

Kernel MACH è stato in termini pratici un fallimento


Mach è un microkernel di prima generazione. Da allora sono cambiate moltissime cose e lo stesso Mach è unanimemente riconosciuto come il miglior modo per non creare un microkernel funzionante.

Se guardi l'architettura di L4 ( ma anche quella di Minix ) noterai è tutt'altra musica.

[ishtar1900]

Probabilmente ho aggiornato il post mentre mi stavi rispondendo, ed è venuta un po di confusione. Ora, ovviamente mi riferivo a minix e alle schermaglie tra Tanenbaum e torvalds. Come mi riferivo esclusivamente a uso server/desktop.
Detto cio, se non ricordo male perchè sono passati parecchi anni, questa architettura fu spacciata come superiore tout-court, incluso sicurezza, protezione e robustezza, ma non solo. Personalmente ritengo, come gia accennato, che progresso significhi minor spreco di risorse, in tutti i campi, e non capisco perchè l'informatica ne debba essere esente. In merito al "fallimento" ripeto mi riferivo ad ambiti server/desktop, non saprei dare una definizione diversa ad un progetto che nell'idea di chi lo appoggiava era talmente "superiore" al monolitico da soppiantarlo in breve termine, mentre in realtà le cose sono andate diversamente. Un conto è la teoria, un conto è evidentemente mettersi a compilare questo microkernel per gli usi sopra indicati. Poi, leggendo le tue obiezioni noto che sei molto preparato in merito, molto piu di me, io mi limito semplicemente a constatare i fatti.

[ishtar1900]

Questo è un discorso di ingegneria del software e riguarda tutto il software prodotto industrialmente. Semplicemente si preferisce ridurre il tempo uomo necessario per sviluppare il software, pagando come prezzo un maggiore tempo macchina nell'esecuzione dello stesso.

E il problema si acuisce man mano che il software diventa più complesso. Il che vuol dire che un kernel monolitico è maggiormente soggetto a questo problema rispetto ad un microkernel ( che è stato ideato anche per meglio gestire la complessità ).

Hai ragione, ma se ci pensi è un controsenso, per risparmiare produco software pessimo, il monolitico ha piu criticità a gestirlo quindi cambio tutto e uso il microkernel, non perchè è migliore ma perchè riesce a mettere una "pezza" a software,librerie ed altro scritti di fretta e furia da programmatori poco pagati, e se poco pagati spesso anche poco capaci
Inoltre il "mondo" open source dovrebbe essere esente da questa sequenza di cause ed effetti............

[pabloski]

Personalmente ritengo, come gia accennato, che progresso significhi minor spreco di risorse, in tutti i campi, e non capisco perchè l'informatica ne debba essere esente.


E' questione di trade-off. Se per sprecare meno risorse bisogna sacrificare eccessivamente la sicurezza, allora non ne vale la pena ( soprattutto in un'epoca di computer ubiqui e IoT ).

Poi i sistemi operativi "moderni" di risorse ne sprecano parecchie e senza essere microkernel. Guarda Windows, con i suoi 15-17 GB divorati solo per installare il sistema operativo.


In merito al "fallimento" ripeto mi riferivo ad ambiti server/desktop, non saprei dare una definizione diversa ad un progetto che nell'idea di chi lo appoggiava era talmente "superiore" al monolitico da soppiantarlo in breve termine, mentre in realtà le cose sono andate diversamente.


E' stata maggiormente una questione di inerzia del mercato. Ad esempio FreeBSD ha fallito ( relativamente ) rispetto a Linux, ma non perchè fosse inferiore. All'epoca ci fu il casino della causa legale, ecc... ecc... Lo stesso discorso va fatto con i microkernel, cominciando dal fatto che Mach era un aborto di microkernel ma veniva spacciato come microkernel definitivo. E moltissima gente ancora oggi associa il concetto di microkernel con Mach.

I microkernel sono in circolazione e li usiamo tutti i giorni ( gli OS baseband degli smartphone o come Dom0 in alcuni sistemi, anche mobile, che usano la virtualizzazione ). Alcuni OS mainstream sono microkernel ( Blackberry OS ad esempio e la piattaforma automotive della medesima azienda ).

E' una questione strettamente commerciale e di marketing, per cui i microkernel non li vediamo. Si potrebbe, ad esempio, creare un microkernel fighissimo da usare come base per un OS desktop/server, ma poi? I driver chi li scrive? E il software chi li porta? Ci sono voluti 20 anni per rendere Linux usabile, credo che i vari Google ( ma anche le comunità open/free ) non sarebbero molto felici di dover ricominciare da zero.

Tuttavia c'è da notare che i produttori di hardware ( Intel in testa ) hanno lavorato e stanno lavorando in una direzione che aiuta i microkernel a dare il meglio di sè. E non credo sia un risultato incidentale, ma piuttosto voluto e parte di una precisa strategia.

[ishtar1900]

Aldilà di questo interessante scambio di opinioni, tornando al tuo primo post, sono d'accordo che Linux (inteso come kernel) e di conseguenza le distro che lo usano, dovranno fare i conti con l'inevitabile scambio generazionale, anche se non sarei cosi pessimista in merito al futuro. Mal che vada, potrebbe pure accadere che freebsd, per questioni di semplice "sopravvivenza", riveda le sue licenze e si ritrovi supportata da parecchi sviluppatori, in tal caso sarebbe un'ottima alternativa.

[pabloski]

dovranno fare i conti con l'inevitabile scambio generazionale


Ho preso spunto dal titolo del post. Systemd è una delle ragioni per cui la comunità si sta già spaccando. Il problema è che ormai l'evoluzione di Linux viene decisa dalle multinazionali e sono cominciate ad accadere cose spiacevoli ( Allwinner che usa codice GPL e fa finta di non aver capito come funziona la licenza, le aziende cloud che usano e non rilasciano le modifiche ).

Poi c'è che Linux è diventato enorme e il grosso dello sviluppo avviene tra 4-5 grosse multinazionali, con una scarsità di documentazione incredibile ( non che in passato ce ne fosse di più, ma bastava leggere il codice per capire come funzionavano certe parti ).

Uno sviluppatore che volesse avvicinarsi al kernel da dove dovrebbe cominciare?


Mal che vada, potrebbe pure accadere che freebsd, per questioni di semplice "sopravvivenza", riveda le sue licenze e si ritrovi supportata da parecchi sviluppatori, in tal caso sarebbe un'ottima alternativa.

I BSD-zealot che cambiano idea? Forse quando il mare diventerà viola :D

E comunque la BSD sta rivivendo una secondo gioventù, grazie al fatto che gran parte del codice open dei vari Google e compagnia è sotto licenza BSD.

Comunque FreeBSD può essere già un'alternativa, a patto di scegliere accuratamente l'hardware e accettare il fatto che gli sviluppatori lo testano sotto virtualbox :D

[IngMetallo]

Ho preso spunto dal titolo del post. Systemd è una delle ragioni per cui la comunità si sta già spaccando. Il problema è che ormai l'evoluzione di Linux viene decisa dalle multinazionali e sono cominciate ad accadere cose spiacevoli ( Allwinner che usa codice GPL e fa finta di non aver capito come funziona la licenza, le aziende cloud che usano e non rilasciano le modifiche ).

Poi c'è che Linux è diventato enorme e il grosso dello sviluppo avviene tra 4-5 grosse multinazionali, con una scarsità di documentazione incredibile ( non che in passato ce ne fosse di più, ma bastava leggere il codice per capire come funzionavano certe parti ).

Uno sviluppatore che volesse avvicinarsi al kernel da dove dovrebbe cominciare?

systemd ha creato molto casino, ma alla fine mi pare che la comunità abbia accettato questa soluzione.
Se Arch, Debian e Ubuntu passano a systemd allora significa che qualcosa di buono dovrà pur averlo, visto che le prime due sono distribuzioni fatte dalla comunità e l'ultima invece ha rinunciato ad upstart :D

Uno sviluppatore che volesse avvicinarsi al kernel da dove dovrebbe cominciare?

Questa difficoltà è dovuta alla tipologia di kernel o ad altro ?
Ovvero, un microkernel avrebbe cambiato qualcosa ?

Faccio queste domande da profano, non mi sono mai avvicinato al codice sorgente del kernel.

[pabloski]

systemd ha creato molto casino, ma alla fine mi pare che la comunità abbia accettato questa soluzione.
Se Arch, Debian e Ubuntu passano a systemd allora significa che qualcosa di buono dovrà pur averlo, visto che le prime due sono distribuzioni fatte dalla comunità e l'ultima invece ha rinunciato ad upstart :D


Certamente ci sono pro e contro. Ad esempio systemd è una buona cosa perchè centralizza molti software interdipendenti, però dall'altro rendere binari i log....beh....

E il vero problema è che semplicemente se ne sono fregati delle obiezioni della comunità e soprattutto stanno legando mani e piedi l'intero ecosistema linux a systemd ( perchè diavolo gnome deve avere come dipendenza systemd? ).

Quando il piano sarà concluso, semplicemente non ci sarà modo di usare altri init system sotto linux ( kdbus sarà l'ultimo chiodo sulla bara ).


Questa difficoltà è dovuta alla tipologia di kernel o ad altro ?
Ovvero, un microkernel avrebbe cambiato qualcosa ?


Un microkernel ha due vantaggi:

1. costringe gli sviluppatori a modularizzare il sistema, il che li costringe a fare sul serio riguardo api e retrocompatibilità delle stesse

2. i moduli sono relativamente piccoli e possono essere studiati con relativa facilità ( mentre se prendi linux, buona fortuna capirci qualcosa tra quelle milioni di righe di codice )

Ovviamente una minore spericolatezza sulle api avrebbe consentito, ad esempio, di poter avere una migliore compatibilità dei driver con le varie versioni del kernel ( avremmo Android che può essere aggiornato da Google riutlizzando però i driver preinstallati, ad esempio ).


Faccio queste domande da profano, non mi sono mai avvicinato al codice sorgente del kernel.

E' un'esperienza interessante, soprattutto se tieni accanto un libro tipo Linux kernel internals o Professional Linux kernel architecture. In caso contrario è una corsa sulle montagne russe :D

[IngMetallo]

Nemmeno io sono riuscito a capire la scelta di Gnome, però non ho mai indagato a fondo.

Ah nel frattempo che noi siamo qui a discutere, è uscita l'ultima versione (220) di systemd: http://www.phoronix.com/scan.php?page=news_item&px=Systemd-220 :D

Quei libri sono validi nonostante siamo arrivati alla versione 4.0 ? I concetti di base dovrebbero essere sempre validi giusto ?
Intanto li ho messi tra i bookmark, ad agosto potrei farci un pensierino anche se prima avevo intenzione di studiarmi per bene "The C++ programming language" di Stroustrup.

PS: pabloski che sistema operativo usi ?

[pabloski]

Nemmeno io sono riuscito a capire la scelta di Gnome, però non ho mai indagato a fondo.

Azzarderei l'ipotesi che trattandosi di progetti di Redhat, beh... :D


Quei libri sono validi nonostante siamo arrivati alla versione 4.0 ? I concetti di base dovrebbero essere sempre validi giusto ?


Per fortuna si.


PS: pabloski che sistema operativo usi ?

Archlinux e giocherello con Haiku ogni tanto :D

[SuperISD32]

A me systemd sembra una cagata pazzesca.

Quella di Debian non è una marchetta pro-Rad Hat, ma una severa dimostrazione di mancanza di manodopera nella gestione dell'organizzazione che porta Debian ad adeguarsi passivamente alle forze che guidano il mercato. Perché Zacchiroli è stato eletto a due cariche consecutive senza voti contrari? Perché non c'è stato nessun altro volontario a candidarsi per il ruolo!

Come farebbe Debian a divergere dal flusso evolutivo spinto da Red Hat? Red Hat ha prodotto tante di quelle cazzate (perlomeno negli ultimi anni), poi fagocitate anche da Debian, come il systemd, la nomenclatura random e imprevedibile dei block device dopo ogni boot a partire dai kernel 3.x.ballshit, che costringe ogni sysadmin all'abuso sessuale degli UUID, all'impossibilità di identificare univocamente filesystem non-linux (NTFS) e i componenti di un array RAID (sì, non è più possibile identificare con certezza i componenti di un array (http://serverfault.com/questions/696638/proper-way-to-identify-member-devices-in-mdadm-conf)).

A me questo di Red Hat sembra uno modello di sviluppo simile a quello di Oracle con MySQL: il software va prodotto, e in quantità; si punta a raggiungere gli obiettivi e implementare le feature prefissate, e con la qualità, l'integrità e l'omogeneità del software ci si pulisce il culo (si veda ad esempio il confronto MySQL vs Postgres, dove il primo è un conglomerato di software di varie razze e nature, pur vagamente funzionante, il secondo è un progetto chiaro e preciso fin dal blueprint a matita). Probabilmente il modello Red Hat è dettato dalla stessa necessità di Oracle, cioè quella economica.

Per fare un esempio, il systemd quando si inchioda e per una ragione o per l'altra non avvia il sistema, nemmeno ti dà un messaggio di errore, rimane zitto come un cretino (a la mo' di Windows) e ti costringe a: 1) riavviare, 2) cercare attivamente (perdendo tempo) tra i log, 3) ottenere finalmente il messaggio di errore, che sysVinit invece ti avrebbe già dato 5 minuti prima direttamente sulla console (sempre se si fosse inchiodato).

La seconda ragione di questo modello di sviluppo, oltre che per la necessità economica di ottenere un'abbondante spremuta di software dagli sviluppatori mangia-stipendi (il che è a scapito della reale qualità del risultato, e non delle feature sbandierate) è forse quella di produrre software orrendo intenzionalmente. Se il software fa schifo, ma pur "tutti lo usano" (vedi es. MySQL, che tra i DBMS mainstream è il più diffuso al mondo (http://www.mysql.com/why-mysql/), eppure il più scadente (https://www.digitalocean.com/community/tutorials/sqlite-vs-mysql-vs-postgresql-a-comparison-of-relational-database-management-systems)), diventa necessario vendere corsi di formazione per i sysadmin, ormai incapaci di comprendere da sé come configurare e usare certe porcherie di software, e vendere consulenze telefoniche, su cui di fatto RedHat basa il suo business.

Comunque sia, ho abortito su tutti i miei computer l'upgrade da Debian 7 a Debian 8, cioè la versione che ha introdotto quest'invenzione del sysinitd. Un boicottaggio a tempo indefinito insomma. Nei prossimi anni vedremo chi vincerà: se Red Hat riuscirà a spopolare col suo software-concime e io mi troverò costretto all'upgrade per via dell'obsolescenza e delle crescenti incompatibilità del mio software installato (IPv6, formati Office, standard HTML5, ...), o se qualcuno si opporrà in modo determinato e rimetterà Debian e compagnia sui binari.

[GTKM]

Quei libri sono validi nonostante siamo arrivati alla versione 4.0 ? I concetti di base dovrebbero essere sempre validi giusto ?
Intanto li ho messi tra i bookmark, ad agosto potrei farci un pensierino anche se prima avevo intenzione di studiarmi per bene "The C++ programming language" di Stroustrup.

Io ho messo tra i bookmark Professional Linux Kernel Architecture. Tempo fa avevo provato ad avvicinarmi timidamente al codice di Linux, ma è impossibile farlo, senza un manualone (oppure ti serve un team di gente che studi le varie parti in parallelo e tragga delle conclusioni). Per quanto mi riguarda, a questo punto si sta andando praticamente contro la filosofia di UNIX, il cui cuore (e genilità tecnica) è proprio l'idea di tante piccole parti che comunicano tra loro.

Per il C++, credo sia meglio il testo di Eckel. Quello di Stroustrup non mi ispira più di tanto onestamente.

Tornando in tema, la "polemica" Systemd offre uno spaccato esemplare di quella che è la situazione attuale dell'ecosistema GNU/Linux: nel momento in cui entrano in gioco le multinazionali, e lo fanno in maniera pesante, tutto il resto viene semplicemente spazzato via. La comunità stessa, diciamocelo, non sembra in grado di riprendere in mano le redini, a parte i soliti 3-4 elementi pesanti. Se si fa da parte Torvalds (che comunque non è nemmeno il massimo dal punto di vista manageriale), e prima o poi dovrà pur farlo, son dolori.

Analogamente, secondo me, accadrà alla comunità del Free Software. Dopo Stallman sembra esserci il vuoto assoluto.

[alex87alex]

A me systemd piace, nonostante la riluttanza iniziale. Come debugging mi fa molto comodo lo status che è molto più prolisso rispetto all'init.