monde_de_merde a écrit 540 commentaires

Je cite le communiqué :
[...] AMD and Intel obtain patent rights from a new 5-year cross license agreement[...]

Je pense qu'un accord de licence sur 5 ans, compte tenu de ce qui est en jeu vaut presque autant que les dédommagements en liquidités non ? Pour moi c'est surtout ça le point "intéressant" de l'accord, après je sais pas ce qui est inclus la dedans.

Merci !

Pourquoi je n'arrive pas a remettre celle par défaut :(

Je reviens systématiquement à la css openSuse dés que je reviens à la page des dépêches.

Qu'on me corrige si je me trompe, mais une installation de Dotclear 2 peut hébergé plusieurs blogs modulo quelques bidouilles (je veux dire que l'on sort un peut du processus tout-par-le-navigateur qui est la norme pour l'installation standard).

Ceci dit je ne sais pas comment se présente une installation de LifeType.

Le push c'est quand le serveur envoie des données à un client quand elle sont disponible.
Le pull (la méthode la plus répandue) c'est quand le client demande des donnée au serveur.

Ce qu'il veut faire, je pense, c'est "singer" du pull, puisque le protocole HTTP (qu'on me corrige si je me trompe) ne permet pas directement le push. En gros il veut un système ou le client ouvre une connexion, et quand les données sont dispos, le serveur les pousse dans la connexion. Éventuellement, il ne ferme pas la connexion pour pouvoir pousser d'autres données par la suite quand elles seront dispos.

/agree

Cet homme est un sage.

Il a pourtant tout "wikifié", mais il est vrai qu'une vague explication donnerait du corps à la dépêche et l'envie de se renseigner plus pour les lecteurs intéressés.

Je suis l'heureux propriétaire d'une radeon hd 4870 (que j'utilisais encore pour jouer il y a peu). Aujourd'hui je l'utilise avec KDE (Kwin) et les effet openGL et ça marche bien, je n'ai pas encore souffert de crash intempestif.
Auparavant je l'utilisais en 2D et je n'ai jamais connus ces plantages intempestifs dont tu parles.

Sur mon autre desktop c'est une X1xxx (me souviens plus mille excuses) qui fonctionne avec Kwin et ce depuis déjà quelques mois de manière stable. De la même façon, le drivers libre me permet de l'utiliser en 2D de manière stable depuis de long moi déjà.

Et r600 et r700 partage la même architecture (à peu de choses prés) et les drivers sont developpés en parallèle, le support est donc identique pour ces deux générations.

Je pense pour ma part que tu généralises à partir d'une expérience malheureuse. Et je serais ravis de t'aider à changer d'avis...

Merchi :)

Le fait est qu'en effet Xorg n'est pas la seule couche graphique pour Linux (et je ne prend pas en compte le monde l'embarqué, par ex : Qt extended improved utilisé par le projet OpenMoko). Mais Xorg n'est pas non plus qu'une couche graphique, c'est un "window system".

En plus de l'affichage (et donc du dessin effectif à l'écran) de tous les 'trucs" imaginables dont une application peut avoir besoin, Xorg prend en charge un certain nombre d'autres choses : le concept de fenêtre et ce qui en découle (le focus par exemple), les entrées et la redirection des événements d'entrée, la gestion des écrans...

Le framebuffer et bien n'est finalement que ça : une zone de la mémoire (buffer) dont la taille correspond à la résolution de l'écran (frame) dans laquelle on "dessine".

Loin de moi l'idée de dénigrer une pièce des système Linux, mais de mon point de vu d'utilisateur lambda-mais-pas-tout-à-fait, c'est vrai que j'assimile (un peu trop ?) facilement la libc au noyau même si ce sont pourtant deux morceaux bien distinct.

En plus, je suis beaucoup plus intéressé par les développements que connait Xorg que par le monde (obscur s'il en est) de la libc, auquel je ne pane strictement rien.

Mes excuses pour les erreurs, malgré le passage du correcteur orthographique et une relecture attentive on efface pas 25 ans de cancre-attitude syntaxique !

Et merci c'est une bonne piste le wiki !

(PS : ça sert à quoi le karma ? J'ai découvert ça dans le mail d'info d'acceptation)

Je ne puis qu'être d'accord avec toi. Et même si je suis pas madame Michu, mais si je peux avoir mon système Arch agréable à l'œil je prend sans soucis...

D'ailleurs c'est même ce qui m'a fait choisir Arch : pouvoir tout faire comme j'en ai envie, y compris rajouter des trucs inutiles.
Ce n'est pas parce que je me sens à l'aise avec la console que j'ai pas envie de coller plein d'eyecandy partout. (parce qu'il faut bien reconnaitre, que même pour un œil averti, la console, ça reste super moche, surotut sur un écran 24").

Dans les commentaires de l'article du développeur d'x264 on peut lire :

# Mathias Says:

[...] And I also wonder, if there was that high penalty, how did Windows compare to encoding on Linux and how does it compare now? And this is all coming with 2.6.32?

# Dark Shikari Says:
[...]
@Mathias

Yes, it was probably slower than Windows. This explains a number of benchmarks I’ve seen recently where Windows trashes Linux at the same applications (when there’s really no good reason for it to do so).

And yes, it’s all coming in 2.6.32.


La régression était connue mais son origine n'avait pas était éclaircie semble-t-il

Le module VGA arbiter est revenue dans le noyau (2.6.31 je crois, mais faudrait vérifier) donc à priori il y a un début de support propre (mieux gérer moins prise de tête à configurer etc...). J'ai pas plus de détail que ça au niveau de X, mais c'est possible c'est sûr.

Je crois pas que pour l'instant il y ait quoi que ce soit de plus complet.

Par ailleurs il n'est *pas* conseillé d'activé cette fonctionnalité, à moins de disposé d'un toolkit qui la prend en charge. En effet, si par malheur, ton clavier et ta souris réel ne sont pas raccordé au bon "maître", le toolkit (et par extension le bureau) ne recevra plus le flux d'entrée.

Par ailleurs, je ne sais pas comment se comporte un terminal face à plusieurs clavier, il y a aussi des risques à ce niveau et c'est autrement plus embêtant qu'un gnome cassé.

C'est presque hors sujet et uniquement pour ma culture personnelle mais, il est pas tout le mec derrière Phoronix plutôt ? Michael Larrabel je crois.

(et c'est vrai que parfois ça tire un peu sur le sensationnalisme et c'est bien dommage...)

C'est une peu une extrapolation sauvage ça non ?

Cela fait plusieurs années que les différentes moutures de Windows sont comprises, qui par un bootkit, qui par un trojan vicieux et j'en passe et que windows accapare toujours 95% du marché (estimation au pif, j'ai la flemme d'aller voir les stats).

je pense donc pour ma part que le glas de l'église microsoft se couvrira de poussière pendant encore quelques années.

Je ne suis pas un expert et je ne suis pas de très prêt le dévellopement de Wayland, mais il me semble avoir compris que ce n'est pas vraiment un remplaçant pour Xserver (et non pas de Xorg en entier).

Wayland est fonctionnellement destiné à être un remplaçant de Xserver, mais s'en est surtout une énorme simplification.

Le premier point c'est qu'il s'agit d'un serveur graphique qui devrait accomplir certaines choses en recourant directement aux dernières technologies introduites récement (GEM, TTM-GEMisé, DRM etc...). Sur cet aspect la pile Xorg supporte aussi d'anciennes méthodes de rendu.

Le second point, c'est que Wayland ne prend pas en charge à l'heure actuelle certains aspects du protocole X11 (qui est véritablement monstrueux) alors que la pile Xorg le prend plus moins en charge intégralement. En se concentrant sur l'essentiel Wayland est encore uen fois plus simple et plus rapide.

Enfin, Wayland redéfinit une API différente de notre Xorg, et comme incidemment il se trouve que l'on a fait des progrès en conception d'api et que l'on a appris des erreurs commises par le passé il est aussi plus simple à cet égard là.

L'un des désavantages de cette approche c'est qu'il est nécessaire de réécrire les back-ends des librairies graphiques actuelles pour qu'elle puisse être rendue par Wayland plutôt que par Xserver. Actuellement QT, GTK+, Clutter etc... usent de Xlib pour l'affichage. Le travail est en cours pour Clutter (d'aucun y verront un effet de mode, openGL tout ça...) et il était prévu de le faire aussi pour GTK+, peut être même que cela a commencé.

Je ne sais donc pas s'il est possible de vraiment essayer Wayland, mis à part lui faire héberger un Xserver ou un terminal.

Par ailleurs j'aimerai savoir ce qui justifie le "une fois de plus"...

ça je sais pas.
En tout cas tu as envie de la lancer sur DLFP dirait-on, et ça c'est mal...

A part ça, c'est super de glisser des clins d'œil et autres références dans ton texte, mais ça le rend difficile à lire et c'est bien dommage.

Sans compter le style ampoulé...

J'ai appris des trucs quand même, parce que j'avais pas tout suivit du feuilleton, donc merci malgré tout.

Merci :)

Je ne met pas en doute ta bonne foi mais en l'absence d'information complémentaire, rien ne prouve que le bitrate de theora soit effectivement de 1500kbps ni que celui des autres le soit.

Il nous faudrait une comparaison aussi poussé que celle qui avait été faite par quelqu'un (dont j'ai oublié le nom) qui comparait theora et h264 pour youtube.

Si cette dépêche ne s'adresse qu'aux gens vraiment concernés, alors on peut légitimement supposer que ceux-ci suivent déjà avec intérêt les informations concernant maven.
Dans ce cas cette dépêche ne sert à rien.

Par contre s'il s'agit de donner un peu de visibilité à un projet de documentation (et donc au projet cible de la documentation), un peu de pédagogie ne nuirait pas. En tout cas ça ne me déplairait pas.

Au risque de reprendre une critique fréquemment adressée aux auteurs de dépêches, je trouve qu'il manque des éléments qui ajouteraient beaucoup à l'intérêt de la dépêche. Par exemple, en quelques mots et avec quelques liens, qu'est ce que Maven ?