GNOME compie vent'anni e festeggia

[aqua84]

Originariamente inviato da sonnet

...vedi un po te la dimensione della fesseria che hai scritto

questa mi fa ancora piu ridere delle altre cose che hai scritto
comunque vedo che ne vai fiero di ciò che scrivi, nn voglio svegliarti dal mondo dei sogni

[s-y]

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

[pabloski]

Originariamente inviato da zappy

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 )

Originariamente inviato da zappy

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

Originariamente inviato da zappy

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

Originariamente inviato da zappy

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

[omerook]

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

[cdimauro]

Originariamente inviato da pabloski

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.

[pabloski]

Originariamente inviato da cdimauro

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

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?

Originariamente inviato da cdimauro

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.

[aqua84]

in effetti a me upstart non è che dispiacesse

[cdimauro]

Originariamente inviato da pabloski

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

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.

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.

[s-y]

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

[s0nnyd3marco]

Originariamente inviato da cdimauro

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.

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.

[cdimauro]

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

[pabloski]

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Quel genere di mentalita' devono avere i suoi creatori.

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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

Poettering e Sievers amano crearli i problemi

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

[cdimauro]

Originariamente inviato da pabloski

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

Quel genere di mentalita' devono avere i suoi creatori.

Beh, Linux E' un kernel monolitico, per cui non è che ci sia differenza. 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.

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

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

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

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.

[digieffe]

Originariamente inviato da pabloski

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)

[pabloski]

Originariamente inviato da cdimauro

Capito. Comunque non è tutto così (altrimenti saremmo già passati ad altre soluzioni ), 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

[cdimauro]

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



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.

[pabloski]

Originariamente inviato da cdimauro

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

purtroppo

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

[cdimauro]

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

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.