Link alla notizia: http://www.hwupgrade.it/news/sistemi-operativi/gnome-compie-vent-anni-e-festeggia_70513.html

GNOME ha compiuto vent'anni e ha avviato i festeggiamenti per questo traguardo: uno degli ambienti desktop più famosi del mondo *NIX ha plasmato la storia di Linux sul desktop e continuerà probabilmente a farlo in futuro.

Click sul link per visualizzare la notizia.

Auguri a Gnome da un utente KDE.

Auguri anche da parte mia, che ultimamente sono passato a KDE, ma in attesa di trovare la "mia dimensione" con GNOME per tornare a usare quest'ultimo.

:)

:( io son rimasto a GNOME 2 poi gnome-fallback...

Prima o poi proverò una nuova distribuzione Ubuntu...

Ma almeno MATE, dai :asd:

quanti ricordi..i continui cambi tra kde e gnome, le attese per le nuove versioni...

sono vecchio :cry:

auguri e figli maschi

per intendere che (a parte il modo di dire 'sessita' che fa parte solo della citazione) dalla 3 in poi sono più usabili, per uso dektop, i figli (i citati cinnamon e mate) poco da fare

sono cmq curioso sugli sviluppi futuri, che dopo l'affossamento di unity da parte dell'astronauta potrebbero esserci ripercussioni anche sorprendenti

auguri e figli maschi

per intendere che (a parte il modo di dire 'sessita' che fa parte solo della citazione) dalla 3 in poi sono più usabili, per uso dektop, i figli (i citati cinnamon e mate) poco da fare

sono cmq curioso sugli sviluppi futuri, che dopo l'affossamento di unity da parte dell'astronauta potrebbero esserci ripercussioni anche sorprendenti
meno frammentazione e maggiore sviluppo su meno progetti forse gioverebbe agli ecosistemi open

meno frammentazione e maggiore sviluppo su meno progetti forse gioverebbe agli ecosistemi open

in genere e' il contrario

se non ci fosse frammentazione, oggi saremmo tutti zombie che seguono bovinamente la filosofia di systemd

per cui ben vengano fork, lotte, frammentazione, il pensiero non deve appiattirsi

meno frammentazione e maggiore sviluppo su meno progetti forse gioverebbe agli ecosistemi open

Scusami, senza polemica, ma secondo me questa affermazione è errata. La frammentazione nel mondo open credo che sia alla base dello spirito del movimento. Si tratta di progetti spesso non finanziati o che ricevono finanziamenti nel tempo, grazie a idee che hanno riscosso un certo consenso. Idee che non potrebbero nascere se tutti lavorassero a un determinato progetto solo per abbracciare la causa della non frammentazione.

Per esempio, se gli sviluppatori di MATE Cinnamon e Gnome (tralasciando il discorso sulle rispettive mission) lavorassero tutti su Gnome, avremmo un DE migliore? Forse. Ma ogni progetto essendo open può attingere dagli altri, se questi hanno un'idea rivoluzionaria, o se da qualche parte riescono a trovare il fix per un un problema qualunque.

E se io adesso nel mio scantinato progettassi il mio DE? Vale quanto sopra.

My 2 cents.

ok, frammentiamo.

linux (gnome? kde? cinnamon? lxde? xfce? mate?) è sul 95% dei desktop? non mi pare.
tanti progetti tutti +/- carenti sotto qualche punto di vista. x me è MALE.

dipende dalle prerogative

ok, frammentiamo.

linux (gnome? kde? cinnamon? lxde? xfce? mate?) è sul 95% dei desktop? non mi pare.
tanti progetti tutti +/- carenti sotto qualche punto di vista. x me è MALE.

stai partendo dall'assunto che il market share sia dovuto unicamente alla minore o maggiore frammentazione

ovviamente non e' cosi'

windows non frammentato...a quanto sta su mobile? ecco, ci sono dinamiche che vanno un pelino aldila' della frammentazione, al lavoro

e android? android e' basato sul frammentato linux

si capisce dove voglio andare a parare? se c'e richiesta di un prodotto stabile e supportato, qualcuno si fa avanti, usa i pezzi frammentati che la comunita' ha prodotto e crea un prodotto sviluppato piu' o meno centralmente

le parole chiave qui sono ovviamente frammentazione e comunita'

la comunita' e' di per se' eterogenea ed anarchica, cioe' non puoi costringere la gente a lavorare a cio' che vuoi tu

e c'e' la questione dell'innovazione, ovvero la stabilita' va bene per creare un prodotto rifinito da vendere, ma e' in un ambiente anarchico e frizzante che nascono nuove idee

da dove sono nate le vagonate di codice che ms, apple e soci hanno usato nei loro prodotti? nella comunita' open, principalmente quella bsd

Auguri anche da parte mia, che ultimamente sono passato a KDE, ma in attesa di trovare la "mia dimensione" con GNOME per tornare a usare quest'ultimo.

:)

se usavi Gnome ,Mate dovrebbe fare al caso tuo. Abbastanza stabile.

Preferisco KDE, ma MATE e' fatto molto bene secondo me.

ok, frammentiamo.

linux (gnome? kde? cinnamon? lxde? xfce? mate?) è sul 95% dei desktop? non mi pare.
tanti progetti tutti +/- carenti sotto qualche punto di vista. x me è MALE.

Dal tuo punto di vista avresti ragione. Ma dimentichi che alla fine tolti KDE e GNome, gli altri sono progetti nati e sviluppati per iniziative personali.
Il bello dell'ecosistema Linux e' che ognuno puo' sviluppare per proprio divertimento.
Lo sviluppatore di Cinammon se non sviluppasse Cinnamon non svilupperebbe mica per KDE o Gnome. Quindi non viene tolto niente a questi.

Personalmente il vero rammarico non e' che ci siano piu' DE, ma che ci siano diversi toolkits.
E non per ragioni tecniche quanto politiche.

Lo sviluppatore di Cinammon se non sviluppasse Cinnamon non svilupperebbe mica per KDE o Gnome. Quindi non viene tolto niente a questi.te lo ha confidato di persona lo stesso Clement?

te lo ha confidato di persona lo stesso Clement?

Guarda..Cinammon e' nato proprio perche' a Clement non piaceva la direzione presa da Gnome 3...vedi un po te la dimensione della fesseria che hai scritto :D
E non lo ha confidato solo a me...lo ha scritto proprio pubblicamente! :D :D
http://blog.linuxmint.com/?p=1910
We used MATE and MGSE to provide an easier transition away from Gnome 2, but without being able to truly offer an alternative that was better than Gnome 2. Both MATE and Gnome Shell are promising projects but MATE’s ultimate goal is to replicate Gnome 2 using GTK+ and Gnome Shell doesn’t provide what we need in a desktop and is going in a direction we do not want to follow. So for these reasons we’re designing a new desktop called Cinnamon, which leverages new technology and implements our vision.

Guarda..Cinammon e' nato proprio perche' a Clement non piaceva la direzione presa da Gnome 3...vedi un po te la dimensione della fesseria che hai scritto :D
ma esisteva già lxde, xfce, e forse anche mate.
imho sarebbe stato meglio se fosse "cresciuto" uno di questi progetti anzichè reinventare da capo la ruota.

il problema che sopra ho definito "frammentazione" è più che altro questa continua reinvenzione della ruota, per poi avere 8000 ruote incompatibili, tutte imperfette e mai concluse, tutte rifatte ogni volta da capo per cambiare solo il colore di un particolare insignificante, di cui 4000 morte prima di maturare.

se si mettesse un po' da parte l'orgoglio e la cazzoneria, si potrebbe magari collaborare su 2, o 3 progetti più completi, diffusi, aggiornati, pieni di opzioni per soddisfare le esigenze di tutti.
x dire: non ti piace il pulsante X a detstra? non rifai da capo il DE, ma aggiungi l'opzione per avere quel particolare come piace a te.

stai partendo dall'assunto che il market share sia dovuto unicamente alla minore o maggiore frammentazione

ovviamente non e' cosi'

windows non frammentato...a quanto sta su mobile? ecco, ci sono dinamiche che vanno un pelino aldila' della frammentazione, al lavoro

e android? android e' basato sul frammentato linux
la diffusione dipende dalle funzionalità e lo sviluppo di queste dipende dal rapporto lavoro vs. risultato.
se ci sono 10000 versioni diverse e incompatibili, ci saranno meno funzionalità e quindi meno interesse.
android sarà frammentato, ma è sempre android e bene o male le app ci girano.
win non lo è, ma è arrivato tardi, e cmq ha poche app = poco interesse = meno app = meno utenti = poco interesse ecc...

ma esisteva già lxde, xfce, e forse anche mate.
imho sarebbe stato meglio se fosse "cresciuto" uno di questi progetti anzichè reinventare da capo la ruota.

il problema che sopra ho definito "frammentazione" è più che altro questa continua reinvenzione della ruota, per poi avere 8000 ruote incompatibili, tutte imperfette e mai concluse, tutte rifatte ogni volta da capo per cambiare solo il colore di un particolare insignificante, di cui 4000 morte prima di maturare.

se si mettesse un po' da parte l'orgoglio e la cazzoneria, si potrebbe magari collaborare su 2, o 3 progetti più completi, diffusi, aggiornati, pieni di opzioni per soddisfare le esigenze di tutti.
x dire: non ti piace il pulsante X a detstra? non rifai da capo il DE, ma aggiungi l'opzione per avere quel particolare come piace a te.

Si ma ognuno fa col proprio tempo cio' che vuole.
Se una persona decide di sviluppare una propria idea, non e' che si puo' costringerlo ad abbandonarla.

A me spiace solo che vi siano diversi toolkit, perche' quelli si sono sviluppati da compagnie.
In particolare mi spiace che Red Hat non abbia abbandonato lo sviluppo delle gtk una volta che le librerie qt sono diventate completamente open source. Questo avrebbe fatto un gran bene alla comunita', molto piu' che non avere 2 librerie principali.
Invece Red Hat a volte sembra voler navigare contro gli interessi della comunita', al fine di urtare altre compagnie concorrenti.

auguri :D
alla faccia di unity

...vedi un po te la dimensione della fesseria che hai scritto :D:D :D :D questa mi fa ancora piu ridere delle altre cose che hai scritto :D :D
comunque vedo che ne vai fiero di ciò che scrivi, nn voglio svegliarti dal mondo dei sogni :)

spesso credo che si tenda a considerare il pinguino come se fosse un progetto unitario nato come tale. ma, poco da fare, non è così, e anzi la eterogeneita è proprio la sua caratteristica principale, con vantaggi e svantaggi relativi ovviamente

quindi, ad ora, è prendere o lasciare, poco da fare

la diffusione dipende dalle funzionalità e lo sviluppo di queste dipende dal rapporto lavoro vs. risultato.


ma il punto e' che quella gente comunque non lavorerebbe a quello che vuoi tu, semplicemente andrebbe altrove

alla fin fine, lo sviluppo professionale di linux e' nelle mani di redhat

ovvio che redhat possa pretendere, gli da' lo stipendio, ma non e' detto che i risultati siano brillanti ( vedi pulseaudio, systemd )


se ci sono 10000 versioni diverse e incompatibili, ci saranno meno funzionalità e quindi meno interesse.


questa e' una pura e semplice leggenda metropolitana

le 10.000 distro che vedi su distrowatch sono al 90% derivate ubuntu

le uniche differenze apprezzabili esistono tra debian, fedora, arch, slackware, alpine, void, clear e qualche altra

e di quelle citate le uniche mainstream sono le prime 2, la terza e' per smanettoni, le altre per usi molto molto specifici, con un'utenza di qualche punto percentuale


android sarà frammentato, ma è sempre android e bene o male le app ci girano.


ma perche' sulle varie distro linux non ci girano? diamine, una valanga di applicazioni linux girano pure sui bsd

fatti un giro con un paio di distro linux, non prestare attenzione alle leggende che circolano sul web


win non lo è, ma è arrivato tardi, e cmq ha poche app = poco interesse = meno app = meno utenti = poco interesse ecc...

appunto, windows e android dimostrano che il problema principale non e' la frammentazione

se c'e' mercato e quindi soldi da fare, gli sviluppatori si scapicolleranno per tappare tutte le porcate che il sistema operativo fa

Auguri gnome pero ora che hai finito il de per i tablet torniamo a sviluppare quello per i desktop! :)

ovvio che redhat possa pretendere, gli da' lo stipendio, ma non e' detto che i risultati siano brillanti ( vedi pulseaudio, systemd )
Lo sento ripetere spesso, ma vorrei capire cos'abbia di sbagliato systemd.

Esiste un tool simile che riesca a fare (almeno) le stesse cose (ovviamente "meglio")?

Preciso che non m'interessano discussioni filosofiche del perché sì o no. Sono pragmatico e mi serve uno strumento che mi consenta di risolvere i miei problemi, con una certa produttività ovviamente. ;)

Lo sento ripetere spesso, ma vorrei capire cos'abbia di sbagliato systemd.

Beh considerando che 1 volta su 3 ti si blocca durante lo spegnimento del computer :D

Poi c'e' il fatto che stia inglobando sempre piu' funzionalita', il che introduce tanti bug in un init system. Non credo sia una scelta saggia.

I log binari onestamente non si possono vedere su un sistema Unix. Perche' non dovrei poter usare cat, nano o vim per guardarmi i log?


Esiste un tool simile che riesca a fare (almeno) le stesse cose (ovviamente "meglio")?


Direi di no. Systemd ingloba talmente tante funzionalita', che nessun tool e' in grado di fare le stesse cose.

Ma Systemd dovrebbe essere un init system, non un demone dhcp.

Scherzi a parte, Runit faceva tanto schifo a Poettering? Ma anche Upstart poteva andare. Entrambi fanno gli init system e consentono l'avvio in parallelo dei demoni, che poi era quello il pomo della discordia.

in effetti a me upstart non è che dispiacesse

Beh considerando che 1 volta su 3 ti si blocca durante lo spegnimento del computer :D
Con la VM che uso (Ubuntu 16.02 LTS, se non ricordo male) non m'è mai capitato. E ovviamente nemmeno con le centraline dell'auto. :P
Poi c'e' il fatto che stia inglobando sempre piu' funzionalita', il che introduce tanti bug in un init system. Non credo sia una scelta saggia.
Ma systemd non è più un init system da tempo. E' una sorta mini-/meta o.s. che si occupa di tutta una serie di funzionalità.
I log binari onestamente non si possono vedere su un sistema Unix. Perche' non dovrei poter usare cat, nano o vim per guardarmi i log?
Ma puoi sempre riprodurre il log a video/console, e poi te lo guardi (con less/more o altro).

Tra l'altro puoi anche eseguire ricerche raffinate, senza ricorrere necessariamente a grep.

Capisco, comunque, il tuo punto di vista, però se uno dei fondamenti di Unix sono le pipe... riproduci il log e lo redirezioni dove vuoi. :fagiano:
Direi di no. Systemd ingloba talmente tante funzionalita', che nessun tool e' in grado di fare le stesse cose.
Mi riferivo a un pacchetto che lo installi e ti mette a disposizione tutta una serie di componenti che fanno le stesse cose.
Ma Systemd dovrebbe essere un init system, non un demone dhcp.
Come detto sopra, non lo è più da tempo. Adesso integra pure udev, ad esempio. Che nell'ottica in cui si pone systemd, ha assolutamente senso.

Sia chiaro che comprendo chi sia abituato a BSD et co., ma non per questo si deve rimanere fossilizzati e non sperimentare nuove idee. Con ciò mi riallaccio a quello che si stava dicendo prima (ma potrei citare anche Wayland).

Come sai, sono un utente Windows, per cui non ho pregiudizi nel valutare un tool anziché un altro in un mondo completamente diverso, che è quello Unix. Che poi c'è da dire che a me, da professionista, interessa soltanto risolvere i miei problemi.
Scherzi a parte, Runit faceva tanto schifo a Poettering? Ma anche Upstart poteva andare. Entrambi fanno gli init system e consentono l'avvio in parallelo dei demoni, che poi era quello il pomo della discordia.
Penso che avrai visto qualche benchmark, e dovresti sapere che systemd non solo supera prestazionalmente le soluzioni esistenti, ma offre anche ben altri vantaggi su come definire minuziosamente quali e in che modo i servizi debbano essere avviati, gestiti, ecc. e lo fa di gran lunga più semplicemente.

Comunque la velocità di avvio è estremamente importante in ambito embedded. Considera che nel settore auto la legislazione USA impone che il quadro debba essere operativo in massimo 2 secondi. Immagina di dover fare lo stesso con qualunque altra soluzione alternativa a systemd, e a contempo gestire il tutto: secondo me c'è da spararsi (e l'idea di andare a colpi di script bash non mi attira di certo, come puoi immaginare).

My 2 cents sull'argomento systemd, e sulla sperimentazione di nuove soluzioni. :)

a prescindere dalle argomentazioni 'strettamente' tecniche, penso che una delle critiche più sensate (relativamente alla eterogeneità di cui sopra) a systemd sia che, sotto il cofano, rende meno differenti distro che un tempo erano, quasi, 'mondi paralleli'

cmq contemporaneamente il tutto può essere anche un pregio, per motivi diametralmente opposti e altrettanto validi probabilmente, o per lo meno a seconda del punto di vista

io tendo più verso la prima, ma poi appunto, uso per fare altro, e quindi , se funge, bon...

Con la VM che uso (Ubuntu 16.02 LTS, se non ricordo male) non m'è mai capitato. E ovviamente nemmeno con le centraline dell'auto. :P

Ma systemd non è più un init system da tempo. E' una sorta mini-/meta o.s. che si occupa di tutta una serie di funzionalità.

Ma puoi sempre riprodurre il log a video/console, e poi te lo guardi (con less/more o altro).

Tra l'altro puoi anche eseguire ricerche raffinate, senza ricorrere necessariamente a grep.

Capisco, comunque, il tuo punto di vista, però se uno dei fondamenti di Unix sono le pipe... riproduci il log e lo redirezioni dove vuoi. :fagiano:

Mi riferivo a un pacchetto che lo installi e ti mette a disposizione tutta una serie di componenti che fanno le stesse cose.

Come detto sopra, non lo è più da tempo. Adesso integra pure udev, ad esempio. Che nell'ottica in cui si pone systemd, ha assolutamente senso.

Sia chiaro che comprendo chi sia abituato a BSD et co., ma non per questo si deve rimanere fossilizzati e non sperimentare nuove idee. Con ciò mi riallaccio a quello che si stava dicendo prima (ma potrei citare anche Wayland).

Come sai, sono un utente Windows, per cui non ho pregiudizi nel valutare un tool anziché un altro in un mondo completamente diverso, che è quello Unix. Che poi c'è da dire che a me, da professionista, interessa soltanto risolvere i miei problemi.

Penso che avrai visto qualche benchmark, e dovresti sapere che systemd non solo supera prestazionalmente le soluzioni esistenti, ma offre anche ben altri vantaggi su come definire minuziosamente quali e in che modo i servizi debbano essere avviati, gestiti, ecc. e lo fa di gran lunga più semplicemente.

Comunque la velocità di avvio è estremamente importante in ambito embedded. Considera che nel settore auto la legislazione USA impone che il quadro debba essere operativo in massimo 2 secondi. Immagina di dover fare lo stesso con qualunque altra soluzione alternativa a systemd, e a contempo gestire il tutto: secondo me c'è da spararsi (e l'idea di andare a colpi di script bash non mi attira di certo, come puoi immaginare).

My 2 cents sull'argomento systemd, e sulla sperimentazione di nuove soluzioni. :)


Sinceramente anch'io ero partito con dei pregiudizi su systemd, ma devo ricredermi. Imparando ad usarlo ne ha apprezzato la filosofia e l'idea di offrire un layer standard. Anche il log binario alla fine non e' stata questa tragedia inenarrabile.

Tornando in topic, Gnome non mi e' mai piaciuto. Gia' la versione due la ritenevo molto inferiore a KDE 3. Poi quando e' uscito Gnome 3 si e' toccato il fondo. Lo trovo inusabile. Inoltre le librerie gtk fanno schifo e sono mal documentate. Trovo di gran lunga superiori le Qt, sia come API, che come look and feel e come documentazione. Senza parlare della superiorita' dei tool di sviluppo a disposizione se si utilizza il Qt framework.

Non posso che concordare. E meno male che Unity è stato ucciso.

Con la VM che uso (Ubuntu 16.02 LTS, se non ricordo male) non m'è mai capitato.


Sul ferro invece capita. E' simpatico che si blocca praticamente SEMPRE l'immagine di installazione di Ubuntu. Tu vai per riavviare e lui tira fuori un job che non termina mai ( quella cosa che ti dice che se la cavera' in un minuto e mezzo, messaggio simpatico ).


Ma systemd non è più un init system da tempo. E' una sorta mini-/meta o.s. che si occupa di tutta una serie di funzionalità.

Ed e' appunto quello il problema. Mi ricorda tanto il voler, nel 2017, scrivere un kernel monolitico e in C :D

Quel genere di mentalita' devono avere i suoi creatori.


Ma puoi sempre riprodurre il log a video/console, e poi te lo guardi (con less/more o altro).


Solo con i tool che supportano il formato dei log. Se per esempio uno avvia Alpine da una chiavetta e vuole ispezionare i log di Fedora...buona fortuna!

Poi c'e' il problema che i file si possono sempre corrompere. Un file di testo e' alla fin fine leggibile anche se corrotto. Un file binario se scazza un campo non lo parsi piu'.


Tra l'altro puoi anche eseguire ricerche raffinate, senza ricorrere necessariamente a grep.


E questo e' un ulteriore punto di critica. La Unix-way e' quella che sappiamo, cioe' appunto e' bene che esista grep e lo si debba usare.

Poettering ha una visione diametralmente opposta, tant'e' che qualche ha coniato il termine SystemdOS.


Mi riferivo a un pacchetto che lo installi e ti mette a disposizione tutta una serie di componenti che fanno le stesse cose.

Sarebbe comunque una deviazione dalla Unix-way. La critica maggiore e' proprio che Systemd vuole essere troppe cose per troppa gente.



Sia chiaro che comprendo chi sia abituato a BSD et co., ma non per questo si deve rimanere fossilizzati e non sperimentare nuove idee. Con ciò mi riallaccio a quello che si stava dicendo prima (ma potrei citare anche Wayland).


Nulla contro chi sperimenta. E magari e' pure giusto che si prendano strade "strane". Il problema e' che Redhat pesa tanto e la sua parola e' legge. Un po' come il M5S dove "uno vale uno" e poi la parola di Grillo scavalca bellamente la volonta' di milioni di elettori e simpatizzanti.

Che poi c'è da dire che a me, da professionista, interessa soltanto risolvere i miei problemi.

Poettering e Sievers amano crearli i problemi :D


Penso che avrai visto qualche benchmark, e dovresti sapere che systemd non solo supera prestazionalmente le soluzioni esistenti, ma offre anche ben altri vantaggi su come definire minuziosamente quali e in che modo i servizi debbano essere avviati, gestiti, ecc. e lo fa di gran lunga più semplicemente.

Il vantaggio prestazionale rispetto agli init system classici c'e'. Ma e' merito della parallelizzazione. Runit e OpenRC hanno prestazioni comparabili. Qualcuno potrebbe disquisire sul formato degli script di avvio. Questione di abitudine.


Comunque la velocità di avvio è estremamente importante in ambito embedded.


Ma se non sbaglio si usano altre soluzioni. Android stesso ha un suo init system.

Sul ferro invece capita. E' simpatico che si blocca praticamente SEMPRE l'immagine di installazione di Ubuntu. Tu vai per riavviare e lui tira fuori un job che non termina mai ( quella cosa che ti dice che se la cavera' in un minuto e mezzo, messaggio simpatico ).
Capito. Comunque non è tutto così (altrimenti saremmo già passati ad altre soluzioni :fagiano: ), ma se il problema è comune immagino ci siano già degli issue aperti.
Ed e' appunto quello il problema. Mi ricorda tanto il voler, nel 2017, scrivere un kernel monolitico e in C :D

Quel genere di mentalita' devono avere i suoi creatori.
Beh, Linux E' un kernel monolitico, per cui non è che ci sia differenza. :p Anzi, con udev hanno spostato un po' di roba in user-space, che non fa male.
Solo con i tool che supportano il formato dei log. Se per esempio uno avvia Alpine da una chiavetta e vuole ispezionare i log di Fedora...buona fortuna!
Basta creare un tool standalone che legga il journal: il codice è già lì. ;)
Poi c'e' il problema che i file si possono sempre corrompere. Un file di testo e' alla fin fine leggibile anche se corrotto. Un file binario se scazza un campo non lo parsi piu'.
Ehm... non è così. Dipende tutto da come realizzi il parser.

Ad esempio, quando ho realizzato un decoder JPEG 2000 durante il mio stage+tesi all'STMicroelectronics, il focus fu posto anche nel cosiddetto "error concealment". Il che è ovvio, visto che in un sistema embedded non ti puoi permettere il lusso che una decodifica andata a male mandi in "guru meditation" tutto.
Nello specifico, il mio decoder era estremamente robusto: anche a fronte di una quantità immane di errori, non è mai andato in crash, e nella maggior parte dei casi riusciva anche a visualizzare qualcosa. Mentre l'implementazione open source dell'epoca (JasPer) e il decoder di riferimento messo a disposizione dal comitato JPEG 2000 erano anche andati in segmentation fault alcune volte (nelle immagini strapiene di errori).

Per cui nulla impedisce di realizzare un parse in grado di rilevare gli errori, e di gestirli correttamente, con eventuale risincronizzazione dello stream dati.
E questo e' un ulteriore punto di critica. La Unix-way e' quella che sappiamo, cioe' appunto e' bene che esista grep e lo si debba usare.

Poettering ha una visione diametralmente opposta, tant'e' che qualche ha coniato il termine SystemdOS.

Sarebbe comunque una deviazione dalla Unix-way. La critica maggiore e' proprio che Systemd vuole essere troppe cose per troppa gente.
Non ho mai abbracciato la filosofia Unix, primo perché sono un tipo pragmatico, e secondo perché anche le implementazioni di alcuni software Unix la tradiscono.

Hai mai provato ad aprire il sorgente di tar? Ebbene, è stato appositamente modificato per far sì che questo comando sia direttamente in grado di generare file .tgz o .tbz, e dunque gestendo autonomamente de/compressione a seconda del tipo di codec usato. Il tutto quando la filosofia Unix imponeva l'accoppiata tar|gzip o gunzip|tar.

Perché tutto ciò? Perché la filosofia è una cosa, mentre la vita reale tutt'altra, e pragmaticamente aveva ed ha senz'altro molto senso rompere un pilastro per venire incontro alle esigenze primarie degli utenti.

Ecco perché non mi scandalizza affatto se systemd, o qualunque altro software, vadano contro filosofie consolidate: conta il risultato. :)

Comunque quando parlavo di pacchetto che installa diversi componenti, mi riferivo semplicemente a un package o rpm che, quando lo installi, installa pure diversi altri componenti. Un po' come quando decidi di installare KDE, ad esempio, che installa parecchi altri componenti che gli servono. ;)
Nulla contro chi sperimenta. E magari e' pure giusto che si prendano strade "strane". Il problema e' che Redhat pesa tanto e la sua parola e' legge. Un po' come il M5S dove "uno vale uno" e poi la parola di Grillo scavalca bellamente la volonta' di milioni di elettori e simpatizzanti.
ROFL Abbiamo una certa affinità elettiva. :D

Però Red Hat è UNA distro, ma ce ne sono altre ugualmente importanti. Debian, e quelle da lei derivate (Ubuntu in primis), ha una certa "forza" nella comunità... però è passata anche lei a Systemd.

L'unica rimasta senza Systemd è Slackware, se non erro.
Poettering e Sievers amano crearli i problemi :D
Sievers credo non ne faccia più tanti, visto che mi pare sia stato bannato da Torvalds (che, se non erro, ama appiccicare "systemd sucks" o qualcosa di simile nelle patch di cui fa review). :asd:

Comunque anche alcuni miei colleghi non amano particolarmente Poettering (che ha mostrato problemi di comprensione di alcune problematiche di sicurezza), ma alla domanda: "c'è qualcosa di equivalente ma migliore" scrollano sommessamente le spalle...
Il vantaggio prestazionale rispetto agli init system classici c'e'. Ma e' merito della parallelizzazione. Runit e OpenRC hanno prestazioni comparabili.
Finora i benchmark che ho visto favoriscono nettamente systemd, ma se ne hai mi piacerebbe analizzarli: non si sa mai che salti fuori qualche valida alternativa. Coi 2 secondi di cui parlavo prima siamo sul filo del rasoio, e poter guadagnare qualcosa non ci spiacerebbe di certo.
Qualcuno potrebbe disquisire sul formato degli script di avvio. Questione di abitudine.
Da "esterno" ho trovato che il formato di systemd sia decisamente comodo, semplice e duttile. Gli equivalenti script bash per gestire lo stesso servizio col vecchio init/SysV BSD mi sembrano degli autentici abomini.

Poi, come dici, sarà questione di abitudine, visto che trovo estremamente indigesta bash... :Puke:
Ma se non sbaglio si usano altre soluzioni. Android stesso ha un suo init system.
Non conosco Android da questo punto di vista, ma dando un'occhiata ai tempi di avvio degli smartphone su di esso basati direi che il suo init non risulti particolarmente brillante. :D

Sul ferro invece capita. E' simpatico che si blocca praticamente SEMPRE l'immagine di installazione di Ubuntu. Tu vai per riavviare e lui tira fuori un job che non termina mai ( quella cosa che ti dice che se la cavera' in un minuto e mezzo, messaggio simpatico ).

a me, su bare metal, dopo il minuto e mezzo (con tanto di count down, "esc"ape per farlo comparire) procede tutto regolarmente.
tieni conto che il tutto mi è durato per un paio di sottoversioni (16.04, 16.10)

Capito. Comunque non è tutto così (altrimenti saremmo già passati ad altre soluzioni :fagiano: ), ma se il problema è comune immagino ci siano già degli issue aperti.

Altro che ed e' un'ulteriore occasione di scandalo, con Kay Sievers che se ne frega, chiude i bug report che non gli vanno a genio. Tanto che Torvalds ha dovuto mazzolarlo per benino :D

Allora ricordavo bene, come avevo scritto:

"Sievers credo non ne faccia più tanti, visto che mi pare sia stato bannato da Torvalds (che, se non erro, ama appiccicare "systemd sucks" o qualcosa di simile nelle patch di cui fa review)."

:asd:

Comunque ormai Systemd è lì e credo sia destinato a rimanerci. Spero che la situazione migliori, perché non c'è altro strumento al momento che possa soddisfare almeno i suoi requisiti.

Comunque ormai Systemd è lì e credo sia destinato a rimanerci.


purtroppo


Spero che la situazione migliori


iterando: sviluppo, test sugli utenti, bugfix

prima o poi migliora per inerzia

intanto sara' passato qualche decennio di "l'opensource fa schifo", "linux non funziona"

eppure gli strumenti e le tecniche esistono...non dico che un init system debba essere scritto necessariamente in haskell, ma almeno l'abc dell'ingegneria del software...


perché non c'è altro strumento al momento che possa soddisfare almeno i suoi requisiti.

ovviamente e' difficile trovare in giro un init che vuol fare il sistema operativo :D

Forse perché il sistema operativo non era strutturato granché bene. :O

Checché ne dica Torvalds, Linux è un'implementazione di Unix/Posix, che di conseguenza si porta dietro un bel po' di vecchiume (concetti/"filosofie"/API).

Systemd quanto meno prova ad ammodernarne alcune parti, visto che un s.o. di questi giorni si porta dietro problematiche/necessità ben diverse da quelle di 40 e passi anni fa.

Aggiungendo altre problematiche, nulla da dire su questo, ma com'è ovvio che sia per un software così complesso nonché delicato.

Non ne farei nemmeno una questione ideologica sull'open source o "Linux che non funziona". Linux è sviluppato per l'80% da aziende che investono fiumi di denaro per le loro esigenze, e Systemd è una (delle tante) tecnologia che viene fuori "semplicemente" dalle esigenze di questi colossi. Esigenze che non si possono procrastinare indefinitamente, perché se qualcosa ti serve... ti serve e ci lavori, appunto.

Cerchiamo, dunque, di essere pragmatici, ma sempre: se Linux è così diffuso ormai, non è certo per virtù dello spirito santo. Di ideologia non si campa. E lo "sterco del diavolo", checché se ne dica, fa comodo a tutti. ;)