Annunciato ufficialmente GNOME 3.0

[mnovait]

Originariamente inviato da Claudinho_ita

Spero che riscrivino tutto in java, così da levarsi dalle palle sto C che ce lo portiamo dietro dall'anteguerra! Basta guardare gli attuali listati per notare i salti mortali che devono fare gli sviluppatori ora per tirare fuori qualcosa di decente con questo linguaggio. Ci vuole obbligatoriamente un linguaggio ad oggetti.
Per il resto sono completamente d'accordo col passaggio il più graduale possibile.. la scottatura di KDE 4 insegna

attenzione che qui qualche pioniere potrebbe venirti a strozzare direttamente a casa!

ps:comunque..sarebbe interessante..argomenta ancora!
dici che il salto fare a è un linguaggio OO?allora andrebbe bene in c++?

[71104]

Originariamente inviato da mjordan

Come mai l'object orientation è necessaria?

l'object orientation, parlando molto in generale e al di là del singolo linguaggio, consiste in una serie di meccanismi sintattici offerti dal compilatore che non possono far altro che aiutare il programmatore. un esempio: devi realizzare un sistema di puntatori a funzioni, per esempio perché vuoi far conoscere al tuo toolkit grafico una serie di callbacks? non ne sono rimasti molti al giorno d'oggi di programmatori che sanno dichiarare in C un puntatore a funzione, ma in OOP si tratta di una banalissima questione di funzioni virtuali, o di classi che rispondono ad una certa interfaccia.

Il C è anteguerra?

decisamente: è nato un bel po' di tempo fa direi, e offre costrutti sintattici che oserei definire non troppo moderni e un tantino limitati. in Java si discute se mettere o no le closures e in C ancora non si sa bene se è lecito usare const. in qualunque cacchio di piattaforma managed trovi un sistema di packages facile da usare e a prova di cicli, e in C ancora devi proteggere gli headers dall'inclusione multipla. e soprattutto, e questa è colossale... il C non offre collection classes. mi pare ovvio, una collezione in genere è un oggetto, ma se gli oggetti non ci stanno... ebbè, vorrà dire che un toolkit scritto in C non potrà fare uso di collections. inoltre poco poco che ti capita di programmare usando solo librerie che non offrono collection classes è la fine: niente hash tables, niente liste linkate, niente alberi binari, niente array a dimensione dinamica... tutto da riscrivere a mano. divertiti

Facciamo cosi. Togli il C dal pianeta. Cosa rimane dei sistemi Unix, di tutte le librerie vecchie e nuove che sono basate su C?

and your point is...?

Quali funzioni ti mancano dei nuovi linguagi di programmazione con le quali non potresti assolutamente vivere?

ma fammi il piacere -.-'
a parte che leggendo il resto del post te ne sarai fatto un'idea, ma il discorso non è che non si può stare senza: in C puoi programmare qualunque cosa, quarant'anni fa c'era il C e si viveva col C, quindi non è che non si può stare senza i linguaggi moderni; il discorso è che senza i linguaggi moderni si sta molto peggio, per l'esattezza si sta come si stava quarant'anni fa; se ci siamo evoluti un motivo ci sarà.

E soprattutto, come mai un DE in Java? Quale toolkit? Swing? SWT? Jambi? SwingX?

il toolkit grafico di Java è Swing: gli altri sono third-parties.


PS: di contro avresti potuto offrirci numerose argomentazioni per non usare la OOP in un toolkit grafico, di certo molto più valide della storia che se ne può fare a meno perché il C è attualità
tanto per cominciare ipotizziamo che un toolkit sia scritto in C++: si presentano immediatamente i soliti problemi di ABI mismatch. ipotizziamo che questo toolkit offra le sue classi standard sostitutive delle STL, e ignoriamo l'ABI mismatch tra versioni differenti della stessa libreria (casomai risolviamo tramite link statico): resta il fatto che con quel toolkit ci puoi programmare solo in C++. in realtà però non sto dicendo nulla di nuovo: questi e altri problemi sono stati risolti decenni fa da Microsoft con il tanto bistrattato COM, che costituisce uno standard binario grazie al quale è possibile far interagire applicazioni scritte in linguaggi diversi (purché COM-aware) secondo un'architettura object oriented: un oggetto COM può essere istanziato e richiamato in C, C++, Visual Basic, Delphi, .NET, Python...

[71104]

Originariamente inviato da mnovait

ps:comunque..sarebbe interessante..argomenta ancora!
dici che il salto fare a è un linguaggio OO?allora andrebbe bene in c++?

no, vedere post #42. è inutile portare avanti questa discussione, come ho già scritto è stato tutto già ampiamente osservato analizzato e risolto da Microsoft: Linux è semplicemente indietro, come al solito.

[mjordan]

Originariamente inviato da Europa

Java?!? Ma siamo pazzi? Quanto di più pesante possa esistere al mondo!

Anche questo è un po un mito. I tempi di startup della VM sono sicuramente lunghi, tuttavia molti test hanno evidenziato come delle applicazioni numeriche scritte in Java, tolto l'overhead iniziale dello startup della VM, venissero eseguiti in alcuni casi in tempi anche superiori all'equivalente algoritmo scritto in C++.
La tecnologia delle VM e dei bytecodes è crescita e migliorata esponenzialmente negli ultimi anni.

[Barra]

Originariamente inviato da Europa

- E17: Sinceramente, non esiste un DE più performante (ovvio, fluxbox e altri simili lo sono, ma sono esageratamente scarni).
La stessa velocità la riscontri sia se usi un P2 233Mhz che un Quad Core (prestazionalmente, quello che accade anche con Mac Os X). Esteticamente il più affascinante di tutti. Se fosse un po più stabile e avesse un Desktop+Filemanager più completo, non avrebbe eguali. Da quando lo uso costantemente (quasi un anno), non mi sono più sganciato... e ho accettato anche le sue limitazioni. Lo adoro e non c'è KDE/Gnome che tengano... voglio un ambiente che voli letteralmente e non mi piace sopperire con il processore alle scarse prestazioni del DM.
Sicuramente non lo consiglierei a mia nonna o mia madre... però se usi Linux e ne capisci un po, non puoi non rimanere affascinato dalle potenzialità di questo DE (provate la SVN + Exalt + Itask-ng...)

Quel progetto ha un unico problema: chi ne è a capo probabilmente è un ottimo programmatore (viste le prestazioni imho ha delle librerie che danno la paga alle QT) ma ha bisogno di qualcuno che gli dia qualche bel calcio nei maroni ogni tanto x ricordargli che esistono scadenze e che un progetto così complesso deve essere ben documentato, ben gestito e soprattutto DEVE ESSERNE PIANIFICATO LO SVILUPPO NEL TEMPO CON UNA CERTA COSTANZA!. Qui siamo a beta perenni, versioni definitive non se ne vedono da anni. Le api ho letto che sono tanto potenti quanto mal documentate. Così non si va da nessuna parte....

[71104]

Originariamente inviato da mjordan

[...] venissero eseguiti in alcuni casi in tempi anche superiori all'equivalente algoritmo scritto in C++.

*inferiori

[mjordan]

Originariamente inviato da 71104

l'object orientation, parlando molto in generale e al di là del singolo linguaggio, consiste in una serie di meccanismi sintattici offerti dal compilatore che non possono far altro che aiutare il programmatore. un esempio: devi realizzare un sistema di puntatori a funzioni, per esempio perché vuoi far conoscere al tuo toolkit grafico una serie di callbacks? non ne sono rimasti molti al giorno d'oggi di programmatori che sanno dichiarare in C un puntatore a funzione, ma in OOP si tratta di una banalissima questione di funzioni virtuali, o di classi che rispondono ad una certa interfaccia.

Strano perchè il C è uno dei linguaggi fra i piu' utilizzati al mondo (nel suo ambito e dopo Java, che comunque ricopre un ruolo non proprio parallelo a quello del C). Molti software nuovi continuano ad essere scritti in C proprio perchè C viene considerato "lingua franca". I "programmatori" che non sanno dichiarare puntatori a funzione, francamente, non andrebbero nemmeno definiti tali.
Nemmeno quelli che non capiscono che una collezione non è altro che una banalissima struttura dati.

Se non si è capito il concetto di puntatore, ho i miei grossi dubbi si sia capito il concetto di riferimento a oggetto. E di fatti molti dei problemi legati ai memory leaks in Java è dovuto al fatto che molti non sanno nemmeno cosa significhi. "Tanto ci pensa il garbage collector". Peccato che se un'oggetto rimane referenziato, non viene collezionato.

il C non offre collection classes. mi pare ovvio, una collezione in genere è un oggetto, ma se gli oggetti non ci stanno... ebbè, vorrà dire che un toolkit scritto in C non potrà fare uso di collections.

Questa è una sciocchezza grande come una casa. Una "collection" è semplicemente un'astrazione di una struttura dati, o meglio, una collezione di strutture dati, non è affatto "un'oggetto" che invece a sua volta è semplicemente un'ulteriore astrazione. E una struttura dati è un tipo aggregato. Un tipo aggregato non è altro che una struttura o una serie di strutture legate fra loro in modo da costruire un tipo complesso con una qualche forma logica. Inoltre, se non ti dovesse essere chiaro, una classe non è nient'altro che una struttura in grado di contenere metodi, con qualche paradigma in piu' a suo supporto come ereditarietà e incapsulamento. GLib è ciò che tu definisci "collection classes".
Non ci vuole di certo l'object orientation per programmare una lista o una tabella hash.

inoltre poco poco che ti capita di programmare usando solo librerie che non offrono collection classes è la fine: niente hash tables, niente liste linkate, niente array a dimensione dinamica... tutto da riscrivere a mano. divertiti

Perchè, usare semplici librerie esterne è cosi difficile? Sembra che programmare in un linguaggio si debba per forza di cose utilizzare SOLO la libreria fornita a corredo. In C la quasi totalità dei programmi si riferisce a Glib (nei sistemi Unix) ma è cosi portabile che non c'è praticamente motivo per scegliere di non usarla altrove. Gli array dinamici in C si chiamano array variabili e fanno parte del linguaggio dal 1999 e sono standard ISO.

il discorso è che senza i linguaggi moderni si sta molto peggio, per l'esattezza si sta come si stava quarant'anni fa; se ci siamo evoluti un motivo ci sarà.

Ci siamo cosi evoluti che ancora la quasi totalità delle applicazioni è scritta ancora in C/C++ cosi come la maggiorparte delle librerie. Tanto evoluti accademicamente che poi a livello pratico sempre al "passato" ci si va a parare. Non metto in dubbio che siano passi in avanti. Molte tecniche nell'ingegneria del software probabilmente non sarebbero nemmeno esistite grazie a questi linguaggi. Ma nel mondo pratico? Nel futuro? Sempre li andiamo a parare.

il toolkit grafico di Java è Swing: gli altri sono third-parties.

Tu posti sempre per far vedere che sai. Cosa c'entra adesso l'essere di terze parti o meno con la mia richiesta lo sai solo tu.

PS: di contro avresti potuto offrirci numerose argomentazioni per non usare la OOP in un toolkit grafico, di certo molto più valide della storia che se ne può fare a meno perché il C è attualità
tanto per cominciare ipotizziamo che un toolkit sia scritto in C++: si presentano immediatamente i soliti problemi di ABI mismatch. ipotizziamo che questo toolkit offra le sue classi standard sostitutive delle STL, e ignoriamo l'ABI mismatch tra versioni differenti della stessa libreria (casomai risolviamo tramite link statico): resta il fatto che con quel toolkit ci puoi programmare solo in C++.

QT Jambi è un'esempio che contraddice la tua (banale) dissertazione: è semplicemente una serie di classi wrapper collegate mediante JNI a un toolkit nativamente scritto in C++ che offre classi standard sostitutive alla STL. Nel breve futuro è previsto un wrapper per C#.

in realtà però non sto dicendo nulla di nuovo: questi e altri problemi sono stati risolti decenni fa da Microsoft con il tanto bistrattato COM, che costituisce uno standard binario grazie al quale è possibile far interagire applicazioni scritte in linguaggi diversi (purché COM-aware) secondo un'architettura object oriented: un oggetto COM può essere istanziato e richiamato in C, C++, Visual Basic, Delphi, .NET, Python...

Fantastico. Gli altri lo fanno pure senza COM. Elegante soluzione, non c'è che dire. Peccato che COM, in fondo in fondo non è un paradigma inventato da Microsoft nè tantomeno è interoperabile se non nel mondo Microsoft. Pure CORBA non è che sia stato tutto questo successo. E comunque rimane un paradigma: non capisco perchè COM sia la soluzione mentre classi wrapper non lo possano essere. Anche perchè COM non è proprio famoso per aver cosi alleviato la vita alla gente, anzi...

Io non sto facendo una guerra fra la strutturata e la object orientation: ognuna delle due tecniche presenta pregi e difetti e questo è innegabile. Io sto solo chiedendo i motivi alla gente che afferma che l'OO sia necessaria in Gnome. I vantaggi della OO li conosco, quindi è inutili che mi disserti. Qui siamo in un thread su Gnome. Tra l'altro Gnome ha proprio intenzione di integrare classi wrapper alle gnome-libs scritte in Java. Premesso che riscrivere il codice solo per togliere un capriccio è questione impensabile.

[Nocs]

Mi sa' che del release cycle del kernel linux avete capito ben poco.
Il merge window dura circa 10-14 giorni in cui vengono apportate le modifiche principali ai sorgenti linux (a _TUTTE_ le parti del kernel; questo perche' non esiste, come negli anni precedenti, una branch di sviluppo con numero dispari, per esempio la 2.3 o la 2.5 per i successivi kernel stabili 2.4 e 2.6). Le modifiche provengono di solito dalla branch di Andrew Morton che contiene patch sperimentali le quali vengono appunto testate per alcuni mesi nei sorgenti 'mm' prima di essere immesse nella branch principale del kernel. Dopo questo periodo Linus 'blocca' la branch e i successivi RC contengono principalmente bugfix a bug o regressioni introdotte durante il merge window di cui sopra. E' ancora Linus che decide quanti RC rilasciare, ma di solito sono da 7 a 9 (in media 1 RC a settimana).
Da alcuni mesi hanno introdotto una nuova branch detta 'linux-next' che serve a accumulare/contenere le patch per la release +2 e quindi per dare la possibilita' ai maintainer delle varie architetture e dei subsystem di adeguare le patch tra di loro.
Dopo ogni release finale, la procedura riparte dall'inizio. Nello stesso tempo un gruppo di sviluppatori cerca e elimina bugs nella versione stabile. Queste successive release prendono il nome di 2.6.25.YY (per esempio per la serie 2.6.25).

[zappy]

Originariamente inviato da peppepz

gnome è da drogati, non ci sono i tasti "annulla" nelle finestre di dialogo, siamo pazzi? :-D

X te sarà uno scherzo, ma la mancanza di OK-Annulla imho è una cosa fastidiossissima e che mi fa seriamente dubitare di usare Gnome. Trovo che sia estremamente idiota da parte degli sviluppatori fare di tutto x tenere lontano chi proviene dal mondo windows, x es usando combinazioni di tasti diverse togliendo l'annulla dalle finestre (troiata immane) ecc. ecc.

Quanto alle gtk, ci sono già diversi sw anche x win che le usano. Peccato che spesso ogni sw che installi si installa le "sue" gtk, in pratica inficiando compeltamente il concetto di "libreria".

[Barra]

Originariamente inviato da zappy

X te sarà uno scherzo, ma la mancanza di OK-Annulla imho è una cosa fastidiossissima e che mi fa seriamente dubitare di usare Gnome. Trovo che sia estremamente idiota da parte degli sviluppatori fare di tutto x tenere lontano chi proviene dal mondo windows, x es usando combinazioni di tasti diverse togliendo l'annulla dalle finestre (troiata immane) ecc. ecc.

Sinceramente è ormai 2 anni che uso solo linux. 2 anni passati quasi esclusivamente con lo gnomo. Devo dire che non ho mai sentito la mancanza del tasto annulla. Sono cmq convinto che a molti piacerebbe averlo.

Quanto alle gtk, ci sono già diversi sw anche x win che le usano. Peccato che spesso ogni sw che installi si installa le "sue" gtk, in pratica inficiando compeltamente il concetto di "libreria".

Infatti installare su windows un app scritto con le gtk è peggio che usare wine su linux!

Originariamente inviato da Claudinho_ita

Spero che riscrivino tutto in java, così da levarsi dalle palle sto C che ce lo portiamo dietro dall'anteguerra! Basta guardare gli attuali listati per notare i salti mortali che devono fare gli sviluppatori ora per tirare fuori qualcosa di decente con questo linguaggio. Ci vuole obbligatoriamente un linguaggio ad oggetti.
Per il resto sono completamente d'accordo col passaggio il più graduale possibile.. la scottatura di KDE 4 insegna

Java necessità che venga caricata una VM in memoria, è solitamente più lento (sicuramenente con la VM in client mode) anche perchè vi è l'overhead della traduzione da parte della VM da bytecode a codice nativo.

Poi non sono così sicuro che abbandonare il C per usare un linguaggio OO in librerie più o meno "basilari" sia così saggio. A cominciare dal fatto che se poi volessi usare un'API da un programma scritto in un linguaggio non OO (ad esempio per piccoli programmi l'OOP è pressochè inutile) inizierebbero le complicazioni, mentre il contrario è un'operazione già più agile (anche grazie a GObject).

[Rafagano-RM]

ma che è una gara? Gnome e KDE sono figli vostri? Se volete parlare di leggerezza semmai usate XFCE ! Scusate ma mi sembrano polemiche sterili, è meglio questo .... è meglio quello... secondo me è solo questione di gusti, ed ognuno si tenga i propri.. L'importante è non usare Microsoft !!!
Un saluto a tutti i pinguini.
El Rafagano, tu Hermano.

Originariamente inviato da Barra

Quel progetto ha un unico problema: chi ne è a capo probabilmente è un ottimo programmatore (viste le prestazioni imho ha delle librerie che danno la paga alle QT) ma ha bisogno di qualcuno che gli dia qualche bel calcio nei maroni ogni tanto x ricordargli che esistono scadenze e che un progetto così complesso deve essere ben documentato, ben gestito e soprattutto DEVE ESSERNE PIANIFICATO LO SVILUPPO NEL TEMPO CON UNA CERTA COSTANZA!. Qui siamo a beta perenni, versioni definitive non se ne vedono da anni. Le api ho letto che sono tanto potenti quanto mal documentate. Così non si va da nessuna parte....

Mah... per guadagnare un po' di velocità, Enlightenment utilizza delle soluzioni tutt'altro che eleganti. Ad esempio per l'interfaccia non viene usata grafica vettoriale ma vengono utilizzate solo immagini bitmap (non parlo solo delle icone, ma di tutti gli elementi grafici).

[peppepz]

Ancora tutte queste battaglie gnome vs. kde? C vs. C++? Java vs. resto del mondo?
A parte che la battaglia non si pone neanche perché kde domina su gnome e Java prende a calci nel sedere entrambi C e C++ (), manteniamo la discussione nel campo dell'obbiettività mettendo sul tavolo i pro e i contro:

- C è più semplice, più portabile (paradossalmente) e richiede meno risorse (vabbe' questo ha cessato di essere un problema ai tempi dei 386). Ecco perché la maggior parte delle librerie Unix sono ancora scritte in C, laddove in Windows il C è stato abbandonato dalla fine degli anni '80 (avete dato un'occhiata ai sorgenti di windows "scivolati" sul mulo qualche mese fa? ;-)). Provate col gcc a compilare un progetto in C e uno in C++, a parità di complessità di codice quello in C++ ci starà tre volte tanto. Per non parlare dei problemi in cui si incorre mescolando codice scritto in C++ con ABI diverse (speriamo che abbiano finito di modificarle ogni tre mesi...).

- C++ (l'orientamento agli oggetti) rende il codice più elegante, più veloce da scrivere e da riutilizzare: guardate la velocità con cui procede lo sviluppo di KDE, che in meno di un anno è passato da un'accozzaglia di codice crascereccio a un ambiente utilizzabile (provate il 4.1). Non sarà che gnome è più "semplice" più per... necessità che per scelta? E guardate gli artifici che sono costretti a usare nelle librerie C per renderle un po' più simili a qualcosa di orientato agli oggetti: macro che generano codice che definisce gli oggetti (difficili da comprendere e infernali da debuggare), nomi delle funzioni stile reverse-polish (roba tipo gtk_button_background_paint() per intenderci ), reference counting manuale (che puntualmente finisce per malfunzionare visto che i progetti più complessi sono sempre appestati di memory leak). Insomma, col C ti ritrovi a dover fare tanto lavoro che il C++, o meglio ancora un ambiente di sviluppo completo tipo QT o Java, fa per te.

- Gnome è più semplice ed elegante: la gente che lo sviluppa ha un'ossessione per le linee guida ai limiti del fascismo, e questo si vede nel risultato finale che è un ambiente operativo coerente, puntuale e conciso. Difficile trovare due modi diversi di fare una stessa cosa oppure trovarsi di fronte a scelte multiple senza sapere quale sia la migliore.

- KDE dal canto suo ha sempre portato avanti la filosofia "prima mangiare, poi filosofare": le nuove caratterstiche si aggiungono sempre e comunque e solo poi, se resta tempo, si rimette tutto in ordine. Tanto per fare un esempio, confrontate kopete con pidgin, le caratteristiche in più del primo non si contano (una fra tutte, supporto video?) eppure per qualche motivo la gente continua a preferire il secondo.
Un esempio "storico": KDE è stato progettato fin dall'inizio sulle QT, che erano malviste dal mondo GNU per motivi puramente politici; gli sviluppatori di KDE non si sono lasciati scoraggiare perché semplicemente le QT funzionavano meglio di qualunque altro toolkit dell'epoca, mentre una scelta del genere da parte degli gnomofili sarebbe stata impensabile.

Qual è un giudizio finale che dò personalmente? Semplice, quello che conta non è tanto il linguaggio quanto le API. Il KDE4 è fatto in C++ naturalmente, ma ha bindings per Ruby, Python etc. etc. IMHO la migliore scelta è mantenere aggiornati i binding, per consentire agli sviluppatori di scegliere il linguaggio che ritengono più adatto alla loro applicazione. L'utente finale non dovrebbe accorgersi del linguaggio usato per creare un programma (capito, sviluppatori del Java ;-)?).

[bLaCkMeTaL]

manca la funzione "annulla" dite? Io da un anno uso ubuntu e neanche me ne ero accorto!

[peppepz]

Originariamente inviato da bLaCkMeTaL

manca la funzione "annulla" dite? Io da un anno uso ubuntu e neanche me ne ero accorto!

E' da un anno che usi ubuntu? Vabbe' non ti preoccupare, non è grave, si rimedia in 5 minuti. Apri una shell e scrivi sudo apt-get install kubuntu-desktop. Meglio ancora se prima attivi i repository della intrepid, così ti trovi installato il kde 4.1 che è una poesia .

[Spottyblu]

Beh davvero si discute del sesso degli angeli. Io ho sempre ritenuto un guaio il fatto che la stessa cosa si possa fare in 10 modi diversi: la odiavo sotto Win perché alla fine poche operazioni necessarie creano situazioni elefantiache. Ho usato lungamente KDE poi installando Ubuntu (non avevo kubuntu) ho cominciato ad usare Gnome e me ne sono innamorato (avete mai usato il nautilus action configuration? non mi pare che ci sia in giro niente di simile ... almeno in Win e Kde non ne ho rilevati se non hanno aggiunto adesso..).
Sulla semplicità di Gnome mi pare non si possa discutere, ovviamente non può farlo chi usa un sistema da 10 anni, è evidente che passando ad altro lo trovi più complicato ed incompleto.
Vi manca Annulla? Può darsi, ma il fatto che qualunque operazione debba fare possa farla e ricordarmene dopo 20 giorni senza impazzire fra menu di tutte le forme e dimensioni ammp (perchecaxxo dobbiamo usare pure le sigle inglesi?) è impagabile.
Poi pensare che ci sia qualcosa di "meglio" mi pare demenziale come dire se sono meglio le bionde o le brune quelle in linea da indossatrice o quelle supermaggiorate... se hai scelto quello è evidente che ti piace di più...

[peppepz]

Vabbe' dai, queste sono sane flamewar, lo sappiamo tutti benissimo che non esiste un migliore in senso assoluto, ma il divertimento sta nello scrivere tutto quello che ti pare lecito per far cambiare idea a chi non la pensa come te .
P.S. hai qualche dubbio su cosa scegliere fra la supermaggiorata e una modella sifilidica dall'espressione cagnesca e i piedi storti? Tsk!

[masand]

Originariamente inviato da peppepz

Vabbe' dai, queste sono sane flamewar, lo sappiamo tutti benissimo che non esiste un migliore in senso assoluto, ma il divertimento sta nello scrivere tutto quello che ti pare lecito per far cambiare idea a chi non la pensa come te .
P.S. hai qualche dubbio su cosa scegliere fra la supermaggiorata e una modella sifilidica dall'espressione cagnesca e i piedi storti? Tsk!

E no dai... GNOME non è sifilidico!!!

A parte gli scherzi, io ero utente KDE ultra sfegatato, praticamente ho cominciato ad usare Linux da quando c'è stata la prima release di KDE... Poi, così tanto per far avvicinare mia moglie al pinguino le ho installato Ubuntu 6.06 e da allora, cercando di configurarglielo a dovere, mi sono innamorato di GNOME. È vero che KDE ha molte opzioni a portata di click, ma è anche vero che GNOME ha moltissime di quelle opzioni solo che sono più nascoste.

Con il gconf-editor fai molte cose che non ti è permesso fare con i tool grafici (ma che sinceramente un utente normale non ne ha nemmeno poi così bisogno), per non parlare delle opzioni del gtkrc dei temi, di GNOME stesso... ecc. ecc.

Sinceramente, per come è stata la MIA esperienza, sono portato a dire che GNOME è più da smanettoni...

Poi oh, va benissimo che ci siano più DE, non trovate? Ognuno sceglie quale più si confà al suo uso.

Che usino C, Java o il Padre nostro, sinceramente non me ne importa molto... Sono un utente non un programmatore

Un saluto a tutti...
masand

[Europa]

Originariamente inviato da Spottyblu

Poi pensare che ci sia qualcosa di "meglio" mi pare demenziale come dire se sono meglio le bionde o le brune quelle in linea da indossatrice o quelle supermaggiorate... se hai scelto quello è evidente che ti piace di più...

Non posso essere d'accordo con te... Non c'è dubbio che le bionde maggiorate siano certamente la categoria migliore in assoluto!