# Gentoo con gcc4 xorg7 initng hibernate,..

## assente

C'è qualcuno che già utilizza tutti i sw sopracitati o singolarmente?

Visto che ci sono pensavo di fare un'aggiornamento come si deve   :Razz: 

Mi auguro che la miscela non crei troppi casini, comunque un tbz2 di gcc me lo sono fatto

----------

## .:chrome:.

initng non l'ho mai provato ma so di gente che lo usa con buoni risultati.

gcc-4 è un suicidio tecnologico. va incontro a più rischi di corruzione e malfunzionamento che altro

xorg-7 l'ho provato su una macchina di test. se è hard masked è per un ottimo motivo, visto che gli ebuild non si compilano e che hanno dipendenze errate.

il 6.8.99, che diventerà 6.9 è stabile e funziona bene. io me lo sono installato sul portatile e non ha mai dato rogne.

se hai un buon motivo per aggiornare è l'unico che ti posso consigliare. se è solo curiosità lascia perdere, ti risparmi tempo e mal di testa

quel che è certo è che gcc-4 è da evitare come la peste

----------

## mambro

Eppure fedora core 4 è stata interamente compilata con gcc4..

----------

## .:chrome:.

 *mambro wrote:*   

> Eppure fedora core 4 è stata interamente compilata con gcc4..

 

ok, ma dietro Fedora c'è RedHat con tutti i suoi begli ingegneri (con i coglioni e i contro-coglioni) che stanno tutto il giorno a sviluppare e testare...

e RedHat è solita applicare patch molto voluminose ai prodotti che distribuisce

ci sono due scuole di pensiero. c'è chi dice che è un bene e chi dice che è un male.

io dico solo che quelle patch sono fatte un gran bene... basta vedere i kernel che distribuiscono...

----------

## Apetrini

 *k.gothmog wrote:*   

> 
> 
> quel che è certo è che gcc-4 è da evitare come la peste

 

Sicuramente è pieno di buchi, ma io sono fiducioso, in fondo è uno dei progetti piu grossi e piu potenti della comunità... (intendo il gcc in generale).

E come sempre la verià è figlia del tempo. Intanto aspetto e spero...

----------

## knefas

Io uso le suspend2 sources e hibernate da un bel po'. Devo dire che pero' nel caso del mio laptop non funzionano (per colpa del modulo nvidia!)  :Neutral:  Per cui continuo a testare e vedere cosa succede.

----------

## XstefanoX

Guarda, io ho l'intero sistema compilato con gcc 4 e non ho mai avuto problemi, e mi sembra pure un po' più veloce dei precedenti per quanto riguarda i tempi di compilazione. Poi non non sono un esperto di compilatori e del gcc, quindi non posso dire se gcc-4 sia un progetto riuscito o un mezzo passo falso.

Ti può capitare che qualche pacchetto isolato non compili, allora usi gcc-3.4, ma è molto raro. Questa è la mia situazione:

pacchetti installati: 318

pacchetti compilati con gcc-4: 312

pacchetti compilati con un gcc-3.4: 6

----------

## .:chrome:.

 *Apetrini wrote:*   

> Sicuramente è pieno di buchi, ma io sono fiducioso, in fondo è uno dei progetti piu grossi e piu potenti della comunità... (intendo il gcc in generale).
> 
> E come sempre la verià è figlia del tempo. Intanto aspetto e spero...

 

infatti non intendevo certo dire che non sia un buon progetto.

solo che i tempi non sono maturi.

in fondo di discussioni sui compilatori ce ne sono state decine, e in tutte sono sempre emersa le parole EFFETTO PLACEBO. questo dovrebbe dare da pensare.

@XstefanoX:

quelli che mi vengono a dire "è effettivamente più veloce" lasciano un po' il tempo che trovano... più veloce rispetto a cosa?

o si portano dei numero concreti oppure questi modi di dire non vogliono dire assolutamente niente.

----------

## assente

Grazie a tutti e proprio questo che cercavo,

@XstefanoX: mi dici la versione di gcc che usi?

cosa intendi come sistema? kernel apache, gnome 2.12, openoffice,.. o qualcosa di più minimale?

Chi sono quei sei?

----------

## XstefanoX

@k.gothmog

Ok, hai ragione, ho dato un'occhiata ai tempi di compilazione di alcuni pacchetti usando genlop e in effetti non ci sono molte differenze rispetto alle versioni precedenti di gcc. Evidentemente era stata solo una mia impressione sbagliata.

@assente

Dunque io uso gcc-4.0.1, che si trova in portage con keyword -*. Con questo ho compilato tutto, vale a dire kernel, pacchetti in system e in world (xorg, kde, firefox, non ho provato openoffice, apache e gnome, per citare quelli che hai detto tu). Per i seguenti ho usato gcc-3.4.4-r1:

app-accessibility/festival-1.4.3-r4

app-accessibility/speech-tools-1.2.3-r3

dev-libs/liboil-0.3.2

media-libs/libsdl-1.2.9

media-libs/xine-lib-1.1.0-r4

sys-libs/glibc-2.3.5-r1(questo forse compila con gcc-4, ma tra una cosa e l'altra non ho ancora avuto tempo di ricompilarlo...)

----------

## Ic3M4n

 *k.gothmog wrote:*   

> 
> 
> in fondo di discussioni sui compilatori ce ne sono state decine, e in tutte sono sempre emersa le parole EFFETTO PLACEBO. questo dovrebbe dare da pensare.
> 
> 

 

hai completamente ragione, il tuo discorso fila liscio come l'olio. cmq lo so che non è un dato oggettivo, cmq l'altro giorno ho messo fedora4 ad un mio amico che vuole vedere le differenze tra distro e distro, beh... io ho sempre reputato fedora un macigno nell'avviarsi, ovvero: accondo il pc vado a fare colazione e poi lo uso. invece devo ammettere che è diventata abastanza performante anche sotto questo punto di vista. molto probabilmente non sarà tutto merito di gcc, nel senspo che magari gli sviluppatori di fedora ci hanno messo del loro.

----------

## randomaze

 *k.gothmog wrote:*   

> infatti non intendevo certo dire che non sia un buon progetto.
> 
> solo che i tempi non sono maturi.

 

(molto) probabilmente hai ragione ma, se non ci fossero persone come Xstefanox (e non solo lui) che sperimentano le novitá difficilmente i tempi potrebbero diventare maturi.

Probabilmente é vero, gcc4 sarebbe un suicidio tecnologico per un sistema di produzione, ma se uno vuole provare basta che abbia la cognizione di causa di sapere che alcune (molte) cose potrebbero non funzionare e che ci potrebbe essere il rischio di fare danni non risolvibili banalmente. Ma da qui a dire "é da evitare come la peste" ce ne passa.

Peraltro, volente o nolente, quello é il futuro. Forse gentoo adotterá direttamente un ipotetico 4.1 invece dell'instabile 4.0 proprio per i motivi che tu dici, ma, in ogni caso non credo che si tornerá indietro.

Ah, un appunto in merito agli "ingegneri RH". Io ho abbandonato quella distro quando i valenti tecnici hanno fatto una distro con il gcc 2.96.

Un gcc non ufficiale, con delle patch studiate da loro e via dicendo. Aveva solo un problema: non era in grado di compilare un kernel vanilla.

Certo, puó darsi che abbiano imparato dai loro stessi errori...

----------

## Ic3M4n

 *randomaze wrote:*   

> (molto) probabilmente hai ragione ma, se non ci fossero persone come Xstefanox (e non solo lui) che sperimentano le novitá difficilmente i tempi potrebbero diventare maturi. 

 

beh, è anche vero però che per poter fare dei bug report "decenti" bisogna comunque anche sapere di cosa  si parla, i bug report completi comprendono anche patch al programma per risolvere il problema... personalmente credo che l'utilizzo di software instabile per debugging dell'applicazione sia una cosa che non tutti ci possiamo permettere, io in primis non saprei scrivere patch per cambiare il nome di un device, figuriamoci andare a toccare gcc. piuttosto anche io faccio parte di quella parte di persone che accetta i rischi di mantenere parte del sw instabile per poter fare lo "sborone" e dire agli amici che appena uscito gnome-2.12  io ce l'avevo... conscio del fatto che non tutto probabilmente sarebbe andato correttamente.

 *randomaze wrote:*   

> Peraltro, volente o nolente, quello é il futuro. Forse gentoo adotterá direttamente un ipotetico 4.1 invece dell'instabile 4.0 proprio per i motivi che tu dici, ma, in ogni caso non credo che si tornerá indietro. 

  beh, di sicuro ne parlano bene di gcc-4.0, nel senso che a parte la ristrutturazione generale del funzionamento di gcc sembra che prometta bene. poi... questo è quello che si legge, la mia opinione vale molto poco in questo campo.

----------

## .:chrome:.

@randomaze

è una cosa di cui si è già parlato...

è verissimo che nel momento in cui spariscono le persone che fanno i test, il software open-source smette di progredire; infatti io non dico di non testare un pacchetto finché non diventa stabile.

penso però, nel momento in cui mi rendo conto di non avere le capacità per testare GCC (e per quanto riguarda me, io so di non essere all'altezza del compito), che farlo sia solo una perdita di tempo per me e per gli sviluppatori.

io, nel mio piccolo mi accontento di testare qualche pacchetto, e cerco di contribuire attivamente allo sviluppo. in questi casi cerco di conoscere il software e cerco di mandare dei bugreport utili agli sviluppatori. non perché ce l'ho con XstefanoX (ci mancherebbe) ma mandare messaggi inutili è solo una seccatura per chi legge.

lasciamo che a testare GCC sia gente capace di farlo. la versione 4 arriverà comunque; non è che se non ce l'abbiamo subito installato non possiamo più fare niente...

non è che ce l'ho con GCC-4. anzi, io spero che arrivi presto... semplicemente non sono d'accordo con questa corsa all'ultima versione, che oltre che immotivata mi sembra anche un po' stupida (senza offesa, sempre)

RedHat ce l'ho installata anche io su un paio di macchine. ho visto con i miei occhi la velocità di quella distribuzione... ma mi chiedo se sia solo merito del GCC-4. io non credo... come dicevo nei primi post, in RedHat fanno largo uso di patch mooolto invasive. non sto a discutere se questo sia bene o male. dico solo che queste patch sono fatte bene (e comunque non tutti i pacchetti sono compilati con GCC-4)

----------

## randomaze

 *Ic3M4n wrote:*   

> personalmente credo che l'utilizzo di software instabile per debugging dell'applicazione sia una cosa che non tutti ci possiamo permettere, io in primis non saprei scrivere patch per cambiare il nome di un device, figuriamoci andare a toccare gcc.

 

Su questo sono daccordo, avevo cercado di sintetizzare questo punto nella frase:

 *randomaze wrote:*   

> se uno vuole provare basta che abbia la cognizione di causa di sapere che alcune (molte) cose potrebbero non funzionare e che ci potrebbe essere il rischio di fare danni non risolvibili banalmente.

 

 :Wink: 

----------

## Apetrini

 *randomaze wrote:*   

> 
> 
> Ah, un appunto in merito agli "ingegneri RH". Io ho abbandonato quella distro quando i valenti tecnici hanno fatto una distro con il gcc 2.96.
> 
> Un gcc non ufficiale, con delle patch studiate da loro e via dicendo. Aveva solo un problema: non era in grado di compilare un kernel vanilla.
> ...

 

Ma lol. io non riuscirei a definire compilatore qualcosa che non "compila" il kernel vanilla.

Comunque mi state facendo voglia di provare il kernel RH. è solo che ho smpre diffidato di qualsiasi kernel patchato da terzi, non uso neanche quello gentoo, uso il vanilla con qualche  patch su....

Ovviamente ho anche il mm e il ac. MI piace smanettare sul kernel.

@k.gothmog: cosa intendi quando dici che hai visto tu stesso la velocità di RH? la velocità in che senso? di avviamento? di quanto ci mette a far partire le appliczioni? spiegati un po' meglio...

è solo che ho perso parecchi tempo a capire cosa fare per "Volare con gentoo" (anche nel forum ci sono molti post a riguardo) e l'idea che loro usino qualche tipo di approccio e/o sistema che io non ho considerato mi turba....vorrei almeno sapere cos'è.

----------

## Ic3M4n

 *Apetrini wrote:*   

> vorrei almeno sapere cos'è.

 

beh, sono soliti visionare i sorgenti e modificarli in più punti.

----------

## .:chrome:.

 *Apetrini wrote:*   

> cosa intendi quando dici che hai visto tu stesso la velocità di RH? la velocità in che senso? di avviamento? di quanto ci mette a far partire le appliczioni? spiegati un po' meglio...
> 
> è solo che ho perso parecchi tempo a capire cosa fare per "Volare con gentoo" (anche nel forum ci sono molti post a riguardo) e l'idea che loro usino qualche tipo di approccio e/o sistema che io non ho considerato mi turba....vorrei almeno sapere cos'è.

 

intendo proprio che a parità di macchina (il mio vecchio computer di casa) l'ho vista più veloce di gentoo. più agile nell'avviarsi, nell'avviare le applicazioni, più responsiva (ok, quest'ultima dipende solo dal kernel) nonostante lo stage1, le ottimizzazioni, e tutte le acrobazie che facevo in gioventù (come se fossi vecchio)

il dramma è che non è capitato solo a me. ne ho parlato con diverse persone parecchio competenti, e tutti, dal primo all'ultimo, hanno confermato quello che alla fine pensavo: compilare tutto il sistema non da vantaggi in termini di velocità, se non si cambia il codice sorgente

è per questo che mi fanno semplicemente ribrezzo quelli che dicono "compilo perché è più veloce". vuol dire parlare di cose che non si conoscono

----------

## randomaze

Ho splittato le divagazioni sul tema CFLAGS in quest'altro thread.

----------

## yardbird

 *randomaze wrote:*   

> Ah, un appunto in merito agli "ingegneri RH". Io ho abbandonato quella distro quando i valenti tecnici hanno fatto una distro con il gcc 2.96.
> 
> Un gcc non ufficiale, con delle patch studiate da loro e via dicendo. Aveva solo un problema: non era in grado di compilare un kernel vanilla.

 

 :Laughing: 

Un paio di link per chi non si ricorda la figuraccia di RH con gcc 2.96:

http://www.mplayerhq.hu/DOCS/HTML/en/gcc-296.html

http://gcc.gnu.org/gcc-2.96.html

Altri esempi del comportamento di RH sono le famose versioni "zoppe" di KDE (ad esempio avevano tolto dai menu delle applicazioni la voce "About KDE" nel nome di una omogeneità del loro DE - una specie di ibrido fra Gnome e KDE).

Ingegneri con i contro-maroni, eh?  :Rolling Eyes: 

----------

## assente

http://distrowatch.com/weekly.php?issue=20050912#1

Su distrowatch sembra che le ultime distribuzioni carichino Gnome a 76s e Kde a 52s.. sarebbe bello sapere che demoni caricano all'avvio e a cosa è dovuto questo incremento

----------

## Ic3M4n

molto probabilmente al fatto che oltre a lavorare a livello di singolo pacchetto, vanno a modificare a volte anche  in maniera sostanziale il codice sorgente. cosa che noi non facciamo, a parte occasionalmente con delle patch. mi sembra che questa sia una cosa ormai consolidata e farne orecchie da mercante non serve a nulla. quindi come già specificato in innumerevoli post: IL CONFRONTO CON ALTRE DISTRO NON PUÒ ESSERE FATTO SEMPLICEMENTE, ma bisogna tenere conto di particolari che non sempre sono visibili con un "top".

----------

## assente

Ok modificano il sorgente delle applicazioni, per farli funzionare, per farli andare più veloce, ecc..

continuo a non capire, però, perchè non si aggiungano agli ebuild(con una use) delle patch di altre distro più o meno collaudate; visto che comunque sono obbligati a rilasciare il sorgente.. prima fra tutte:

http://packages.ubuntu.com/breezy/web/firefox-gnome-support

supporto Gnome-vfs a Firefox vedi https://bugs.gentoo.org/show_bug.cgi?id=105412

..poi Eclipse su gcj e altre.

Se il vantaggio in prestazioni di compilare da sorgente è trascurabile, non è trascurabile la facilità con cui Gentoo gestisce le patch, quindi (se le patch sono fatte bene) è un peccato non poterle usare anche su Gentoo, no?

----------

## Ic3M4n

parlo di una cosa che non conosco bene, intendo la creazione di ebuild, personalmente non sono in grado di scriverne di efficienti, solo piccole cose, però in generale aggiungere un'opzione in un ebuild a volte può non essere semplice. tu sei in grado di farlo?

----------

## .:chrome:.

 *assente wrote:*   

> continuo a non capire, però, perchè non si aggiungano agli ebuild(con una use) delle patch di altre distro più o meno collaudate; visto che comunque sono obbligati a rilasciare il sorgente..

 

parli... ma non sai di cosa

se guardi con attenzione le prime fasi della compilazione di un ebuild ("patching" e "configuring") vedrai SPESSO, come l'ho visto io con i miei occhi patch provenienti da altre distribuzioni.

per ora ho notato diverse patch provenienti da debian, e mandrake. alcune da RedHat

ti consiglio di informarti meglio, prima di postare

----------

## assente

 *Ic3M4n wrote:*   

> molto probabilmente al fatto che oltre a lavorare a livello di singolo pacchetto, vanno a modificare a volte anche  in maniera sostanziale il codice sorgente. cosa che noi non facciamo, a parte occasionalmente con delle patch. [...].

 

Mi sembra strano, emerge sync scarica sempre un mucchio di patch, basta vedere quelle per amd64 e gcc4

```
find /usr/portage -iname  *gcc4*
```

@k.gothmog: probabilmente non sono bene informato sulla provenienza delle patch, ma per quello che mi è capitato di vedere.. sono aggiustatine per Gentoo o patch provenienti dal sito ufficiale.

Comunque sia, la patch per integrare il fs di gnome in firefox esiste da firefox 1.0.2, mi sembra la usi anche fedora

----------

## Ic3M4n

 *assente wrote:*   

> Mi sembra strano, emerge sync scarica sempre un mucchio di patch, basta vedere quelle per amd64 e gcc4 

 

la gestione delle patch in gentoo:

 *http://www.gentoo.org/proj/it/devrel/handbook/handbook.xml?part=2&chap=1 wrote:*   

> 
> 
> Generalmente, il Portage tree deve essere usato solo per contenere i files .ebuild insieme ad altri file piccoli, come patch o esempi di configurazione. Questi tipi di files devono andare nella directory /usr/portage/categoria/pacchetto/files per tenere pulita la directory categoria/pacchetto. Le eccezioni a questa regola sono per grandi patch (patch più grandi di 20KB) che dovrebbero essere messe nei Gentoo mirrors in modo che la gente non sprechi eccessivamente la larghezza di banda e lo spazio dell'hard drive.
> 
> ...
> ...

 

l'ultimo pezzo sta ad indicare che solitamente aumentando il numero di revisione si aggiungono ulteriori patch.

----------

## .:chrome:.

@assente:

```
chrome@morgoth /usr/portage $ find . -type f | grep -i debian

./app-admin/syslog-ng/files/syslog-ng.conf.debian

./app-arch/gzip/files/gzip-1.3.5-debian.patch

./app-i18n/chinput/files/chinput-3.0.2-debian.patch

./app-i18n/jfbterm/files/jfbterm-0.4.7-sigchld-debian.patch

./app-i18n/unicon/files/unicon-3.0.4-debian.patch

./app-text/gv/files/gv-3.5.8-debian.diff.gz

./app-text/txt2man/files/txt2man-1.4.8-debian.patch

./app-text/yodl/files/yodl-1.31.18-debian.patch

./dev-libs/libedit/files/20031222-debian-to-gentoo.patch

./dev-libs/libedit/files/libedit-20050531-debian-to-gentoo.patch

./dev-util/fenris/files/fenris-0.07m-debian.patch

./games-action/gltron/files/gltron-0.70-debian.patch

./games-misc/bsd-games/files/2.13-debian-11.patch

./media-video/dvdbackup/files/0.1.1-debian-FPE.patch

./metadata/cache/sys-apps/debianutils-1.16.7-r4

./metadata/cache/sys-apps/debianutils-2.13.1-r1

./metadata/cache/sys-apps/debianutils-2.14.1-r1

./net-analyzer/mtr/files/mtr-0.69-debian.patch

./sci-chemistry/rasmol/files/rasmol.sh.debian

./sys-apps/debianutils/files/debianutils-1.16.7-gcc33.patch

./sys-apps/debianutils/files/debianutils-1.16.7-gentoo.patch

./sys-apps/debianutils/files/debianutils-2.14.1-no-bs-namespace.patch

./sys-apps/debianutils/files/debianutils-compress.patch

./sys-apps/debianutils/files/digest-debianutils-1.16.7-r4

./sys-apps/debianutils/files/digest-debianutils-2.13.1-r1

./sys-apps/debianutils/files/digest-debianutils-2.14.1-r1

./sys-apps/debianutils/ChangeLog

./sys-apps/debianutils/Manifest

./sys-apps/debianutils/debianutils-1.16.7-r4.ebuild

./sys-apps/debianutils/debianutils-2.13.1-r1.ebuild

./sys-apps/debianutils/debianutils-2.14.1-r1.ebuild

./sys-apps/debianutils/metadata.xml

./sys-apps/kbd/files/kbd-1.12-debian.patch

./sys-apps/util-linux/files/util-linux-2.12q-debian-10cfdisk.patch

./sys-devel/gcc/files/3.3.3/gcc333-debian-arm-getoff.patch

./sys-devel/gcc/files/3.3.3/gcc333-debian-arm-ldm.patch

./sys-libs/ncurses/files/xterm-debian.ti

./sys-libs/slang/files/slang-debian-utf8.patch

./sys-process/anacron/files/anacron-2.3-compile-fix-from-debian.patch

./www-apps/mantisbt/files/0.19.2-debian.patch

./x11-plugins/wmxres/files/wmxres-debian-1.1-1.2.patch
```

----------

## Apetrini

 *assente wrote:*   

> http://distrowatch.com/weekly.php?issue=20050912#1
> 
> Su distrowatch sembra che le ultime distribuzioni carichino Gnome a 76s e Kde a 52s.. sarebbe bello sapere che demoni caricano all'avvio e a cosa è dovuto questo incremento

 

Io sul mio Centrino 1,6 512mb di ram ho appena relevato col cronometro la velocità da quando si batte invio su lilo a quando finisce di caricare lo splashscreen di kde. Non avevo voglio di star li a tirar via kdm, cosi ho cercato di esser piu veloce possibile a digitare la passwd e a battere invio. Il risultato è stato sui 60secondi che tirati via i 2 secondi per la passwd,

 fa 58 secondi.

Non so se è un buon risultato, ma vi dico subito come ho fatto...

CFLAGS="-Os -march=pentium3 -pipe -fomit-frame-pointer". Tra le USE ho messo "pic","nptl","nptlonly" e "sse2".

Filesystem XFS, Scheduler Deadline, kernel 2.6.13.

I moduli sono i soliti per un portatile centrino, quindi tutto il relativo a scheda video, audio, speedstep. NO hotplug!

e poi ho fatto delle modifiche agli script di avvo in modo da non far controllare inutilmente lo stato dei moduli prima di caricarli e altre chicche... sono 10/12 righe di script da cambiare, ma è tutta roba che trovate nel forum cercando "Volare con gentoo". 

Infine sto adoperando "prelink", infatti come molti avranno notato c'è la USE "pic". Da qui si puo disabilitare il demone per il rilevamento automatico di librerie dinamiche di kde. 

P.s. ho anche disabilitato il restore all'ultima sessione su kde.

P.p.s ah si ho compilato tutto con "i686-pc-linux-gnu-3.3.6" che è l'ultimo gcc stabile...

Accetto volentieri suggerimenti....

----------

## assente

 *Apetrini wrote:*   

> 
> 
> Io sul mio Centrino 1,6 512mb di ram ho appena relevato col cronometro la velocità da quando si batte invio su lilo a quando finisce di caricare lo splashscreen di kde. Non avevo voglio di star li a tirar via kdm, cosi ho cercato di esser piu veloce possibile a digitare la passwd e a battere invio. Il risultato è stato sui 60secondi che tirati via i 2 secondi per la passwd,
> 
>  fa 58 secondi.

 

Potresti mettere un attimo l'autologin su un certo utente per non digitare la password   :Smile: 

poi bu..

http://gentoo-wiki.com/HOWTO_Initng

http://gentoo-wiki.com/HOWTO_Use_hdparm_to_improve_IDE_device_performance

http://gentoo-wiki.com/HOWTO_ICC_and_Portage

----------

## flocchini

mah, onestamente non so quanpo possa essere affibabile un test del genere... Per curiosita' ho cmq provato (centrino 1,6 512mb di ram) e ho avuto un 50 secondi netti, con caricamento di superkaramba e tutto il resto su kde 3.4. Il sistema e' compilato con 

```
ortage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.12-gentoo-r10 i686)

=================================================================

System uname: 2.6.12-gentoo-r10 i686 Intel(R) Pentium(R) M processor 1.60GHz

Gentoo Base System version 1.6.13

ccache version 2.3 [disabled]

dev-lang/python:     2.3.5

sys-apps/sandbox:    1.2.11

sys-devel/autoconf:  2.13, 2.59-r6

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5

sys-devel/binutils:  2.15.92.0.2-r10

sys-devel/libtool:   1.5.18-r1

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"

CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"

CXXFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig distlocks sandbox sfperms strict"

GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/"

LDFLAGS="-Wl,-O1"

LINGUAS="it"

PKGDIR="/usr/portage/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="x86 X aalib acpi alsa apm arts avi bash-completion berkdb bitmap-fonts crypt cups dga dvd dvdr eds emboss encode fam foomaticdb fortran gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 hal ieee1394 imagemagick imlib ipv6 ithreads java jpeg kde libg++ libwww mad mikmod motif mp3 mpeg ncurses nls nptl ogg oggvorbis opengl oss pam pda pdflib perl png python qt quicktime readline real samba sdl spell ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xml2 xmms xpm xv xvid zlib linguas_it userland_GNU kernel_linux elibc_glibc"

Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, MAKEOPTS

```

non da cosa possa dipendere il "vantaggio", il prelink a me ha sempre fatto solo danni e quindi non ci penso nemmeno, per di piu' ho anche hotplug...

----------

## .:chrome:.

 *Apetrini wrote:*   

> Io sul mio Centrino 1,6 512mb di ram ho appena relevato col cronometro la velocità da quando si batte invio su lilo a quando finisce di caricare lo splashscreen di kde

 

e tu saresti un informatico...?

va bene tutto... ma questa è davvero grossa come una casa...

vieni ad Ingegneria di Brescia a dire che hai fatto un benchmark in quel modo. Se lo dici al docente giusto ti GARANTISCO che tu non ti laureerai mai né a Brescia né in nessuna Università del nord Italia... e nemmeno in Svizzera e Francia...

Se cambi docente potrai ricevere un allegro unsulto e sentirti dare dell'ignorante davanti a cani & porci (queste scene succedono davvero!)

per quanto riguarda ME, a uno che mi esce con una sparata del genere, risponderei di andare a lavorare subito come operaio (con tutto il rispetto per gli operai) e di lasciar perdere il computer. Probabilmente (sicuramente) non sai nemmeno perché hai detto una smisurata cazzata...

Oggi mi stupivo che dopo essere stato cazziato da mille persone avessi ancora il coraggio di sostenere le tue tesi... adesso non mi stupisco più di niente: credo di avere capito.

per quanto mi riguarda il thread è chiuso, o almeno... questa è l'ultima risposta che mando a un tuo messaggio

ciao a tutti

----------

## randomaze

 *k.gothmog wrote:*   

> vieni ad Ingegneria di Brescia a dire che hai fatto un benchmark in quel modo.

 

Sinceramente mi sembra che il suo scopo fosse quello di misurare il tempo di avvio della sua macchina, non quello di mettere su un benchmark.

Se tale misurazione gli va bene anche "a spanne" sicuramente il suo sistema funziona. Certo non é il massimo della precisione ma se a lui va bene cosí non vedo il problema.

 *Quote:*   

> per quanto mi riguarda il thread è chiuso, o almeno... questa è l'ultima risposta che mando a un tuo messaggio

 

Visto il tono che hai usato nella tua ultima risposta trovo che questa sia una buona notizia. Non mi piace chiudere thread e vorrei evitarlo, anche se ogni volta che leggo nuovi messaggi in questo thread mi chiedo perché non lo ho ancora chiuso.

----------

## assente

Personalmente anche a me non piacciono i toni che sta prendendo questo thread.

Ho fatto anch'io prove col cronometro (e non me ne vergogno) e i dati non mi soddisfano affatto.

Computer di test athlonxp 1400, stesse versioni dei programmi, stessi demoni all'avvio no hotplug, cups e molti altri, sì hald dbus hdparm ecc..

A=da grub a gdm

B=da gdm fino all'apertura del menu Applicazioni(click)

Installazioni fresche-fresche:

vidalinux+gnome2.10/i686

A=1m 20s + B=20s

fedora+gnome2.10/i386

A=54s + B=20s

winxp

Totale 34s

Conclusioni personali: i colli di bottiglia sono l'init e gnome-session

le gtk 2.8 sono molto più responsive delle 2.6(da altro pc), xorg7 è più veloce ma non aggiorna sempre tutti i caratteri sullo schermo

----------

## Dr.Dran

 *k.gothmog wrote:*   

> 
> 
> per quanto riguarda ME, a uno che mi esce con una sparata del genere, risponderei di andare a lavorare subito come operaio (con tutto il rispetto per gli operai) e di lasciar perdere il computer. Probabilmente (sicuramente) non sai nemmeno perché hai detto una smisurata cazzata...

 

Hey ma io faccio l'operaio metalmeccanico... è il lavoro che attualmente mi garantisce una retribuzione fissa   :Laughing:   :Laughing:   :Laughing:   :Laughing:   :Laughing: 

SObh siamo sempre la categoria + bistrattata noi periti e operai   :Laughing:   :Laughing:   :Laughing:   :Laughing:   :Laughing: 

----------

## Apetrini

 *k.gothmog wrote:*   

> 
> 
> per quanto riguarda ME, a uno che mi esce con una sparata del genere, risponderei di andare a lavorare subito come operaio (con tutto il rispetto per gli operai) e di lasciar perdere il computer. Probabilmente (sicuramente) non sai nemmeno perché hai detto una smisurata cazzata...
> 
> Oggi mi stupivo che dopo essere stato cazziato da mille persone avessi ancora il coraggio di sostenere le tue tesi... adesso non mi stupisco più di niente: credo di avere capito. 

 

Ma LoL.... Mi spiace che tu non mi ritenga degno di queste cose. E poi anche se mille persone mi hanno detto il contrario di quello che penso io (mi riferisco alle CFLAGS e dintorni) non mi va di prendere le cose per buone solo perche loro sono in mille, questo per me significherebbe prendere una cosa per buona solo perche la sostengono gli altri (quindi per sentito dire), farò delle prove e tra 6/7 mesi al massimo vi dirò che avevate ragione! Solo dopo essermi scottato da solo...

Potrebbe venire giu Dio in persona a dirmi queste cose e io rimarrei con il mio solito scetticismo.

 *k.gothmog wrote:*   

> 
> 
> vieni ad Ingegneria di Brescia a dire che hai fatto un benchmark in quel modo.

 

benchmark??? Io non capisco perche quest'uomo si agita per ogni cavolata..... Io non ho detto che ho fatto un benchmark, questo lo dice lui. Stavo ormai uscendo di casa, quando ho letto il post e volevo vedere se il mio sistema era piu o meno li. Riavviato, cronometrato e ho scoperto che non ci mette piu di 1 minuto. Io non ho parlato di bench...

Non capisco perche ogni volta quest'uomo la deve prendere sul personale; Io ho postato solo "quello che ho fatto" sta al singolo poi valutare nel modo piu opportuno la cosa, senza pretese di fare un bench.

Ma sei stressato dalla vita? Sei scontento perche la gente non apprezza fino in fondo la tua grandissima competenza? Se hai qualche cosa possiamo parlarne... 

Non mi sembra il caso di infuocarsi per ogni stupidaggine. Se secondo te ho detto delle cavolate amen, il forum è fatto per discutere di varie cose, c'è chi è piu esperto chi meno, penso che ognuno sia libero di dire (e di credere) cio che vuole, sempre nel limite della civiltà.... Devo ancora capire perche ti da cosi tanto fastidio che uno abbia delle idee diverse dalle tue; non mi va che qualcuno "mi imponga" per forza il suo pensiero anche se è piu competente di me. Se io sono un idiota, forse lo sarò per sempre, e certe cose non le capirò mai, tu, invece, che sei una persona piu acuta potresti comprendere il mio limite e agire di conseguenza, senza aver la presunzione di "dare le perle ai porci".

Il fatto che tu continui a gettare letame su di me non mi tocca minimamente, certo che stai pur tranquillo che non mi riduco a non postare piu per paura di contraddirti, di contraddire il grande k.gothmog , come si è ridotto qualcun'altro...

Se poi mi dite, guarda che spari troppe cavolate e stai arrecando danno alla comunità e al forum, allora mi metto una mano sulla coscienza e me ne vado...  

P.s. valuterò il tuo consiglio di fare l'operaio, sei contento?

----------

## Ic3M4n

 *Apetrini wrote:*   

> Se poi mi dite, guarda che spari troppe cavolate e stai arrecando danno alla comunità e al forum, allora mi metto una mano sulla coscienza e me ne vado... 

 

no, queste sono cose che devono sempre essere evitate. non si sta arrecando nessun danno alla comunità. tutti noi possiamo dare del nostro per migliorarla. di sicuro la perdita di un utente del forum è una cosa brutta e quindi come tale deve essere evitata fino all'ultimo. detto questo e dopo aver riletto attentamente gli ultimi post, soprattutto di Apetrini e di k.gothmog credo che la discussione stia degenerando verso un qualcosa di non costruttivo e visto comunque l'argomento del discorso, secondo me interessante, vi pregherei di cercare di mantenere la calma pena l'intervento di un moderatore, visto che già siamo stati avvertiti.

----------

## gutter

 *Apetrini wrote:*   

> Se poi mi dite, guarda che spari troppe cavolate e stai arrecando danno alla comunità e al forum, allora mi metto una mano sulla coscienza e me ne vado... 

 

Non mi sembra il caso di valutare soluzioni così drastiche. Ritengo che il contributo di tutti gli utenti crei un forum e non i post di pochi "eletti". 

 *Ic3M4n wrote:*   

> 
> 
> dopo aver riletto attentamente gli ultimi post, soprattutto di Apetrini e di k.gothmog credo che la discussione stia degenerando verso un qualcosa di non costruttivo e visto comunque l'argomento del discorso, secondo me interessante, vi pregherei di cercare di mantenere la calma pena l'intervento di un moderatore, visto che già siamo stati avvertiti.

 

Come sottolineato da Ic3M4n vorrei esortare sia Apetrini che k.gothmog a mantenere toni più pacati ed evitare inutili attacchi personali. 

Preciso che se al prossimo post uno dei due si lancia in attacchi nei confronti dell'altro chiudo il thread.

----------

## akiross

Ehm, io ho appena reinstallato gentoo sul muovo 64 bit e ovviamente ho tentato di metterci il gcc4. Pero' mentre cercavo le documentazioni ho trovato una pagina che mi ha fatto pensare.

La conclusione del discorso e' che gcc4, seppur tecnicamente migliore, presenta ancora diverse incompatibilita' e non e' ancora maturo a tal punto da essere un sostituto decente al 3.4.x che c'e' attualmente.

In effetti, a meno che il tuo compito E' quello di sviluppare patch per gcc4, o a meno che tu richieda molta velocita' nel **compilare** (e non eseguire) codice C++, attualmente credo che non ti conviene installare il 4, o almeno, aspettare una relase 4.1.0 visto che per ora ci sono solo bugfix e patch (4.0.1 e 4.0.2).

Questo e' quello che penso su gcc4. Xorg7 neanche l'avevo mai sentito prima  :Very Happy: 

Ciauz

EDIT: Eh, non vorrei aggiungere zizzania, ma solo una considerazione personale: i benchmark SI FANNO con il cronometro... l'unica cosa che vedo di sbagliato nel metodo di apetrini e' che e' un po spannometrica la cosa, visto che bisognerebbe sapere prima quali servizi ha su, che genere di configurazioni adotta ecc ecc... insomma: se redhat avvia apache e apetrini no, il test risulta sfalsato.

In ogni caso non vedo niente di male nell'usare un cronometro, e ritengo che il post dell'ingeniere di brescia, poteva anche essere risparmiato... piuttosto che flammare cosi' taci e scansati dal thread.

EDIT2: Un applauso a DranXXX, che fa il metalmeccanico e mantiene alta la reputazione dei metalmeccanici! Dran se tutti i metalmeccanici fossero bravi come te il mondo sarebbe un posto migliore, e parlo sul serio! Forse la gente sottovaluta gli operai, ma mi sembra che i lavori umili (senza offesa eh) rendano la gente migliore... Andro' a fare il pizzaiolo va!  :Very Happy:   :Very Happy: 

----------

## Dr.Dran

[OT]@akiross

Così mi fai vergognare   :Embarassed:   :Embarassed:   :Embarassed: 

Grazie mille per i complimenti   :Wink:  ma credo che sia meglio farli a chi se li merita veramente   :Very Happy: 

----------

## .:chrome:.

 *akiross wrote:*   

> i benchmark SI FANNO con il cronometro... l'unica cosa che vedo di sbagliato nel metodo di apetrini e' che e' un po spannometrica la cosa, visto che bisognerebbe sapere prima quali servizi ha su, che genere di configurazioni adotta ecc ecc...

 

appunto

- che configurazione

- che macchina (CPU)

- che tipo di memoria

- quale kernel (può fare davvero la differenza)

- che servizi

- in che modo è stato compilato il software

- quale software e in che versione

- quali servizi partono

e una manciata di altre cose.

e comunque ok il cronometro... ma non manuale. per i benckmark che hanno insegnato a fare a me si usa una macchina dedicata... non lo swatch

trascurare queste cose non è da poco. una sola variazione tra queste può sconvolgere il test. figuriamoci fregarsene di tutte quante in blocco...

si produrrebbe un dato che vale quanto le chiacchiere tra mia madre e la fornaia

supponiamo pure che io abbia il software meglio scritto e meglio compilato che esista su questo mondo... e se avessi un disco rigido lento...? la velocità del mio software se n'è già andata a quel paese.

questo dovrebbero tenerlo bene in considerazione prima di tutto quelli che scrivono gli allegri test comparativi sulle allegre riviste che parlano di informatica... e poi quelli che a quei test credono.

----------

## randomaze

 *k.gothmog wrote:*   

> si produrrebbe un dato che vale quanto le chiacchiere tra mia madre e la fornaia

 

k.gothmog, quello che ancora non sei riuscito a capire é che ad apetrini interessa proprio un dato che "equivale alle chiacchere tra tua madre e la fornaia". Le quali, per quanto ne so, potrebbero parlare dell'ultima puntata di beautiful oppure commentare, puntualmente e con cognizione di causa, l'influenza del risultato elettorale tedesco nell'economia globale con divagazioni sul come questo influenzerá il processo d'integrazione dell'europa.

----------

## .:chrome:.

ma si, per carità... facevo solo notare che le variabili in gioco sono tante (troppe?)

----------

## Apetrini

 *akiross wrote:*   

>  Eh, non vorrei aggiungere zizzania, ma solo una considerazione personale: i benchmark SI FANNO con il cronometro... l'unica cosa che vedo di sbagliato nel metodo di apetrini e' che e' un po spannometrica la cosa, visto che bisognerebbe sapere prima quali servizi ha su, che genere di configurazioni adotta ecc ecc... insomma: se redhat avvia apache e apetrini no, il test risulta sfalsato.

 

è il meglio che ho potuto fare avendo 5 minuti a disposizione (stavo uscendo di casa quando ho letto il post), piuttosto se qualcuno riesce a fare un rilevamento preciso ed accurato della sua macchina, lo faccia, il mio test fa abbastanza schifo, ma sono gli unici test(insieme ad altre 2 persone sul forum che hanno svolto il test alla mia maniera) che "abbiamo". Ripeto se qualcuno ci puo illuminare su tutto questo postando un analisi "concreta" e non solo teorica, per me sarebbe una gran cosa.

----------

## Ic3M4n

adesso riaccendo un po' la fiamma nel pollaio e faccio beccare ancora un po di polli... (senza offesa per nessuno, mi raccomando, è solo un modo di dire...)

apertini:

```
Centrino 1,6 512mb di ram

CFLAGS="-Os -march=pentium3 -pipe -fomit-frame-pointer".

USE ho messo "pic","nptl","nptlonly" e "sse2". 

Filesystem XFS, Scheduler Deadline, kernel 2.6.13. 

e poi ho fatto delle modifiche agli script di avvo in modo da non far controllare inutilmente lo stato dei moduli prima di caricarli e altre chicche...

 sto adoperando "prelink", 

disabilitato il restore all'ultima sessione su kde. 

tutto con "i686-pc-linux-gnu-3.3.6" che è l'ultimo gcc stabile... 
```

flocchini

```
superkaramba e tutto il resto su kde 3.4

gcc-3.4.3-20050110

CFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer" 

USE="x86 X aalib acpi alsa apm arts avi bash-completion berkdb bitmap-fonts crypt cups dga dvd dvdr eds emboss encode fam foomaticdb fortran gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 hal ieee1394 imagemagick imlib ipv6 ithreads java jpeg kde libg++ libwww mad mikmod motif mp3 mpeg ncurses nls nptl ogg oggvorbis opengl oss pam pda pdflib perl png python qt quicktime readline real samba sdl spell ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xml2 xmms xpm xv xvid zlib linguas_it userland_GNU kernel_linux elibc_glibc" 

... mancano altre informazioni importanti...
```

adesso una domanda per apertini: come mai hai compilato per pentium3 quando solitamente si consiglia di compilare il centrino come pentium4? almeno... il tuo è il 2 MB di cache di L2 o sbaglio?

cmq 8 secondi di differenza... molto probabilmente ci sono servizi differenti, però sono tanti...

----------

## Apetrini

 *Ic3M4n wrote:*   

> adesso riaccendo un po' la fiamma nel pollaio e faccio beccare ancora un po di polli... 

 

Ma LoL. Il mio è gia cotto, ha pure il bichini...

Oggi ho rifatto il test con l'autologin e mi ha fatto 54/55 secondi. Non sarà perche ho kde con tutti gli effetti grafici attivi...?

 *Ic3M4n wrote:*   

> 
> 
> adesso una domanda per apertini: come mai hai compilato per pentium3 quando solitamente si consiglia di compilare il centrino come pentium4? almeno... il tuo è il 2 MB di cache di L2 o sbaglio? 
> 
> 

 

Si si, il mio ha 2MB di cache. All'epoca mi ricordo che stavo valutando la cosa, e mi sembrava che il pentium3 fosse molto piu prossimo al PentiumM di quanto lo era il Pentium4. La differenza tra il pentium3 e pentiumM è soprattutto la quantità di cache e il supporto alle SSE2, differenza questa che ho "aggirato" settando nelle USE SSE2. Il pentium4 ,invece, ha una pipeline molto piu lunga rispetto agli altri 2. Il pentium4 dovrebbe avere la pipeline a 31 stadi quello a 90nm,20 quello a 130nm. Il pentium3 dovrebbe avere 10 stadi. Ora, siccome all'epoca l'intel non ha rivelato il numero di stadi della pipeline(non so se poi lo ha fatto, dovrei fare delle ricerche),ha detto solo che sono piu di 10 e meno di 20. gli esperti dicono che dovrebbe essere un valore piu vicino ai 10 che ai 20.

Ma poi non si sa, perche il pentium M ha un algoritmo in piu per la "previsione della pipeline" rispetto al pentium e questo avrebbe dovuto consentire di poter stare un po' piu abbondanti con gli stadi. IL problema della pipe lunga è che se le previsioni dell'algoritmo dovessero essere sbagliate la cpu dovrebbe ricalcolare il tutto e se questo succede spesso le prestazioni ne risentono.

Ripeto all'epoca avevo fatto le mie considerazioni e le mie scelte, forse sarebbe il caso di rivalutare la questione....

P.s. hai ragione quando dici che molti consigliano pentium4 è solo che non sono abituato a prendere per buone a priori le considerazioni degli altri, preferisco fare delle considerazioni mie a costo di sbagliare....

P.p.s. se qualcuno sa di piu sugli stadi del pentium-M si faccia vivo. Comuqnue il gcc 3.4 taglia la testa al toro perche ha la flag pentium-m...

----------

## .:chrome:.

 *Ic3M4n wrote:*   

> adesso una domanda per apertini: come mai hai compilato per pentium3 quando solitamente si consiglia di compilare il centrino come pentium4? almeno... il tuo è il 2 MB di cache di L2 o sbaglio?

 

e questa da dove esce? sei sicuro?

per quello che ne so io Banias/Dothan e Prescott hanno delle differenze abissali. a occhio non mi sembra una grande idea complilare per pentium4

diverso discorso è per i celeron-M che consumano come i centrino, ma non perché lo siano: si tratta infatti di un core derivato da quello dei Pentium-4 di seconda generazione (o terza? ho perso il conto)

----------

## Ic3M4n

 *k.gothmog wrote:*   

> e questa da dove esce? sei sicuro? 

 

semplicemente l'ho letto nel forum, ed il mio centrino l'ho compilato come pentium4. poi sono passato a gcc 3.4 che supporta il pentium-m.

x es. qui ne parlano https://forums.gentoo.org/viewtopic-t-263995-highlight-centrino+cflags.html

----------

## .:chrome:.

 *Ic3M4n wrote:*   

> semplicemente l'ho letto nel forum, ed il mio centrino l'ho compilato come pentium4

 

mah... non per sfiducia nei confronti di chi scrive, per carità... ma io ho qualche dubbio.

l'architettura centrino (almeno quella che ho visto io) è in generale più vicina al Pentium-3 che al Pentium-4. e poi c'è la questione della pipeline, che influenza moltissimo le prestazioni, e il centrino non da di certo una pipeline lunga come quelal del P4, per non parlare della superscalarità, indubbiamente superiore...

l'ideale sarebbe avere qualche indicazione dal team di sviluppo di GCC, oppure qualcosa di Intel

----------

## Ic3M4n

non so che dirti... cmq ho usato il gcc 3.3 per poco... sono passato quasi subito alla versione successiva proprio per la nativa gestione del processore. quindi non ho un metro di paragone affidabile. ho scritto solo una convinzione dovuta al fatto che molti hanno utilizzato tali opzioni di compilazione su pentium-m.

----------

## Apetrini

Ok.

Per la gioia di questo 3d ho emerso il gcc4. Allora, per me affinche un gcc sia utilizzabile(almeno un po') deve compilare almeno il kernel, e aimè il gcc-4.0.1 e il 4.0.2_pre20050917 non riescono a portare a termine la compilazione.

Per fare sto mini test ho usato i sorgenti gentoo i "linux-2.6.12-gentoo-r10" cosi non mi dite che non compila perche il mio vanilla è ultra patchato. Quello gentoo ha delle patch ma comunque nulla di troppo invasivo che non dovrebbe permettere la compilazione.

L'errore è sempre lo stesso:

```

drivers/video/vesafb-thread.c:40: error: static declaration of 'errno' follows non-static declaration

include/linux/unistd.h:4: error: previous declaration of 'errno' was here

make[2]: *** [drivers/video/vesafb-thread.o] Error 1

make[1]: *** [drivers/video] Error 2

make: *** [drivers] Error 2
```

P.s. il gcc 3.3.6 ovviamente porta la compilazione a buon fine ...

P.p.s il gcc4 comunque mi da un sacco di warning in piu rispetto al 3, non sarà mica che il gcc4 non tollera quelle cose che non sono ufficialmente supportate dal C, ma che vengono comunque tollerate da gcc3? Bo mistero... è tardi tra 4 ore mi devo svegliare, vado a nanna, ci penso su un altro giorno.

----------

## Apetrini

Ieri notte ho messo su xorg-6.8.99.15-r2 e devo dire che è piu veloce ad avviarsi, ho avuto delle piccole incompatibilità con i driver Open Source che avevo su, piccolezze che ho risolto installando gli ultimi driver Ati open source. Non ho testato questa versione di xorg con i driver Ati closed perche attualmente non gli uso, e non gli userò finche non si decidono ad implementare il supporto alle estensioni composite(si dice in giro che sarà implementato quando sarà stabile il nuovo xorg). Comunque il nuovo xorg mi sembra molto stabile....

Poi ho provato a compilare qualcos'altro con il gcc4 e la scelta è caduta su gimp 2.2.8(che se è compilato senza problemi), mi sembra che questo gcc compili le cose in tempi leggermente piu brevi rispetto ai predecessori. Ho provato a sforzare gimp con altissime risoluzioni e filtri su fultri, il risultato è un gimp comunque stabile e mi sembra anche abbastanza reattivo...

P.s. se qualcono ha fatto prove posti pure le sue impressioni...

----------

## Dr.Dran

[Curiosità] il nuovo xorg ha una struttura modulare vero? nel senso che installo solo quello che mi serve vero?

----------

## Apetrini

In teoria il 6.9 e il 7.0 sono identici, solo che il 7 è modulare il 6.9 no.

Se vuoi emergere quello modulare devi cercarti i singoli moduli , per esempio xorg-server...

Mi pare...

----------

## Dr.Dran

Thanx mi interessava sapere se in portage era già stato inserito, in modo tale da poi provarlo successivamente quando sarà stabile  :Very Happy: 

----------

## federico

 *k.gothmog wrote:*   

>  *Ic3M4n wrote:*   semplicemente l'ho letto nel forum, ed il mio centrino l'ho compilato come pentium4 
> 
> mah... non per sfiducia nei confronti di chi scrive, per carità... ma io ho qualche dubbio.
> 
> l'architettura centrino (almeno quella che ho visto io) è in generale più vicina al Pentium-3 che al Pentium-4. e poi c'è la questione della pipeline, che influenza moltissimo le prestazioni, e il centrino non da di certo una pipeline lunga come quelal del P4, per non parlare della superscalarità, indubbiamente superiore...
> ...

 

A dirla tutta anche io prima che uscisse il pentium-m nel gcc compilai come P4 perche' (ora non trovo il link purtroppo) era un consiglio ufficiale sul sito intel di compilare come p4, perche' secondo loro (che lo producono) la struttura del centrino e' simile al p4, e non al p3.

----------

## Apetrini

 *federico wrote:*   

> 
> 
> A dirla tutta anche io prima che uscisse il pentium-m nel gcc compilai come P4 perche' (ora non trovo il link purtroppo) era un consiglio ufficiale sul sito intel di compilare come p4, perche' secondo loro (che lo producono) la struttura del centrino e' simile al p4, e non al p3.

 

Che casino.... Tutto questo perche l'Intel non vuole dicchiarare apertamente le specifiche Centrino, almeno un po' di tempo fa non si sapeva nulla, se ora qualcuno sa ce lo dica per favore.... Mi andrebbero bene anche specifiche fatte (stimate) da altri...tipo dal team gcc.

----------

## SonOfTheStage

 *Apetrini wrote:*   

> Che casino.... Tutto questo perche l'Intel non vuole dicchiarare apertamente le specifiche Centrino, almeno un po' di tempo fa non si sapeva nulla, se ora qualcuno sa ce lo dica per favore.... Mi andrebbero bene anche specifiche fatte (stimate) da altri...tipo dal team gcc.

 

Nella documentazione del gcc dice:

 *Quote:*   

> 
> 
> <snip>
> 
> pentium-m
> ...

 

----------

## Apetrini

Come pensavo io........ma da quel che dice "federico" sembra che intel invece consigli di usare pentium4.

----------

## Ciccio Bueo

oggi ho visto che xorg 7 è in x86,  pensavo di installarlo (perchè ho una via epia e quindi già usavo la versione instabile,  ma ha un macello di dipendenze maskerate, qualcuno lo sta già usando? ha problemi?

----------

## Apetrini

Stanotte ho provato una configurazione nuova sul mio portatile e ho provato a ricronometrare quanto ci mette ad entrare in kde.

Mi sembra migliorato...43 secondi usando l'autologin.

Il mio sistema è il mio solito portatile e le mie scelte sono:

CFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer"

nptl

reiser4 su /

xfs su /home

kernel 2.6.14-mm quello in portage

gcc 3.4.4 (pentium-m)

xorg 6.8.99.15-r4

kde 3.5_rc1 (con tutti gli effetti attivi tranne le trasparenze/ombre in hardware)

soliti script "volare con gentoo".

All'avvio parte il minimo....

```

cpufrequtils                                                        [ started ]

 domainname                                                          [ started ]

 hald                                                                [ started ]

 hdparm                                                              [ started ]

 laptop_mode                                                         [ started ]

 local                                                               [ started ]

 netmount                                                            [ started ]

 xdm      

```

per quelli di "boot",be  sono i "soliti."

Considerazioni: il nuovo xorg si avvia piu velocemente di quello vecchio, spero che quello modulare sia ancora piu veloce...

il mio collo di bottiglia all'avvio mi sembra essere xfs, all'inizio ho messo la home in ext3 e mi sembrava piu veloce, dico mi sembrava perche non ho cronometrato.

Chissa forse xfs non offre prestazioni eclatanti quando si tratta di leggere tanti piccoli file....

P.s. questa volta non ho messo il prelink, ma sto valutando la cosa....magari provando a compilare kde con gcc 4... cosi tanto per provare....

----------

## .:chrome:.

 *Apetrini wrote:*   

> Chissa forse xfs non offre prestazioni eclatanti quando si tratta di leggere tanti piccoli file...

 

hai mai letto le specifiche del file system?

XFS è uno dei file system più veloci che ci siano. con determinate ottimizzazioni (applicabili purtroppo solo in fase di formattazione) raggiunge livelli considerevoli.

ok fare considerazioni, ma se non si hanno le basi tecniche, fondarle solo su osservazioni empiriche tralasciando il background tecnico che hanno porta, come in questo caso, a commettere degli errori. il riportare poi gli errori in un luogo pubblico come questo porta la comunità a farsi unìidea sbagliata. non penso sia quindi una buona pratica

----------

## Ic3M4n

 *k.gothmog wrote:*   

> ok fare considerazioni, ma se non si hanno le basi tecniche, fondarle solo su osservazioni empiriche tralasciando il background tecnico che hanno porta, come in questo caso, a commettere degli errori. il riportare poi gli errori in un luogo pubblico come questo porta la comunità a farsi unìidea sbagliata. non penso sia quindi una buona pratica

 quoto tutto e mi riallaccio anche all'altro thread su xfs in cui hai postato la tua opinione... purtroppo il tuo utilizzo del pc va oltre il normale utilizzo... quindi è normale sfasciare filesystem. 

tornando it: se misuri le performance del tuo pc sui tempi di avvio del pc, perchè non hai ancora utilizzato initng?

```
sys-apps/initng

     Available versions:  0.3.3 0.3.5 0.4.0 9999
```

 attualmente la versione 4, (sul sito mi sembra ci sia l'ebuild della 4.5) è ormai abbastanza stabile da poter essere utilizzata in concorrenza con l'init tradizionale. io la utilizzo quando sono in giro e mi serve un boot veloce. calcola che in circa 20-25 secondi ho il sistema al login e non sono uno che si ammazza di lavoro per migliorare i tempi di avvio. anzi... mentre tu sei arrivato ai 40 sec con pochi servizi attivati io sono a 25 con tutti i servizi di uso desktop di un pc.

----------

## !equilibrium

'rumors' dal planet di gentoo dicono che Ã¨ stata inserita nel CVS di portage una patch per permettere un 'reale'  boot init con start-up dei demoni in parallelo, migliorando sensibilmente il tempi di avvio dell'init.

ora vedo se riesco a ripescare il blog del developer della patch.

----------

## Apetrini

@Ic3M4n: se guardi bene l'ora capisci che ormai erano le 5.00 del mattino, ormai ero esausto, comunque l'ho appena messo su e non cambia di tanto il tempo di avvio, 42 secondi. 

Ma per curiosità che computer hai ?

@k.gothmog,Ic3M4n: mha non mi sembra di aver avuto pretese di insegnare qualcosa a qualcuno, nel mio post è ben specificato che sono considerazioni e nulla piu. Ho parlato di mie personalissime sensazioni. E poi visto che ogni volta si entra nel circolo vizioso della mia incapacità, chiedo tanto se qualcuno dopo aver criticato correggesse i miei errori? Mi sembra che il forum serva anche a questo...per imparare. E non cominciate a citarmi leggi e i 10 comandamenti  del pc perche anche se mi va bene la teoria, se non mi date una mano a concretizzare il tutto io non vado tanto lontano. Quindi visto che mi è sembrato che voi ne sappiate piu di me ...datemi 10 consigli pratici per avviare il mio laptop(con kde) in meno tempo possibile, cosi alla fine anche io traggo vantaggio da qualche vostro post....

Grazie anticipatamente per le risposte....

----------

## .:chrome:.

ma guarda che non era un attacco verso di te. era solo una sterile osservazione su quello che avevo letto.

ho trovato qualcosa che secondo me era sbagliato, e te l'ho fatto notare, spiegandoti anche il perché: sei saltato subito a conclusioni affrettate ed infondate, e non mi pare cosa giusta perché una persona, leggendo, potrebbe farsi idee sbagliate.

l'argomento è stato trattato più e più volte, quindi non ho ritenuto necessario ripetere cose che si erano già dette. tutto qui

vuoi qualche link? eccoli:

migliorare le performance di SGI XFS Filesystem

alcune notizie su XFS direttamente da SGI

uno studio su Iron File System che dimostra quanto ReiserFS sia un colabrodo

per cominciare credo bastino

ERRATA CORRIGE: iron file system mi risulta non raggiungibile. lo sposto quiLast edited by .:chrome:. on Mon Nov 28, 2005 8:36 pm; edited 2 times in total

----------

## Apetrini

Ho letto dei post che ne parlavano, ho seguito le indicazioni... forse qualcosa nella mia procedura non va come dovrebbe...

Puoi postarmi per favore dove sono stati trattati questi argomenti per vedere se qualche post mi è sfuggito...

Perche a me sembra di avere fatto tutte le cose come si deve eppure mi sembra che (da quello che dice Ic3M4n) non ho fatto abbastanza...

Mi puoi dare qualche dritta? 

Alla fine tutti criticano e tutti dicono la loro, ma le persone che hannos critto un modus operandi per far avviare piu velocemente la propria macchina sono poche...

----------

## .:chrome:.

allora... ti dico cosa ho fatto io, ok?  :Smile: 

ho tenuto le partizioni di /boot e /tmp separate e ho formattato in ext2

fai attenzione al parametro -b (blocchi più grandi producono file system più maneggevoli e dall'indicizzazione più rapida, ma producono slack space). avendo una /tmp grande ho usato anche -O dir_index

il resto del sistema è formattato in XFS, con opzione -d unwritten=0 e con allocazione personalizzata dei gruppi (questo non posso dirti io come farlo. dipende dal tuo hard disk) e le partizioni sono montate con opzione async (occhio che ti prosciuga la RAM).

ho tenuto separata la root da /var e ho montato quest'ultima con l'opzione noatime (occhio che non sempre puoi farlo. dipende da che software usi, perché con quell'opzione eviti la scrittura di informazioni importantissime per tutti quei programmi che basano il loro funzionamento sull'analisi dello stato del file system)

monto una copia di /etc/init.d in RAM (tmpfs) ed ho abilitato il parallel startup in /etc/conf.d/rc

settimanalmente cron lancia il prelink

ho fatto un po' di sistemazioni allo scheduler di I/O via /sys e ai parametri di XFS via /proc (ma questo, sebbene dia vantaggi tangibili te lo sconsiglio: è parecchio delicato mettere le mani lì dentro)

spero di essere stato abbastanza chiaro, e che questa volta il post sia di tuo gusto.

P.S.: io queste cose me le sono cercate da solo. se vuoi imparare non lo farai di certo facendoti preparare la pappa sul forum, e bada bene che non è affatto una critica, ma un consiglio

----------

## Apetrini

 *k.gothmog wrote:*   

> 
> 
> ho tenuto separata la root da /var e ho montato quest'ultima con l'opzione noatime (occhio che non sempre puoi farlo. dipende da che software usi, perché con quell'opzione eviti la scrittura di informazioni importantissime per tutti quei programmi che basano il loro funzionamento sull'analisi dello stato del file system)
> 
> 

 

Non sapevo che potesse creare problemi, terrò in considerazione quello che dici....

 *k.gothmog wrote:*   

> 
> 
> monto una copia di /etc/init.d in RAM (tmpfs) ed ho abilitato il parallel startup in /etc/conf.d/rc
> 
> 

 

Non monto nulla sulla ram ma il parallel startup l'ho abilitato anche io e oggi provando initng non mi sembrava fosso molto piu veloce di init normale.

 *k.gothmog wrote:*   

> 
> 
> settimanalmente cron lancia il prelink
> 
> 

 

Le altre volte che mettevo su un sistema usavo sempre il prelink, questa volta non l'ho messo, ma rimedierò presto....

Piuttosto ora ho notato una cosa....il mio kernel quando fa il boot la cpu è a 600mhz perche il speedstep è attivato e poi quando si carica cpufrequtils torna a 1,6ghz perche sotto sforzo, dovrei trovare un modo per far bootare il kernel con cpu a 1,6...

Grazie comunque delle risposte, apprezzo il gesto.

----------

## yardbird

 *k.gothmog wrote:*   

> uno studio su Iron File System che dimostra quanto ReiserFS sia un colabrodo

 

Eh? Guarda che da quel paper reiserfs non esce affatto male... Ho dato una letta veloce e:

 *Quote:*   

> â¢ ReiserFS: First, do no harm. ReiserFS is the most concerned
> 
> about disk failure. This concern is particularly evident upon write
> 
> failures, which often induce a panic; ReiserFS takes this action
> ...

 

(Enfasi aggiunta da me). Da dove emergerebbe che Ã¨ un colabrodo? A me pare che ext3 (che fra il resto Ã¨ piÃ¹ giovane) ne esca peggio...

----------

## Ic3M4n

 *Apetrini wrote:*   

> 
> 
> @k.gothmog,Ic3M4n: mha non mi sembra di aver ...cut...  ...cut... cosi alla fine anche io traggo vantaggio da qualche vostro post....
> 
> Grazie anticipatamente per le risposte....

 

il mio portatile è un centrino 1,6 con 512 Mb di ram. 80G di hd.

xfs non l'ho tirato più di molto perchè non il pc mi serve funzionante e non ho tempo per mettere le mani in tutti i buchi del mio pc. diciamo che tutto quello che c'è nel link che ti ha passato k.gothmog su xfs mi interessa moltissimo e non vedo l'ora di provarlo. cmq la mia non era una critica alla tua incapacità con il pc. non l'ho mai detto e non intendo dirlo. se hai capito questo, mi spiace ma hai capito male. solamente non condivido la tua opinione che xfs sia un fs rottame. secondo me è uno dei più robusti che ho trovato... alcuni crash e sempre tutto funzionante. al max ho dovuto ricreare una volta a manina l'fstab sul portatile perchè non mi sono accorto che stava finendo e lo stavo modificando. cmq x il resto non mi ha mai tradito. la mia osservazione era riferita al fatto che in generale uno non può lamentarsi se perde dei dati se utilizza il pc per test con il kernel patch varie e moduli esoterici. 

per i moduli che carico con initng ti faccio sapere dopo. adesso sono sull'altro pc...

queste sono le cose che partono al boot con initng

```

acpid   | default

agetty  |                             system up

cpufreqd | default

dbus    | default

famd    | default

gdm     | default

getty    |                             system up

gpm     | default

 hald    | default

ifplugd | default

sshd    | default

syslog-ng | default

vixie-cron | default

net       | default                     system

alsasound | default

bootmisc |                             system

clock     |                             system

coldplug |                             system

consolefont |                             system

domainname | default

hdparm |                             system

hostname |                             system

initial |                             system

keymaps |                             system

modules |                             system

 mountfs |                             system

mountroot |                             system

static-modules |                             system

swap |                             system

urandom |                             system

usb | default

eth0 | default

lo | default                     system

```

con questo popò di roba ed un kernel con dentro il mondo in ca 35 sec sono al login. cmq se ti metti a limare un po' di qua e di la riesci a raggiungere i 25-30 secondi tranquillamente.

----------

## .:chrome:.

 *yardbird wrote:*   

> Da dove emergerebbe che Ã¨ un colabrodo?

 

l'ho letto tempo fa... vado a memoria

dipende da ch punto di vista guardi le cose (come sempre del resto  :Smile: )

se parliamo di velocità immediata ed istantanea, ReiserFS esce (quasi) sempre vincitore da un confronto con gli altri

il problema è chequesta velocità si ottiene con algoritmi che in molti hanno criticato per le scelte "audaci" in fase di progetto, e questa cosa è stata portata all'estremo con ReiserFS 4. lo stesso team di sviluppo del kernel ha giudicato male ReiserFS e si è scontrato molte volte con Hans Reiser, per questo motivo.

a questo si aggiunge il pesante impatto che ha sulla struttura del disco rigido, che viene molto sollecitato. statisicamente i dischi formattati con ReiserFS hanno un MTBF (misurato, non dichiarato) più basso.

ciliegina sulla torta: in caso di guasto, ReiserFS è quello che rende più difficile (pressoché impossibile) il recupero dei dati.

basta cercare, e si trovano documentazioni molto precise, a riguardo. ReiserFS ha avuto dei casi di fallimento clamorosi e catastrofici. ext2/3 sono ovviamente più lenti, poiché non hanno nessun sistema di ottimizzazione, ma soffrono molto meno dei problemi citati sopra. da qui la scelta di basare ifs su ext2/3

----------

## yardbird

 *k.gothmog wrote:*   

>  l'ho letto tempo fa... vado a memoria

 

Beh, il mio rilievo era indirizzato al paper specifico che hai citato... LÃ¬ il giudizio su reiserfs Ã¨ sicuramente positivo.

 *k.gothmog wrote:*   

> lo stesso team di sviluppo del kernel ha giudicato male ReiserFS e si ï¿½scontrato molte volte con Hans Reiser, per questo motivo.

 

Seguo lkml da parecchio tempo ormai, e l'impressione che mi sono fatto io Ã¨ che ci sia una parte degli sviluppatori (Hellwig in testa) che ha delle evidenti incompatibilitÃ  caratteriali con Reiser. La sua personalitÃ  puÃ² dare fastidio, questo lo capisco, ma ciÃ² non dovrebbe mai entrare nelle questioni tecniche. Purtroppo anche i kernel dev sono umani... D'altro canto c'Ã¨ una grossa fetta di hacker (e fra questi ci sono gli stessi Torvalds e Morton) che dÃ  spesso ragione a Reiser nelle discussioni sulla lista. E (molto) raramente ho visto Reiser avere la peggio quando la discussione Ã¨ stata portata in ambito prettamente tecnico.

 *k.gothmog wrote:*   

> a questo si aggiunge il pesante impatto che ha sulla struttura del disco rigido, che viene molto sollecitato. statisicamente i dischi formattati con ReiserFS hanno un MTBF (misurato, non dichiarato) pi basso.

 

Sarebbe interessante vedere qualche riscontro di ciÃ² che dici... link?

 *k.gothmog wrote:*   

> ciliegina sulla torta: in caso di guasto, ReiserFS ï¿½quello che rende pi difficile (pressochï¿½impossibile) il recupero dei dati.

 

Questa Ã¨ una scelta progettuale precisa. E' opinione del team di sviluppo che il filesystem non debba occuparsi di correggere eventuali bug/errori del controller IDE o della ram. Questa scelta puÃ² essere criticata, ma ciononostante c'Ã¨ una motivazione dietro. Puoi avere il filesystem piÃ¹ conservativo che esista, ma non c'Ã¨ niente da fare in caso di guasto hardware, l'unica Ã¨ avere backup aggiornati.

 *k.gothmog wrote:*   

> basta cercare, e si trovano documentazioni molto precise, a riguardo. ReiserFS ha avuto dei casi di fallimento clamorosi e catastrofici. ext2/3 sono ovviamente pi lenti, poichï¿½non hanno nessun sistema di ottimizzazione, ma soffrono molto meno dei problemi citati sopra. da qui la scelta di basare ifs su ext2/3

 

Allora come spieghi questa affermazione, tratta proprio dal paper su ifs?

 *Quote:*   

> The main problem with ext3 is its failure handling for 
> 
> write errors, which are ignored and cause serious problems including 
> 
> possible ï¬le system corruption.

 

 :Question: 

EDIT: mi ero dimenticato di una cosa. Storie dell'orrore su questo o quel fs si sentono dovunque, sarebbe opportuno avere qualche elemento piÃ¹ concreto in mano.

----------

## .:chrome:.

 *yardbird wrote:*   

> Sarebbe interessante vedere qualche riscontro di ciÃ² che dici... link?

 

mi viene il tremendo dubbio che stia facendo casino tra i documenti, perhcé sono convinto di averlo letto in quell'articolo.

stanotte lo rileggerò

vale lo stesso per il resto

----------

## !equilibrium

 *k.gothmog wrote:*   

> ho tenuto separata la root da /var e ho montato quest'ultima con l'opzione noatime (occhio che non sempre puoi farlo. dipende da che software usi, perché con quell'opzione eviti la scrittura di informazioni importantissime per tutti quei programmi che basano il loro funzionamento sull'analisi dello stato del file system)

 

e aggiungo, che se si usa il profilo hardened di gentoo con GrSec si potrebbero avere problemi anche con 'nodiratime' e altre opzioni di mount specifiche per XFS, per cui fate attenzione a dove mettere le mani ed agite con cognizione di causa.

 *k.gothmog wrote:*   

> monto una copia di /etc/init.d in RAM (tmpfs) ed ho abilitato il parallel startup in /etc/conf.d/rc
> 
> settimanalmente cron lancia il prelink

 

ecco questa mi mancava  :Very Happy: 

grazie per la segnalazione k.gothmog

 *k.gothmog wrote:*   

> ho fatto un po' di sistemazioni allo scheduler di I/O via /sys e ai parametri di XFS via /proc (ma questo, sebbene dia vantaggi tangibili te lo sconsiglio: è parecchio delicato mettere le mani lì dentro)

 

a riguardo sappiate che l'accoppiata CFQ + TMPFS, in aggiunta a valori molto aggressivi di 'vm.swappiness' e di XFS produce un ambiente molto instabile perchè il kernel inizia a liberare memoria che in realtà è allocata dai software in esecuzione, causandone ovviamente il crash. (è un problema dell'algoritmo dello swappiness della VM)

----------

## matttions

Ciao  :Smile: 

Sul mio pc ho attivo e funzionante:

* hibernate --> uso i 

```
suspend2-sources-2.6.14-r5
```

 e funziona egregiamente.

Con i radeon, non con gli Ati-closed.

* initng --> funziona abbastanza bene.. anche se a volte partono certi servizi, altre volte no... diciamo che fà un pò casino...

ma sostanzialmente và.

Xorg 6.9/7 ne parlano tutti molto bene..ma nn l'ho mai testato [in verità provato ad installarlo ma trovato dei problemi]

Sul gcc-4 non sò  :Smile: 

Anche io ho un centrino.

Su questo post si parla del mio portatile, e c'è anche un buono spunto sulle CFLAGS  :Smile: 

http://gentoo-wiki.com/Gentoo_Acer_Travelmate_803LCi_Manual#Design_of_the_Pentium-M

ciauz  :Smile: 

----------

## yardbird

E' il mio turno? Vediamo...

- sistema ricompilato con gcc 4 (attualmente uso 4.0.2)

- Xorg 7.0rc2 con driver EXA su radeon (e le trasparenze vanno alla grande  :Cool:  ) 

- suspend2 attivo e funzionante.

Initng l'ho provato e mi ha fatto un'ottima impressione, dimezzando i tempi di avvio della macchina. Il problema è che serve riconfigurare gli script di avvio, e gli script per alcuni servizi proprio mancano. Inoltre se un servizio si incrania c'è la fastidiosa tendenza a crashare in toto il processo di init, con conseguenze non proprio esaltanti.

Ma in fondo, con suspend2, i tempi di avvio non sono più un problema  :Wink: 

----------

## matttions

 *yardbird wrote:*   

> E' il mio turno? Vediamo...
> 
> - sistema ricompilato con gcc 4 (attualmente uso 4.0.2)
> 
> 

 

Bene .. quindi anche il kernel riesci a ricompilare.. oppure no?

 *yardbird wrote:*   

> 
> 
> - Xorg 7.0rc2 con driver EXA su radeon (e le trasparenze vanno alla grande  ) 
> 
> 

 

Il modulare quindi...

ottimo.. e le trasparenze le gestisci con transett e compagnia bella, oppure hai un window manager che le integra di default...

p.s.: Dicci il tuo sistema ... così ci facciamo un'idea..

 *yardbird wrote:*   

> 
> 
> - suspend2 attivo e funzionante.
> 
> 

 

Infatti questo è una manna  :Smile: 

 :Smile: 

----------

## yardbird

 *matttions wrote:*   

> Bene .. quindi anche il kernel riesci a ricompilare.. oppure no?

 

Yay... ho solo quel compilatore installato, quindi o così o niente  :Wink: 

 *matttions wrote:*   

> Il modulare quindi...
> 
> ottimo.. e le trasparenze le gestisci con transett e compagnia bella, oppure hai un window manager che le integra di default...

 

Ho utilizzato per un po' xcompmgr+transser-df+xbindkeys, come descritto qui. Ora sto utilizzando kompmgr, che viene installato con KDE. Tutti e due funzionano comunque bene, solo permettono di fare cose leggermente diverse.

 *matttions wrote:*   

> p.s.: Dicci il tuo sistema ... così ci facciamo un'idea..

 

E' un portatile HP, con pentium4 2.4 e scheda video radeon IGP 345M con memoria condivisa (quindi abbastanza ciofeca). gcc-4.0.2, binutils 2.16.1, glibc-2.3.6-r1. Il kernel è un 2.6.15-rc3 modificato con varie patch, il filesystem su / è reiser4 (con un trucchetto extra per aumentare notevolmente le performance  :Wink:  ).

```
CFLAGS="-mtune=pentium4 -march=pentium4 -fomit-frame-pointer -O2 -pipe -mfpmath=sse -ffast-math"

LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,-s -Wl,--as-needed"
```

Il sistema è stato ricompilato interamente con gcc4. Alcuni pacchetti hanno dato problemi, ma nella maggior parte dei casi si è trattato di installare la versione ~x86 oppure di farsi un giretto sul bugzilla per cercare le patch che correggono il problema. Non ho notato instabilità di alcun tipo. Se è per quello non ho notato neanche aumenti o diminuzioni di peformance. D'altro canto nell'utilizzo tipico di un desktop sono altri i fattori che incidono sulla "velocità" percepita dell'ambiente di lavoro (leggi dimensione dei binari, performance dell'hard-disk, efficienza nel caricamento delle librerie condivise, etc.).

In realtà avevo messo su il gcc4 per due motivi: 1) testare il supporto all'attributo "visibility" in C++ e in Qt+KDE in particolare ("-fvisibility-inlines-hidden -fvisibility=hidden") (ma pare che i tempi non siano ancora maturi per questo) e 2) avere un compilatore fortran90/95 free. Ora almeno ho il mio compilatore fortran  :Wink: 

----------

## Dr.Dran

Scusate se mi intrometto, ma potreste eventualmente fornire, qualche test su programmini compilati con una versione di gcc e poi confrontarli con l'ultima installata? Oppure fare il profiling del sistema? In questo modo sarebbe un approccio + analitico e meno empirico e non si lascierebbe spazio ad indesiderati effetti placebo...  :Very Happy: 

Grazie ciauz   :Wink: 

----------

## .:chrome:.

 *DranXXX wrote:*   

> In questo modo sarebbe un approccio + analitico e meno empirico e non si lascierebbe spazio ad indesiderati effetti placebo.

 

concordo. basta con le leggende metropolitane sui compilatori

----------

## mambro

 *yardbird wrote:*   

>  il filesystem su / è reiser4 (con un trucchetto extra per aumentare notevolmente le performance  ).
> 
> 

 

Cioè?

----------

## yardbird

 *mambro wrote:*   

> Cioè?

 

Patch:

NON APPLICATE LA PATCH SEGUENTE SE NON SAPETE COSA STATE FACENDO. ANZI, NON APPLICATELA PROPRIO COSI' FACCIAMO PRIMA  :Wink: 

```
--- fs/buffer.c.orig    2005-11-26 01:31:00.786939533 +0100

+++ fs/buffer.c 2005-11-26 01:31:35.357147332 +0100

@@ -376,12 +376,14 @@

 asmlinkage long sys_fsync(unsigned int fd)

 {

-       return do_fsync(fd, 0);

+       /*return do_fsync(fd, 0);*/

+       return 0;

 }

 asmlinkage long sys_fdatasync(unsigned int fd)

 {

-       return do_fsync(fd, 1);

+       /*return do_fsync(fd, 1);*/

+       return 0;

 }

 /*
```

ATTENZIONE: non mi assumo responsabilità riguardo questa patch, provatela (se volete) a vostro rischio e pericolo.

Sostanzialmente la patch rimuove le chiamate sys_fsync* dal kernel. Queste funzioni non sono ancora state ottimizzate nel caso di reiser4, il che comporta un certo calo di performance in quelle applicazioni che (stupidamente) fanno un uso pesante della chiamata sync(). reiser4 ha un suo meccanismo interno (chiamato "lazy writes") per il flushing su disco dei dati nel buffer, quindi questa patch dovrebbe essere sicura (e sottolineo il condizionale). La uso da qualche tempo ormai, e so di altra gente che la impiega (c'è stata una discussione su reiserfs-list in questo senso). Nel mio caso (notata la sottolineatura?) la patch non ha mai creato problemi, anche a fronte di alcuni kernel panic dovuti a sperimentazioni con schede pcmcia wireless con conseguente cold boot. fsck.reiser4 non ha mai rilevato errori di sorta.

Nota bene: l'applicazione "sync" continuerà a funzionare anche dopo la rimozione di sys_fsync*, dal momento che utilizza un metodo differente per forzare il flushing su disco dei dati presenti nel buffer. Quindi se volete andare sul sicuro, prima di fare qualche operazione potenzialmente rischiosa che può bloccare la macchina, lanciate un bel "sync" (anche come utenti standard).

Fate vobis  :Wink: 

----------

## .:chrome:.

 *yardbird wrote:*   

> Patch:

 

ma stai scherzando?

a parte che il meccanismo che tu dici delle lazy writes esiste da sempre in XFS, quindi se volevi usarle quello bastava un file system diverso (e più stabile), ma al di là di questo...

mi chiedo con quale testa tu posti una patch simile. il fatto che nel tuo caso (notata la sottolineatura?) non abbia dato problemi, non vuol dire che rimuovere le chiamate sys_fsync* dal kernel sia una cosa sana.

non hai pensato che forse al file system può anche stare bene, ma alle strutture del kernel (e degli scheduler I/O) no?

forse sarò io troppo quadrato, ma penso che queste pratiche che consigliano più o meno direttamente agli utenti anche inesperti patch non standard e non approvate da chi è preposto a farlo sia molto dannoso.

----------

## yardbird

 *k.gothmog wrote:*   

> mi chiedo con quale testa tu posti una patch simile. il fatto che nel tuo caso (notata la sottolineatura?) non abbia dato problemi, non vuol dire che rimuovere le chiamate sys_fsync* dal kernel sia una cosa sana.
> 
> non hai pensato che forse al file system può anche stare bene, ma alle strutture del kernel (e degli scheduler I/O) no?

 

Eh? Ma cosa centra sys_fsync() con gli scheduler I/O? sys_fsync() è una chiamata esposta dal kernel per l'utilizzo da parte delle applicazioni userspace, non viene utilizzata all'interno del kernel space. Quindi non vedo come possa influenzare le "strutture del kernel" (qualunque cosa tu intenda dire). sys_fsync() è utilizzata dalle applicazioni quando si vuole essere sicuri che uno o più file siano fisicamente scritti su disco (e non siano "volatili" sul buffer). Tipicamente ciò accade all'uscita dell'applicazione, o come conseguenza di qualche comando tipo "Salva File".

 *Quote:*   

> forse sarò io troppo quadrato, ma penso che queste pratiche che consigliano più o meno direttamente agli utenti anche inesperti patch non standard e non approvate da chi è preposto a farlo sia molto dannoso.

 

Primo: io non ho consigliato niente a nessuno. Mi è stata chiesta una delucidazione ed io l'ho data. Secondo: non vado in giro a dire "applicate questa patch e il vostro PC volerà!!! LOLOL!!!!11111 OMFG!!!!!", è semplicemente uno (sporco) hack per ovviare ad alcune temporanee carenze di reiser4 performance-wise. Terzo: mi pare di avere messo sufficientemente in chiaro i rischi collegati a questa patch nel mio post iniziale.

Spero di essere stato abbastanza chiaro...

----------

## .:chrome:.

 *yardbird wrote:*   

> Eh? Ma cosa centra sys_fsync() con gli scheduler I/O?...

 

l'I/O va comunque schedulato. ovvio che le azioni che riporti tu hanno diritto di prelazione, ma ho seri dubbi sul fatto che il normale lavoro dello scheduler, che in considzioni normali tiene conto anche di questi fatti, non venga perturbato eccessivamente da una modifica di quel tipo.

se è veramente una carenza di ReiserFS, e se qualcuno ha scritto quelal patch, perché non è stata inclusa nel kernel?

permetti che mi venga qualche dubbio circa la sua bontà...

per il resto... ho solo fatto un'osservazione. è vero che non hai consigliato (ho scelto male le parole, prima) però continuo a dire che, non conoscendo la bontà della patch (hai ammesso di trascurare i problemi di scheduling I/O), non mi sembra il caso di pubblicizzarla troppo. tutto qui

----------

## mambro

Bè io ho solo chiesto per curiosità.. non penso proprio che proverò la patch perchè non sono in grado di valutare da solo la "bontà" dell'hack e in mancanza di una approvazione largamente condivisa (come per i set di patch "famosi")   preferisco astenermi  :Wink: 

----------

## yardbird

 *k.gothmog wrote:*   

> se è veramente una carenza di ReiserFS, e se qualcuno ha scritto quelal patch, perché non è stata inclusa nel kernel?
> 
> permetti che mi venga qualche dubbio circa la sua bontà...

 

Beh, proprio perché è un hack "quick & dirty". Il problema va ovviamente risolto in altro modo, ma da quanto ho capito tutto il lavoro di ottimizzazione è rimandato in attesa dell'inclusione di Reiser4 nel kernel vanilla.

 *Quote:*   

> per il resto... ho solo fatto un'osservazione. è vero che non hai consigliato (ho scelto male le parole, prima) però continuo a dire che, non conoscendo la bontà della patch (hai ammesso di trascurare i problemi di scheduling I/O), non mi sembra il caso di pubblicizzarla troppo. tutto qui

 

Ok, per me non c'è problema ad ammettere che quella patch è malvagia. Anzi, ci metto un ulteriore bel disclaimer, ok?  :Smile: 

----------

## matttions

ho messo su anche Xorg 7.0 ..

finchè mi limito alle ombre è okkey, se inizio a buttare le trasparenze quà e là è la fine  :Smile: 

cmq volevo sapere ..

La software-suspend2 a chi ha lo Xorg 7.0.0_rc2-r1 funziona bene ?

----------

## !equilibrium

riporto la mia esperienza in merito:

- Xorg 7.0 RC3 (cvs)

- driver SIS con supporto EXA completo (cvs)

- QT4 (snapshot cvs di ieri)

- KDE 3.5

che dire, i widgets delle QT4 vengono disegnati a video con openGL tramite la GPU e non più tramite emulazione software, questo riduce drasticamente i tempi per generare le finestre/bottoni/widgets ecc ecc ecc.

tutto il desktop ne risulta ultra leggero, veloce e molto reattivo, ma soprattutto molto conservativo come RAM occupata (altra nuova caratteristica delle QT4). Prima dell'uso di EXA e delle QT4, il top mostrava sempre il processo di X con un'attività normale tra il 4/5% della cpu, con picchi dell'ordine del 10/15% quando doveva disegnare finestre con molti widgets. Con il supporto EXA non ho mai visto il processo X andare oltre il 2%  :Cool:  (e ho testato il tutto su un notebook scassone con una CPU VIA 733Mhz)

Ci stiamo avvicinando sempre di + ad un DE completamente accellerato openGL (come già avviene per MACOSX e Win) e questo non può che giovare a tutta la community opensouce e ad attirare nuove adepti.

p.s.: le QT4 non sono ancora pienamente supportate da KDE 3.5 per tanto potreste avere grossi problemi di stabilità del DE dovuto a questo, ergo, vi sconsiglio di usarle se non per test o usi didattici, non per un uso quotidiano.

----------

## yardbird

 *DarkAngel76 wrote:*   

> riporto la mia esperienza in merito:

 

Uh? Guarda che le Qt4 saranno supportate solo con KDE4, non puoi essere riuscito a compilare KDE 3.x con quelle. Ci sono grossi cambiamenti API/ABI. Da quanto ne so nel KDE4 cvs hanno portato a Qt4 il desktop base e poco più, la maggior parte dei programmi ancora non funziona. E comunque KDE3.5 è in un altro branch di sviluppo....

----------

## !equilibrium

 *yardbird wrote:*   

> Uh? Guarda che le Qt4 saranno supportate solo con KDE4, non puoi essere riuscito a compilare KDE 3.x con quelle. Ci sono grossi cambiamenti API/ABI. Da quanto ne so nel KDE4 cvs hanno portato a Qt4 il desktop base e poco più, la maggior parte dei programmi ancora non funziona. E comunque KDE3.5 è in un altro branch di sviluppo....

 

infatti non ho detto che tutto KDE 3.5 funziona (vedi la mia nota in fondo al mio post), anzi tutt'altro, i miei test si riferiscono ad un'applicazione scritta da me e che ho convertito a QT4 per vederne gli effetti.

----------

## Ic3M4n

non me ne intendo perchè è un po' che non bazzico più su sistemi win, però io sapevo che con win tutto quello che riguarda la grafica, quindi desktop e finestre varie fosse completamente gestito dal processore, quindi niente utilizzo della gpu della scheda video. utilizzata solamente per giochi o applicazioni specifiche in ambito grafico. sbaglio?

----------

## Ciccio Bueo

 *Ic3M4n wrote:*   

> non me ne intendo perchè è un po' che non bazzico più su sistemi win, però io sapevo che con win tutto quello che riguarda la grafica, quindi desktop e finestre varie fosse completamente gestito dal processore, quindi niente utilizzo della gpu della scheda video. utilizzata solamente per giochi o applicazioni specifiche in ambito grafico. sbaglio?

 

anche a me risultava così, solo con "areo" viene utilizzata l'accelerazione grafica..

----------

## Apetrini

Si ma non è detto che un SO operativo che usa solo la cpu per le finestre sia meno performante di uno che usa l'accelerazione 3d.

Vi porto un esempio concreto...

Installando MacOs per x86 sul mio vaio all'epoca non c'erano i driver ati x86 per cui usavo i generici vesa per settare la risoluzione a 1024x768. Vi assicuro che anche senza accelerazione (e senza driver) riuscivo ad avere le trasparenze native sulle finestre (quindi eleborate interamente dalla cpu) cosa che ora come ora con EXA e il nuovo xorg non ho(nel senso che funzionano ma sono state piu fluide le trasparenza di mac usando solo cpu).

Quindi secondo me è sempre e solo questione di codice....

----------

## Ic3M4n

beh... semplicemente i dev di X hanno pensato bene di far fare il lavoro sporco alla gpu, esonerando il processore da calcoli inutili. essendo ancora una cosa a livello embrionale è logico che ancora non funzioni correttamente.

----------

## Ciccio Bueo

dopo l'ultimo update alla mia mata gentoo xorg non và più.... non so se sia il passaggio al nuovo gcc (3.4), ma visto che c'ero pensavo di passare a xorg 7.0, tanto anche prima usavo l'instabile 6.x, volevo sapere se qualcuno la sta usando e gli funziona... devo usarla su una via epia.   :Rolling Eyes: 

----------

## .:chrome:.

ora come ora è meglio di no.

siamo in un periodo di transizione, e installare X modulare proprio ora vuol dire andare incontro ad un mucchio di rogne. i dettagli sono spiegati sulla GWN, dove parla della nuova categoria "virtual"

----------

## Ciccio Bueo

grazie del consiglio.

mi sa che dovrò ri-patchare xorg per usare la epia.   :Crying or Very sad: 

----------

## xbb

ho provato initng, alcuni script non funzionano, altri li devi scrivere da solo...

Secondo me parallel startup su gentoo è la migliore soluzione  :Smile: 

Uso già da diverso tempo Xorg 6.9 (monolitico) installato con l'ebuild di nxsty (https://forums.gentoo.org/viewtopic-t-396898.html), sembra molto stabile, non mi ha mai dato nessun problema fino ad adesso.

----------

## matttions

initng è sotto forte sviluppo  :Smile: 

In effetti 3 volte su 4 s'incasina  :Smile: 

Xorg 7.0 installato in modo modulare non dà problemi quà.

[non sono riuscito ancora a riabilitare il Direct Rendering tuttavia.. ma nn ho nemmeno avuto troppo tempo da dedicargli.]

----------

## Ciccio Bueo

scusa, che scheda video usi?

----------

## matttions

ati Mobility Radeon 9000  :Sad: 

costruito con la flag 

```
dri
```

fatto eselect.

ma nn và.

Qualcuno con la mia stessa scheda c'è riuscito ?

----------

## .:chrome:.

 *xbb wrote:*   

> ho provato initng, alcuni script non funzionano, altri li devi scrivere da solo...
> 
> Secondo me parallel startup su gentoo è la migliore soluzione 
> 
> Uso già da diverso tempo Xorg 6.9 (monolitico) installato con l'ebuild di nxsty (https://forums.gentoo.org/viewtopic-t-396898.html), sembra molto stabile, non mi ha mai dato nessun problema fino ad adesso.

 

concordo sotto ogni aspetto. l'unica differenza è che io non ho usato, per X11, ebuild in overlay, ma quello distribuito in portage

----------

## matttions

non riesco a far andare l'accellerazione con le OpenGL.

Sui log di Xorg ho questo :

```
mattions@the-tux ~ $ cat /var/log/Xorg.0.log | grep glx

(II) LoadModule: "glx"

(WW) Warning, couldn't open module glx

(II) UnloadModule: "glx"

(EE) Failed to load module "glx" (module does not exist, 0)

```

idee ?

[a che punto il vostro link openGL ?]

----------

## Ic3M4n

preso da un attimo di follia ieri ho messo xorg-7.0-rc3 e (che culo) oggi è uscita la rc4   :Crying or Very sad: 

in pratica mi sono imbattuto nella gestione dei virtual, blocchi su tutto, un macello insomma. credo proprio che per il momento rimarrò con il monolitico. ci sono ancora troppe cose strane che non vanno per il momento.

----------

## .:chrome:.

 *Ic3M4n wrote:*   

> preso da un attimo di follia ieri ho messo xorg-7.0-rc3 e (che culo) oggi è uscita la rc4  
> 
> in pratica mi sono imbattuto nella gestione dei virtual, blocchi su tutto, un macello insomma. credo proprio che per il momento rimarrò con il monolitico. ci sono ancora troppe cose strane che non vanno per il momento.

 

ehm... è prorpio quello a cui mi riferivo  :Confused: 

----------

## Ic3M4n

si, lo so... solo che sai com'è... uno deve provare sulla sua pelle prima di rendersi conto che gli altri hanno ragione!   :Wink: 

comunque ero curioso di vedere com'era il tutto, anche perchè il programma in se è usabile, non ho avuto strani problemi, anzi direct rendering funzionante, un giorno di utilizzo intensivo e nessun problema etc etc. l'unica cosa è che mi son trovato con emerge bloccato e la necessità di aggiornare alcune cose. quindi per il momento ho rimandato, tanto il ritorno a quellomonolitico è abbastanza semplice, ovvero: non è un viaggio di sola andata verso il modulare.

----------

## .:chrome:.

 *Ic3M4n wrote:*   

> comunque ero curioso di vedere com'era il tutto, anche perchè il programma in se è usabile, non ho avuto strani problemi, anzi direct rendering funzionante, un giorno di utilizzo intensivo e nessun problema etc etc. l'unica cosa è che mi son trovato con emerge bloccato e la necessità di aggiornare alcune cose. quindi per il momento ho rimandato, tanto il ritorno a quellomonolitico è abbastanza semplice, ovvero: non è un viaggio di sola andata verso il modulare.

 

concordo. X modulare funziona molto bene. la riscrittura del codice ha dato i suoi effetti. sembra più piccolo e snello. il codice non l'ho ancora guardato, ma il pacchetto hard-masked non mi ha mai dato il minimo malfunzionamento, o quantomeno... niente che non si potesse sistemarein quattro e quattr'otto mettendo mano alle configurazioni.

è stata una bella fregatura l'introduzione del pacchetto virtual. mi ha costretto a fare il downgrade  :Sad: 

----------

## Ciccio Bueo

ciao belli, ho messo su xorg 7, e ovviamente non và una mazza, (lo so, è hard-masked), ma se aveste qualche dritta da darmi per farlo andare sarebbe bello...

allora, la mia scheda video è la stramaledetta via cle 266 della via epia, prima mettevo  come driver "via" e la cosa funzionava, ora no..

xorg mi dà i seguenti errori:

(sitentetizzo perchè devo ricopiare a manina)

-> error to load module vga (module not exist)

-> error to load module mouse (module not exist)

-> error to load module kbd (module not exist)

-> fatal server error ->no screens found

sto leggendo questo http://dev.gentoo.org/~spyderous/xorg-x11/migrating_to_modular_x_howto.txt e sto compilando xf86-input-mouse xf86-input-keyboard xf86-video-via.... sono sulla strada giusta?

immagino che dipenda da qualche flag, ma non so dove cercare...

grazie

----------

## Ic3M4n

no, non ci sono flag da settare, ti devi prendere a manina l'ebuild giusto e metterlo su. cmq, si, sei sulla strada giusta. la differenza tra il modulare e lo statico è che nel modulare xorg-x11 è molto minimale, tutto l'extra devi metterlo a manina, anche quei supporti che sembrano scontati ma che non lo sono, in quanto se ci pensi uno con un touchscreen che se ne fa del supporto per il mouse?

----------

## Ciccio Bueo

ok, grazie ora va, ho riemerso xf86-input-mouse xf86-input-keyboard xf86-video-via, e ora sembra andare. ma mi si è incasinato firefox-bin (non si avvia), ora controllo meglio, oppure mi sa che devo compilarlo invece del binario.

grazie   :Wink: 

----------

## .:chrome:.

oggi è uscito l'ebuild per X11-7.0. potrebbe essere la fine dei guai per chi ha X modulare

----------

## Apetrini

Sono uno di quelli che ha atteso questo momento a lungo perche la ATI aveva detto che avrebbe

fatto i driver con il supporto alle estensioni "composite" non appena il nuovo Xorg sarebbe uscito ufficialmente.

Ma pochi minuti fa ho guardato il sito e ...nada de nada. Spero non ci mettano tanto. Invece di fare i driver per Vista(che ancora deve uscire) potrebbero darsi una svegliata su questi benedetti driver linux...

----------

## .:chrome:.

 *Apetrini wrote:*   

> Sono uno di quelli che ha atteso questo momento a lungo perche la ATI aveva detto che avrebbe
> 
> fatto i driver con il supporto alle estensioni "composite" non appena il nuovo Xorg sarebbe uscito ufficialmente.
> 
> Ma pochi minuti fa ho guardato il sito e ...nada de nada. Spero non ci mettano tanto. Invece di fare i driver per Vista(che ancora deve uscire) potrebbero darsi una svegliata su questi benedetti driver linux...

 

il rilascio di X11-7.0 è una cosa di pochissimi giorni fa. primasi avevano le varie RC

dai tempo.

visto che hai installato il modulare, non hai provato ad usare i driver open?

----------

## Apetrini

Attualmente ho su i driver open, devo dire che EXA gira relativamente bene, certo ho dovuto disabilitare l'antialiasing dei font...

Spero sempre nei driver proprietari perche sono piu performanti...

----------

## .:chrome:.

 *Apetrini wrote:*   

> Attualmente ho su i driver open, devo dire che EXA gira relativamente bene, certo ho dovuto disabilitare l'antialiasing dei font...
> 
> Spero sempre nei driver proprietari perche sono piu performanti...

 

abbi pazienza... non sono in ~ per niente, tutti quegli aggeggi

e abbi fiducia nella struttura modulare: l'hanno fatta apposta per accelerare lo sviluppo

----------

## Apetrini

Siccome ho avuto problemi con il nuovo blender 2.40 ho dovuto mettere su i driver ATI proprietari (sto usando Xorg 7.0) e devo dire che anche se non supportano le estensioni composite i 8.20.8 funzionano bene con Xorg 7.0. 

Volevo solo segnalarlo....

----------

## Dr.Dran

Volevo chiedere una cosa... per xorg 7.0 sono anche considerate le estensioni xgl? E' una domanda da nubbio   :Razz:   :Very Happy: 

Ciauz   :Very Happy: 

----------

## cloc3

Ho compilato su una installazione sperimentale xorg (stabile) con gcc-4.1 ed ho avuto una sensazione di alleggerimento del sistema che razionalmente non mi aspettavo. gentoo-box superaccelerata. glxgears (lo so, non sono un benchmark) da 3800 fps a 4200 fps.

Non ci credo troppo. Secondo voi, dove sta l'inganno?

----------

## .:chrome:.

non credo che il merito sia di gcc, quanto dei nuovi driver di X11 modulare. stanno riscrivendo tutto quanto, compresa l'interfaccia verso il server grafico, il processore e la memoria.

spero che non ci voglia molto perché possa diventare stabile, in portage, ma dubito che uscirà dall'expermental prima del rilascio della versione 7.1

----------

## cloc3

 *k.gothmog wrote:*   

> non credo che il merito sia di gcc, quanto dei nuovi driver di X11 modulare. 

 

```

s939 ~ # emerge -pv xorg-x11

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] x11-base/xorg-x11-6.8.2-r6  USE="bitmap-fonts dlloader nls opengl pam truetype-fonts type1-fonts xprint xv -cjk -debug -dmx -doc -font-server -insecure-drivers -ipv6 -minimal -nocxx -sdk -static" 0 kB

```

Dicevo xorg stabile. Con gli stessi driver che prima erano compilati con gcc-3.4.

Naturalmente parlo a livello di sensazione epidermica, e immagino che scoprirò presto qualche inghippo.

Ma per ora, dico quello che vedo.

----------

## .:chrome:.

perdonami, non avevo capito.

essendo in questo thread, ho pensato si trattasse del server modulare

----------

## cloc3

 *cloc3 wrote:*   

> glxgears (lo so, non sono un benchmark) da 3800 fps a 4200 fps.
> 
> Non ci credo troppo. Secondo voi, dove sta l'inganno?

 

Ecco. gcc4.1 non centra niente.

Ho cambiato kernel (2.6.16-r1) e glxgears è tornato 3800.

----------

