Gabriel Linder a écrit 175 commentaires

On n'est pas obligés de le faire tourner en root, d'ailleurs c'est la première chose que j'ai faite après l'installation...

http://bughost.org/ipw3945/daemon/README.ipw3945d (section 4).

Au cas où çà en intéresse ici, en attendant le nouveau driver sans démon binaire : j'ai un script d'init modifié pour Arch qui gère tout ce qu'il faut, il vous suffira de créer un user limité ipw3945d :)

J'ajoute avec du recul (l'ayant utilisé jusqu'à maintenant, toujours sur la même config) que ce plugin fuit toujours comme une truie : regarder une vidéo de 34Mo en flash m'a rempli ma RAM ainsi que mon swap. Allez y, moinssez moi :)

Une solution pour faire tourner le démon avec un accès limité (le root caymal) est fournie par Intel dans la doc[1] (section 4. RUNNING AS NON-ROOT). C'est toujours sale, mais çà devient supportable. Testé et approuvé sur Arch Linux, une simple modification du script /etc/rc.d/ipw9345 suffit.

Sinon cette nouvelle d'un vrai driver décent et sans blob m'a vraiment fait plaisir :)

[1] : http://bughost.org/ipw3945/daemon/README.ipw3945d

Moi il me plante régulièrement firefox (je suis sous Slackware, donc non il n'y a aucun patch fantaisiste qui pourrait l'expliquer), mais c'est vrai qu'il marche malgré tout bien mieux que son prédécesseur.

En plus de "se faire plaisir" et "améliorer le code", j'aurais cité ce but là aussi :)

Il faut bien voir que sans Firefox, Thunderbird, MinGW (portage Win32 de GCC), GAIM et X-Chat, qui étaient les seules applications que j'utilisais sous Windows pendant un temps, je ne serais peut être pas passé définitivement sous Linux. Çà remonte mais bon... Et puis je préfèrerais voir plus de personnes utiliser Konqueror qu'IE 7 :p

Quand on sait où on a rangé ses documents...

Le seul truc bordélique chez moi c'est ~/tmp, et il est rare qu'il dépasse 20 documents vu qu'après quelque temps j'efface ou je classe :)

Quand j'ai installé Linux au boulot (contraint de garder XP dans un coin au cas où j'aurais à utiliser certains softs), j'avais utilisé la distribution RIP (Recovery Is Possible) qui inclut tout ce qu'il faut, entre autres un README bien conçu et un script qui s'occupe de tout.

J'avais défragmenté mon disque avant, mais apparemment il n'y en avait pas besoin, les utilitaires déplaçant les fichiers si besoin. J'ai été favorablement impressionné je l'avoue, je m'attendais à ce que Windows disparaisse mais en fait non, tout s'est très bien passé :)

[1] : http://en.wikipedia.org/wiki/Recovery_Is_Possible

...je devais m'acheter un nouveau portable :)

Sauf que les BSD et autres X11 utilisent tous GCC comme une part à peu près irremplaçable dans l'état actuel des choses pour compiler leur joli code sous license non GPL.

...pour ce beau cadeau, papa noel :)

Moi j'ai négocié ma barbe : " Si tu m'obliges à me raser, je configure ton .xinitrc pour utiliser twm au lieu de Gnome ! ", elle n'a pas insisté ;)

Oups, j'ai oublié : pour activer les effets, il faut utiliser transset (transparence) et xcompmgr (ombres et autres effets), voir les pages man pour plus de détails ;)

J'ai retrouvé que celui là[1], mais il ne manque qu'une ligne Option "Composite" On dans la section Extensions, et une ligne Option "AccelMethod" "EXA" dans la section de la carte vidéo. Après tu peux tweaker les paramètres du pilote (man 4 via) pour améliorer les performances, en particulier les options ExaScratchSize et MigrationHeuristic :)

[1] : http://athanatos.free.fr/Arch/new/xorg.conf

Ce qui serait fort dommage :(

J'ai jamais dit que çà l'était.

Vu que les effets de transparence sont à la mode j'en ai mis pour le screenshot, mais je ne l'utilise certainement pas tel quel, merci pour mes yeux. Sinon dans le domaine du "petit plus appréciable qui ne nique pas les yeux" il y a les ombres de fenêtres / menus, parfaitement fluides et relativement discrets.

Effectivement j'ai oublié de préciser pas mal de détails. Alors :

1) Arch Linux n'interdit pas les blobs, au contraire elle fournit des paquets pour ceux qui veulent utiliser nvidia/ati/ndiswrapper, on a le choix :)

2) EXA est une architecture d'accélération graphique pour X, marquée expérimentale pour le moment mais prometteuse et bien plus rapide que XAA, l'architecture traditionnelle d'X

3) Composite est une extension d'X qui permet de gérer la transparence (ce qu'on voit sur le screen)

4) La carte vidéo tourne grâce au driver libre via, avec de relativement bonnes performances en 3D (on peut jouer à Cube et Open Arena, par exemple). Aussi bonnes qu'on peut en avoir avec de la mémoire partagée, en tout cas :(

Mea culpa.

On peut avoir un système sexy, agréable à utiliser, et libre : http://athanatos.free.fr/EXA-Composite.png

Après je suis d'accord, chacun utilise ce qu'il veut, c'est çà aussi le libre :)

...et j'irais même jusqu'à dire que c'est une bonne chose, quoiqu'en dise Linus. Je sélectionne de toute façon soigneusement mon matos pour éviter les blobs, quitte à avoir du matériel de la génération précédente, mieux supporté (et moins cher). Même avec des portables, c'est possible :)

Je ne comprend pas pourquoi ce post est moinssé, il soulève un vrai débat sur l'uniformisation d'un bureau linux... Là Gnome et KDE s'évertuent à réimplémenter à leur sauce / toolkit des softs qui marchent déjà très bien, uniquement pour que le look soit uniforme dans le bureau par défaut, bonjour la perte de temps.

Perso mon rêve serait de voir ce #$@!% de firefox utiliser des widgets GTK dans les formulaires web (pour le moment seul XUL en profite), çà fait tâche et ils sont quand même très moches, leurs widgets actuels.

Tiens c'est marrant, moi j'ai préféré GAIM sous Windows à Psi sous Windows parce que Psi ramait comme pas possible. Par contre c'est vrai que X-Chat déconne sous Windows, je sais pas d'où çà vient, et je sais pas si çà vient vraiment de GTK vu que GAIM ne déconne pas, lui :/

La manipulation ce ne serait pas ceci des fois ?

$ cat /etc/profile.d/gtk+.sh
#!/bin/sh
GDK_USE_XFT=1
export GDK_USE_XFT

En tout cas c'est amusant de voir que Slackware est bien configurée par défaut, contrairement à d'autres distributions soi-disant grand public ;)

Mais rien du tout, c'est au contraire très impressionnant. Par contre le Haskell n'est pas ce qu'il y a de plus lisible par rapport à ce qui se fait habituellement, c'est en ce sens que je considère ce projet comme une torture pour mes neurones :)

http://programatica.cs.pdx.edu/House/

On va prendre un exemple concret : pendant un temps les processeurs Intel (je sais pas si çà vaut pour AMD ni si çà a pas changé depuis) considéraient que le if { foo } avait 80% de chances de s'exécuter par rapport au else { bar }, et commençaient à charger le code de cette partie avant même d'avoir pu évaluer le test conditionnel.

Si la prédiction était juste, on gagne du temps : le processeur a chargé le code pendant qu'il calculait la condtion. Par contre si elle était fausse, il faut vidanger le code chargé pour rien, puis charger le bon code : pendant ce temps il ne peut rien faire d'autre, et perd donc du temps.

A une échelle humaine c'est difficilement quantifiable vu que çà se joue sur des millièmes de secondes (si c'est pas moins), par contre pour le processeur c'est énorme. Depuis les processeurs ont des instructions de prefetch, mais il me semble qu'elles ne concernent que les données, pas les branchements conditionnels (ex: je vais avoir besoin des données à telle adresse, assure toi qu'elles soient dans le cache pendant que tu calcules autre chose stp merci)

Certains processeurs (chers) ne s'encombraient pas de tant de finesse : pendant le calcul de la condition ils chargeaient les deux blocs possibles, exécutant ensuite celui qui s'était avéré bon (qui a dit brutal ?) ;)