Quand on en arrive à dire que Chrome est moins bien que Firefox parce que Chrome propose une fonctionnalité supplémentaire, on devine rapidement qui est le trolleur :-)
Quant à IE11, même niveau de troll, la vitesse c'était dans le sens des FPS une fois la page chargée (css transition, canvas, etc) (mais c'est ma faute on va dire, j'aurai du préciser). "Il est encore derrière firefox pour tout le reste heureusement" comme je l'ai déjà dit. Mais c'est bien de préciser que les outils de développement d'IE sont en effet bien pourris, on est d'accord.
IE11 c'était pour la vitesse, il est encore derrière firefox pour tout le reste heureusement. Sauf que l'utilisateur final ne voit que la vitesse.
quand Firebug m'indique directement la liste des nœuds
C'est ton point de vu, car pour le coup, Firebug (et même des outils de développement de Firefox) perd une information importante: le type de l'objet. Pour jQuery, cette information n'est pas importante, pour les autres cas, cette information vaut le coup d'être connue. Je préfère avoir cette information, plutot que jamais. Chacun ses goûts.
Chrome permet par contre de simuler un faible débit, Firefox, lui de visualiser le DOM en 3d, chacun ses plus et ses moins, Firefox s'améliore, mais le problème reste les performances quand j'active les outils de développement sur Firefox (en particulier quand il y a des requêtes ajax, css transition, dom manipulation)
Vers la fin, j'ai séparé le point de vu du web-dev et de l'utilisateur car beaucoup pense que les problèmes ne concernent qu'une minorité. Mais ce qu'il faut comprendre, c'est que l'utilisateur va simplement changer de navigateur au lieu d'essayer de convaincre les autres qu'il y a un problème.
En général, quand quelqu'un se plaint, cela veut dire que derrière, en fonction du type de projet (et du prix), il y a x10, x100, x1000, x10000 personnes qui ont réellement été impacté par le problème. Pour un projet open source gratuit, cela peut être plus. Tout à l'heure pour le problème de moz-focus-inner, j'avais trouvé sur github 1 607 990 occurrences (à la louche en comptant les doublons, on va dire qu'il y a 1 000 000 de projets concernés - sur github seulement). Pourtant le bug n'a que 28 votes.
faire les remarques n'est pas pour le plaisir de troller.
Aujourd'hui, si on peut penser que c'est surtout les web-dev qui se plaignent, c'est parcequ'ils ont apprécié ce navigateur et qu'ils veulent continuer le voir à briller. Ce n'est pas par plaisir c'est sûr, c'est même à contre coeur pour moi devoir critiquer le navigateur qui nous a sauvé d'IE6.
Je comprends que vous souhaitez justifier l'état actuel de Firefox et espérer qu'au fond ce n'est pas si grave, que cela va dans tous les cas s'améliorer. J'espère bien que ce sera le cas, je serai moi-même bien attristé de voir Firefox disparaitre. Mais en attendant, l'impression générale est que Firefox est moins bien que d'autre (Chrome, voire IE11).
Il y a toujours des choix à faire dans n'importe quel projet, mais je n'ai rien supposé du tout, ni sur les priorités, ni sur le pourquoi, ni sur le comment, je constate simplement que la situation n'est pas aussi bonne qu'elle pourrait l'être. Le pourquoi est un problème interne, le résultat est la situation actuelle.
Ton explication du CSS montre que tu n'as pas spécialement regardé les bugs, en dehors du problème du zoom (dont je ne connais pas le détail mais dont la régression a été trouvé), la correction des bugs est triviale. Dommage que le 307866 est un regroupement de plusieurs bugs, mais corriger le problème de min-height ne doit nécessiter aucune connaissance en algo de reflow puisque min-height est un alias de height (car si il y a trop d'éléments dans un tableau, la hauteur augmente peu importe la valeur de height, c'est d'ailleurs le workaround de ce bug).
Quant à moz-focus-inner, c'est plus que trivial, c'est un choix (j'espère) de conserver ce comportement mais de conserver le bug ouvert car ce n'est pas standard… Avec un moteur de recherche (soyons fou, avec Google), on trouve des sujets (2013) qui traitent ce problème. Ce problème est particulièrement visible quand on veut qu'une balise A ressemble à celle d'un BUTTON (et que l'on place un bouton et un lien l'un à coté de l'autre). Problème moins problématique grâce aux feuilles de style de reset (voir la fin du fichier) de plus en plus populaire. Mais une recherche sur github est plus amusante avec 1 607 990 occurrences trouvées, avec à chaque fois (ou presque) la réinitialisation à 0 du padding et margin.
Pour un navigateur de nos jours, c'est marcher sur la tête en ne respectant pas le padding/margin spécifié par le développeur. Même constat pour ccs2 avec min-height. Il faut faire quoi pour que Firefox se bouge ? Un nouveau test Acid ? Si il n'y a que la motivation de celui qui a la plus grosse qui est motivante, il faudra peut-être en arriver là.
Je n'ai pas sorti ces trois bugs de mon chapeau, j'en connais d'autres de bugs, mais pour rester dans le fil du sujet, ceux-là sont la base d'un navigateur, tout comme les Webforms.
Pour le bla bla que tu me sors aujourd'hui sur la gestion de projet, ce n'est qu'une question de priorité. Cela me fait penser à: tant qu'il y a plus de nouveaux clients que de clients qui partent, alors on continue. Le genre d'entreprise qui misent tout sur les killer features et le marketing. Quand Firefox perd 50 utilisateurs, il y a peut-être derrière ce nombre 200 personnes déçues et 150 nouvelles personnes ravies d'essayer ce logiciel.
Moi aussi je peux sortir des généralités (du blabla) sur les projets, où les gens se donnent à fond au début puis c'est la relache, où la super équipe de dev qui a fait décoller le projet travaille ensuite sur autre chose (tout le monde ne fait pas 10 ans la même chose) (FirefoxOS?), où l'équipe qui reprend le projet n'est pas motivé (personne n'est motivé pour la correction de bug ou l'évolution de code crade), où le nouveau chef est un abruti qui démotive tout le monde, où le mec qui s'occupe du bug-tracker n'utilise pas son cerveau et attend bêtement le seuil de votes atteint avant de faire corriger un bug. Et comme tout gros projets, des maillons faibles il y en a partout, même dans les projets open source.
Mais si Mozilla veut s'amuser à faire un OS avec tout ce qui va avec, c'est tant mieux pour eux. Sauf qu'aujourd'hui j'entends "- putain Firefox il rame à mort avec le webmail de la boite; - quoi ?! regarde sur Chrome, c'est ultra fluide". Avant les développeurs faisaient de la publicité sur leur site pour Firefox, par pur idéologie ou peut-être simplement par simple haine d'IE6… aujourd'hui je vois des développeurs faire de la pub pour Chrome, gratuitement. Peut-être, qu'arriver à ce point, il faudrait réfléchir…
En parlant de killer features, j'estime que les webforms en sont une. A l'époque je suivais la page (plus à jour bien sûr) de la personne en charge de cela… belle déception face à Chrome.
Après la base du navigateur, je peux aussi discuter de Firefox Hello, que j'estime moins essentiel mais utile pour l'utilisateur (contrairement à ES6). Chez moi, WebRTC fait planter Firefox, tout simplement. Un plantage comme je n'en avais jamais vu depuis longtemps, un beau crash, et ce, depuis bien avant Firefox Hello. En tant que "fan" de firefox, je suis les releases notes, y compris celles des versions beta et aurora. Je m'étais dis "cool, c'est une bonne chose et ils ont du faire un effort de stabilisation sur le webRTC". Perdu! C'était même une double déception.
Primo, il y a eu le fail marketing, après la mise à jour, je me suis dis que j'allais tester ce Firefox Hello. Premier problème, rien n'avait changé dans mon interface. Je regarde le lien d'explication de la release note. Il est juste dit: "by clicking on the ‘chat bubble’ icon under the customize menu." mais je ne vois rien… Je continue la navigation pour trouver enfin une capture d'écran. Mais en vain, je n'arrive à pas à acceder à la fonctionnalité.
Mais j'insiste, je trouve enfin l'article qui me dit où est le bouton hello. If you don't see the Hello button […] please check back in a few weeks. C'est cool non ? Ils auraient pas pu le dire AVANT ? Dans la release note par exemple ? La version française de l'aide précise au moins comment forcer l'activation. Il faut bien noter que je n'ai pas été le seul dans cette situation, à chercher ce fameux bouton sans le trouver. C'est ici (linuxfr) que j'apprends que c'est visible pour 10% des utilisateurs, faire du "Buzz" avec 90% de déçus, c'est pas mal quand même (tout le monde ne lit pas la release note, mais beaucoup de sites ont parlé de la fonctionnalité).
Secondo, coté technique, j'ai lancé Firefox Hello, et crash au moment de l'autorisation d'accès à la webcam. Rien n'a changé. Ce n'est pas acceptable quand on sait qu'avec le plug-in flash de Firefox, la webcam marche très bien, qu'avec le plug-in flash de Chrome, la webcam marche très bien, qu'avec webrtc de Chrome, cela marche très bien, mais avec webrtc de Firefox => CRASH (vu le message d'erreur cela sent l'exception non gérée)
Pour les outils de développement, j'ai lu tout à l'heure Firebug… c'était une blague ? Firebug mieux que les outils de Chrome ? On est dans la grosse blague. Firefox a quand même depuis le temps ses propres outils de développement (CTRL+ALT+I quand ça veut bien marcher, cela vient de bugger sur la page de linuxfr… et même un WebIDE comme expliqué dans cette news, mais pour FirefoxOS) qui ont mis fin au calvaire de Firebug (Firebug était même déprécié à un certain moment sur certaines plateformes). Mais contrairement à Chrome, les outils de Firefox font considérablement tout ralentir. Alors pour déboguer une simple page web, c'est ok, pour une application web un peu lourde c'est le drame (et là, direction Chrome).
Pour résumer, Firefox accumule les problèmes. Si la majorité ne concerne que le web-dev qui ronchonne dans son coin, quand on assemble tout, cela donne, pour l'utilisateur classique:
1. Les performances mauvaises
2. Les web-dev qui font la pub gratuite pour Chrome au lieu de Firefox (au moment du choix d'alternative pour remplacer IE par exemple)
3. Les crashs occasionnels (je ne suis surement pas tout seul)
4. Le rendu css2 raté (d'après 307866) (à comparer avec Chrome)
pour le web-dev:
5. Les outils de développement non optimisés
6. Des workarounds spécifiques firefox
7. La déception de voir Chrome plus en avance que Firefox sur l'HTML5 (cf webforms)
8. La possibilité d'imposer Chrome (ou Chromium) pour les back-office au lieu de Firefox (des entreprises qui font et vendent du dev pour un navigateur précis, ça existe)
Le paysage n'est quand même pas si dramatique que cela. C'est juste la sonnette d'alarme, mais tout comme "rupteur" l'a dit, il y a de moins en moins de personne avec des oeillères. Le coup fatal serait qu'Internet Explorer se mette à implémenter les nouveautés HTML5 avant Firefox.
A la fin, le marketing de Firefox se résumera a un troll de haut niveau, comme ici de la part d'un "Mozilla hacker" (Choose Firefox Now, Or Later You Won't Get A Choice, … you must stop using Chrome now). Les commentaires anglais sous-entendent malheureusement que Firefox est à la traine. Mais la bonne nouvelle, est qu'il peut rattraper ce retard :-)
je trouve juste dommage que la base même d'un navigateur soit oubliée.
Oui, la base même d'un navigateur est oubliée… mais bon, tu comprends bien qu'ils ont autre chose à faire les dev de firefox, alors si tu ne votes pas tu n'as que ce que tu mérites, ok ⸮
C'est évidemment des conneries, et des expériences négatives comme toi, il y en a plein. Ce n'est pas pour rien que Firefox perd en part de marché.
Mais comme cela a été dit dans d'autres commentaires, il y a beaucoup de choses qui ne sont pas encore validées. Par contre, ce qui provoque une déception de la part de Firefox, c'est d'une part d'avoir habitué les développeurs à être au top sur les nouveautés, même en cours de rédaction, et d'autre de part de voir que c'est Chrome qui possède une avance considérable là dessus (plus de 2 ans d'écart pour l'input type number).
D'autant plus que concernant les Webforms, cela possède un réel impact sur l'expérience utilisateur qui ne peut être que bénéfique: plus besoin de magouilles javascript ou plug-in jQuery lourdingue, celles-ci deviennent des polyfills. Par contre, faire évoluer le javascript pour supporter les brouillons de ES6, l'utilisateur n'y verra rien du tout et c'est à mon avis moins important, mais c'est bien de le faire aussi.
Il est à noter que le type date et time sont standardisés et ne sont pas supportés par Firefox. Par contre le type datetime n'est pas encore validé w3c et a d'ailleurs été renommé en datetime-local. Mais l'ironie est que c'est quand même supporté sur la version mobile (au bout de 8 ans quand même), comme quoi ils ont le sens de la réalité, car saisir une date sur mobile sans Webforms c'est un échec niveau interface utilisateur (hors astuce javascript)
Mais avant le HTML5, il y a d'autres choses que Firefox néglige et qui sont pourtant la base d'un navigateur. Parmi ceux que j'ai rencontrés (pour réaliser une simple admin), il y a:
- 307866, depuis 2005, soit 9 ans (et 4 doublons): la propriété css2 min-height sur un tableau ne fonctionne pas. Il existe une solution heureusement, mais le bug est là à l'abandon, avec occasionnellement des relances d'utilisateurs.
- 140562, depuis 2002, soit 12 ans (et 14 doublons): c'est le bug collector, où il faut modifier la propriété CSS -moz-focus-inner si l'on souhaite obtenir une dimension qui respecte le boxmodel (sinon extra padding à en devenir fou).
- 410959, depuis 2008, soit 6 ans (et 6 doublons): avec le high dpi, le zoom est de plus en plus courant, mais cela provoque des bugs d'affichage grossier, dans mon cas, toutes les bordures d'une colonne étaient correctes, sauf une qui faisait anormalement le double en taille. On sent dans les commentaires la volonté d'aider, Elbart en avril 2014 qui trouve la régression, et puis, c'est tout, plus rien…
Ce qui est amusant est que dans chacun des bugs report, les utilisateurs sont sur le cul:
307866 (min-height pour l'élément table):
Any news on this bug, this is still current en very much annoying. Any idea on when it will be fixed, it seems to take a long time…
I do not understand why it takes so long to fix "min-height" because the "height" property is interpreted as minimum height on tables anyway (it's like an alias).
140562 (-moz-focus-inner)
it’s intransparent, and a huge element of surprise for webdevs who want to control how focus looks.
I think so, yes. It would really confuse users.
410959 (Zoom):
2014 and this is still an issue? Wow.
Firefox ne veut plus être réglo sur les détails, maintenant il y a des workarounds spécifiques Firefox. Mais que faut-il faire ? Ah, voter ? Lancer une grande campagne de votes sur les bugs triviaux de Firefox pour éviter des workarounds spécifiquement pour ce navigateur ? Ah en fait non, la solution est de réduire les parts de marché. Mais même pas besoin de l'aide du bouche à oreille pour réduire les parts de marché, les faibles performances de Firefox s'en sont déjà chargées (c'est du vécu et toujours d'actualité).
Je suis également pro-mozilla, j'ai fais les recherches nécessaires pour les bugs, avec les votes qui vont bien, j'ai même contacté un développeur (à la base pour les problèmes de performance), mais ensuite on laisse juste tomber quand tout le monde s'en fou.
mais qu'est-ce qui te pousse à te plaindre ? Pourquoi le faire ici plutôt qu'à ceux qui peuvent y faire quelque chose ?
…
attends j'ai loupé un épisode ?
Oui, tu as loupé un épisode XD Cela me fait penser à une sorte de "dou tu critik firefox twa, té ki dabor", alors que tous les commentaires de cette dépêche donnent leur avis dessus. Mais bon, cher rupteur, tu arrives comme ça, tu critiques direct firefox, ça va pas la tête ^
Peut-être faut-il suggérer à Freedesktop d'ajouter ~/.bordel quand une application mélange données et configuration xD
Il ne faut pas prendre la recommandation de Freedesktop comme la meilleure pratique à suivre. Personnellement, je trouve "~/.local/share" incohérent comme chemin pour des données que Freedesktop qualifie de "user specific data" (".local" est redondant car on est déjà dans ~, et "share" est un non sens car c'est justement spécifique à l'utilisateur). Mais c'est surement pour ressembler à "/usr/local/share/".
Pour ma part, je m'attends à trouver les fichiers de config dans le dossier de config, avec en bonus directement les données au même endroit (et si c'est le cas ça m'arrange), sinon à aller les chercher dans ~/.local/share. Dans le pire des cas, je regarde dans ~.
Si je fouille dans mon .config, je vois qu'il y a déjà Chromium qui mélange tout dedans, Transmission, Inkscape, LibreOffice, KVirc, etc. Après c'est sûr que ce n'est pas parce que d'autres le font, qu'il faut faire pareil.
Qu'il soit difficile de choisir entre tout mettre dans le dossier des données ($XDG_DATA_HOME) et tout mettre dans le dossier des configurations ($XDG_CONFIG_HOME) ne doit fort heureusement pas obligatoirement conduire à créer son propre dossier de config/données n'importe où.
Par contre, choisir de pourrir le $HOME c'est facile. Les spécifications de Freedesktop permettent justement d'éviter la situation d'avoir 800 fichiers/dossiers qui commencent par un "." dans le dossier $HOME.
Les spécifications de Freedesktop ne sont heureusement que des recommandations, ce qui permet toujours de faire ce que l'on veut, cela permet donc de mélanger données et configuration dans $XDG_DATA_HOME (ou $XDG_CONFIG_HOME).
Et quand on y pense, un fichier de configuration c'est juste une donnée spéciale. Quand on a pas le choix, tout irait dans le dossier des données, bien que je constate que la majorité des applications mélangent tout dans le dossier de configuration.
Cette distribution s'adresse à des personnes qui s'y "connaissent" et tout problème est à cause de l'utilisateur car il n'aura pas fait attention à tel ou tel message dans les logs, ou car il n'a pas suivi les news, ou pas lu le wiki, ou seulement lu à moitié.
Partant de ce principe, en ajoutant le classique "chez moi ça marche", il est difficile d'affirmer ici qu'il peut exister des problèmes car tout problème provient de l'interface chaise/clavier (de l'utilisateur).
Il faut savoir que les problèmes dépendent aussi des paquets installés, en particulier la source (AUR, community, extra?). Car tous les mainteneurs ne font pas la chose correctement et se reposent souvent sur l'idée que c'est une distribution pour des gens qui s'y connaissent (du coup ils peuvent faire de la merde plus facilement).
A part quelques problèmes liés aux mainteneurs/paquets (oui ça existe vraiment), tous les autres problèmes que j'ai eu proviennent d'upstream. Par exemple, avec GTK3, TrueCrypt (update de wxgtk de 2.8 vers 3.0) veut m'ouvrir nautilus au lieu de dolphin comme cela avait toujours été le cas avant (car je suis sur KDE). Une sorte de /bin/nautilus codé en dur dans le code, c'était une énorme régression, mais ce n'était pas la faute d'Archlinux dont l'objectif est de proposer des logiciels à jour…
Ceci dit, ils font quand même des tests, l'ouverture de l'explorateur de fichiers par wxgtk sur KDE n'avait pas du être testé. Ce problème qui date d'avril n'est toujours pas corrigé upstream, je ne sais pas si c'est à cause de wxgtk qui possède "/bin/nautilus" en dur (je n'ai pas trouvé cette chaine dans le code source), ou GTK3 (je penche plus vers cela). Quoi qu'il en soit, c'est un problème upstream. La solution consiste à créer une sorte de lien symbolique de /bin/nautilus vers dolphin. Mais j'aurai pu pester en disant qu'un mainteneur aurait pu prévoir ce lien symbolique pour moi xD
J'ai également eu d'autres problèmes, comme une mise à jour du driver nvidia qui a empêché le serveur X de se lancer au prochain démarrage. En attendant de trouver plus de temps, j'ai interdit la mise à jour des paquets concernés.
Tout ça pour dire qu'avec Archlinux, le problème n'est pas tout le temps entre l'interface chaise/clavier, le problème n'est pas Archlinux non plus, mais surtout les logiciels. C'est surement pour cette raison que certaines distributions patchent à mort les logiciels intégrés.
Et je confirme donc que chaque mise à jour peut potentiellement faire perdre du temps. Cela n'arrive pas souvent, à vu de nez pour moi c'est un petit problème tous les trois mois et un gros par an.
A mon avis il ne se base pas sur des chiffres, mais sur une vision à très long terme. Avec le temps il y aura de moins en moins de personne utile grace aux gains de productivité, et donc de plus en plus de personnes seront pauvres.
Imaginons dans un futur où seulement 20% de la population doit travailler grâce à cet énorme gain de productivité:
Soit on ne "partage" pas ce gain de productivité, et ce sont tout le temps les mêmes personnes qui travaillent, et qui sont donc les plus riches. Les 80% restants sont sans emplois, donc pauvre.
Soit on "partage" ce gain de productivité, avec par exemple un roulement des personnes qui travaillent. Au lieu de travailler tous les jours, on ne travaillerait qu'un seul jour par semaine. Ou au lieu de travailler tous les mois, on ne travaillerait qu'un mois sur 5. Ou par exemple encore, mettre en place un "revenu de base/universel".
Ceci est bien sûr un exemple exagéré pour montrer l'idée.
mais il semble qu'une grosse majorité préfère travailler plus pour gagner plus, plutôt que de travailler moins pour gagner moins.
Cela dépend si travailler moins signifie diviser par deux son salaire pour le partager avec une autre personne, ou travailler vraiment 35h au lieu de 39h quand l'entreprise le veut bien. Pour les personnes que je connais, elles préférent travailler moins en général.
Ou pas. J'ai l'exemple précis d'une personne qui jouait à Diablo 3 et dont le jeu ramait par moment sur son PC portable. Jusqu'au jour où il avait découvert qu'il pouvait indiquer à Windows qu'il voulait le mode performance maximale (par effet de bord son PC chauffait plus du coup). Ce jour là je lui ai dis que c'était pareil sur linux, on choisit le mode que l'on veut (powersave, ondemand, performance). Ce n'est pas pour rien que ces trois modes existent, sinon seul ondemand existerait si c'était parfait.
Je veux que mon PC économise le maximum d'électricité mais qu'il me fournisse la puissance maximale quand j'en ai besoin
Je veux la même chose, mais quand on n'a pas le choix et qu'on tombe à moins de 1fps dans le jeu en fonction des séquences et qu'on constate que c'est à cause du gouverneur, cela met juste la haine à tel point que j'avais été déçu sur le coup.
Personne ne veut se préoccuper de son gouverneur, moi le premier, mais des fois on n'a pas le choix. Alors c'est bien qu'ils améliorent "ondemand" car personnellement cela m'embette et je trouve cela ridicule de changer de mode de gouvernance quand je veux jouer.
C'est juste qu'il n'y a rien d'étonnant qu'en améliorant le gouverneur par défaut ondemand, alors cela améliore les performances pour atteindre une performance proche ou égale au gouverneur "performance". D'où ma déception en lisant l'article par rapport à son titre, que je renommerai en "Mise à jour du gouverneur ondemand pour améliorer les performances globales". Après c'est un journal écrit à partir d'un article de phoronix… xD
Il n'y a rien d'étonnant, quand on sait qu'on veut le maximum de performance, autant changer le gouverneur pour "performance" au lieu de faire confiance à "ondemand".
Ce problème décrit de "ondemand" est bien connu de certains jeux, en particulier sous wine. Du coup, pour ceux qui changent déjà à la main leur gouverneur, il n'y aura aucun gain de performance, par contre cela leur évitera de changer de gouverneur avant et après la session de jeu.
J'aurai utilisé un titre de journal moins sensationnel du coup. Plutot du genre: "amélioration du gouverneur ondemand" ou bien "correction d'un bug de linux" XD. Et du coup cela améliore les performances globales, pas seulement graphiquement.
Le vol du cookie d'authent permet de voler votre identité
Pas toujours. Certains sites permettent de limiter la session à une seule IP. Le problème est alors résolu… sauf pour ceux avec une IP public dynamique (derrière des proxies par exemple). C'est pour cela que ces sites proposent de désactiver cette sécurité supplémentaire.
Une fois j'ai eu besoin d'une version très récente d'un logiciel. Et je n'étais pas le seul, car il s'agissait de Mumble (logiciel VoIP en gros) qui avait changé son protocole, donc utiliser la dernière version était nécessaire pour fonctionner avec les serveurs qui avaient été mis à jour.
Le hic, c'est que le binaire n'existait que pour Windows… Je me souviens encore du topic dans leur forum, le développeur s'explique dans le deuxième message:
With linux this isn't so easy. You'd have to release and maintain a packet for every distro / version. (Ubuntu 9.10/8.10/8.04 RedHat….and so on). This is why you have packet maintainers for the different OSses that feed your releases into the source tree of the distro.
We don't do that for snapshots/pre release version. So you either have to self-compile or find a packet from someone who did. If you have a specific request for a distribution you might be lucky and someone in this forum can give it to you.
Les développeurs ne veulent pas perdre de temps à générer les paquets pour tout le monde, ils fournissent le code source et les mainteneurs se débrouillent (bon d'accord, dans la citation il parle de snapshot et pre release). Après c'est aux utilisateurs de faire pression aux mainteneurs pour l'avoir le plus rapidement possible.
Ce mainteneur entre le développeur et l'utilisateur est pénalisant pour linux, même si le système de dépôt en lui-même est un gros avantage. Le développeur devrait pouvoir fournir un binaire linux facilement en attendant qu'un mainteneur se donne la peine. Peut-être quitte à ce que se soit un binaire mal foutu avec toutes les dépendances dedans…
Je veux bien croire que linuxfr c'est la crème de la crème, mais pour ce cas là, je doute que ce soit à cause de ma machine. C'est un simple GET de l'url https://linuxfr.org/tableau-de-bord, pour l'occasion j'ai testé avec telnet sur la version non https du coup:
GET /tableau-de-bord HTTP/1.0
Host: linuxfr.org
Cookie: linuxfr.org_session=<cookie>
HTTP/1.1 500 Internal Server Error
Server: nginx/0.7.67
Date: Fri, 01 Jun 2012 19:20:00 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1586
Connection: close
(suivi du contenu de la page)
Aucun code n'est sans bugs :-) Pour tes questions, j'y ai répondu au dessus il y a quelques minutes.
Peu importe le navigateur, testé avec firefox et chrome sous windows, firefox et chromium sous linux. Avec javascript et sans extensions farfelues.
En y réfléchissant, c'est peut-être parce que j'avais posté un commentaire sur un article du wiki qui (l'article) a été supprimé.
Je n'ai pas plus d'information à fournir. C'est reproductible tout le temps avec mon compte. Cela fait plus de trois mois maintenant, mais je reproduis le bug assez souvent pour vérifier si ça remarche et générer des traces.
Pour Chrome 18 et Firefox 12 sur WinXP, il y a un bug d'affichage sur la page d'accueil (voir ici) qui n'est pas présent dans la "full demo". La zone d'édition pour certaines colonnes est décalée à droite et empiète sur la colonne voisine.
Cela me fait penser à la mise à jour assez récente (en mars) du paquet ufw, les fichiers de configuration ont été déplacé (de /lib vers /usr) mais le script d'installation n'a pas prévu de les copier au nouvel endroit… Beaucoup et à vrai dire tout le monde utilisant ce paquet s'est retrouvé à devoir les copier à la main. Et pour ceux qui n'ont pas vu les avertissements lors de là mise à jour, des topics comme celui-ci ont fleuris.
On peut voir les changements ici, et s'apercevoir qu'un "cp" des anciennes configurations n'était pas compliqué à faire. C'est la faute du mainteneur bien évidemment, mais cela fait parti des petits détails qui énervent.
Ceci me rappelle ce blog. Au fil du temps, (arch) linux c'est toujours bien, mais qu'est ce que c'est chiant.
Le cerveau humain n'étant pas spécialement conçu pour travailler avec du texte, c'est pour cela que ce genre de faille arrive. Alors si le hash visuel est une matrice à 32 cases, dont chaque case correspond à un quartet (donc 16 couleurs possibles par case), il me semble qu'un humain détectera plus rapidement des hashs différents (pour peu que l'image ne soit pas microscopique)
Après dans l'exemple de VizHash, il y a des formes/courbes, ceci peut être utilisé pour différencier deux hashs trop ressemblant (je pense à 1 ou 2 quartets de différence). Or je constate que l'outil Fuzzy Fingerprint génère des hashs avec énormément de différence. Donc je pense qu'un hash visuel peut être suffisant pour certains domaines (du moins pour le grand public), mais c'est sûr que ce sera moins bien qu'une comparaison textuelle (qui sera toujours utile en entreprise).
Mais rien n'empêche de mettre les deux, un hash visuel et un écrit :-)
Pourquoi en faisant un clic droit sur du texte je peux recharger mais pas sur une image ? Les deux sont des éléments d'information de la page.
Je viens de cliquer droit du texte sélectionné, je ne peux pas recharger la page.
Qui a parlé de texte sélectionné ? Un click simple sur du texte permet d'actualiser la page (car considéré comme un click sur la page), alors qu'un click sur une image ne le permet pas. Pour moi, cela me semble presque logique (car habitué?), mais ce n'est peut-être pas le cas pour tout le monde.
[^] # Re: Et le support standard du HTML 5 ??
Posté par Thrillseeker . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 2.
Quand on en arrive à dire que Chrome est moins bien que Firefox parce que Chrome propose une fonctionnalité supplémentaire, on devine rapidement qui est le trolleur :-)
Quant à IE11, même niveau de troll, la vitesse c'était dans le sens des FPS une fois la page chargée (css transition, canvas, etc) (mais c'est ma faute on va dire, j'aurai du préciser). "Il est encore derrière firefox pour tout le reste heureusement" comme je l'ai déjà dit. Mais c'est bien de préciser que les outils de développement d'IE sont en effet bien pourris, on est d'accord.
[^] # Re: Et le support standard du HTML 5 ??
Posté par Thrillseeker . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à -1.
IE11 c'était pour la vitesse, il est encore derrière firefox pour tout le reste heureusement. Sauf que l'utilisateur final ne voit que la vitesse.
C'est ton point de vu, car pour le coup, Firebug (et même des outils de développement de Firefox) perd une information importante: le type de l'objet. Pour jQuery, cette information n'est pas importante, pour les autres cas, cette information vaut le coup d'être connue. Je préfère avoir cette information, plutot que jamais. Chacun ses goûts.
Chrome permet par contre de simuler un faible débit, Firefox, lui de visualiser le DOM en 3d, chacun ses plus et ses moins, Firefox s'améliore, mais le problème reste les performances quand j'active les outils de développement sur Firefox (en particulier quand il y a des requêtes ajax, css transition, dom manipulation)
[^] # Re: Et le support standard du HTML 5 ??
Posté par Thrillseeker . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 2.
Vers la fin, j'ai séparé le point de vu du web-dev et de l'utilisateur car beaucoup pense que les problèmes ne concernent qu'une minorité. Mais ce qu'il faut comprendre, c'est que l'utilisateur va simplement changer de navigateur au lieu d'essayer de convaincre les autres qu'il y a un problème.
En général, quand quelqu'un se plaint, cela veut dire que derrière, en fonction du type de projet (et du prix), il y a x10, x100, x1000, x10000 personnes qui ont réellement été impacté par le problème. Pour un projet open source gratuit, cela peut être plus. Tout à l'heure pour le problème de moz-focus-inner, j'avais trouvé sur github 1 607 990 occurrences (à la louche en comptant les doublons, on va dire qu'il y a 1 000 000 de projets concernés - sur github seulement). Pourtant le bug n'a que 28 votes.
Aujourd'hui, si on peut penser que c'est surtout les web-dev qui se plaignent, c'est parcequ'ils ont apprécié ce navigateur et qu'ils veulent continuer le voir à briller. Ce n'est pas par plaisir c'est sûr, c'est même à contre coeur pour moi devoir critiquer le navigateur qui nous a sauvé d'IE6.
[^] # Re: Et le support standard du HTML 5 ??
Posté par Thrillseeker . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 6.
Je comprends que vous souhaitez justifier l'état actuel de Firefox et espérer qu'au fond ce n'est pas si grave, que cela va dans tous les cas s'améliorer. J'espère bien que ce sera le cas, je serai moi-même bien attristé de voir Firefox disparaitre. Mais en attendant, l'impression générale est que Firefox est moins bien que d'autre (Chrome, voire IE11).
Il y a toujours des choix à faire dans n'importe quel projet, mais je n'ai rien supposé du tout, ni sur les priorités, ni sur le pourquoi, ni sur le comment, je constate simplement que la situation n'est pas aussi bonne qu'elle pourrait l'être. Le pourquoi est un problème interne, le résultat est la situation actuelle.
Ton explication du CSS montre que tu n'as pas spécialement regardé les bugs, en dehors du problème du zoom (dont je ne connais pas le détail mais dont la régression a été trouvé), la correction des bugs est triviale. Dommage que le 307866 est un regroupement de plusieurs bugs, mais corriger le problème de min-height ne doit nécessiter aucune connaissance en algo de reflow puisque min-height est un alias de height (car si il y a trop d'éléments dans un tableau, la hauteur augmente peu importe la valeur de height, c'est d'ailleurs le workaround de ce bug).
Quant à moz-focus-inner, c'est plus que trivial, c'est un choix (j'espère) de conserver ce comportement mais de conserver le bug ouvert car ce n'est pas standard… Avec un moteur de recherche (soyons fou, avec Google), on trouve des sujets (2013) qui traitent ce problème. Ce problème est particulièrement visible quand on veut qu'une balise A ressemble à celle d'un BUTTON (et que l'on place un bouton et un lien l'un à coté de l'autre). Problème moins problématique grâce aux feuilles de style de reset (voir la fin du fichier) de plus en plus populaire. Mais une recherche sur github est plus amusante avec 1 607 990 occurrences trouvées, avec à chaque fois (ou presque) la réinitialisation à 0 du padding et margin.
Pour un navigateur de nos jours, c'est marcher sur la tête en ne respectant pas le padding/margin spécifié par le développeur. Même constat pour ccs2 avec min-height. Il faut faire quoi pour que Firefox se bouge ? Un nouveau test Acid ? Si il n'y a que la motivation de celui qui a la plus grosse qui est motivante, il faudra peut-être en arriver là.
Je n'ai pas sorti ces trois bugs de mon chapeau, j'en connais d'autres de bugs, mais pour rester dans le fil du sujet, ceux-là sont la base d'un navigateur, tout comme les Webforms.
Pour le bla bla que tu me sors aujourd'hui sur la gestion de projet, ce n'est qu'une question de priorité. Cela me fait penser à: tant qu'il y a plus de nouveaux clients que de clients qui partent, alors on continue. Le genre d'entreprise qui misent tout sur les killer features et le marketing. Quand Firefox perd 50 utilisateurs, il y a peut-être derrière ce nombre 200 personnes déçues et 150 nouvelles personnes ravies d'essayer ce logiciel.
Moi aussi je peux sortir des généralités (du blabla) sur les projets, où les gens se donnent à fond au début puis c'est la relache, où la super équipe de dev qui a fait décoller le projet travaille ensuite sur autre chose (tout le monde ne fait pas 10 ans la même chose) (FirefoxOS?), où l'équipe qui reprend le projet n'est pas motivé (personne n'est motivé pour la correction de bug ou l'évolution de code crade), où le nouveau chef est un abruti qui démotive tout le monde, où le mec qui s'occupe du bug-tracker n'utilise pas son cerveau et attend bêtement le seuil de votes atteint avant de faire corriger un bug. Et comme tout gros projets, des maillons faibles il y en a partout, même dans les projets open source.
Mais si Mozilla veut s'amuser à faire un OS avec tout ce qui va avec, c'est tant mieux pour eux. Sauf qu'aujourd'hui j'entends "- putain Firefox il rame à mort avec le webmail de la boite; - quoi ?! regarde sur Chrome, c'est ultra fluide". Avant les développeurs faisaient de la publicité sur leur site pour Firefox, par pur idéologie ou peut-être simplement par simple haine d'IE6… aujourd'hui je vois des développeurs faire de la pub pour Chrome, gratuitement. Peut-être, qu'arriver à ce point, il faudrait réfléchir…
En parlant de killer features, j'estime que les webforms en sont une. A l'époque je suivais la page (plus à jour bien sûr) de la personne en charge de cela… belle déception face à Chrome.
Après la base du navigateur, je peux aussi discuter de Firefox Hello, que j'estime moins essentiel mais utile pour l'utilisateur (contrairement à ES6). Chez moi, WebRTC fait planter Firefox, tout simplement. Un plantage comme je n'en avais jamais vu depuis longtemps, un beau crash, et ce, depuis bien avant Firefox Hello. En tant que "fan" de firefox, je suis les releases notes, y compris celles des versions beta et aurora. Je m'étais dis "cool, c'est une bonne chose et ils ont du faire un effort de stabilisation sur le webRTC". Perdu! C'était même une double déception.
Primo, il y a eu le fail marketing, après la mise à jour, je me suis dis que j'allais tester ce Firefox Hello. Premier problème, rien n'avait changé dans mon interface. Je regarde le lien d'explication de la release note. Il est juste dit: "by clicking on the ‘chat bubble’ icon under the customize menu." mais je ne vois rien… Je continue la navigation pour trouver enfin une capture d'écran. Mais en vain, je n'arrive à pas à acceder à la fonctionnalité.
Mais j'insiste, je trouve enfin l'article qui me dit où est le bouton hello. If you don't see the Hello button […] please check back in a few weeks. C'est cool non ? Ils auraient pas pu le dire AVANT ? Dans la release note par exemple ? La version française de l'aide précise au moins comment forcer l'activation. Il faut bien noter que je n'ai pas été le seul dans cette situation, à chercher ce fameux bouton sans le trouver. C'est ici (linuxfr) que j'apprends que c'est visible pour 10% des utilisateurs, faire du "Buzz" avec 90% de déçus, c'est pas mal quand même (tout le monde ne lit pas la release note, mais beaucoup de sites ont parlé de la fonctionnalité).
Secondo, coté technique, j'ai lancé Firefox Hello, et crash au moment de l'autorisation d'accès à la webcam. Rien n'a changé. Ce n'est pas acceptable quand on sait qu'avec le plug-in flash de Firefox, la webcam marche très bien, qu'avec le plug-in flash de Chrome, la webcam marche très bien, qu'avec webrtc de Chrome, cela marche très bien, mais avec webrtc de Firefox => CRASH (vu le message d'erreur cela sent l'exception non gérée)
Pour les outils de développement, j'ai lu tout à l'heure Firebug… c'était une blague ? Firebug mieux que les outils de Chrome ? On est dans la grosse blague. Firefox a quand même depuis le temps ses propres outils de développement (CTRL+ALT+I quand ça veut bien marcher, cela vient de bugger sur la page de linuxfr… et même un WebIDE comme expliqué dans cette news, mais pour FirefoxOS) qui ont mis fin au calvaire de Firebug (Firebug était même déprécié à un certain moment sur certaines plateformes). Mais contrairement à Chrome, les outils de Firefox font considérablement tout ralentir. Alors pour déboguer une simple page web, c'est ok, pour une application web un peu lourde c'est le drame (et là, direction Chrome).
Pour résumer, Firefox accumule les problèmes. Si la majorité ne concerne que le web-dev qui ronchonne dans son coin, quand on assemble tout, cela donne, pour l'utilisateur classique:
1. Les performances mauvaises
2. Les web-dev qui font la pub gratuite pour Chrome au lieu de Firefox (au moment du choix d'alternative pour remplacer IE par exemple)
3. Les crashs occasionnels (je ne suis surement pas tout seul)
4. Le rendu css2 raté (d'après 307866) (à comparer avec Chrome)
pour le web-dev:
5. Les outils de développement non optimisés
6. Des workarounds spécifiques firefox
7. La déception de voir Chrome plus en avance que Firefox sur l'HTML5 (cf webforms)
8. La possibilité d'imposer Chrome (ou Chromium) pour les back-office au lieu de Firefox (des entreprises qui font et vendent du dev pour un navigateur précis, ça existe)
Le paysage n'est quand même pas si dramatique que cela. C'est juste la sonnette d'alarme, mais tout comme "rupteur" l'a dit, il y a de moins en moins de personne avec des oeillères. Le coup fatal serait qu'Internet Explorer se mette à implémenter les nouveautés HTML5 avant Firefox.
A la fin, le marketing de Firefox se résumera a un troll de haut niveau, comme ici de la part d'un "Mozilla hacker" (Choose Firefox Now, Or Later You Won't Get A Choice, … you must stop using Chrome now). Les commentaires anglais sous-entendent malheureusement que Firefox est à la traine. Mais la bonne nouvelle, est qu'il peut rattraper ce retard :-)
[^] # Re: Et le support standard du HTML 5 ??
Posté par Thrillseeker . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 10.
Oui, la base même d'un navigateur est oubliée… mais bon, tu comprends bien qu'ils ont autre chose à faire les dev de firefox, alors si tu ne votes pas tu n'as que ce que tu mérites, ok ⸮
C'est évidemment des conneries, et des expériences négatives comme toi, il y en a plein. Ce n'est pas pour rien que Firefox perd en part de marché.
Mais comme cela a été dit dans d'autres commentaires, il y a beaucoup de choses qui ne sont pas encore validées. Par contre, ce qui provoque une déception de la part de Firefox, c'est d'une part d'avoir habitué les développeurs à être au top sur les nouveautés, même en cours de rédaction, et d'autre de part de voir que c'est Chrome qui possède une avance considérable là dessus (plus de 2 ans d'écart pour l'input type number).
D'autant plus que concernant les Webforms, cela possède un réel impact sur l'expérience utilisateur qui ne peut être que bénéfique: plus besoin de magouilles javascript ou plug-in jQuery lourdingue, celles-ci deviennent des polyfills. Par contre, faire évoluer le javascript pour supporter les brouillons de ES6, l'utilisateur n'y verra rien du tout et c'est à mon avis moins important, mais c'est bien de le faire aussi.
Il est à noter que le type date et time sont standardisés et ne sont pas supportés par Firefox. Par contre le type datetime n'est pas encore validé w3c et a d'ailleurs été renommé en datetime-local. Mais l'ironie est que c'est quand même supporté sur la version mobile (au bout de 8 ans quand même), comme quoi ils ont le sens de la réalité, car saisir une date sur mobile sans Webforms c'est un échec niveau interface utilisateur (hors astuce javascript)
Mais avant le HTML5, il y a d'autres choses que Firefox néglige et qui sont pourtant la base d'un navigateur. Parmi ceux que j'ai rencontrés (pour réaliser une simple admin), il y a:
- 307866, depuis 2005, soit 9 ans (et 4 doublons): la propriété css2 min-height sur un tableau ne fonctionne pas. Il existe une solution heureusement, mais le bug est là à l'abandon, avec occasionnellement des relances d'utilisateurs.
- 140562, depuis 2002, soit 12 ans (et 14 doublons): c'est le bug collector, où il faut modifier la propriété CSS -moz-focus-inner si l'on souhaite obtenir une dimension qui respecte le boxmodel (sinon extra padding à en devenir fou).
- 410959, depuis 2008, soit 6 ans (et 6 doublons): avec le high dpi, le zoom est de plus en plus courant, mais cela provoque des bugs d'affichage grossier, dans mon cas, toutes les bordures d'une colonne étaient correctes, sauf une qui faisait anormalement le double en taille. On sent dans les commentaires la volonté d'aider, Elbart en avril 2014 qui trouve la régression, et puis, c'est tout, plus rien…
Ce qui est amusant est que dans chacun des bugs report, les utilisateurs sont sur le cul:
307866 (min-height pour l'élément table):
140562 (-moz-focus-inner)
410959 (Zoom):
Firefox ne veut plus être réglo sur les détails, maintenant il y a des workarounds spécifiques Firefox. Mais que faut-il faire ? Ah, voter ? Lancer une grande campagne de votes sur les bugs triviaux de Firefox pour éviter des workarounds spécifiquement pour ce navigateur ? Ah en fait non, la solution est de réduire les parts de marché. Mais même pas besoin de l'aide du bouche à oreille pour réduire les parts de marché, les faibles performances de Firefox s'en sont déjà chargées (c'est du vécu et toujours d'actualité).
Je suis également pro-mozilla, j'ai fais les recherches nécessaires pour les bugs, avec les votes qui vont bien, j'ai même contacté un développeur (à la base pour les problèmes de performance), mais ensuite on laisse juste tomber quand tout le monde s'en fou.
Oui, tu as loupé un épisode XD Cela me fait penser à une sorte de "dou tu critik firefox twa, té ki dabor", alors que tous les commentaires de cette dépêche donnent leur avis dessus. Mais bon, cher rupteur, tu arrives comme ça, tu critiques direct firefox, ça va pas la tête ^
[^] # Re: Emplacement fichiers de config
Posté par Thrillseeker . En réponse à la dépêche Enemy Territory: Legacy, en résistance. Évalué à 1.
Peut-être faut-il suggérer à Freedesktop d'ajouter ~/.bordel quand une application mélange données et configuration xD
Il ne faut pas prendre la recommandation de Freedesktop comme la meilleure pratique à suivre. Personnellement, je trouve "~/.local/share" incohérent comme chemin pour des données que Freedesktop qualifie de "user specific data" (".local" est redondant car on est déjà dans ~, et "share" est un non sens car c'est justement spécifique à l'utilisateur). Mais c'est surement pour ressembler à "/usr/local/share/".
Pour ma part, je m'attends à trouver les fichiers de config dans le dossier de config, avec en bonus directement les données au même endroit (et si c'est le cas ça m'arrange), sinon à aller les chercher dans ~/.local/share. Dans le pire des cas, je regarde dans ~.
Si je fouille dans mon .config, je vois qu'il y a déjà Chromium qui mélange tout dedans, Transmission, Inkscape, LibreOffice, KVirc, etc. Après c'est sûr que ce n'est pas parce que d'autres le font, qu'il faut faire pareil.
[^] # Re: Emplacement fichiers de config
Posté par Thrillseeker . En réponse à la dépêche Enemy Territory: Legacy, en résistance. Évalué à 2.
Qu'il soit difficile de choisir entre tout mettre dans le dossier des données ($XDG_DATA_HOME) et tout mettre dans le dossier des configurations ($XDG_CONFIG_HOME) ne doit fort heureusement pas obligatoirement conduire à créer son propre dossier de config/données n'importe où.
Par contre, choisir de pourrir le $HOME c'est facile. Les spécifications de Freedesktop permettent justement d'éviter la situation d'avoir 800 fichiers/dossiers qui commencent par un "." dans le dossier $HOME.
Les spécifications de Freedesktop ne sont heureusement que des recommandations, ce qui permet toujours de faire ce que l'on veut, cela permet donc de mélanger données et configuration dans $XDG_DATA_HOME (ou $XDG_CONFIG_HOME).
Et quand on y pense, un fichier de configuration c'est juste une donnée spéciale. Quand on a pas le choix, tout irait dans le dossier des données, bien que je constate que la majorité des applications mélangent tout dans le dossier de configuration.
[^] # Re: Rolling release et Chakra Linux
Posté par Thrillseeker . En réponse au journal Une idée de distribution Linux. Évalué à 6.
Cette distribution s'adresse à des personnes qui s'y "connaissent" et tout problème est à cause de l'utilisateur car il n'aura pas fait attention à tel ou tel message dans les logs, ou car il n'a pas suivi les news, ou pas lu le wiki, ou seulement lu à moitié.
Partant de ce principe, en ajoutant le classique "chez moi ça marche", il est difficile d'affirmer ici qu'il peut exister des problèmes car tout problème provient de l'interface chaise/clavier (de l'utilisateur).
Il faut savoir que les problèmes dépendent aussi des paquets installés, en particulier la source (AUR, community, extra?). Car tous les mainteneurs ne font pas la chose correctement et se reposent souvent sur l'idée que c'est une distribution pour des gens qui s'y connaissent (du coup ils peuvent faire de la merde plus facilement).
A part quelques problèmes liés aux mainteneurs/paquets (oui ça existe vraiment), tous les autres problèmes que j'ai eu proviennent d'upstream. Par exemple, avec GTK3, TrueCrypt (update de wxgtk de 2.8 vers 3.0) veut m'ouvrir nautilus au lieu de dolphin comme cela avait toujours été le cas avant (car je suis sur KDE). Une sorte de /bin/nautilus codé en dur dans le code, c'était une énorme régression, mais ce n'était pas la faute d'Archlinux dont l'objectif est de proposer des logiciels à jour…
Ceci dit, ils font quand même des tests, l'ouverture de l'explorateur de fichiers par wxgtk sur KDE n'avait pas du être testé. Ce problème qui date d'avril n'est toujours pas corrigé upstream, je ne sais pas si c'est à cause de wxgtk qui possède "/bin/nautilus" en dur (je n'ai pas trouvé cette chaine dans le code source), ou GTK3 (je penche plus vers cela). Quoi qu'il en soit, c'est un problème upstream. La solution consiste à créer une sorte de lien symbolique de /bin/nautilus vers dolphin. Mais j'aurai pu pester en disant qu'un mainteneur aurait pu prévoir ce lien symbolique pour moi xD
J'ai également eu d'autres problèmes, comme une mise à jour du driver nvidia qui a empêché le serveur X de se lancer au prochain démarrage. En attendant de trouver plus de temps, j'ai interdit la mise à jour des paquets concernés.
Tout ça pour dire qu'avec Archlinux, le problème n'est pas tout le temps entre l'interface chaise/clavier, le problème n'est pas Archlinux non plus, mais surtout les logiciels. C'est surement pour cette raison que certaines distributions patchent à mort les logiciels intégrés.
Et je confirme donc que chaque mise à jour peut potentiellement faire perdre du temps. Cela n'arrive pas souvent, à vu de nez pour moi c'est un petit problème tous les trois mois et un gros par an.
[^] # Re: Rien de nouveau à l'horizon
Posté par Thrillseeker . En réponse au journal Google Robotics. Évalué à 4.
A mon avis il ne se base pas sur des chiffres, mais sur une vision à très long terme. Avec le temps il y aura de moins en moins de personne utile grace aux gains de productivité, et donc de plus en plus de personnes seront pauvres.
Imaginons dans un futur où seulement 20% de la population doit travailler grâce à cet énorme gain de productivité:
Soit on ne "partage" pas ce gain de productivité, et ce sont tout le temps les mêmes personnes qui travaillent, et qui sont donc les plus riches. Les 80% restants sont sans emplois, donc pauvre.
Soit on "partage" ce gain de productivité, avec par exemple un roulement des personnes qui travaillent. Au lieu de travailler tous les jours, on ne travaillerait qu'un seul jour par semaine. Ou au lieu de travailler tous les mois, on ne travaillerait qu'un mois sur 5. Ou par exemple encore, mettre en place un "revenu de base/universel".
Ceci est bien sûr un exemple exagéré pour montrer l'idée.
Cela dépend si travailler moins signifie diviser par deux son salaire pour le partager avec une autre personne, ou travailler vraiment 35h au lieu de 39h quand l'entreprise le veut bien. Pour les personnes que je connais, elles préférent travailler moins en général.
[^] # Re: Performance
Posté par Thrillseeker . En réponse au journal Amélioration des performances graphiques du noyau 3.12. Évalué à 4.
Ou pas. J'ai l'exemple précis d'une personne qui jouait à Diablo 3 et dont le jeu ramait par moment sur son PC portable. Jusqu'au jour où il avait découvert qu'il pouvait indiquer à Windows qu'il voulait le mode performance maximale (par effet de bord son PC chauffait plus du coup). Ce jour là je lui ai dis que c'était pareil sur linux, on choisit le mode que l'on veut (powersave, ondemand, performance). Ce n'est pas pour rien que ces trois modes existent, sinon seul ondemand existerait si c'était parfait.
Je veux la même chose, mais quand on n'a pas le choix et qu'on tombe à moins de 1fps dans le jeu en fonction des séquences et qu'on constate que c'est à cause du gouverneur, cela met juste la haine à tel point que j'avais été déçu sur le coup.
Personne ne veut se préoccuper de son gouverneur, moi le premier, mais des fois on n'a pas le choix. Alors c'est bien qu'ils améliorent "ondemand" car personnellement cela m'embette et je trouve cela ridicule de changer de mode de gouvernance quand je veux jouer.
C'est juste qu'il n'y a rien d'étonnant qu'en améliorant le gouverneur par défaut ondemand, alors cela améliore les performances pour atteindre une performance proche ou égale au gouverneur "performance". D'où ma déception en lisant l'article par rapport à son titre, que je renommerai en "Mise à jour du gouverneur ondemand pour améliorer les performances globales". Après c'est un journal écrit à partir d'un article de phoronix… xD
# Performance
Posté par Thrillseeker . En réponse au journal Amélioration des performances graphiques du noyau 3.12. Évalué à 3.
Il n'y a rien d'étonnant, quand on sait qu'on veut le maximum de performance, autant changer le gouverneur pour "performance" au lieu de faire confiance à "ondemand".
Ce problème décrit de "ondemand" est bien connu de certains jeux, en particulier sous wine. Du coup, pour ceux qui changent déjà à la main leur gouverneur, il n'y aura aucun gain de performance, par contre cela leur évitera de changer de gouverneur avant et après la session de jeu.
J'aurai utilisé un titre de journal moins sensationnel du coup. Plutot du genre: "amélioration du gouverneur ondemand" ou bien "correction d'un bug de linux" XD. Et du coup cela améliore les performances globales, pas seulement graphiquement.
# ou pas toujours
Posté par Thrillseeker . En réponse au journal La fin du monde est (une fois de plus) pour demain : SSL crime. Évalué à 1.
Pas toujours. Certains sites permettent de limiter la session à une seule IP. Le problème est alors résolu… sauf pour ceux avec une IP public dynamique (derrière des proxies par exemple). C'est pour cela que ces sites proposent de désactiver cette sécurité supplémentaire.
[^] # Re: Problèmes?
Posté par Thrillseeker . En réponse au journal Linux a des défauts sur le bureau. Évalué à 4.
Une fois j'ai eu besoin d'une version très récente d'un logiciel. Et je n'étais pas le seul, car il s'agissait de Mumble (logiciel VoIP en gros) qui avait changé son protocole, donc utiliser la dernière version était nécessaire pour fonctionner avec les serveurs qui avaient été mis à jour.
Le hic, c'est que le binaire n'existait que pour Windows… Je me souviens encore du topic dans leur forum, le développeur s'explique dans le deuxième message:
Les développeurs ne veulent pas perdre de temps à générer les paquets pour tout le monde, ils fournissent le code source et les mainteneurs se débrouillent (bon d'accord, dans la citation il parle de snapshot et pre release). Après c'est aux utilisateurs de faire pression aux mainteneurs pour l'avoir le plus rapidement possible.
Ce mainteneur entre le développeur et l'utilisateur est pénalisant pour linux, même si le système de dépôt en lui-même est un gros avantage. Le développeur devrait pouvoir fournir un binaire linux facilement en attendant qu'un mainteneur se donne la peine. Peut-être quitte à ce que se soit un binaire mal foutu avec toutes les dépendances dedans…
[^] # Re: WTF ?
Posté par Thrillseeker . En réponse à l’entrée du suivi Erreur 500 tableau de bord. Évalué à 1 (+0/-0).
En effet, mon tableau de bord fonctionne à nouveau. Merci :-)
[^] # Re: WTF ?
Posté par Thrillseeker . En réponse à l’entrée du suivi Erreur 500 tableau de bord. Évalué à 1 (+0/-0). Dernière modification le 01 juin 2012 à 21:25.
Je veux bien croire que linuxfr c'est la crème de la crème, mais pour ce cas là, je doute que ce soit à cause de ma machine. C'est un simple GET de l'url https://linuxfr.org/tableau-de-bord, pour l'occasion j'ai testé avec telnet sur la version non https du coup:
Aucun code n'est sans bugs :-) Pour tes questions, j'y ai répondu au dessus il y a quelques minutes.
[^] # Re: Les erreurs 500 c'était mieux à vent
Posté par Thrillseeker . En réponse à l’entrée du suivi Erreur 500 tableau de bord. Évalué à 1 (+0/-0).
Peu importe le navigateur, testé avec firefox et chrome sous windows, firefox et chromium sous linux. Avec javascript et sans extensions farfelues.
En y réfléchissant, c'est peut-être parce que j'avais posté un commentaire sur un article du wiki qui (l'article) a été supprimé.
Je n'ai pas plus d'information à fournir. C'est reproductible tout le temps avec mon compte. Cela fait plus de trois mois maintenant, mais je reproduis le bug assez souvent pour vérifier si ça remarche et générer des traces.
[^] # Re: Les erreurs 500 c'était mieux à vent
Posté par Thrillseeker . En réponse à l’entrée du suivi Erreur 500 tableau de bord. Évalué à 1 (+0/-0).
Reproductible: always
Step to reproduce: click on "Mon tableau de bord"
Oooops, j'ai écris sur bugzilla.gnome.org… ah non c'est bien sur linuxfr xD
[^] # Re: Erreur
Posté par Thrillseeker . En réponse au journal The avengers. Évalué à 1.
=> ce type de films
C'est surement fait exprès en fait.
[^] # Re: Erreur
Posté par Thrillseeker . En réponse au journal The avengers. Évalué à 1.
=> tous les êtres humains.
=> un demi-dieu
[^] # Re: Bugs?
Posté par Thrillseeker . En réponse à la dépêche EditableGrid, des nouvelles du projet. Évalué à 1.
Pour Chrome 18 et Firefox 12 sur WinXP, il y a un bug d'affichage sur la page d'accueil (voir ici) qui n'est pas présent dans la "full demo". La zone d'édition pour certaines colonnes est décalée à droite et empiète sur la colonne voisine.
# Arch linux
Posté par Thrillseeker . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à 4.
Cela me fait penser à la mise à jour assez récente (en mars) du paquet ufw, les fichiers de configuration ont été déplacé (de /lib vers /usr) mais le script d'installation n'a pas prévu de les copier au nouvel endroit… Beaucoup et à vrai dire tout le monde utilisant ce paquet s'est retrouvé à devoir les copier à la main. Et pour ceux qui n'ont pas vu les avertissements lors de là mise à jour, des topics comme celui-ci ont fleuris.
On peut voir les changements ici, et s'apercevoir qu'un "cp" des anciennes configurations n'était pas compliqué à faire. C'est la faute du mainteneur bien évidemment, mais cela fait parti des petits détails qui énervent.
Ceci me rappelle ce blog. Au fil du temps, (arch) linux c'est toujours bien, mais qu'est ce que c'est chiant.
# Les erreurs 500 c'était mieux à vent
Posté par Thrillseeker . En réponse à l’entrée du suivi Erreur 500 tableau de bord. Évalué à 1 (+0/-0).
Le problème est toujours présent…
[^] # Re: Utile, pas plus compliqué qu'autre chose
Posté par Thrillseeker . En réponse au journal À propos de GPG et de son avenir. Évalué à 1.
L'exemple du site est:
Le cerveau humain n'étant pas spécialement conçu pour travailler avec du texte, c'est pour cela que ce genre de faille arrive. Alors si le hash visuel est une matrice à 32 cases, dont chaque case correspond à un quartet (donc 16 couleurs possibles par case), il me semble qu'un humain détectera plus rapidement des hashs différents (pour peu que l'image ne soit pas microscopique)
Après dans l'exemple de VizHash, il y a des formes/courbes, ceci peut être utilisé pour différencier deux hashs trop ressemblant (je pense à 1 ou 2 quartets de différence). Or je constate que l'outil Fuzzy Fingerprint génère des hashs avec énormément de différence. Donc je pense qu'un hash visuel peut être suffisant pour certains domaines (du moins pour le grand public), mais c'est sûr que ce sera moins bien qu'une comparaison textuelle (qui sera toujours utile en entreprise).
Mais rien n'empêche de mettre les deux, un hash visuel et un écrit :-)
[^] # Re: Utile, pas plus compliqué qu'autre chose
Posté par Thrillseeker . En réponse au journal À propos de GPG et de son avenir. Évalué à 1.
Il fait référence à la présentation, pas de supprimer l'étape de vérification. Au niveau présentation, il existe des hashs visuels.
[^] # Re: Selections and Contextual Actions
Posté par Thrillseeker . En réponse au journal GNOME3: après le shell, les applications ?. Évalué à 2.
Qui a parlé de texte sélectionné ? Un click simple sur du texte permet d'actualiser la page (car considéré comme un click sur la page), alors qu'un click sur une image ne le permet pas. Pour moi, cela me semble presque logique (car habitué?), mais ce n'est peut-être pas le cas pour tout le monde.