Xaapyks a écrit 543 commentaires

Il parlait des applications KDE
Oui c'est extrêmement lent...
On voit les boutons se dessiner parfois tellement c'est lent. (et non, mon X est très bien configuré)
Et Dolphin qui met 2 secondes à se lancer...

C'est inacceptable (mais un peu compréhensible, dolphin n'est pas gardé en mémoire si on le ferme)

"Ma distribution de logiciels libres préférée, c'est Debian "

Rhoo ce troll !
Bien placé ;)

https://www.gnu.org/distros/free-distros.html

Mais ca ne s'applique qu'aux applications KDE j'imagine.
L'intérêt est donc très très limité, comparé à tsocks, par exemple, qu'on charge grâce a LD_PRELOAD et qui écrase les ouvertures de connexions de la libc par une connexion SOCKS.

Oui moi aussi je trouve Michael un peu limite sur plusieurs aspects...
Articles souvent baclés, remplis de pubs ( ne sortez pas sans abdlock ) .
Quand il tombe sur des gros bugs il ne les remonte pas mais en fait un article, etc...

Mais d'un autre côté il est très réactif sur ce qui se passe niveau développement dans le libre, donc ça compense...

Anglophone, très axé kernel , mesa et Xorg

Ce pilote est censé fonctionner oui.
Attention ce n'est que le DDX hein, tu auras pas de 3D avec ça, que l'accelaration de X ( Xrender)
Je pense que tu le sais mais c'est du côté de mesa qu'il faut se pencher pour openGL

Je te rassure, même avec les toutes dernières versions de Xorg, le fichier xorg.conf est toujours supporté...
Et l'autodétection de Xorg si tu n'en as pas ( et pas de xorg.conf.d non plus ) ne prend pas nvidia par défaut mais bien vesa.

Heu j'ai une 6870 et je tourne sous driver libre sans problème, la 3D marche bien (pas très très rapide, mais acceptable)
Mets à jour ;-)

winehq c'est juste le nom du site de wine.
Et ce que tu demandes c'est tout simplement la base de données de compatibilité de wine :
http://appdb.winehq.org/

T'es sur que t'as modifié ton xorg.conf ?
A mon avis t'étais en software...

Je crois que tu as raté le point important :

gcc -M

Et ça, ça te sort une liste dans un fichier de tous les headers ou autre include utilisés dans ton fichier source sous forme de règle make. Si tu l'inclues c'est gagné car si un des headers est plus récent que la source, on recompile les objets basés sur ce fichier source.

(Ca fait longtemps que j'y ai plus touché, mais en gros c'est ça)

Je ne comprends pas.
Tu dis que les autotools sont un truc tout branlant ou justement qu'ils ne le sont pas ?

http://omgmg.dyndns.org:6543/

Il semblerait que ce CPU soit quand même bien vieux (2 ans selon mes recherches) ce serait dommage de partir avec un truc obsolète...
Dirige toi vers de l'i3, i5 ou de l'AMD Fusion

Sauf que tu oublies de dire que le RC6 a été désactivé sur les récentes puces pour des problèmes d'instabilité.
Le réactiver peut poser problème et pour preuve, tu en as.

Je suis tout à fait d'accord, mais là on touche à un problème bien plus philosophique.
Et je n'ai pas la réponse comme ça... C'est vrai que je verrais plutôt mal que la ceinture en voiture ou le casque à moto soient par exemple rendus facultatifs. Mais dans le fond, qui aujourd'hui utilise ce genre de sécurités rien que par peur de l'amende ? Pas moi...
Pour garder ton exemple de la ceinture, si la loi venait à disparaitre, les constructeurs continueraient à en mettre dans leurs véhicules. Et je pense que beaucoup de gens responsables la mettraient par habitude et par choix.

Après y a ce qu'on appelle la sélection naturelle...

Pourquoi légiférer ? Les gens se démerdent... ! S'ils abusent c'est de leur faute. Ce n'est pas une nouvelle que l'abus de ces boissons est mauvais.
Faut se responsabiliser et pas sortir des lois à tour de bras...

Après on se retrouve avec des Hadopi et autres lois qui veulent penser pour nous et nous apprendre comment se comporter.

Ah, les utilisateurs aussi sont sous NDA maintenant ?

Le plus logique serait que les constructeurs fassent connaitre ce "mot technique" (pas si compliqué), car les gens savent, pour la plupart, déjà ce que ça signifie. Cependant ils utilisent plutôt le terme "clé USB" que stockage de masse. C'est imprécis mais on voit de quoi ils parlent.

Au lieu de materner les clients, faudrait leur apprendre quel standard est utilisé.
"Format jack" en gros et derrière "compatible iPod + zune + baladeurs jack 3.5" pour préciser me choquerait moins, ça rassure les indécis.

Un peu HS, mais ça me fait penser à la dernière imprimante HP que je viens d'acheter ( d'ailleurs, profitez-en : https://www.materiel.net/pub/pdf/BTS_HP_2011_Leaflet.pdf ). Il est marqué "compatible Windows et Mac OS X". Aucune mention d'autres OS ni GNU/Linux. Or HP lui-même fournit des drivers pour cette imprimante pour Linux via CUPS... ( http://hplipopensource.com/hplip-web/index.html ) Donc pourquoi ne pas le mettre sur la boîte ?!

Normalement les images sont hybrides et tu dois pouvoir les copier sur ta clé avec dd.

Le mot "Linux" est inconnu au bataillon.

Et je trouve ça plutôt logique. (Si c'était délibéré)
Dans ce cas tu supportes Linux mais pas FreeBSD ? OpenBSD ? Haiku ? Pourtant je pense qu'au moins les 2 premiers supportent l'USB Mass Storage.
La mention de l'USB Mass Storage suffit à partir du moment où il n'y a aucun soft à installer sur le PC et que la norme est plus que standard.

Ce serait autant insensé que les Casques audio/écouteurs Jack qui arborent fièrement un "Compatible iPod !"

Le plus "simple" pour savoir si le support de l'UMS est là est de chercher des avis sur internet ou des amis qui ont ce modèle, mais c'est pas évident... Sinon, mail au constructeur ?

J'en connais un qui a abusé du Jack...

Je vais peut-être dire une bêtise, mais :

J'étais conscient en choisissant canalblog qu'ils devenaient propriétaires de mes
messages mais je m'étais dit que je pourrais toujours écrire un script pour les récupérer
si cela m'intéressait

Si tu cède tes articles à un tiers, ils ne t'appartiennent plus, non ? Si tu les récupères ensuite n'est-ce pas du vol et du plagiat ^W^W^W ?

Quelqu'un pour m'éclairer là-dessus ?

Et bien non pas exactement, mais l'idée y est.
C'est une recherche dichotomique en gros sur une période donnée.
Donc on ne fait pas TOUS les commits avant de trouver le fautif mais qu'une dizaine en général.

cpufreq-info peut te donner ca je pense.
Dans le paquet cpufreq pour ArchLinux, pour les autres distribs je sais pas.