Newsgroup: it.comp.os.dibattiti
Titolo: GNOME: Armageddon

Cari lettori l'armageddon di GNOME è iniziato.
In primo luogo desidero chiarire che questo testo è stato scritto per
essere una fonte di informazioni altrimenti non avrei passato tanto tempo
nella sua scrittura.  
Anche se non vi frega nulla di GNOME, potreste trovare alcune informazioni
interessanti all'interno di questo testo che gradite leggere. per favore
provate a capire i miei punti di vista anche se è a volte difficile,
altrimenti vi svegliate un giorno ed avvertite l'esigenza di passare ad un
sistema operativo differente.
Nelle righe seguenti proverò a darvi una certa comprensione della Comunità
di GNOME, le cose che stanno avvenendo dietro le quinte, le informazioni
che potrebbe valere la pena comunicare e riflettere sopra. 
Molti di noi seguono il progetto GNOME fin dall'inizio. GNOME è un
progetto promettente soprattutto perché è scritto in C, facile da usare,
configurabile e quindi si inserisce perfettamente nella filosofia di *NIX,
per citare soltanto alcuni dei vantaggi.
Purtroppo questi vantaggi sono cambiati con la versione recentemente
rilasciata di GNOME.  Il team di sviluppo ha avuto in qualche modo l'idea
di ottimizzare GNOME verso un tipo completamente diverso di utente, il
cosiddetto utente corporativo.
In altre parole stanno designando come bersaglio la gente che non ha
solitamente familiarità o esperienza con gli ambienti desktop, solitamente
gente orientata agli affari che è disposta a pagare per avere GNOME sui
propri computers.
Avendo questo nuovo obiettivo in mente, la squadra di sviluppo,
principalmente sotto contratto di società come RedHat, Ximian e Sun ha
deciso di semplificare il desktop il più possibile rimuovendo tutta la sua
flessibilità in favore di un'interfaccia semplice, pulita e facile per non
confondere i loro nuovi possibili clienti.  Finora l'idea di un desktop
pulito e facile da usare è onorabile.
Alcune delle nuove idee, caratteristiche e applicazioni quali gconf
http://www.gnome.org/projects/gconf/
 , un sistema diabolico in stile
Windows-Registry, il riordino dei pulsanti nelle finestre di dialogo, la
rimozione del 90%-95% di tutte le preferenze visibili nel centro di
controllo e nelle applicazioni, la nuova direzione di GNOME
l'atteggiamento del team di sviluppo ha reso molti degli utenti realmente
infelici. Questi sono soltanto un paio di esempi e la lista può essere
espansa facilmente ma per ora questo è abbastanza.  Ora lasciatemi entrare
più in profondità in questi aspetti.
Potete immaginare che gli utenti sono diventati veramente frustrati
http://www.osnews.com/story.php?news_id=1280
 perché il loro caro desktop
GNOME era maturato in qualcosa che non avevano desiderato.  Col tempo,
sempre più email arrivarono sulle mailing lists di GNOME dove gli utenti
tentarono di spiegare le loro preoccupazioni e frustrazioni
http://mail.gnome.org/archives/usability/2002-October/msg00021.html
http://mail.gnome.org/archives/usability/2002-October/msg00033.html
http://mail.gnome.org/archives/GNOME-devel-list/2002-September/msg00017.html

 - GNOME: Armageddon <GN...@Armageddon.it> : 
[snip]
ROTFL !
Questi troll non sanno più cosa inventarsi :D










.
Ma al team di sviluppo di GNOME non importa nulla di quello che i loro
utenti pensano o desiderano e il più delle volte danno sempre le
stesse risposte. Gli utenti dovrebbero o "aprire una segnalazione" su
BugZilla o le email degli utenti sono rifiutate così che alla fine
sembrano flameo il feedback degli utenti semplicemente non è
apprezzato. qualsiasi cosa avvenga le risposte non sono realmente
soddisfacenti per l'utente. anche suggerimenti costruttivi non sono
apprezzati
http://mail.gnome.org/archives/usability/2002-August/msg00261.html
 .
Se ci pensate per un minuto è chiaro che al team di sviluppo in realtà
non importano le lamentele dell'utente casalingo -- è più importante
per loro raggiungere i clienti con i soldi. Sembra che questo sia
stato detto loro dai leader delle società -- tutto ciò che riguarda
GNOME è già stato deciso, non è possibile tornare indietro o
comunicare direttamente. Non fatevi ingannare da frasi come 'noi
ascoltiamo i nostri utenti'. Vi ascoltano -- si, per fare stupide
battute su di voi dopo.
Credevo che fosse tutto fondato sull'amicizia, sul programmare per
hobby, sulla comprensione. Ma in realtà sembra che tutto ciò che
importa siano i soldi, tutto il resto sono bugie e sogni. E' ora che
la gente si svegli.
Non molto tempo fa hanno espulso dal team uno dei più importanti
sviluppatori di GNOME, Martin Baulig
http://lists.gnome.org/archives/gnome-hackers/2001-June/msg00120.html
-- una persona che lavorava duramente per dare la giusta direzione a
GNOME, un'ottima persona che dedicava tutto il suo tempo a GNOME.
Ma le meschine élites di GNOME come Havoc Pennington
http://www106.pair.com/rhp/
 sono responsabili del suo abbandono del
progetto GNOME -- la pressione che era stata posta su di lui era
troppa.
Con il nuovo desktop GNOME sono avvenuti molti cambiamenti di
interfaccia come il riordino dei pulsanti
http://mail.gnome.org/archives/usability/2001-November/msg00003.html
-- inutile dire che questo confonderà la gente che è abituata da
secoli all'ordinamento precedente. Anche un guru di Linux come Alan
Cox
http://mail.gnome.org/archives/usability/2001-November/msg00004.html
non era eccitato dall'idea, ma le élites di GNOME come Havoc
Pennington, Seth Nickell, Calum Benson e Dave Bordoley ne sapevano più
di lui. Perché seguire la via di tutti gli altri desktop esistenti?
Perché non fare qualcosa che non confonde gli utenti e rimane ancora
utilizzabile? Be' sembra troppo facile. GNOME deve essere diverso da
tutto il resto allora hanno cambiato l'ordine dei pulsanti cosa che fu
uno dei motivi dell'insoddisfazione degli utenti. Dissero che c'era
stata una dura discussione su questo e fu presa la decisione di
scambiare i pulsanti. Ma credo che abbiano semplicemente copiato da
MacOS perché la maggior parte degli sviluppatori GNOME usa un
Macintrash come portatile o desktop. Peccato che abbiano dimenticato
che gli utenti tendono a mischiare le applicazioni e questo porterà a
strane ricerche del pulsante giusto.
Ma come se non bastasse le stesse persone hanno deciso che le nuove
GNOME Human Interface Guides siano le "ultima non plus ultra" delle
guide alle interfacce utente. L'annuncio sosteneva che quelli del KDE
avevano collaborato alle guide. In realtà ne sentirono parlare la
prima volta
http://lists.kde.org/?l=kde-usability&amp;m=102992933408105&amp;w=2
quando Seth Nickell andò sulla mailing list di KDE cosa avvenuta dopo
l'annuncio. Potete immaginare che si incavolarono molto per questo
atteggiamento. Per riassumere, chiarirono che quelli di GNOME
avrebbero dovuto farsi gli affari propri
http://lists.kde.org/?t=102992891600004&amp;r=2&amp;w=2
 .
Il problema delle nuove guide all'interfaccia fu, che qualsiasi
piccolo smanettone diventò un esperto di UI da un giorno all'altro.
Molti programmi GNOME che noi usiamo spesso diventarono subito un
disastro. Smanettoni che non avevano mai programmato correttamente
nella loro vita cominciarono a seguire la parola d'ordine della
semplificazione. Per esempio guardate cosa è successo a Galeon
http://galeon.sourceforge.net/g2ui.html
 (attenzione all'ultimo
paragrafo). Anche Philip Langdale un progtrammatore di lungo corso di
Galeon si indignò moilto e spedì questa e-mail
http://sourceforge.net/mailarchive/forum.php?thread_id=1176218&forum_id=6200
alla mailing-list.
Ecco un'altra ragione per cui gli utenti si sono arrabbiati. L'élite
dà per scontato, che gli utenti non sanno nulla del loro sistema.
Sulle mailing-list potete trovare un paio di e-mail altamente
offensive contenenti frasi quali:
- "gli utenti non sanno cosa sia un gestore finestre", 
- "gli utenti non sanno cosa sia un tema", 
- "gli utenti non sanno cosa sia una cartella home",
- "gli utenti non sanno ricompilare il kernel", 
- "gli utenti non vogliono personalizzare il desktop", 
- "gli utenti non sanno a cosa servano queste opzioni".
Potete immaginare che molta gente si sia sentita offesa da queste
righe perché è proprio a questi utenti di GNOME che queste frasi si
riferiscono. Per leggere altre frasi del genere sulle mailing list di
GNOME basta che cerchiate negli archivi
http://mail.gnome.org/archives/
 . Va detto che la maggior parte di
queste righe vengono da Havoc Pennington.
Pratiche così malvagie non dovrebbero essere tollerate dagli utenti e
vanno combattute. Gli utenti *NIX non sono stupidi. Chi ha dato ad
Havoc Pennington il diritto di decidere cosa vuole l'utente e cosa no?
Molti utenti gli hanno detto
http://mail.gnome.org/archives/usability/2002-August/msg00001.html
 che
chi usa un sistema *NIX è ben consapevole delle proprie capacità di
gestire un sistema così complesso. C'è un motivo per cui gli utenti
stanno passando a UNIX. Vogliono imparare, vogliono usare tutta la
flessibilità del sistema, vogliono cambiare tutto ciò che vogliono.
Per giunta, guardate cosa è successo a Nautilus. I manutentori
correnti di Nautilus hanno avuto l'idea di cambiare tutti i concetti
di Nautilus in un design di interfaccia utente object-oriented.
Potrebbero interessarvi molto le esatte parole della visione di Alex
Larsson del futuro di Nautilus
http://mail.gnome.org/archives/nautilus-list/2002-September/msg00093.html
.
Per riassumere, si dà per scontato che l'utente non deve occuparsi
della sua cartella home o del suo filesystem perché potrebbe
confolderlo o perché non lo capisce. I nuovi concetti di Nautilus
dovrebbero essere che l'utente si occupa di simboli nella vista di
Nautilus. Ad es. c'è un simbolo di un CD-ROM e cliccandoci sopra
vedete la cartella del cdrom, c'è un simbolo di una fotografia e
cliccandoci sopra vedete la lista di tutte le vostre immagini, c'è un
simbolo musicale e cliccandoci sopra vedete una lista dei vostri mp3.
Non sapete dove sono tutti questi files perché non vi occupate del
livello inferiore della vostra homedir o filesystem come menzionato
prima.
Non molto tempo fa c'è stato un report sui 'due capitani del Nautilus'
da parte di un contributore GNOME. Potete immaginare che un report del
genere nonn può essere preso sul serio perché è fatto proprio da
quelli di GNOME. Ora potete saperne di più
http://www.gnomedesktop.org/article.php?thold=-1&mode=thread&order=0&sid=718
. Possono essere interessanti le risposte da parte di vari utenti
sparsi per il mondo di ciò che pensano di GNOME e Nautilus. Un altra
lettura interessante si trova qui
http://www.gnomedesktop.org/article.php?sid=731
 .
Il problema del file selector è stato discusso a lungo nella comunità
di GNOME. Alla fine hanno trovato una soluzione ed hanno deciso di
usare questo brutto fileselector
http://www.linuxworld.com/site-stories/2003/0228.petreley.html
 invece
di quest'altro 
http://home.wanadoo.nl/sbm/
 che è stato sviluppato a
lungo da un volontario e in generale ha aspetto e funzionalità
migliori.
La maggior parte degli utenti non ha nessun problema con l'idea di
mantenere le cose pulite ed eleganti. Rimuovere qualche opzione
ridondante è in effetti una buona idea ma non ci si ferma più. La
gente ha cominciato a rimuovere tutto dalle proprie applicazioni.
Siete costretti ad usare dubbi programmi come GConf-editor che
funziona in pratica come regedit di Windows, per modificare opzioni
non documentate. Non credo che sia un vantaggio. Anche la possibilità
di modificare le opzioni a mano è stata rimossa con questa brutta
implementazione di GConf. Tutte le vostre preferenze sono memorizzate
in un albero di directory con un numero sconosciuto di files *.xml.
Anche se cancellate programmi le loro chiavi rimangono orfane in
questi alberi e trovarle è come cercare un ago in un pagliaio. Alla
fine merita una discussione un tale sistema registry-like su un
sistema gestito da un singolo utente casalingo. Non abbiamo avuto
bisogno di un tale sistema per oltre 30 anni ma il team di sviluppo di
GNOME ha avuto l'idea di copiare uno dei più stupidi sistemi di
Windows. Per non dire che la copia è ancora peggio dell'originale.
E' una vergogna vedere come un ottimo desktop è stato gettato
nell'immondizia da queste persone. Ma c'è molto altro dietro le quinte
che non sappiamo. Tutto intorno a GNOME è una grande strategia di
marketing. Povera gente lavora così tanto su GNOME gratis, e società
come quelle che ho citato sopra fanno i soldi. Certo potreste dire --
fai un fork() di GNOME -- ma seriamente come è possibile? un progetto
di queste dimensioni richiede molta gente solo per mantenere il codice
in vita e compatibile. Be' sapete, è tutto open sorcio, il codice è
firmato con la GNU/GPL o la GNU/LGPL, nessuno lo può controllare.
Anche le società lo sanno. Ma se non potete possedere il codice --
assumete gli sviluppatori. Potete dirigerli come fantocci in qualsiasi
direzione vogliate. E' proprio questo che sta accadendo a GNOME.
Be' potreste facilmente dirmi semplicemente di non usare GNOME e
lasciare che facciano quel che vogliono. Avete ragione ma le cose sono
più complicate al giorno d'oggi. GNOME sta influenzando molti progetti
come xfree86, che recentemente ha aggiunto molti componenti di GNOME
alla CVS. Sappiate che con la prossima versione di Xfree86 vi
ritroverete molti componenti GNOME senza saperlo, codice come
gnome-xml 
http://www.xmlsoft.org/
 , pkgconfig
http://www.freedesktop.org/software/pkgconfig/
 , fontconfig
http://www.fontconfig.org/
 , xcursor ed xft2 è stato scritto da gente
che è pesantemente coinvolta nello sviluppo di GNOME. Anche GIMP sta
maturando sempre più nell'aspetto e la funzionalità di un'applicazione
nativa GNOME. La versione CVS di GIMP ha molte pixmap GNOME
all'interno e stanno lavorando pesantemente per integrare GIMP in
GNOME. Mon oggi, ma la direzione e segnata e temo il giorno che
succederà.
E' bene che queste cose esistano ed è bene che si lavori su xfree86 e
gimp. Ma pensate a chi non usa GNOME. E loro? Perché costringerli ad
avere componenti GNOME installati? Perché GNOME non può fare come KDE
e farsi gli affari oropri senza infettare altri progetti come l'AIDS.
Vedo sempre più librerie ed applicazioni che non hanno nulla a che
vedere con GNOME saltare sulla barca di pkgconfig che non serve a
nulla. Guardate a quello che accadrà a Solaris, il famoso sistema
operativo *NIX usato da grosse società e grandi esperti. Stanno
veramente progettando di sostituire CDE con GNOME. So che CDE non era
il migliore desktop ma almeno si inchiodava raramente e si inserisce
molto meglio nella filosofia di Xfree86 con il suo sistema di
configurazione rispetto a GNOME. Sapete la vecchia maniera con le
opzioni definite in .xdefaults e tutte le configurazioni di default
vanno in /etc/x11/app-defaults/ etc. Comprensibile che la veccia
maniera possa bloccare il futuro delle applicazioni per sistemi
multiutente -- ma perché deve essere un sistema stile Windows Registry
che rimpiazza la configurazione futura ?
Be' per finire personalmente non mi piace molta di questa roba. Non
sopporto il riordino dei pulsanti, non mi piace GConf, e soprattutto
non mi piace l'influenza di GNOME sulle altre applicazioni.
L'atteggiamento di alcuni sviluppatori GNOME è un'altra storia perché
siamo tutti umani che reagiscono diversamente. Per fortuna c'è molta
gente che la pensa come me altrimentti non potrei inserire tanti link.
Anche tra gli sviluppatori di GHNOME ci sono voci silenziose di gente
che detesta molte di queste decisioni ed in silenzio usa
qualcos'altro.
Adesso se controllate la CVS di GNOME quotidianamente scoprite che lo
sviluppo di GNOME sembra essersi praticamente fermnato. Ci sono pochi
contributi alla loro CVS. Mentre progetti come KDE raggiungono
facilmente 10-20mila commits al mese -- GNOME arriva a 1-2mila al mese
nei periodi migliori.
La situazione di GNOME sembra veramente poco chiara quindi sarebbe
meglio se non influenzasse così tanto gli altri programmi o alla fine
dovremo fare i conti con un disastro.
Ora spero che questo testo sia stato informativo per voi. Spero che
iniziate a pensare alla situazione e la direzione complessiva. La
situazione di GNOME è poco chiara, anche il loro obiettivo vacilla
dato che non riesco a pensare che gli utenti a cui si rivolgono
abbiano mai sentito parlare di *NIX o Linux. Progettano di uscire
dalla lotro nicchia dello 0.05% ma certamente questo non succederà se
continueranno con questo atteggiamento.

 Potete immaginare che gli utenti sono diventati veramente frustrati...
un bel fork no, eh?
saluti longilinei

 Cari lettori l'armageddon di GNOME č iniziato.
[cut]
Ma sei Maya?
-- 
il Vide - ICQ# 5301833
IAMM - it.arti.musica.metal 
http://www.heavy-metal.it
Tessera #8 "Tira Clarenzo e m' illumino d' immenzo"

 un bel fork no, eh?
 
Se si dovesse forkare ogni volta che gli utenti non sono contenti ci
sarebbero 800 versioni per ogni applicazione OS.
Prima era immaturo perchè non c'erano delle *guide* o un draft per 
l'interfaccia, era difficile da usare, i menu erano troppo difficili
e blablabla.
Adesso è troppo facile e non permette  alcune personalizzazioni (tipo ?
lasciato alla fantasia del lettore).
Nello stesso articolo quotato dal fake/troll/spammer (che altra riprova
non ha trovato se non la classica flame-fest ala Punto Informatico) c'è
il solito FUD da tre soldi e le solite cose dette e ridette.
E' stato ripetuto migliaia di volte che sono le distribuzioni a dover
personalizzare Gnome, che la versione su 
gnome.org
 è semplicemente una
piattaforma. Che distro usa 'sto qua ? Red Hat, dove per strambi motivi
non si possono cambiare i menu se non con un hack ? SuSE dove Gnome
viene praticamente compilato 'as is' e sbattuto tra gli RPM ? Xiamian
Desktop ? Debian ? Slackware ?
Cazzate, come sempre.
Con la chicca di GConf, che alcuni anzichè 'registro alla Windows'
chiamano 'file XML'. LoL :D

 sarebbero 800 versioni per ogni applicazione OS.
Concordo; ero ironico, senza faccina ma ironico.
saluti contestuali

 
http://mail.gnome.org/archives/GNOME-devel-list/2002-September/msg00017.html
scusa, dov'è l'entrata in profondità?

 veramente progettando di sostituire CDE con GNOME.
No, non stanno progettando, hanno progettato.
Si sono sentite molte lamentele devo dire... :D

Più che informativo divertente.
Grazie
	Nicholas

 Ma sei Maya?
Naaaaaaaaa, matta, non troll.

 Gnome, che pensiero strano.
Effettivamente sarebbe Gnome a essere un'applicazione di Gimp, a essere
fiscali :D

 Più che informativo divertente.
Bah, le solite trollate alla Loli-Queru, in più un po' di paranoia
simil "GNOME in MONO" che era esplosa un annetto fa...
Ciao,
 Emmanuele.
-- 
"L'ottimismo è un atto rivoluzionario" -- Col. Nick Fury, USM 24
Emmanuele Bassi (Zefram)              [ 
http://digilander.iol.it/ebassi/
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 nei periodi migliori.
Guarda che maggior numero di commit non vuol dire miglior codice, o
miglior risultato.
+++
Ho snippato su molte cazzate deliranti, ma ci sarebbe roba da smontare
in ogni paragrafo. E non ho tempo, né voglia.


 
Invece io concordo,nonostante lui abbia usato toni un po' sopra le righe.
Gnome1.4 era migliore, sia come filosofia, che per una certa categoria di
utenti (con me incluso).
L'idea iniziale di gnome, un sistema modulare con alternative fra di loro
compatibili ( si poteva scegliere il window manager etc.) e' stata
brutalmente uccisa: gnome2 ha ristretto le scelte (e, ribadisco, il wm di
default metacity, bleah)
Oggi per esempio e' uscita la nuova versione di sawfish (1.3) l'ho
installata e la mia vita e' migliorata di colpo!
Non parlatemi poi di gconf, quante volte ho dovuto cancellare la directory
perche' non andava niente e ho perso anche le configurazioni dei programmi
innocenti.
Mi mancano anche varie features di galeon, come i tab sulla sinistra.
Io continuo a sperare che si ravvedano.
Insomma come utente "tecnico" preferivo gnome1.4. 
Devo anche dire che ci saranno vari utenti "non tecnici" che si troveranno
in difficolta' con metacity.
E cio' mi spiace.

 in difficolta' con metacity.
io invece trovo che metacity, per quanto più ridotto faccia il suo dovere
egregiamente.
Secondo me mancano due cose solo (che magari ci sono ma non le ho viste):
un modo di gestire i temi complessivo, cioè sia gtk che metacity che
sfondoe non tre robe distinte e una applet che monitorizzi la scheda di
rete bella come wmnd.

 Perché tu hai *prove* di questo, vero?
c'è una cosa bella che voglio dire.
Nel corso di anni mi sono fatto vari programmi in gnome e gtk. La cosa che
mi ha colpito è che spesso alle mie domande rispondono Havoc Pennington
o Swenn Neumann.
Come se nelle mailing list della M$ rispondesse gates...

 o Swenn Neumann.
Oppure Owen Taylor.
E sono sempre cortesi e gentili, anche con chi, alle volte, fa delle
domande che, per loro, risultano sicuramente banali.


 Insomma come utente "tecnico" preferivo gnome1.4. 
Come utente "tecnico" e occasionale sviluppatore, gnome2.x è una ventata
di razionalità e di chiarezza senza precedenti. C'è molta più percezione
di un traguardo, e delle regole usate per raggiungerlo. E ciò è un bene.


 
Si, ma io rimarro' sempre dell'idea che il traguardo e' quello SBAGLIATO.
Non sarebbe male l'idea di un fork, come quello che stanno finalmente
provando a fare come XFree86.
Anche quello, fonte di delusioni.
Poco fa mi e' partito il salvaschermo opengl e' si e' inchiodato linux,
perche' quelli di xfree hanno avuto la bella idea di fare inserire nel
kernel linux le API per la scheda grafica.
Window lo fa, sanno tutti che e' una brutta cosa, ma quelli di XFree la
copiano pari pari per linux (senza chidere nulla a nessuno).
Per questo e per altri motivi meritano proprio un fork.

 Come è giusto che sia.
A me farebbe comodo che le applicazioni fossero scritte prevedendo
anche la possibilita` di essere usate senza avere a disposizione GNOME
o KDE. Capisco, pero`, che e` difficile progettare un software che
possa vivere su sistemi e usando/non usando alcune librerie.
Io vorrei NON installare ne` KDE ne` GNOME.
Purtroppo pero` sono costretto ad installare molte librerie solo
perche` alcuni programmi (galeon, xchat, konsole, ecc...) le usano e
di cui non ho trovato nessun altro software comparabile (tenendo conto
delle mie necessita` e preferenze).
-- 
Massimo  ;-)  | EMail: 
q-con...@iol.it
 * ICQ: 37930285
--------------> 
http://digilander.iol.it/MaQ
  BABYLON5  --> 
http://digilander.iol.it/babylon5
  *TRIBOL*  --> 
http://digilander.iol.it/usstribolo

 delle mie necessita` e preferenze).
Tra installare le librerie e installare il DE ce ne passa di strada... Non
e' neanche grave installare alcuni programmi dei due maggiori DE perche'
non e' che facciano tutti schifo...
E le librerie non impiegano 2 minuti ad avviarsi e non occupano neanche
tanto spazio su disco.
-- 
try: troll.uses(Brain)
except TypeError, data: 
   troll.plonk()
Co-Responsabile Hardware Information & Technology 
http://hit.edengames.net

 delle mie necessita` e preferenze).
Se i programmi sono scritti con delle librerie create per non dover
riscrivere, chessò, il supporto per la clipboard, oppure per il
drag&drop, oppure per le opzioni di configurazione, questo è il prezzo
da pagare.
Si dovrebbe replicare una tonnellata e mezza di codice, facendo
diventare il progetto molto pesante, e difficilmente manutenibile.


 kernel linux le API per la scheda grafica.
Se ti si inchioda, è un bug di xscreensaver o di X o del kernel.
Personalmente, mai successo.
Quanto al DRI nel kernel: è perfettamente disabilitabile (io non ce
l'ho, ad esempio). Al contrario di Windows.


 input in una finestra scomparsa sotto) 
[...]
argh. Sospetto che le dialog modali siano non standard, o un'estensione 
relativamente recente. Ho cari ricordi dell'interazione di Kedit con il 
window manager del CDE a proposito
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.1. C, C++ and ASM developers
                               and beta testers are welcome!

 inserire nel kernel linux le API per la scheda grafica.
prego prego prego? OK, so che va di moda criticare di default qualsiasi 
cosa giri in kernel mode (Hyperion, com'è che era? "Un sistema POSIX in 
kernel mooode? MIO DIO CHE ABOMINIO! AL ROGO!"), ma siamo sicuri che lo 
stesso non si verifichi con qualsiasi programma che occupa la CPU, pre-
emptando continuamente il server X?


 argh. Sospetto che le dialog modali siano non standard,
Nelle GTK, esistono da sempre (o, perlomeno, dalla 1.0), ma sono
sconsigliate. Dalle release 1.3 di sviluppo sono altamente sconsigliate.


 window manager di riferimento per il progetto.
C'è da dire che a quel punto avrebbero fatto meglio a scegliere qualcosa
di diverso da Metacity, visto che come dici tu si tratta di funzioni
*basilari* e IMHO piuttosto importanti. I requisiti adatti a Gnome2 credo
si potessero trovare in un qualsiasi wm della serie *box, magari creandone
un derivato apposito senza ricominciare da zero e avendo comunque ottimi
risultati in termini di leggerezza.

 emptando continuamente il server X?
Milioni di volte ho avuto programmi impazziti.
Ma al limite entravo via ethernet con ssh e li killavo e tutto tornava
come prima o, al limite, potevo fare lo shutdown.
Qui sto parlando di un bug dentro dri dentro al kernel (avete visto i
driver di nvidia o ati? ci mettono 800k circa dentro al kernel) che mi
inchioda il KERNEL!
Addio a tutto! Fortuna che uso file systems journaling.

 
Questo fortunatamente e' un bonus, solamente (piccolo effetto secondario)
perdi tutta la accelerazione opengl.

 risultati in termini di leggerezza.
Avrebbe richiesto comunque l'integrazione del wm all'interno
dell'architettura di GNOME2, quindi un ritardo nella release non
indifferente. Al momento di andare in fase di test, l'unico wm compliant
era Metacity.


 perdi tutta la accelerazione opengl.
Accelerazione hardware che ha bisogno di accedere alle risorse del
kernel, e in userland non c'era nulla di così veloce.
Ripeto: se hai idee migliori, trasformale in codice, e mandale ai
mantainer. Altrimenti è muovere la bocca tanto per, o discutere del
sesso degli angeli.


 
Ecco lo sapevo che mi arrivava la risposta preconfezionata, e dire che
avevo cercato di prevenirla parlando di fork.
Inanzitutto qui siamo su it.comp.os.dibattiti e quindi in questo gruppo si
dibatte, poco piu' giu' c'e' il post di uno che si lamenta che c'e' poca
attivita', ci credo! se arrivano solo risposte preconfezionate...
Poi in realta' cosa sta succedendo, che la gente prima o poi si stanca.
Chi scrive piu' codice ha piu' potere, puo' decidere come portare avanti
il suo progetto. E fino a qui non si possono muovere obiezioni.
La cosa buffa accade pero' in progetti come gnome, dove gli sviluppatori
"magnanimamente" decidono di semplificare il tutto per fare un favore non
a loro ma bensi' agli utenti, pero' NON CHIEDONO agli utenti cosa
vogliono!
Io non ho mai visto nessun sondaggio, ne' ascoltare nessun utente nelle
mailing list, a meno che ovviamente non avesse contribuito con del codice,
ma in tal caso non e' utente, e' PROGRAMMATORE.
Riguardo alla solita riposta preconfezionata di "mandale ai maintainer",
faccio notare che lo scandalo sotto XFree e' scoppiato quando, dopo la
dichiarazione di fork i "maintainer" di XFree86 hanno detto che non
c'erano problemi: molti sviluppatori hanno fatto notare che avevano
mandato patch 9 mesi prima per aggiungere funzioni o correggere bug e
questi patch non erano stati esaminati. Perche' i maintainer, per esempio,
non avevano tempo. "Posso darvi una mano e diventare maintainer anche io":
no, non rompere... questa e' la risposta.
E fra quelli mi ci metto anche io, c'e' un bug in xfree4.0 in avanti che
non fa funzionare la scheda video del mio portatile ibm, mi sono offerto
come aiuto, dopo qualche tentativo il maintainer xfree mi ha risposto di
smetterla di importunarlo che il mio aiuto non gli serviva che magari
risolveva il bug il giorno che avrebbe avuto un portatile ibm come il mio
da provare. Siamo alla 4.3 e non va ancora...
Riguardo all'idea di mettere il dri nel kernel chi la approvata? E'
saltata fuori dal nulla, nessuno degli utenti o sviluppatori l'ha
richiesta ma ora e' li' a rovinare la stabilita' di linux.
A me dispiace, io ci tengo a Linux, lo uso dalla 0.92 del kernel e mi
dispiace dirlo ma c'e' qualcuno che contribuisce solo a rovinarlo, mentre
la maggior parte degli sviluppatori lo migliora continuamente.

 richiesta ma ora e' li' a rovinare la stabilita' di linux.
Io tutta sta rovina non la vedo. Anzi, molti utilizzano con profitto il
DRI. Che buò fa?


 DRI. Che buò fa?
Che Alan Cox, ad esempio, dice di non segnalarli problemi se uno sta 
usando i moduli proprietari NVidia (visto che di open in quei moduli 
c'e` solo la "colla" per attaccarli al kernel) [1].
Che su WinNT e derivati e` la situazione "normale", e non l'eccezione 
come su Linux e soci.
Il problema non e` tanto "driver video nel kernel", ma "codice 
sconosciuto in un kernel monolitico".
-- 
   |   \    \  | ___|_  |_  | ianezz a casa sua... :-)
   |  _ \  | \ | _|    /   /  Visita il LinuxTrent a
  _|_/  _\_|  _|____|___|___| 
http://www.linuxtrent.it

 sconosciuto in un kernel monolitico".
Il codice sconosciuto è un problema di chi si mette a patchare il kernel
con codice sconosciuto. Questo, con i DRI nel kernel c'entra punto poco.
Se metti i driver NVidia nel kernel, sai che devi rivolgerti a loro se
qualcosa non va, non certo al maintainer del DRI. Il DRI, poi, è codice
libero: se qualcuno scrive un driver per le NVidia che usi il DRI, e lo
ponesse sotto licenza GPL, non ci sarebbero problemi a mandare al
maintainer di quel driver delle segnalazioni di bug o dei bugfix.


 
E ci risiamo. C'e' la sua bella differenza fra DRI e il framebuffer.
Un conto e' avere un canale privilegiato e multiplexato per inviare
comandi alla scheda video da un processo utente (come per esempio intende
fare KGI), un conto e' un'interfaccia progettata solo per standardizzare
un metodo per far si che tutti possano infilare giganteschi (un megabyte)
moduli proprietari ( o open source, ma e' quasi uguale) per gestire TUTTA
l'accelerazione 3d dentro al kernel, compromettendone seriamente la
stabilita'.
Cosa che ho potuto provare sulla mia pelle in quanto prima del dri non
c'era modo di far crashare il kernel, al massimo crollava X.

 era Metacity.
Che io sappia Openbox e Waimea funzionano discretamente con Gnome2 (e
senza particolari sforzi di integrazione), il fatto che si siano trovati
all'ultimo momento senza WM (Metacity è arrivato negli ultimissimi tempi
prima della release e quasi per caso, se ricordi era un "giocattolo" di
Pennington) è un altro segno che l'uscita di Gnome2 è stata gestita con
troppa leggerezza (e lo dico con rammarico, visto che io fuori da Gnome2
ormai mi trovo malissimo, qualsiasi altra interfaccia mi capiti tra le
mani).

 troppa leggerezza 
E che "qualcuno" voleva metacity invece di window manager piu' stabili  e
piu' supportati come Openbox, Oroborus e altri.

 mani).
Amen. Siamo in due... :-)


 c'era modo di far crashare il kernel, al massimo crollava X.
Si sietmeranno anche queste cose: in fondo, se vogliamo andare a vedere
è pieno di cose che fanno collassare il kernel. ;-)


 qualcuno scrivesse un framebuffer accelerato.
sicuro. Poi, pian piano, avrà un ioctl per ogni funzione di ogni scheda 
video esistente, e sarà il triplo di quanto DRI è oggi, ma con tre anni 
di ritardo
nota: potrei aver frainteso terribilmente la differenza tra framebuffer 
e DRI, ma dato che la documentazione in proposito fa piangere, mi sento 
più che giustificata


 più che giustificata
E quando la polizia trascino' via Juliet per possesso di copia non autorizzata 
di Bonzi Buddy sul suo pc, lei cerco' di giustificarsi dicendo che l'EULA di 
Bonzi Buddy faceva piangere e non aveva capito i termini della distribuzione.
-- 
limaCAT

 
KGI: versione light di DRI dove c'e' solo una funzione
invia_il_piu_velocemente_possibile_questo_comando_alla_scheda_video(int blah);
in maniera tale da far stare tutto il resto del driver fuori dal kernel
dove crea molti meno danni!

nonostante quello che potrebbe dire il mio nick, sono Juliet. Ah, quasi 
dimenticavo, Davide Inglima - limaCAT ha scritto: 
[...]
differenza tra DRI e framebuffer accelerato?


 kernel dove crea molti meno danni!
danni? tipo, far andare la grafica ad una velocità accettabile?


 danni? tipo, far andare la grafica ad una velocità accettabile?
Dunque, cerchero' di essere calmo e non innervosirmi su queste sterili
provocazioni.
Se ne parlo' tanto a suo tempo.
Se uno vuole una grafica piu' veloce, la cosa migliore e' OTTIMIZZARE il
codice.
Se poi non si vuole fare fatica e non se ne frega niente di rendere il
sistema instabile si mette tutto il sistema grafico comprensivo di drivers
dentro il kernel (come fa windows), o quasi tutto come fa dri+ drivers
proprietari.
Se invece si e' programmatori seri si studia un attimo la situazione e si
vede nel kernel l'unica cosa necessaria e' un minimo supporto per l'invio
veloce di comandi alla scheda video e un supporto alla possibilita' di
piu' applicazioni di inviare i comandi senza creare guai (lock etc.)
Non c'e' bisogno di mettere tutto dentro al kernel!
Se continuare su questo passo allora mettiamo tutto zebra dentro al
kernel, oppure tutto apache massi' dai, sicuramente cosi' vanno piu'
veloci....
Ma che parlo a fare, tanto sta Juliet sara' ancora una di quelli che
credoono di non poter fare a meno di X windows perche' altrimenti perdono
la network transparency 

 piu' veloci....
sì, certo, sparare cazzate random ti farà sicuramente guadagnare almeno 
un punto


 differenza tra DRI e framebuffer accelerato?
Mi spieghi cosa sarebbe un "framebuffer accelerato"?
Un "frame" "buffer" e` un "buffer" per un "frame",
quindi se supporta qualcosa piu` di questo, non
e` piu` un "framebuffer".
bye,
-- 
piergiorgio

 differenza tra DRI e framebuffer accelerato?
Nel secondo caso il software deve tirare una riga per disegnarla puntino per 
puntino (piu' che di framebuffer accelerato si dovrebbe parlare di framebuffer, 
ad accesso diretto). Nel primo caso dici alla scheda grafica di occuparsi di 
tirare una riga e te puoi tornare a gestire l'hard disk, i processi, le pipe, 
eccetera.
(Ovvio, qui piu' che di tirare una riga si parla di creare nmila poligoni, 
displayarne le facce visibili e nascondere quelle invisibili e gli oggetti 
nascosti, applicare i colori, l'effetto ombreggiatura, le textures.)
-- 
limaCAT

 Mi spieghi cosa sarebbe un "framebuffer accelerato"?
sto cercando di capirlo. Non sono io a chiamarlo cosě


 sto cercando di capirlo. Non sono io a chiamarlo così
Nemmeno io, anche se, nel caso un giorno qualcuno lo creasse davvero,
chiederei i diritti sul nome.
Avrei potuto usare "la superscazzola con lo scappellamento a destra",
ma "framebuffer accelerato" ha un non so che di interessante. ;-)


 e` piu` un "framebuffer".
e che c'entra scusa?
il fatto che sia un posto dove io possa andare a
scrivere, nn significa che nn possa utilizzare 
il chip grafico (che ho pagaro btw) per fare
come come il tracciamento di rettangoli&C.
btw, il direct fb di Linux e' accelerato in hw, e
pare funzi bene (ha anche i layer...yuuuuuuuu... =)
cmq sia, la differenze (quelle vera), tra framebuffer 
e i vari DRI&C interessa pure a me... =P
-- 
Paolo

 un punto
Questa non e' una cazzata e' un FATTO. Se metti apache dentro al kernel
SICURAMENTE va piu' veloce. Solo che fortunatamente a nessuno e' ancora
venuto in mente di farlo, per fortuna.

 come come il tracciamento di rettangoli&C.
Non e` piu` un semplice framebuffer, ma altro,
devi chiamarlo diversamente, altrimenti non si
capisce piu` dove finisce il semplice "buffer"
e dove inizia il rendering engine.
bye,
-- 
piergiorgio

 sto cercando di capirlo. Non sono io a chiamarlo così
Comunque sia, il framebuffer e` semplicemente una
interfaccia che espone un'area di memoria mappata
direttamente sul video, con una certa profondita`
(8, 16, 24, etc. bit), una certa risoluzione e varie
(timing, sync, etc.).
Questo aggeggio potrebbe avere anche delle "accellerazioni",
tipo bitblit o font rendering, in questo caso non e`
piu` corretto, pero`, chiamarlo semplicemente "buffer".
Il DRI (Direct Rendering Interface) o DRM (Direct Rendering
Manager), invece, espone un'interfaccia che consente,
come dice il nome, di inviare primitive di rendering
all'HW della scheda video. In linea di principio non ha
neanche il concetto di buffer (ma non e` proprio vero).
Ovviamente, in entrambi i casi, si vorrebbe astrarre l'HW
sottostante. Nel primo caso si vede solo un buffer, nel
secondo un "socket" (mi si passi il termine) nel quale
inviare comandi di rendering.
bye,
-- 
piergiorgio