antistress a écrit 3987 commentaires

tu ne peux pas obtenir un résultat libre si tu construis quelque chose (fut-il libre) sur des fondations non libres. La couche supérieure libre reste limitée/contrôlée par la couche inférieure non libre.
Ce n'est pas mon avis c'est un fait.
C'est ce que PaulK avec qui j'ai discuté explique lui même dans l'interview donnée au Framablog.
Néanmoins ça reste un pas dans la bonne direction ;-)

"Android n'est pas libre à 100%"
donc il ne l'est pas.
Les couches basses sont proprio, tu ne sais pas ce que fait ton téléphone.
Il n'est pas plus libre que Windows Phone, BlackBerry, iPhone et autres

Déjà vaut mieux une distrib sans X.org
Meego dans sa version mobile doit en être dépourvu à mon avis ?

d'après wikipédia répliquant / android c'est dans Blade Runner selon que l'on parle du film ou du livre

sur Framablog on a une interview de PaulK, un des développeurs http://www.framablog.org/index.php/post/2011/10/10/replicant-android-google

ça me dépasse

N'oublions de citer Linus au sujet de l'UEFI "c'est de la merde" (enfin il a été un peu plus dissert : http://kerneltrap.org/node/6884 )

tous les boutons ne sont pas intrusifs, certains lancent juste un protocole lorsqu'ils sont activés (comme les mailto) c'est ce que j'ai sur mon blogue. Est ce possoble pour Diaspora* etc ?

À partir du site http://diasporafoundation.org/ vous trouverez un bouton en haut à droite pour visiter le blogue.

Il est assez bien fait : vous pouvez même partager vos articles via Twitter et... et c'est tout, en fait. Qu'est-ce que vous croyiez : que les utilisateurs de Diaspora* se partageaient des articles ? Sans blague ?

Par contre si quelqu'un peut me donner le code pour insérer un bouton de partage Diaspora* en fin d'articles sur mon blogue je le ferai volontiers http://forum.pluxml.org/viewtopic.php?pid=21258#p21258

Merci pour la dépêche
Sinon fallback reste un mot anglais inusité en français, il serait de bon ton de le traduire (solution de repli, par exemple)...

Les questions soulevées sont intéressantes, je n'en avais pas connaissance.
Il me semble également que tout ce qui est DRM dans le processeur est vain si l'OS ne l'implémente pas également ?
Enfin, avec un BIOS en tout cas, parce qu'avec ces saloperies d'UEFI on n'est plus sûr de rien, hein...

Pour le coup, il me semble qu'AMD est plus coopératif avec le projet Coreboot (ex LinuxBIOS) si on devait remplacer l'UEFI, mais quand on regarde la liste des carte supportées c'est assez maigre pourtant ? www.coreboot.org/

En effet avec l'AVX Intel semble aller au bout de son idée cette fois.

Ça na pas toujours été le cas, on se souvient du MMX, excellent coup marketing mais mauvaise technologie : son utilisation rendait indisponible l'unité de calcul en virgule flottante !

Quand aux versions successives du SSE, des développeurs relativisent l'apport des ajouts successifs : les optimisations internes dans le traitement des SIMD peuvent s'avérer bien plus efficaces que l'ajout de nouvelles instructions (cf l'introduction du Super Shuffle) http://www.outsourcingi.com/articles_content.php?id=454&art=The%20Future%20of%20Linux%20with%20Intel%20Core%202%20%E2%80%9CPenryn%E2%80%9D%20and%20SSE4&cat=Hardware

De ce point de vue, AVX semble aller dans le bon sens.

Je ne suis expert sur la question, mais je peux te dire que certaines cartes mères exploitent la partie graphique du Sandy Bridge, d'autres non.

C'est assez confus chez Intel à ce niveau, on s'y perd facilement, il faut l'avouer :-/

Déjà tu peux filtrer pour ne garder que les cartes mères LGA 1155.
Ensuite tu as différent chipsets, mais pour exploiter la partie graphique il t'en faut un avec support FDI.
Donc si tu regardes ici https://secure.wikimedia.org/wikipedia/en/wiki/List_of_Intel_chipsets#Core_i_Series_chipsets en recoupant les deux critères (LGA 1155+FDI support), ça donne au choix : H61, H67, Z68 et B65 (Q67 et Q65 c'est pour les stations de travail il me semble)
Après je pense que c'est pas mal d'en prendre un qui gère le SATA 6 Gbit/s si tu dois prendre un SSD un jour, ce qui exclut le H61 et il reste alors les H67, Z68 et B65.

Ensuite si tu as des cartes PCI à réutiliser, il te reste alors seulement le B65.

En revanche, pour le RAID c'est H67 et Z68.

En revanche si tu veux overclocker, il faut un processeur avec la lettre K et un chipset Z68.

Voir aussi pour des tableaux récapitulatifs : http://motherboardnews.com/2011/04/07/comparison-of-intels-lga-1155-chipsets/
et pour le détail par chipset http://ark.intel.com/#desktopchipsets

Sous Linux le Sandy Bridge se positionne bien mieux par rapport à la concurrence si on regarde les perfs avec les drivers libres AMD/Nvidia/Intel (cf tests sur Phoronix)

Oui, c'est une bonne remarque. En effet la liste des processeurs est disponible sur la Wikipédia EN : http://en.wikipedia.org/wiki/Sandy_Bridge#Desktop_processors

"il m'a montré un petit programme qu'il avait mis au point, qui utilisait des threads"

dans la bio de Linus http://www.ecoledesloisirs.fr/php-edl/catalogues/fiche-livre.php?reference=E119143 on apprend à quel point c'est impressionnant considérant qu'il écrivait directement en assembleur !

D'ailleurs tout cet article colle de très près à un paragraphe du livre de sorte qu'un imposteur aurait pu l'écrire et que pour ma part je n'ai rien appris...

Ça arrive, cf http://libre-ouvert.toile-libre.org/index.php?article62/firefox-comment-panorama-va-bouleverser-vos-habitudes

Il semblerait d'après ce post [1] que la puce WiFi Broadcom BCM4312 802.11b/g [14e4:4315] soit prise en charge par cette nouvelle version du noyau.
Je n'ai rien lu d'officiel à ce sujet, quelqu'un peut-il confirmer ou infirmer ?
Cette puce équipe par exemple les Netbooks Dell Mini 9
Merci d'avance

[1] http://techpatterns.com/forums/about1897.html

merci :-)

Merci pour cette dépêche désormais classique sur linuxfr

RC-3 : le lien wikipédia pour DRI n'est pas bon, c'est : http://fr.wikipedia.org/wiki/Direct_Rendering_Infrastructure je pense

Au final, ceux qui militaient pour que la v3.0 du noyau soit l'occasion de faire un grand ménage n'ont pas été entendus ?

C'est dommage car je ne veux pas de code proprio sur ma machine.

Du coup j'en viens à devoir choisir nVidia pour ma prochaine carte si je veux avoir du 100% libre (alors qu'ils ne jouent pas le jeu du libre) plutôt qu'AMD (qui le joue mais pas complètement et du coup la situation est paradoxalement moins libre côté AMD) !!!

Ça me fait suer quand même de devoir donner mon argent à nVidia qui se fiche du libre à cause de cette politique presque libre d'AMD :-/

et aussi : conséquences de Wayland en termes de portabilité ;-)
Par exemple via "GEM/KMS On FreeBSD Is Working, But Not Ready" (http://www.phoronix.com/scan.php?page=news_item&px=OTYzMA)

Est-ce que quelqu'un comprend ce qu'il en est des firmwares AMD ?
Apparemment ils ne seraient pas libres malgré "l'ouverture" d'AMD (alors que le projet Nouveau a réussi a libérer ceux de nVidia sans l'aide de ces derniers : par rétro ingénierie) ?!
Est-ce bien le cas ? Et si oui, pourquoi ?

Avec Debian Squeeze, le boulot fait sur insserv (dans le cadre de sysvinit) se ressent bien avec une belle vélocité au démarrage.
A part pour se palucher, systemd a t-il un intéret pratique qui justifie de couper la branche Debian/kFreeBSD ? (c'est une vraie question)

Comme je sais que patrick_g suit Wayland de près, ça serait une bonne idée de poursuivre sur la lancée avec une interview de son développeur ;-)

Je suis très impressionné par le niveau de ce magazine, de très haut vol, le meilleur que j'ai lu depuis longtemps.
Pour l'instant j'ai lu tout ce qui concerne F15 et GNOME3 c'est remarquable.
Deux remarques :
- à un moment vous parlez d'ERP sans le définir, j'imagine que tout le monde ne sait pas de quoi il s'agit
- une coquille "si, malgré la lecture de cette article" au lieu de "cet"

Un grand bravo (et merci) en tout cas

Clutter nécessite OGL 1.4+ seulement, c'est pourquoi on voit des vidéos sur IGP Intel GMA950. Donc pas besoin de viser OGL 2.1 semble t-il