Fedora Core 2 (Tettnang) - Page 2

J'avais pourtant fait un update avec 3 releases d'écart (RHL 7.3 -> FC1) avec succès...
Peut-être que ma base de donnée RPM est corrompue? Je devrais essayer un rpm --rebuilddb...
Peut-être aussi que mon ramdisk était trop petit tout simplement. Les CDs d'installation utilisent ramdisk_size=8192, et j'ai oublié de mettre ça pour les 2 méthodes d'installation sans CD que j'ai essayés.
Je vais faire d'autres essais demain.

bidouillage pawa..

Je me suis retrouvé avec une glibc-common incomplète. Heureusement que j'ai trouvé enfin sur le web comment réinstaller un RPM installé qu'à moitié sans le supprimer:

rpm -e --justdb --nodeps glibc-common
rpm -Uvh .../glibc-common_....rpm

raaa


un

emerge rsync && emerge -Dua system && emerge --Dua world

c'est tellement plus simple ^^

JackosKing VNR :
apt-get dist-up...

Je vais peut-être le faire après tout... Voici les instructions pour les Fedoriens: http://laiskiainen.org/apt/misc/fc1-fc2-apt-hints.txt (et la même chose avec yum: http://linux.duke.edu/%7Eskvidal/misc/fc1-fc2-yum-hints.txt).

Mais je vais d'abord attendre pour voir s'il n'y a vraiment pas de solution à mon problème avec anaconda.

Voilà, je suis enfin sous FC2! apt-get dist-upgrade rulez.

suuuuuuuuuuuuuuxxxxxxxxxxxxxxxxxxxxxxxxx

Oula, là, non seulement tu me fâches, moi, mais aussi tous les utilisateurs de Debian ici (et il y en a pas mal)... Alors si tu pouvais éviter le flamebait?

oué, attention Vark tu vas fâcher nitro

Cesse donc d'être aussi naïf Kevin...

Voilà la configuration idéale pour faire marcher toutes les applications avec son:

/dev/dsp  artsdsp
legacy   ---------> aRts
programs                 \
                          >--> ESD --> ALSA --> matériel
                         /
                     SDL

Les raisons de mes choix:
* Une et une seule application peut utiliser ALSA en même temps. Ça doit être ESD parce qu'il ne gère rien d'autre. (La version de FC2 est compilée pour ALSA seulement, donc on ne peut pas utiliser artsdsp dessus.)
* Le driver aRts de SDL plante dès l'utilisation, donc pas le choix.
* esddsp marche pas ou très mal. (Avec Audacity, j'ai du son horrible suivi d'un plantage.) J'utilise donc artsdsp.

y a pas à dire c'est bien foutu

Chez moi, aRts+ALSA suffisent, le driver aRts de SDL marche très bien, le plugin pour xmms aussi, bref, on peut se passer d'ESD.

faudra que je retente le noyau 2.6, demain, en bootant sous linux...
la dernière fois, j'avais ni le son, ni la molette de la souris...
depuis, j'ai rajouté (sous le 2.4) la gestion de à la fois la souris et le touchpad...
faudra que je vois si la molette marche, maintenant, sous 2.6... et que je réussisse à mettre le son...
et après, on passera à l'acpi (pas gagné... la dernière fois, j'ai essayé de mettre le pc en veille => pour le sortir de veille, y'a fallu que je le débranche, et que je dégage la batterie...)

L'ACPI est le gros point faible de Linux sur les portables, c'est pas sûr du tout que tu puisses le faire marcher.

Kevin Kofler :
Voilà la configuration idéale pour faire marcher toutes les applications avec son:

/dev/dsp  artsdsp
legacy   ---------> aRts
programs                 \
                          >--> ESD --> ALSA --> matériel
                         /
                     SDL

Ne serait-ce pas plus simple d'utiliser SDL-OSS avec artsdsp, afin d'éviter d'avoir deux sound servers qui tournent (plus besoin de ESD) ?

nitro
: Chez moi, aRts+ALSA suffisent, le driver aRts de SDL marche très bien, le plugin pour xmms aussi, bref, on peut se passer d'ESD.

Jusqu'au jour où tu voudras avoir du son dans une application GNOME qui ne connaît que ESD.

squale92> Pour la souris et le noyau 2.6, essaye /usr/sbin/fix-mouse-psaux.

nitro
:

Kevin Kofler :
Voilà la configuration idéale pour faire marcher toutes les applications avec son:

/dev/dsp  artsdsp
legacy   ---------> aRts
programs                 \
                          >--> ESD --> ALSA --> matériel
                         /
                     SDL

Ne serait-ce pas plus simple d'utiliser SDL-OSS avec artsdsp, afin d'éviter d'avoir deux sound servers qui tournent (plus besoin de ESD) ?

J'ai aussi besoin de ESD pour FreeCiv, que je n'ai pas réussi à faire tourner avec l'option SDL et artsdsp. Et des trucs GNOME veulent aussi du ESD.

L'ACPI est le gros point faible de Linux sur les portables,

oué, j'ai déjà remarqué
disons que ça fait drole quand même appuyer pdt quelques secondes sur le bouton power n'éteint pas le pc... il me semble que c'est la première fois que ça me le fait, depuis environ un an, je dirais...

c'est pas sûr du tout que tu puisses le faire marcher.

dommage... la mise en veille prolongée (copie de la RAM sur le dur, puis extinction du pc) m'interesse grandement... c'est une des choses merveilleuses sous windows, par rapport à linux...

squale92> Pour la souris et le noyau 2.6, essaye /usr/sbin/fix-mouse-psaux.

j'essayerai


(bon, ça fait deux fois que je me couche, deux fois que je me releve parce que j'arrive pas à m'endormir ... vais retenter )

Kevin Kofler :
Oula, là, non seulement tu me fâches, moi, mais aussi tous les utilisateurs de Debian ici (et il y en a pas mal)... Alors si tu pouvais éviter le flamebait?

Tiens, j'avais oublié encore un système de son (oui, un sixième! ) dans mon petit diagramme: GStreamer. Voilà comment le router dans ESD:
gconftool-2 -s /system/gstreamer/0.8/default/audiosink -t string esdsink

Donc voici le diagramme complété:

/dev/dsp  artsdsp 
legacy   ---------> aRts 
programs                 \ 
              GStreamer -->--> ESD --> ALSA --> matériel 
                         / 
                     SDL

beuh pourquoi c'est compliqué ? j'ai jamais eu de problème de son sous linux, ni avant avec ma vibra 16 isapnp ni maintenant avec ma puce via intégrée à la carte-mère, il suffit d'avoir les bons modules du noyau et les bons alias dans modprobe.conf en ce qui me concerne

Le problème n'est pas au niveau des drivers, mais au niveau de toutes les différentes surcouches qu'il y a. Et le fait que 2 applications peuvent avoir le son en même temps seulement à travers aRts ou ESD.

ah ok

Kevin Kofler
: Et le fait que 2 applications peuvent avoir le son en même temps seulement à travers aRts ou ESD.

Uniquement si la carte son (ou le driver) ne supporte pas le mix hardware. Avec une SB Live par exemple, pas besoin de aRts ni ESD pour avoir des sons en même temps.

ou a travers alsa directement, avec des vraies cartes son (module emu10k1 par exemple) qui supportent un mixage matériel, donc plusieurs sorties son en meme temps uniquelment sur alsa....
Beaucoup d'applis utilisent a l'heure actuelle alsa sans problemes... ce qui fait qu'on peut se passer de tout l'autre bazar immonde :
xmms -> plugin output alsa
mplayer -va alsa9
xine -> sortie alsa aussi
donc bon... autant simplifier

Et pour celles qui ne supportent pas alsa, y a l'emulation oss d'alsa qui marche très bien...

Perso, sur mon systeme, c'est alsa only, et ça marche très bien, pas de arts, pas de esd, pas de gstreamer...

Oui, on pourrait très bien tout faire avec alsa, même avec les cartes son qui ne mixent pas en hardware (plugin dmix), mais le problème c'est que les applis KDE utilisent aRts et les applis GNOME utilisent ESD.

on peut aussi ne pas utiliser kde ni Gnome
Mais sinon, pour kde, on peut spécifier un player utilisé pour le son systeme, et mettre aplay par exemple, donc ne jamais utiliser arts...

Ca ne marche que pour les sons de notification... les applis KDE utilisent généralement aRts directement.