Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

vlc 0.8.6d: vlc-core et java-vlc

Nicolas Chauvet

Deux nouveaux paquets font leur apparitions pour vlc. vlc-core (séparation entre vlc et vlc-core des fichiers ne nécessitant pas les bibliothèques Xorg) et java-vlc une interface de liaison pour java (encore en stade de développent).

vlc-core: L'intérêt de la séparation entre vlc et vlc-core réside principalement dans l'utilisation serveur. L'installation de vlc-core permet d'utiliser vlc sans installer les dépendances Xorg et autres wxGTK26. Cette séparation n'est disponible qu'à partir de Fedora 8 avec le dépôt livna. La mise à jours est transparente si vous utilisez déjà vlc...
Si vous installer vlc-core, puis vlc, il faut faire attention à la génération du cache. Si il y a des problèmes, il peut être utile de le supprimer en faisant: (pour chaque utilisateur).

 rm -rf ~/.vlc/cache

java-vlc: il devrait être possible d'utiliser cette interface native de liaison pour java... Certains projets comme Homeplayer pourrait en bénéficier... Pour l'instant cette interface est encore en développement. A noter que python-vlc est disponible pour python.

vlc-plugins-dc1394: Ce plugins n'est disponible que depuis le dépôt kwizart.-testing Il permet le contrôle des périphériques vidéo firewire à partir de vlc, mais ne fonctionne qu'avec l'ancienne pile firewire ieee1394...(voir ici pour l'activer). Il pourrait être envisageable d'utiliser libdc1394-2 qui supporte la pile juju, mais pour l'instant la nouvelle API n'est pas supportée.

Quelques commandes utiles et autres problèmes connus avec vlc:
Lorsque il y a un problème avec un plugins interne vous pouvez utiliser cette commande:

 vlc -list -vvv --no-plugins-cache

Ce qui donne par exemple:
main private warning: cannot load module `/usr/lib64/vlc/access_output/libaccess_output_shout_plugin.so' (/usr/lib64/libshout.so.3: undefined symbol: speex_packet_to_header)
Cette erreur indique que libshout n'as pas été compilée avec speex et que par conséquent vlc n'arrive pas à charger libshout... (le problème est en cours de correction).

Problèmes de sons stridents avec pulseaudio
Il est parfois délicat de faire fonctionner pulseaudio après un upgrade de F-7 à F-8 car il faut vérifier que tout les fichiers de configurations sont à jours... (remplacer les fichiers .rpmnew créés dans /etc...)

Utilisation du mutliposte free
Lors de la diffusion d'un flux multimédia par le multiposte, la bibliothèque live555 n'arrive parfois pas à trouver l'adresse ip source... Elle utilise d'abord le fichier /etc/hosts qui doit contenir l'ip du localhost (utilisez une configuration dhcp par adresse mac si nécessaire pour la fixer)... Il est possible aussi d'ouvrir le port udp 15947 (en plus de la plage udp 32000-34000 habituelle).

Deux versions de hostapd pour le mode point d'accès wifi

Nicolas Chauvet

La meilleure solution pour faire fonctionner le mode point d'accès (Master) avec une interface wifi reste encore d'utiliser une carte Atheros (pilote madwifi). Pour les cartes ayant un pilote utilisant mac80211, le support ne devrais pas être stabilisé avant le kernel 2.6.25, je propose une version de test sur ce dépôt.

Hostpad est un daemon utilisé par les serveurs d'authentification. C'est cet utilitaire qui va gérer le point d'accès wifi (Master). Seuls certains pilotes wifi permettent d'utiliser ce mode. Madwifi est pour l'instant la solution la plus efficace...
La version 0.5.9 de hostapd (stable) est disponible dans le dépôt kwizart, alors que la version de 0.6.1 (développement) dans kwizart-testing, permet d'essayer de faire fonctionner avec les pilotes utilisant mac80211.
Il faut installer le dépôt kwizart au préalable.

Pour installer hostpad 0.5.9 pour madwifi

 yum --enablerepo=kwizart install hostapd


Pour installer hostpad 0.6.1 (à tester pour mac80211)

 yum --enablerepo=kwizart-testing install hostapd


Configuration pour madwifi
Le module madwifi du dépot livna crée par défaut l'interface en mode géré (Managed), pour créer l'interface en mode master automatiquement au démarrage, il faut utiliser ce paramètre dans le fichier /etc/modprobe.d/madwifi
options ath_pci autocreate=ap
Une autre solution consiste à détruire l'interface en mode géré, puis en recréer une en mode point d'accès:
wlanconfig ath0 destroy
wlanconfig ath0 create wlandev wifi0 wlanmode ap
Une fois l'interface créée en mode master il faut configurer le fichier /etc/hostapd/madwifi.conf pour ajouter vos paramètres (clef wep/wpa utilisée, nom du réseau, etc). Il est aussi nécéssaire de bien paramétrer l'interface ath0 en mode statique de préférence, et de créer un pont réseau (interface br0 par défaut), voire utiliser un serveur dhcp... Je ne m'étend pas sur ces configurations, vous trouverez une documentation à jours sur la doc Fedora-fr.org:
Configuration du mode Master
Mise en place d'un serveur DHCP Simple

Cinelerra disponible pour F-8

Nicolas Chauvet

Le logiciel de montage video pour linux Cinelerra est disponible pour Fedora 8 pour les architectures x86 et x86_64.

Pour installer Cinelerra:
(Installer le dépôt kwizart au préalable.)

yum --enablerepo=kwizart install cinelerra

Si vous voulez utiliser le firewire, il est possible que les périphériques ohci 1.0 ne soient pas supportés: (voir Couche compatibilité ieee1394 pour Fedora 8 ). Il est peu probable que je porte et maintienne cette couche pour Fedora 7, l'intention originale était de permettre une solution de replie au utilisateurs de Fedora Core 6 ("fin de vie" prévue pour le 8 Décembre).

Il est possible que certaines améliorations seront apportés progressivement pour aboutir à une version tel qu'elle sera disponible sur RPM Fusion. En particulier l'utilisation de syslog-ng pour activer l'option shhmax du kernel nécéssaire pour utiliser cinelerra (actuellement ce paramètres est ajouté au fichier /etc/rc.local). Et éventuellement la correction d'une bibliothèque pour la conformité avec la sécurité du système (selinux pourrait empêcher le chargement de cette bibliothèque en attendant).

Il est à noter que cette version utilise la bibliothèque ffmpeg partagée (donc provenant de RPM Livna). Ne mélangez donc pas les dépôts tiers incompatibles avec livna.

Fedora 8 et Sound Juicer

Thierry D

sj.resized.png Quel plaisir de pouvoir écouter de la musique sur son ordinateur quand nous sommes entrain de travailler ou de nous divertir sur internet.

Rien de plus pratique que de convertir nos CD audio pour pouvoir les écouter directement avec notre Rhythmbox préféré !
Sound Juicer est donc là pour convertir tous nos CD audio dans le format que l'on souhaite de manière simple et extrêmement rapide.

L'installation de Sound Juicer est vraiment très simple grâce à YUM

# yum install sound-juicer

Après avoir introduit le CD audio que l'on désir ripper il suffit de démarrer Sound Juicer qui va automatiquement reconnaitre les pistes audio de votre CD afin de pouvoir sélectionner celles que l'on souhaite ripper.

Les préférences de Sound Juicer permettent de pouvoir affiner un peu plus la façon dont sera converti la piste audio, pour ma part je souhaite avoir un format .ogg.

Une fois cela fait il suffit de lancer l'extraction des pistes désirées.

Et voilà on allume Rhythmbox et on peut enfin écouter notre CD.

Aviez vous aussi remarqué une nouveauté sur Fedora 8 lorsque que l'on pointe la souris sur un fichier .mp3 un icône apparait et la lecture du .mp3 commence ! magique :)

A+

Fedora et l'Install'party de Paris 12-2007

Thierry D

banniere_paris2008.png

Les ambassadeurs Francophone du projet Fedora vous invitent à une Install'Party qui se déroule à Paris (Cité des Sciences de la Villette) le Samedi 8 décembre 2007, de 12h00 à 18h00.

Que vous soyez débutant, confirmé ou non Linuxien, c'est la meilleure occasion pour pouvoir échanger vos avis, vos idées et vos suggestions avec les autres personnes participants au projet Fedora.

Des conférences se dérouleront tout au long de la journée dans la salle Agora afin de vous faire découvrir les principaux avantages de Fedora. Bien entendu vous pouvez venir avec votre matériel afin qu'il y soit installé Fedora et que l'on puisse vous expliquer les bases de l'utilisation de votre nouveau système d'exploitation.

Vous pouvez vous inscrire à l'avance, soit pour aider les installations soit pour recevoir de l'aide pour une installation. Il est aussi possible d'organiser une conférence sur un thème précis, vous pouvez vous manifester ici.

Linuxien confirmé, ou débutant ou simple curieux n'hésitez pas, l'entrée est totalement gratuite, plusieurs ambassadeurs Francophone et plusieurs membres de la communauté Fedora-fr seront présent alors rencontrons NOUS :)

N'oubliez pas de vous inscrire ici si vous souhaitez nous rendre visite !

Date : Le Samedi 8 décembre 2007, de 12h00 à 18h00.
Lieu : Cité des sciences et de l'industrie. 30 avenue Corentin Cariou. 75019 Paris
Accès : Métro : ligne 7, station Porte de la Villette ou Bus : 75, 139, 150, 152, 249, PC
Plan d'accès : cliquez ici

Nous comptons sur votre présence !

Bip ennuyant...

Pierre-Yves Chibon

The sound on the console ... quit annoying...

Le bip dans la console.. un peu pénible

French version

Depuis Fedora Core 6 lors de l'installation on peut avoir dans la console un "bip" quelque peu pénible...

Sous Fedora 7 comme sous Fedora 8 je me suis retrouvé avec ce bip...

La solution pour s'en débarrasser fais partie des bugs commun de FC6 elle consiste à une simple commande à exécuter pour couper le sifflet du terminal :p

Je vous la livre en directe :

su -lc'modprobe -r pcspkr ; echo "install pcspkr :" >>/etc/modprobe.conf'

Enjoy !!

English version

Since Fedora Core 6 the PC speaker is enable by default... This is quite annoying when you are for example typing in your console...

I get this annoying bip on Fedora Core 6, Fedora 7 and now Fedora 8.

The solution to get rid of this is included on the common bugs for FC6.

There is the command to execute on the terminal to get his tranquility back :p

su -lc'modprobe -r pcspkr ; echo "install pcspkr :" >>/etc/modprobe.conf'

Enjoy !!

Fedora 8 et le support audio et vidéo avec Skype

Thierry D

skype.png il y a des problèmatiques récurrentes sur les systèmes d'exploitation Linux, c'est la possibilité de faire de la vidéo et de l'audio via un client de messagerie instantanée.

Quelques clients pouvaient le faire avec le protocole MSN de Microsoft comme Mercury ou encore Amsn.
Simplement le fonctionnement et la stabilité des ces fonctionnalités sont jamais très fiables et assez compliqués à configurer.

Alors des protocoles propriétaires existent et ont réussi à adapter parfaitement le fonctionnement de l'audio et de la vidéo, comme Skype à fait avec sa toute dernière version beta.

Il suffit d'installer la version beta de Skype pour Linux en la téléchargeant en cliquant ici.
Puis de se rendre dans le panneau de configuration pour activer sa webcam (voir la documentation pour configurer votre webcam sur Fedora) et le tour est joué !

Vous pouvez dès maintenant facilement voir et entendre votre correspondant :)

Vivement que Pidgin soit aussi capable de le faire et même avec Jabber si possible!

A+

Switcher bureau 3D

Nicolas Rodt ... ou comment passer en un clic d'un bureau 3D vers un bureau normal et inversement ?

On aime bien Compiz (fusion) et Beryl mais force est de constater qu'ils occasionnent encore parfois quelques ralentissements ou incompatibilités avec certaines applications. En un clic, grâce à une icône dans la zone de notification, il est désormais possible d'arrêter le bureau 3D et par suite de le relancer, puis de l'arrêter de nouveau, puis ... (ok, vous avez compris là) !

start3D   stop3D   quit3D

Il suffit de lancer le script switch3D.

Astuce : ce script fonctionne de manière optimale si vous avez activé le lancement automatique de Compiz / Beryl au démarrage de votre session avec demarrage3D.
download Télécharger le script : switch3D.

Fedora 8 vs Fedora 7 : comparaison des performances pour les versions 32 bits

Patrice Kadionik

Salut.


Ayant récemment installé Fedora 8 sur ma machine de bureau, et suite à mon précédent billet sur les mesures de performances de Fedora 7 64 bits par rapport à Fedora 7 32 bits, j'en ai profité pour comparer les performances de Fedora 8 à celles de Fedora 7 pour la version 32 bits uniquement.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.


Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.


Mon protocole de tests est le suivant :
  • Installation de Fedora 8 version 32 bits.
  • La machine est placée en niveau 3 (init 3).
  • 10 séries de tests avec UnixBench compilé sous Fedora 8 et exécuté sous Fedora 8.
  • 10 séries de tests avec UnixBench compilé sous Fedora 7 et exécuté sous Fedora 8.
Voici les résultats obtenus :


Fedora 8 version 32 bits :

UnixBench, indice global, version compilée sous Fedora 8 :

Série 1 : 771.3
Série 2 : 753.4
Série 3 : 782.7
Série 4 : 738.7
Série 5 : 754.5
Série 6 : 737.4
Série 7 : 755.2
Série 8 : 736.0
Série 9 : 752.3
Série 10 : 742.7

Moyenne : 752.4

UnixBench, indice global, version compilée sous Fedora 7 :

Série 1 : 757.9
Série 2 : 765.0
Série 3 : 745.9
Série 4 : 762.7
Série 5 : 748.1
Série 6 : 753.3
Série 7 : 751.4
Série 8 : 756.3
Série 9 : 751.9
Série 10 : 772.5

Moyenne : 756.5


Fedora 7 version 32 bits :

Il s'agit là des résultats issus des tests précédents. J'ai ici peu de mesures...

UnixBench, indice global, version compilé sous Fedora 7 :

Série 1 : 727.1
Série 2 : 724.3
Série 3 : 715.8

Moyenne : 722.4

Résultats :

Pour Fedora 8, on obtient un indice moyen de 752.4 pour UnixBench compilé sous Fedora 8 et un indice moyen de 756.5 pour UnixBench précédemment compilé sous Fedora 7 mais exécuté ici sous Fedora 8.

La version de gcc sous Fedora 7 était :
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-27)

La version de gcc sous Fedora 8 est :

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)


C'est bien la même version de compilateur dans les 2 cas pour ces tests. Il est donc normal de trouver un même indice moyen pour UnixBench compilé sous Fedora 7 ou Fedora 8 et exécutés sous Fedora 8 32 bits.

Pour Fedora 7, j'avais obtenu un indice moyen de 722.4 pour UnixBench.

On a donc un gain moyen brut de près de 4 % de Fedora 8 32 bits par rapport à Fedora 7 32 bits ((752.4/722.4-1) en %).

Conclusion :

Fedora 8 32 bits est de quelques pourcents plus performant que Fedora 7 32 bits.
Est-ce significatif ? Tout est maintenant dans les commentaires de ce résultat...

Tout d'abord, il faudrait augmenter le nombre de mesures pour affiner ce résultat afin de réduire l' "incertitude statistique" liée à la taille de l'échantillon.
D'où pourrait provenir cette différence ? Du noyau.
De quel noyau parle-t-on ? Du noyau Fedora. Le noyau Fedora est le noyau officiel (noyau vanilla) qui a ensuite été patché par les mainteneurs du projet Fedora.


Au moment de ces tests, le noyau Fedora 8 (basé sur le noyau vanilla 2.6.23) semble modestement un peu plus performant que le noyau Fedora 7 (basé sur le noyau vanilla 2.6.22).
On ne peut pas dire bien sûr que le noyau vanilla est 2.6.23 est plus performant que le noyau 2.6.22. Cela mérite des mesures... Peut-être un autre billet ?
Tout cela donne aussi à réfléchir sur tous les tests "X versus Y" que l'on voit fleurir dans la presse informatique. Peut-on être sûr d'un résultat sur une mesure, 10 mesures ?

Ah, les statistiques !

++

Fedora 8 : J+4. Un bilan

Patrice Kadionik

Salut.


Après une salve d'installations de Fedora 8, je peux faire le bilan personnel suivant :

  • Sur 3 installations de Fedora 8 sur des PC tous différents, je n'ai eu aucun soucis.
  • Sur l'installation de Fedora 8 sur mon portable Sony, j'ai eu un problème à l'installation avec le support du PCMCIA. Pour contourner le problème, j'ai passé l'option nopcmcia au boot de l'installation (voir ici). Après installation, je n'ai plus eu de problème. J'ai vérifié aussi le bon support du PCMCIA en testant le portable avec une carte Wifi PCMCIA.
  • Sur la mise à jour de Fedora 7 vers Fedora 8 d'un PC par un "yum upgrade", je n'ai rencontré aucun soucis. Bien que non préconisée, cette méthode marche et permet de garder la configuration courante de sa machine.

Pour ma part, tout va bien. Le loup-garou se porte bien...


++

Couche compatibilité ieee1394 pour Fedora 8

Nicolas Chauvet

Depuis Fedora 7 et l'utilisation de la pile firewire juju, certains périphériques (ohci 1.0) et autres bibliothèques (libdc1394) ne fonctionnent plus correctement avec Fedora... Voici une méthode pour installer l'ancienne pile ieee1394 avec Fedora 8. sans avoir à recompiler le kernel ni remplacer ces bibliothèques.
Since Fedora 7 and the new firewire stack (juju) some devices (with ohci 1.0) and others libraries (libdc1394) don't work as expected with Fedora... Here is a HOWTO to install the old ieee1394 stack with Fedora 8 without the need to recompile the kernel neither to replace official libraries...

Pour installer le dépôt kwizart pour Fedora 8 ( en x86 et x86_64 )

 su -
 rpm -ivh http://rpms.kwizart.net/kwizart-release-8.rpm
 yum --enablerepo=kwizart-testing install kmod-ieee1394 compat-libraw1394
 reboot

Il faut obligatoirement redémarrer pour que les bons modules soient chargés. Si lors du reboot, le module raw1394 n'est pas chargé, il faut faire

 su - 
 modprobe raw1394

Lorsque vous utilisez Fedora x86_64, il est possible que vous deviez installer manuellement la version compat-libraw1394.i386 (ou alors désinstaller la version i386 )

Si vous utilisez vlc, il est possible d'obtenir le plugins de contrôle firewire libdc1394 (Attention, vous devez utiliser le dépôt livna puisque je suis le mainteneur de ce paquet sur ce dernier).

 yum --enablerepo=kwizart-testing install vlc-plugins-dc1394
 exit
 vlc -list -vvv --no-plugins-cache |grep 1394

Cette dernière commande permet de reconstruire le cache de vlc et de vérifier que le plugin est bien disponible...

Je vais essayer de voir si d'autres modules peuvent être compilés pour utiliser libdc1394 (mplayer , avidemux voire cinelerra)

Fedora 8 et Compiz Fusion

Patrice Kadionik

Salut.


Avec l'arrivée de Fedora 8, j'ai bien sûr voulu retrouver l'environnement graphique Beryl, environnement graphique esthétiquement très beau mais joliment inutile.

Hélas, Beryl n'est plus, vive Compiz Fusion ! Alors, c'est quoi le lien entre Compiz, Beryl et Compiz Fusion ?

Je cite Wikipedia :

"Compiz Fusion est né suite à la réunification du projet originel Compiz et de son fork, Beryl. Cet événement a donné lieu à son nouveau nom : Compiz Fusion.

Compiz et Beryl étaient tous les deux des projets ayant pour objectif d'utiliser les capacités de la carte graphique pour gérer l'affichage des fenêtres, à la place du processeur central (CPU).

Le GPU, qui est alors davantage sollicité, permet d'obtenir des effets visuels impressionnants tout en libérant le CPU de cette tâche, qui peut donc se consacrer aux fonctions qui lui sont attribuées plus rapidement..."


Ah, là, c'est clair : on se met ensemble, on se quitte, on se réconcilie ! La vie, quoi ;-)


Pour la mise en oeuvre sous Fedora 8, il faut avoir les paquetages Compiz Fusion d'installés et faire quelques manipulations.

Il faut donc installer les paquetages en compiz et compiz-fusion (on s'assurera sur sa propre machine que l'on a bien la même liste de paquetages marqués "installed", sinon on les installera par un yum install) :
# yum list *compiz*
Installed Packages
compiz.i386                              0.6.2-3.fc8            installed      
compiz-fusion.i386                       0.6.0-5.fc8            installed      
compiz-fusion-extras.i386                0.6.0-1.fc8            installed      
compiz-fusion-extras-gnome.i386          0.6.0-1.fc8            installed      
compiz-fusion-gnome.i386                 0.6.0-5.fc8            installed      
compiz-gnome.i386                        0.6.2-3.fc8            installed      
compiz-kde.i386                          0.6.2-3.fc8            installed      
compiz-manager.noarch                    0.6.0-3.fc8            installed      
gnome-compiz-manager.i386                0.10.4-2.fc8           installed      
libcompizconfig.i386                     0.6.0-3.fc8            installed      
Available Packages
compiz-bcop.noarch                       0.6.0-1.fc8            fedora         
compiz-devel.i386                        0.6.2-3.fc8            fedora         
compiz-fusion-devel.i386                 0.6.0-5.fc8            fedora         
compizconfig-python.i386                 0.6.0-1.fc8            fedora         
gnome-compiz-manager-devel.i386          0.10.4-2.fc8           fedora         
kicker-compiz.i386                       3.5.4-4.fc8            fedora         
libcompizconfig-devel.i386               0.6.0-3.fc8            fedora         


Si l'on veut avoir le décorateur de fenêtres emerald, il faut l'installer :
# yum list emerald*
Installed Packages
emerald.i386                             0.5.2-2.fc8            installed      
emerald-themes.noarch                    0.5.2-2.fc8            installed      
Available Packages
emerald-devel.i386                       0.5.2-2.fc8            fedora  

Il convient d'installer CCSM (Compiz Config Settings Manager). CCSM sert à configurer de façon simple Compiz Fusion. Il est pour l'instant dans le dépôt updates-testing :
# yum --enablerepo=updates-testing install ccsm

Tout est prêt.


Si l'on veut utiliser le décorateur de fenêtres emerald, exécuter :
$ emerald --replace &
$ compiz --replace ccp &

Si l'on veut utiliser le décorateur de fenêtres GTK, exécuter :
$ gtk-window-decorator --replace &
$ compiz --replace ccp &

Pour configurer son environnement graphique, il faut alors utiliser CCSM, soit par le menu :
Système>Préférences>Apparence>CompizConfig Settings Manager
soit en exécutant la commande :
$ ccsm 




Un grand merci à Sat pour ses explications.
Pour de l'aide, rejoignez la communauté francophone Fedora-fr !

++

Additif du 10/11/07 :
Voici 2 screenshots du résultat :




Additif du 12/11/07 :
Certains ont pu avoir le message d'erreur suivant :
compiz (core) - Error: Failed to manage screen: 0
compiz
(core) - Fatal: No manageable screens found on display :0.0

Il faudra alors essayer la solution suivante :
$ emerald --replace &
$ LIBGL_ALWAYS_INDIRECT=1 compiz --replace ccp &


Fedora 8 : J-1

Patrice Kadionik

Salut.


Nous sommes plus qu'à J-1 de la disponibilité des images ISO de la nouvelle version de la distribution Linux Fedora : Fedora 8, qui sort officiellement le 8 novembre 2007.


Ne reste plus que quelques heures d'attente avant l'ouverture officielle des dépôts.
De longues heures...

++

Metamorphose 1.1.0

Pierre-Yves Chibon

rpm.png

Metamorphose 1.1.0 is out !

Metamorphose 1.1.0 est sorti !!

French version

Avec un peu de retard je tenais quand même à annoncer qu'une nouvelle version de metamorphose est sorti.

La version 1.1.0 prend en compte pas mal de changement que le programme a subit ces derniers temps dont une révision du makefile ainsi que la correction de certains bugs (notamment bug graphique sous kde).

Cette version est dispo en rpm directement sur la page du projet.

Cette version devrait cependant être la dernière version stable jusque la prochaine génération de métamorphose, métamorphose2 !

Testez, aimez (ou pas) et en cas de problème n'hésitez pas à rapporter !!


English version

I am a little bit late, but I would like to announce that the last version of metamorphose is out.

The newest version 1.1.0 take into account the changes that happened on the project since some month (review of the makefile, some bug (ie on KDE)) these bugs have been corrected on this version.

the release should be the last one before the new version of metamorphose, metamorphose2 !

On the site of the project the rpm of the newest version is available to download.

Try, enjoy (or not), and in case you face a problem do not hesistate to report it !!!

Galette 0.63 RC2

Johan Cwiklinski

La seconde Release Candidate pour la version 0.63 de Galette vient de voir le jour !

La « bête » est disponible sur l'espace de téléchargement de Gna! :
http://download.gna.org/galette/galette-0.63-RC2.tgz

N'hésitez pas à tester cette mouture, à la pousser dans ses derniers retranchements, et éventuellement à rapporter les bogues et autres coquilles que vous pourriez constater (en espérant qu'il n'y en aie pas :-p).

kmod-acer_acpi est disponible sur livna

Nicolas Chauvet

Le module acer_acpi est désormais disponible sur le dépôt livna. Ce module est utile pour certains portables Acer (principalement) ayant un interrupteur Wifi géré par le bios (implémentation WMI ). Voici la liste des modèles supportés (liste incomplète).

Pour des raisons spécifiques à l'implémentation de ce type d'interrupteur, ce module noyau pourrait avoir plus de difficultés à être intégré directement dans le noyau Linux... Le passage sur rpm.livna.org est donc une bonne chose pour la continuité du support..
Si vous avez un portable Acer vous pouvez vérifier que le votre modèle est prit en charge. Il peut être nécéssaire d'envoyer le "fichier DSDT" au mainteneur. (Voir SupportedHardware pour cela).
Certains modèles pourrait ne fonctionner qu'avec acerhk. Je reprendrai éventuellement le support de ce module (en 32bit uniquement) si certains ont un meilleur support avec celui-ci...

Quelques nouvelles de dernière minutes:

Fedora 7 version 64 bits vs Fedora 7 version 32 bits : comparaison des performances

Patrice Kadionik

Introduction :


En décembre 2003, avec la sortie de Fedora Core 1, j'avais voulu évaluer les performances de la version 32 bits par rapport à la version 64 bits. J'avais pour cela utilisé le benchmark UnixBench 4.1. Ma machine de l'époque était un Athlon 64 3200+ avec 2 Go de RAM. J'avais trouvé la version 64 bits près de 11 % plus performante que la version 32 bits.

En cette veille de sortie de la nouvelle version de Fedora (Fedora 8), et ayant une nouvelle machine toute nue au bureau, je me suis dit qu'il était temps de refaire des tests de comparaison.

La première chose est de savoir quels benchmarks utiliser pour cette comparaison.
Il existe un HOWTO sur la question : le Benchmarking HOWTO.

Il existe aussi le projet Linux Test Project qui propose une liste d'outils à disposition en fonction des tests que l'on veut faire. LTP ne convient pas car orienté tests d'implantation de Linux.
Parmi la liste, seuls les tests de performances m'intéressent. J'en ai sélectionné 2 pour leur facilité de mise en oeuvre (ce document m'a conforté après coup sur mes choix) :

LMbench  est une suite simple de mini benchmarks écrits en langage C/ANSI. Il permet de mesurer 2 points : temps de latence et débit.
LMbench permet donc de tester les points suivants :
  • Mesures de débit : lecture de fichier en cache, copie mémoire (bcopy), lecture mémoire, écriture mémoire, pipe, TCP.
  • Mesures de temps de latence : changement de contexte, networking, création de fichier et destruction, création de processus, support des signaux, overhead sur appel système, latence sur lecture mémoire.
LMbench ne fournit pas d'incide global.


UnixBench est un vieux benchmark développé pour le test des systèmes UNIX mais il reste toujours valable. Il fournit au final un indice global, ce qui est intéressant pour des comparaisons.

Pour ces tests, ma machine de bureau est équipée d'un quad core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

  • La version LMbench    utilisée est la version 3.0-a8.
  • La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :
  • Installation de Fedora 7 version 64 bits.
  • La machine est placée en niveau 3 (init 3).
  • 3 séries de tests avec LMbench.
  • 3 séries de tests avec UnixBench.
  • Installation de Fedora 7 version 32 bits.
  • La machine est placée en niveau 3 (init 3).
  • 3 séries de tests avec LMbench.
  • 3 séries de tests avec UnixBench.
Voici les résultats bruts obtenus :



Fedora 7, version 64 bits :


UnixBench, indice global :

Série 1 : 811.6
Série 2 : 835.1
Série 3 : 816.0


LMbench :

Séries 1, 2 et 3



Fedora 7, version 32 bits :



UnixBench, indice global :

Série 1 : 727.1
Série 2 : 724.3
Série 3 : 715.8


LMbench :

Séries 1, 2 et 3



Interprétation des résultats :


UnixBench :


Si l'on fait la moyenne des 3 séries, on arrive à :
  • Version 64 bits : 820,9
  • Version 32 bits : 722,4

La version 64 bits est donc 13,6 % plus rapide que la version 32 bits d'après l'indice global de UnixBench.


LMbench :

La comparaison est plus délicate car on n'a pas à disposition un indice global.
J'ai donc choisi quelques points de comparaison en faisant la moyenne des séries sur chaque point.

Communications par pipe en Mo/s :
  • Version 64 bits : 1775
  • Version 32 bits : 1194
La version 64 bits est 48,6 % plus rapide que la version 32 bits.


Lecture mémoire en Mo/s :
  • Version 64 bits : 4785
  • Version 32 bits : 4722
La différence est non significative (1,3 %).


Ecriture mémoire en Mo/s :
  • Version 64 bits : 2186,3
  • Version 32 bits : 2060
La version 64 bits est 6,1 % plus rapide que la version 32 bits.


Création de fichier de 0 Ko en µs :
  • Version 64 bits : 9,7304
  • Version 32 bits : 9,6875
La différence est non significative (0,4 %).

Addition entière 32 bits en ns :
  • Version 64 bits : 0,2433
  • Version 32 bits : 0,2766
La version 32 bits est 13,6 % plus rapide que la version 64 bits.


Addition entière 64 bits en ns :
  • Version 64 bits : 0,31
  • Version 32 bits : 0,62
La version 64 bits est 100 % plus rapide que la version 32 bits.


Il est difficile d'interpréter les résultats. Il faudrait faire plus de tests pour augmenter le nombre de séries et diminuer les erreurs de statistique. Les accès mémoire et les opérations 64 bits avantagent la version 64 bits.



Conclusion :


Il est bien difficile de quantifier exactement la différence de performances entre la version 64 bits et la version 32 bits car :
  • Un résultat dépend de la manière dont on le mesure.
  • Linux est un système complexe. Quels sont les paramètres significatifs que l'on doit mesurer ?
  • Il n'existe pas LE benchmark étalon de référence pour faire des comparaisons. Certains préconisent même de comparer par exemple le temps de compilation des sources d'un noyau Linux.
  • Pour avoir une bonne précision dans les mesures, il faut une taille d'échantillons grande (la plus grande possible) donc augmenter le nombre de tests et donc la durée globale ! Je me suis limité à 3 tests. C'est insuffisant du point de vue statistique. Mais cela m'a déjà pris 2 jours de mesures !
Existe-t-il un benchmark de performances fiable auquel on peut se référer ?

En conclusion, à la vue des résultats, il est clair que la version 64 bits est plus performante que la version 32 bits. Certainement pas d'un facteur 2 !

Le test UnixBench donne la version 64 bits près de 13 % plus rapide que la version 32 bits. Pour rappel, j'avais mesuré un gain de 11 % avec Fedora Core 1 en faveur de la version 64 bits sur une autre machine en décembre 2003. Cela se tient...


Maintenant, quelle est la véracité d'un tel chiffre ? Comment donner un simple chiffre pour résumer un système complexe ?

Pour ma part, et cela n'engage que moi, je pense qu'un gain d'environ 10 % pour la version 64 bits par rapport à la version 32 bits me semble un chiffre raisonnable et réaliste.

Alors, est-ce que cela vaut le coup de passer à la version 64 bits ?

Pour ma part, et cela n'engage que moi, je dis non. Non, simplement à la vue du nombre de posts liés à des problèmes concernant uniquement la version 64 bits que l'on peut lire dans le forum fedora-fr.org.


Seulement pour gagner 10 malheureux petits pourcent !


++

Correctif de 05/11/07 :
A lire le billet Pourquoi passer au 64 bits? ... ou pas ! du blog du Greg sur le même sujet

Mise à jour de mock

Pierre-Yves Chibon

After the update mock changes !

Changement de mock après sa mise à jour

French version

Avec la dernière mise à jour mock change !

Venant de faire face à ce problème, je vous met ici un petit mot pour vous dire que la manière de faire marcher mock a changé avec la dernière mise à jour. En effet au lieu de passer par le traditionnel

mock chemin/to/fichier.src.rpm

ou

setarch i386 mock -r fedora-7-i386 chemin/to/fichier.src.rpm

Il faut dorénavant passer par

mock rebuild chemin/to/fichier.src.rpm

ou

setarch i386 mock -r fedora-7-i386 rebuild chemin/to/fichier.src.rpm

Ce rebuild vous évite une jolie erreure...

Bon mock :)

PS La réponse fut trouvé grace à nphilipp de #fedora-devel et à cette discussion de la list fedora-devel



English version

With the last update of mock the way to use it has also changed !

Because I have just faced that problem, I write down here few words to explain the situation With the new update, your way to use mock:

mock path/to/file.src.rpm

or

setarch i386 mock -r fedora-7-i386 path/to/file.src.rpm

do not work anymore.

I should for now use

mock rebuild path/to/file.src.rpm

or

setarch i386 mock -r fedora-7-i386 rebuild path/to/file.src.rpm

Enjoy your mock :)

PS the awnswer has been found thanks to nphilipp from #fedora-devel and this thread on the mailing list Fedora-devel

ATI + AIGLX, ça marche : mode d'emploi

Nicolas Rodt La dernière version des pilotes ATI fourni, parmi d'autres nouveautés, le support AIGLX. Dorénavant, il n'est plus nécessaire d'utiliser XGL pour pouvoir bénéficier de compiz ou beryl.
L'installation des drivers est assez simple :
  1. Comme on peut enfin se passer de XGL, on peut le cas échéant le désinstaller :
    wget http://nicofo.tuxfamily.org/scripts/xgl/installXGL
    sh installXGL -r
    
  2. L'installation des nouveaux drivers se fait par simple mise à jour : "yum update" ou juste "yum update kmod-fglrx".
    Remarque : yum m'a indiqué un conflit avec le driver précédent : pas de problème, il suffit de le désinstaller manuellement : "yum remove kmod-fglrx"
  3. Activer AIGLX à l'aide de livna-config-display (accessible dans le menu "Applications > System Tools")
  4. À moins de s'amuser avec les commandes du genre "service fglrx restart", il est préférable à ce stade de redémarrer Fedora.
Résultat : ça marche sur ma Radeon X300 !

ATI AIGLX compiz fusion
Problèmes rencontrés
  • Le défilement des pages dans Firefox est assez lent avec compiz ou beryl, ce qui n'était pas le cas avec XGL. Juste un problème de réglage ?
  • Alors que beryl fonctionne sans problème du premier coup, c'est un peu plus compliqué avec compiz fusion : il m'affiche les erreurs
    compiz (core) - Fatal: GLX_EXT_texture_from_pixmap is missing
    compiz (core) - Error: Failed to manage screen: 0
    compiz (core) - Fatal: No manageable screens found on display :0.0
    
    La solution consiste à utiliser "fusion-icon" ou à lancer compiz fusion avec la commande "LIBGL_ALWAYS_INDIRECT=1 compiz --replace".
  • Le curseur de la souris est parfois un peu bizarre (lignes horizontales qui s'ajoutent...)
  • Compiz-fusion et Fedora 7 : en cas de problèmes, sachez qu'il existe une mise à jour de Compiz-fusion pour Fedora 7 (compiz version 0.6.2) : téléchargez l'archive ici, décompressez-la puis mettez à jour les rpm qui y sont contenus (yum update *.rpm). Ça pourrait résoudre certains de vos problèmes.
  • Compiz-fusion et Fedora 8
    Compiz-fusion ne fonctionne pas sur Fedora 8 ? Slander donne une solution dans le commentaire ci-dessous.
  • Compiz-fusion et Fedora 8 et fglrx (ATI)
    Vous obtenez désespérément l'erreur No GLX_EXT_texture_from_pixmap with direct rendering context... nor with indirect rendering, this isn't going to work!. Slander donne aussi la solution dans le même commentaire. (merci Slander !)
Enfin, j'ai testé quelques jeux genre enemy-territory, True Combat: Elite : la fluidité est parfaite ! Même si je n'avais pas vraiment de problèmes de ce côté là avec les anciens drivers, je crois qu'on peut dire qu'ATI / AMD nous a enfin fourni des drivers linux dignes de ce nom...

À voir aussi
  • Installer Compiz Fusion sur Fedora (fonctionne aussi sans XGL) :
    wget http://nicofo.tuxfamily.org/scripts/xgl/installXGL
    sh installXGL -cb
    
  • Lancer Compiz (fusion) ou Beryl automatiquement au démarrage de votre session Gnome / KDE / XFCE. J'ai adapté mon script chooseCompositeWM pour qu'il fonctionne dans toutes les situations (plus uniquement XGL). Pour l'installer :
    wget http://nicofo.tuxfamily.org/scripts/demarrage3D.tar.gz
    tar -xzf demarrage3D.tar.gz
    ./installDemarrage3D
    
    Le résultat : votre session se lance avec compiz ou beryl. En outre vous pouvez à tout moment changer de gestionnaire de fenêtres via le menu "Système > Préférences > Démarrage automatique de Compiz/Beryl" ou chooseCompositeWM.
chooseCompositeWM beryl compiz fusion

ATI : enfin !

Nicolas Rodt ATI Ça y est, comme tous les mois, AMD/ATI a sorti sa nouvelle version des drivers pour Linux (fglrx). Cependant cette version 8.42.3 n'est pas qu'une simple mise à jour. Il s'agit d'une des versions les plus ambitieuses qu'ATI nous aie préparée. Par rapport à la version précédente 8.40.4 (je ne parle pas de la 8.41.7, qui peut être vue comme une version intermédiaire mais non finalisée pour les cartes moins récentes), une bonne partie du code a été réécrit. Et les nouveautés sont nombreuses :
  • support d'AIGLX, enfin !
  • performances accrues de façon drastique pour certains types de cartes (séries R300 à R500)
  • support des dernières cartes (R600)
  • panneau de configuration (AMD Catalyst Control Center) étoffé
  • et bien d'autres (support Xorg 1.4, vidéo playback amélioré, ...)
La principale nouveauté est donc le support tant attendu d'AIGLX (plus d'un an après nVidia quand même...) Ces nouveaux drivers permettront ainsi de jouer avec les effets 3D (compiz et beryl) directement (sans l'intermédiaire d'XGL).

Mais comment les installer? Ces nouveaux drivers sont maintenant disponibles dans les dépôts des principales distributions (livna pour Fedora). La mise à jour s'effectue comme d'habitude. Cependant, si vous utilisiez XGL, vous pouvez le désinstaller (installXGL -r). Une petite modification du xorg.conf est aussi à faire si vous voulez activer AIGLX (pour Fedora, plus détails sur la page ATI + AIGLX, ça marche : mode d'emploi).

Page générée le 20 juin 2018 à 19:30