ecyrbe a écrit 633 commentaires

Je comprends tout à fait ce genre d'usage. Mais personnellement, il ne me convient pas dépassé certaines heures tardives. A ces moments là, je surf sur internet comme un zombie et le clavier je n'y touche plus. Je ne fais que lire et suivre des liens. Bref un usage exclusif de la souris.
Avec chrome, c'est vraiment rébarbatif. trop de clics. Avec FF, je navigue dans mes marques pages comme sur un site web. C'est vraiment le truc ultime de flemmard.

Moi ce que je ne supporte pas avec chrome, c'est qu'il n'y ait pas de barre latérale sur la gauche pour accéder rapidement et en permanence à ses marque-pages.
Mettre les marque-pages en haut, alors que de plus en plus d'écrans sont Wide, voire Ultra Wide, et forcer à faire du clicodrome pour accéder à ses marques pages organisés en répertoires, c'est vraiment du sado-masochisme.
Je reste sous FF pour le moment. Chrome est peut être rapide, mais pas pratique quand on a plusieurs centaines de marque-pages.

Je me relis à chaque fois. Je fais plein d'erreurs en écrivant et la relecture me permet de corriger mes fautes. Mais des fois j'en laisse passer. Du coup après avoir posté, il m'arrive de m'apercevoir qu'il en reste une monstrueuse (comme dans ce suivi : s/part/par).
Donc, en théorie, se relire permet de corriger toutes les fautes, mais en pratique, il en reste souvent plus qu'on ne le voudrait. Permettre de s'éditer permettrait de minimiser cet état de fait et d'améliorer la qualité du contenu de linuxfr.

Je que 5 minutes seraient suffisantes. Très bonne idée par ailleurs. Un post dans le suivi s'impose...

Bonjour l'innovation.

Sur le desktop, Mac c'est moins de 7% de part de marché. Donc tes 20% sont plutôt fantaisistes et on peut donc considérer que ce n'est pas un gestionnaire de fenêtre traditionnel. Et il n'a pas été dit que c'était innovant, tu déformes les propos.

Non, il n'y a pas de problème avec les cartes récentes. Le lien vers radeon features l'explique bien.
J'ai une carte avec le power management à dynamique. ça marche très bien. Je ne vois pas ce que tu veux de plus. Les drivers radeons libres sont à ce niveau là irréprochables.
Tu fais ce que tu veux, mais avec les drivers libres, j'aurais tendance à choisir de l'AMD plutôt que du NVidia, parce qu’ils fournissent les specs et je les remercies en retour en achetant leurs cartes qui sont d'ailleurs très bonnes et consomment très peu. Pour ce qui est de HD5450, sur le papier elle dégomme la GeForce 9500. Donc quand les drivers s'amélioreront, elle défoncera complètement la GeForce 9500. Pour moi il n'y a pas photo.

Merci, tu viens de me réconcilier avec ff... j'ai pu refoutre ce satané bouton home à gauche!

La gestion de l'énergie est très bien gérée par les drivers libres grâce aux specs d'AMD. De ce point de vu, les drivers libres radeon n'ont rien à se reprocher.

D'après ce teste sur openbenchmarking, c'est loin d'être moins puissant.
En fonction du test, c'est l'une ou l'autre qui l'emporte. On est relativement au même niveau de médiocrité de performance. Pour de l'accélération sur le bureau et de la vidéo cela suffit largement... pour jouer, dans les deux cas, tu peux passer ton chemin.

Oui, d'ailleurs je me demande comment Ubuntu va pouvoir maintenir Unity dans le futur. En effet, les applications Gnome 3 ne risquent elles pas de s'intégrer plus profondément avec Gnome-Shell et donc provoquer une rupture de compatibilité avec Unity dans un futur proche?
Je pense plus particulièrement à LibAppIndicator utilisé par Ubuntu (qui est franchement bien foutu pour uniformiser l'interaction avec le panel sous gnome 2) et le système utilisé par Gnome-Shell. Les deux ne semblent pas compatibles. J'ai peur que cela ne demande le double de travail pour développeurs d'applications pour que leurs logiciels fonctionnent sous Unity et Gnome Shell.

En Fanless t'as la radéon HD 5450 de chez saphire dans la même gamme de prix. ça utilise l'architecture evergreen, il te faudra donc installer les derniers drivers libres s'ils ne sont pas fournis avec ta distribution.

Merci pour ces explications. Ce n'était pas du tout pour lancer troll pour ma part, juste une méconnaissance des détails d'implémentation des drivers libres. Je pensais que AtomBios était utilisé partout, hors, c'est juste utilisé par kms, donc effectivement, ça ne peut pas foutre en l'air les performances.
Du coup pour les mauvaises décisions, est-ce qu'il y a moyen de corriger le tir, ou bien de ton point de vu celà demanderait de tout refaire?

Il y a clairement un souci d'implémentation dans les drivers radeons. Une carte d'il y a 6 génération est aussi rapide qu'une carte dernière génération.
Serait-ce du à l'utilisation de la surcouche propriétaire à AMD AtomBIOS? est-ce que AtomBios ne grève pas les performances? Quelqu'un qui suit le développement des drivers Gallium radeon pour nous éclairer?

En fait il faut comprendre aussi que vous êtes ici sur un site de libristes. Pas seulement un site sur Linux.
Sur LinuxFr, les projets closed source n'ont pas spécialement la côte. Alors une dépêche qui fait la promotion d'un jeux closed source et qui fait dans l'opportunisme financier, ça en démange plus d'un.
Ce n'est pas qu'ici personne ne fasse de closed source pour vivre. Juste qu'en faire ici la promotion semble déplacé pour quelques personnes (comme les dépêches sur le cinéma). Surtout lorsque la communication semble si bancale et le projet mal ficelé. On sent la jeunesse de l'équipe et le manque flagrant de moyens. Alors forcément, ça trolle.

Tu n'as pas l'air de comprendre que le port forwarding possède un défaut de conception. Celà autorise n'importe qui à rentrer dans ton réseau, contrairement à la méthodologie stun qui ne laisse rentrer que ceux avec qui tu souhaite communiquer.

Cependant, si tu souhaites vérifier par toi même qu'il n'y a pas de défaut de conception sur ton logiciel, lance un client STUN à part. exemple celui-ci : http://sourceforge.net/projects/stun/ Lance le chez toi et on correspondant pour vérifier que le diagnostique ne renvoit pas "symetric NAT".
S'il renvoi autre chose, c'est un bug dans le logiciel,ou bien un problème de configuration de STUN lui même qui ne pointe pas sur les bon serveurs. S'il renvoi "symetric NAT", et que logiciel est sencé supporter ICE, c'est soit qu'il y a un bug logiciel, soit qu'il ne pointe pas sur un serveur TURN valide. S'il n'y a pas de serveur TURN publiquement accessible (pas étonnant, vu le cout d'un serveur), tu peux installer un serveur TURN ou tu le souhaite. par exemple celui-ci: http://turnserver.sourceforge.net/ Si tu n'as pas accès à une machine avec une adresse publique pour installer ce serveur. Il te reste la solution de secourt que tu propose depuis le début. Met ton serveur TURN directement sur ta machine derrière ton NAT et fait du port forwarding dessus. Configure ton logiciel pour l'utiliser et celui de ton correspondant. C'est manuel et compliqué... mais tu n'as besoin de ça, mais comme tu insiste pour avoir une solution avec mains dans camboui, je te la donne. Amuse toi bien...

Tu essaye de communiquer avec qui? La personne en face de toi installe t'elle le même logiciel que toi?
Si tu as un problème avec un logiciel, poste un message sur le forum en décrivant exactement ce qu'il se passe, la topologie de ton réseau et celui de ton correspondant, le message d'erreur qu'il affiche.
Poste ça sur le forum, je jetterais un coup d'oeil ce soir et te donnerais des pistes s'il s'agit d'un problème réseau, de configuration ou logiciel.

Je dirais que tu as trop de lacunes en réseau pour chercher à faire un diagnostique par toi même. Mon conseil, utilise un logiciel qui fait le boulot à ta place et qui utilise le protocole ICE.
S'il ne marche pas, ou ne te dis pas d'ou vient le problème quand ça ne marche pas, c'est un mauvais logiciel, change de logiciel.

Chez toi, ça ne bloquera pas. On te dis qu'aucune box, ni routeur/firewall, ne bloqueront l'usage de STUN et TURN combinés (méthode appelé ICE). Donc utilise un logiciel qui supporte ICE et tu n'auras jamais de souci sans même avoir besoin de port forwarding.
Mieux, contrairement au port forwarding, vous pourrez être plusieurs ordinateurs derrière ton NAT utiliser la visio simultanément, chose impossible avec le port forwarding sans se casser la tête.

Ca n'est pas aléatoire du tout. STUN permet à l'application de savoir à l'avance si ça va marcher et ce de manière automatique.
En effet STUN te donne des information sur la topologie de ton réseau et celui de ton correspondant.
Si tu vois que ça ne va pas passer (en gros sur des réseaux d'entreprises blindés qui de toute façon refuseront d'ouvrir des ports), le logiciel pourra, s'il voit que c'est possible, passer par un relai TURN. Ce n'est donc pas aléatoire, c'est déterministe, et ça fonctionne. Je développe un logiciel de visio conférence dans mon boulot, qui utilise STUN et TURN et à part quant il y a une volonté de tout bloquer sur son firewall par l'administrateur, ça passe sans que l'utilisateur (et l'admin réseau) n'ait quoi que se soit à configurer.

Le problème c'est que la conception des PS3 n'est pas adapté à une utilisation intensive 24h/24 7j/7. J'espère quand même qu'ils n'ont pas été trop bête et qu'ils ont reconditionné les boitiers dans des rack et enlevé les pièces inutiles comme le GPU et le lecteur BR, sinon la durée de vie de leur supercalculateur risque de ne pas dépasser celle de mes ampoules à incandescence.

Pour faire simple, STUN fonctionne au dessus d'UDP. UDP est un protocole non connecté.
Imaginons deux points A et B souhaitant communiquer. Ils sont tous les deux derrière du NAT.
Par un mécanisme algorithmique que l'on nomme STUN et qui emplois 2 serveurs, A arrive connaitre les information sur son son réseau et celui de B. B arrive à obtenir les mêmes informations. A connait donc un port et une adresse publique ou contacter B par UDP. B aussi.

• Ce faisant, A envoit un premier message test à B. Il ne passe pas le NAT, car B n'as jamais envoyé de message à A.
• B envoit un message test à A. celui passe car A lui a envoyé un message auparavant.
• A avant un message test à B. celui passe car B lui a envoyé un message auparavant.

Et voilà... une communication bidirectionnelle vient de se produire entre A et B. Ce mécanisme tombe à l'eau si l'un des NAT est symétrique. Ce type de NAT est rare (aucune box à ma connaissance ne l'implémente), j'en ai rencontré chez des offres pros de FT et certains FAI qui blindent la sécurité et facturent l'administration à l'ouverture de ports. (en gros ils mettent du NAT symétrique pour des raisons de business model et sous couvert de sécurité).

C'est plutôt le fait que les drivers/extensions du kernel sont pluggé comme des modules. On peut de plus enlever et ajouter des modules à la volé. C'est ça la modularité...

Deux mots anglais, c'est sensé impressionner? constexpr est un mécanisme utilisé pour généraliser le système des expressions évaluable à la compilation. C'est un mécanisme type-safe (d'ou ton data-safety?).
Cependant, il n'a rien à voir avec l'implémentation multi-threading du standard si ce n'est dans la librairie ou de nouvelles méthodes constexpr ont été définies. Pour les mécanisme du compilateur, (modèle mémoire etc...), je ne vois toujours pas le rapport.
Je pense que tu raconte n'importe quoi, je n'ai vu nulle part de problèmes d'implémentation du multi-threading dus à constexpr chez les développeurs de gcc.

Je ne vois pas le rapport entre constexpr et le multi-threading. Quand on parle de la partie multi-threading de c++ on ne parle pas seulement de std::thread mais aussi des operations atomiques ajoutées au standard ainsi que les nouvelles définitions du modèle mémoire qui prennent enfin en compte le multi-threading pour expliquer comment doit marcher un programme c++.
Car pour le moment, le multi-threading, ça tombe en marche plus qu'autre chose car rien n'est définit dans c+03 pour expliquer comment doit se comporter un programme c++ face à des accès mémoires concurrents.

Je pense qu'effectivement, si personne à part le créateur n'a modifié l'article en cours de rédaction il devrait être possible pour celui qui l'a crée de l’effacer.