La feuille de route du navigateur web Firefox vient d'être mise à jour sur le site de la fondation Mozilla: https://wiki.mozilla.org/Firefox/Roadmap
La page a été mise à jour par Mike Beltzner qui est le release manager officiel donc on peut supposer que cette "Firefox 2011 Roadmap" est représentative des priorités de Mozilla pour Firefox.
Alors qu'est-ce qu'il y a dans cette page ? Quelles sont les priorités ?
D'abord nous apprenons que la façon de numéroter les versions va changer pour s'aligner sur la façon de faire de Google Chrome (c'est le mode dit de "l'inflation épileptique"). Alors que nous sommes toujours en attente de la sortie de la version 4.0 c'est une version 7 qui devrait débarquer avant la fin de cette année (Ship Firefox 4, 5, 6 and 7 in the 2011 calendar year).
Évidemment cela implique que les nouvelles versions contiendront moins de choses, que la compatibilité binaire avec les extensions sera préservée, etc. La roadmap par version est disponible ici: https://wiki.mozilla.org/Firefox/Roadmap#Product_Roadmap
Un autre item est consacré à l'amélioration de la réactivité de Firefox. Le but est que l'interface réponde toujours en moins de 50 millisecondes à une action de l'utilisateur. Aucun détail technique n'est disponible dans cette roadmap mais sans doute est-ce à mettre en relation avec le projet "Electrolysis" qui vise à séparer le navigateur en plusieurs processus (dont l'un serait consacré à l'interface utilisateur). D'ailleurs un peu plus loin dans la page on trouve mention d'un fonctionnement de type "un process par onglet".
Ensuite il y a quelques trucs flous. Par exemple un des bullet point s'intitule "Expand the Open Web Platform to include Apps, Social and Identity". Est-ce que ça veut dire un Facebook-like libre sur le modèle Diaspora ? Ou bien un truc du genre OpenID ? Et si c'est le cas (ce que semble laisser croire la phrase "Design and implement open systems for Identity and social interactions) alors qu'est-ce que ça vient faire dans la feuille de route d'un navigateur ? Il sera intéressant d'avoir plus d'informations au sujet de ce mystérieux "open and interoperable social network".
Dans la catégorie banal je pense qu'on peut mettre sans hésiter "Never lose the user's data or state" ou bien "Continue to improve stability". C'est clair que ça va mieux en le disant mais ce n'est quand même pas une annonce révolutionnaire que de dire qu'on va s'efforcer de ne pas se vautrer lamentablement. Tout aussi banal et dépourvu de détails précis est le "Improve user interface polish so that Firefox feels modern, graceful and elegant".
Ah enfin un item qui semble intéressant ! Qu'est-ce qui se cache derrière le mystérieux "Support modern operating systems and platforms" ?
En fait il s'agit de proposer des builds 64 bits pour Windows, d'être prêt pour la sortie du futur Mac OSX 10.7 et de s'introduire aussi vite que possible sur les tablettes Android 3.0.
Vous pourrez faire autant de Ctrl-F que vous voulez sur la page de la roadmap Firefox vous ne trouverez pas une seule mention de Linux. C'est...hum...décevant on va dire.
Journal Firefox 7 avant la fin de l'année ?
8
fév.
2011
# Google Chrome Syndrome
Posté par Thomas J. (site web personnel) . Évalué à 10.
Déjà que l'interface graphique de FF4 est quasi identique à celle de Chrome, si en plus la fondation copie le mode de release ultra-serré, que va-t-il rester au panda roux ?
Un moteur de rendu qui n'a pas su convaincre face à WebKit ?
Un moteur JavaScript qui semble plus lent que la concurrence (j'inclus IE9) ?
[^] # Re: Google Chrome Syndrome
Posté par Paul Rouget . Évalué à 10.
[^] # Re: Google Chrome Syndrome
Posté par patrick_g (site web personnel) . Évalué à 10.
En réalité sur ce plan là il semble que le retard soit en grand partie comblé. Firefox 4 apporte une amélioration vraiment énorme. J'ai testé le bench Kraken (d'origine Mozilla certes mais sur le net on voit pas mal d'avis qui décrivent ce bench comme plus représentatif que les autres).
Résultat Firefox 3.6.13:
31 212 ms
Résultat Firefox 4b10
9 040 ms
Résultat Chrome 10.0.648.18dev
9 734 ms
[^] # Re: Google Chrome Syndrome
Posté par Paul Rouget . Évalué à 4.
http://www.arewefastyet.com/
# pour linux
Posté par Paul Rouget . Évalué à 10.
On a récemment embaucher des gens pour bosser sur l'intégration à Unity et aussi pour bosser sur les perfs de Firefox sur Linux (Mike Hommey, le packager iceweasel).
D'ailleurs, je serais très intéressé de savoir quelle serait votre liste de priorité pour Firefox sous Linux. Genre le top 3 features/bug fix que vous voudriez voir arriver.
[^] # Re: pour linux
Posté par Grunt . Évalué à 10.
Je parle du "choisir une application" quand on ouvre, par exemple, un lien irc:// ou ed2k://
Avoir la liste des applications installées ça serait une meilleure intégration que chercher dans /usr/bin/
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: pour linux
Posté par JGO . Évalué à 10.
[^] # Re: pour linux
Posté par GeneralZod . Évalué à 8.
[^] # Re: pour linux
Posté par JGO . Évalué à 4.
[^] # Re: pour linux
Posté par GeneralZod . Évalué à 3.
[^] # Re: pour linux
Posté par grid . Évalué à 3.
Maître Capello aurait dit "un sélecteur de fichier", là ça pique. Pour autocomplétion, il aurait dit auto-complètement.
[^] # Re: pour linux
Posté par GeneralZod . Évalué à 1.
[^] # Re: pour linux
Posté par Gniarf . Évalué à 2.
[^] # Re: pour linux
Posté par Arthur Geek (site web personnel) . Évalué à 2.
Prochainement, je vous proposerai peut-être un commentaire constructif.
[^] # Re: pour linux
Posté par JGO . Évalué à 3.
[^] # Re: pour linux
Posté par Nonolapéro . Évalué à 1.
[^] # Re: pour linux
Posté par zebra3 . Évalué à 2.
Et ça marche pour tout.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par GeneralZod . Évalué à 1.
[^] # Re: pour linux
Posté par El Titi . Évalué à 10.
dans l'application kivabien !
Tirer toutes les dépendances de KDE pour une simple appli ... quelle honte !
[^] # Re: pour linux
Posté par Gniarf . Évalué à 3.
t'as même le temps de télécharger et compiler l'application en question, cai dire.
[^] # Re: pour linux
Posté par JGO . Évalué à 2.
[^] # Re: pour linux
Posté par gnumdk (site web personnel) . Évalué à 3.
Ou ceci dans un fichier ~/.mailcap (on peut mettre xdg-open du coup).
Par contre, dès qu'on installe gnome-vfs, firefox ignore ce fichier (enfin sous Arch mais il me semble que c'est la même sous Debian).
[^] # Re: pour linux
Posté par modr123 . Évalué à 2.
pas besoin de scroller
[^] # Re: pour linux
Posté par karteum59 . Évalué à 3.
[^] # Re: pour linux
Posté par JGO . Évalué à 2.
[^] # Re: pour linux
Posté par octane . Évalué à 2.
J'ai créé un répertoire
/Applications
qui contient des liens vers les programmes:
/Applications/pdf
/Applications/openoffice
/Applications/gvim
/Applications/xmms
etc...
Un clic, une milliseconde de recherche, et hop.
[^] # Re: pour linux
Posté par Dr BG . Évalué à 7.
Résolu !
[^] # Re: pour linux
Posté par windu.2b . Évalué à 3.
Le premier indique plutôt qu'on a repéré le problème et envisagé une solution pour... le résoudre.
Mais c'est sans doute mon interprétation d'un verbe qui n'existe pas, en me basant sur le sens du substantif dont il dérive...
[^] # Re: pour linux
Posté par fleny68 . Évalué à 2.
[^] # Re: pour linux
Posté par yellowiscool . Évalué à 3.
En général, je lance souvent mon navigateur web, et firefox est beaucoup trop lent à se lancer, par rapport à la concurrence que j'utilise (chromium sur linux, et safari sur mac).
Sur mon fixe, le navigateur web est au contraire rarement fermé. Et les fuites de mémoires de firefox sont assez visibles. Chromium consomme plus en comparaison, mais quand je ferme les onglets d'un site, la consommation redescend. Ce qui est logique, puisque les processus se terminent.
Bref, je trouve firefox très lourd. Sur windows, où il doit être plus optimisé, l'impression de lourdeur est plus faible. Je crois avoir compris que ça vient du fait que la version linux utilise xrender, qui est lent. Enfin, la version mac n'utilise pas xrender, et en comparaison à safari, elle est super lente elle aussi…
Envoyé depuis mon lapin.
[^] # Re: pour linux
Posté par guepe . Évalué à 6.
Ça me gonfle de devoir mettre mon mot de passe alors que je viens de me logger, et donc que toutes les applis qui utilisent gnome-keyring utilisent le verrou libéré au login (y'a un timeout de 30 sec. je crois, mais le navigateur c'est l'une des premières applis que je lance).
En 2 : lors de la restauration de la session, pour chaque page qui demande un accès au trousseau de mot de passe, j'ai un popup de demande de mot de passe. Donc en plus de me le demander une fois, comme j'ai pas le temps de taper le mot de passe assez vite, j'ai wattmille mot de passe à rentrer, toujours le meme. Il faudrait qu'a l'ouverture de session, les onglets se synchronisent et attendent que l'utilisateur rentre son mot de passe, une fois et une seule ! C'est encore plus pénible que le 1.
En 3 : parfois, la awesome bar plante : je n'ai plus de complétion (???) c'est assez bizarre. Je ne sais pas du tout comment le reproduire, par contre j'ai vu plusieurs personnes faire ce commantaire sur les forums, notamment ubuntu.
En 4 : parfois (et encore la, comment reproduire) lorsque je tape dans la barre de recherche, chaque caractère frappé remplace le précédent, au lieu de l'ajouter. Il n'y a aucune sélection…
Après, des trucs pas spécifiques linux :
En 5 : mon dieu que c'est pénible d'attendre qu'une page charge (parce qu'un serveur traine et ne répond pas par exemple) : impossible de switcher d'onglet !!! Mais qui a pensé que les sites répondraient toujours suffisamment vite pour que l'on gèle l'interface pendant le chargement ?????? Des fois c'est 10 secondes d'attente (mesuré à la louche, et c'est irrégulier bien sur) !
En 6 : J'aimerai bien une gestion de groupement d'onglets comme sous les derniers opéra : on peut les grouper directement dans l'interface, sans passer par le nouveau truc de FF4, qui ouvre un onglet dédié à la gestion des groupements. Qui a testé opera beta voit de quoi je parle.
PS : tous ces bugs je les ai sous ubuntu et archlinux (FF 3.6.*). J'ai les 1 et 2 sous FF 4 (build mozilla). Je n'ai pas encore vu les 3 et 4 sous FF4.
[^] # Re: pour linux
Posté par YLD . Évalué à 5.
La même chose pour Gnome et son Gnome-keyring (non testé): [https://addons.mozilla.org/en-us/firefox/addon/gnome-keyring(...)]
On en trouve d'autres par ici toujours pour KDE/FIrefox: [http://maketecheasier.com/5-firefox-add-ons-for-better-kde-i(...)]
[^] # Re: pour linux
Posté par guepe . Évalué à 2.
[^] # Re: pour linux
Posté par Grunt . Évalué à 5.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: pour linux
Posté par johngeek . Évalué à 2.
J'arrive à récupéré la complétion en enlevant le focus de la barre, puis en enlevant le focus de la fenêtre de Firefox (en changeant de fenêtre ou en retournant sur le bureau, par exemple) puis en revenant dans Firefox.
C'est un peu tordu mais ça marche :-)
[^] # Re: pour linux
Posté par patrick_g (site web personnel) . Évalué à 6.
C'est une très bonne nouvelle et en plus le blog de Mike ( http://glandium.org/blog/ ) est super intéressant.
>>> D'ailleurs, je serais très intéressé de savoir quelle serait votre liste de priorité pour Firefox sous Linux. Genre le top 3 features/bug fix que vous voudriez voir arriver.
Bon c'est vrai que quand on est confronté à cette question on reste un peu sec (du moins c'est mon cas) ;-)
J'ai bien quelques reproches à faire à FF mais ça n'est pas vraiment spécifique à Linux.
- Ce serait bien si on avait un support plus long pour les versions précédentes. La nouvelle politique de versionnage va changer quoi à ce niveau ?
- Le lancement à froid est quand même assez lent. Chromium et Epiphany font mieux à ce niveau (mais j'avoue avoir une bonne dizaine d'extensions dans mon Iceweasel).
- Les gels d'interface c'est très énervant...mais Electrolysis est là pour s'en occuper donc wait and see.
- La dispute avec Debian c'est idiot et Mozilla devrait accepter l'emploi du nom Firefox sur un browser patché...mais il parait que c'est en cours de résolution.
- Intégration avec le key ring de GNOME.
Enfin pour finir mon pet bug à moi : https://bugzilla.mozilla.org/show_bug.cgi?id=486918#c16 L'écart qualitatif avec Chrome est énorme sur les screenshots non ?
[^] # Re: pour linux
Posté par Paul Rouget . Évalué à 5.
Bonne question. Je ne sais pas. Je vais me renseigner.
Le lancement à froid est quand même assez lent. Chromium et Epiphany font mieux à ce niveau (mais j'avoue avoir une bonne dizaine d'extensions dans mon Iceweasel).
On y travaille (http://glandium.org/blog/)
- Les gels d'interface c'est très énervant...mais Electrolysis est là pour s'en occuper donc wait and see.
Voilà :)
La dispute avec Debian c'est idiot et Mozilla devrait accepter l'emploi du nom Firefox sur un browser patché...mais il parait que c'est en cours de résolution.
Oui
https://bugzilla.mozilla.org/show_bug.cgi?id=555935
- Intégration avec le key ring de GNOME.
Noté!
Enfin pour finir mon pet bug à moi : https://bugzilla.mozilla.org/show_bug.cgi?id=486918#c16 L'écart qualitatif avec Chrome est énorme sur les screenshots non ?
Noté aussi :)
[^] # Re: pour linux
Posté par Fulgrim . Évalué à 9.
Potentiellement en utilisant les fenêtres de choix d'application du système. Pour le moment, il faut donner le chemin d'une application (genre /usr/bin/okular pour les pdf) et c'est pas très accessible pour un non informaticien.
[^] # Re: pour linux
Posté par zebra3 . Évalué à 8.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: pour linux
Posté par JGO . Évalué à 2.
[^] # Re: pour linux
Posté par drexya . Évalué à 3.
[^] # Re: pour linux
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: pour linux
Posté par nicolas . Évalué à 1.
[^] # Re: pour linux
Posté par Paul Rouget . Évalué à 3.
Ce n'est pas à propos du preload lors du boot.
Toutes les optimes dont tu parles sont évidement considérées (regarde omnijar).
[^] # Re: pour linux
Posté par nicolas . Évalué à 2.
[^] # Re: pour linux
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
cat "$dist_bin"/*.so > /dev/null 2>&1
Fabuleuse "one liner" pour gagner 20% du temps de chargement... C'est pas possible de voir un truc pareil !
"La première sécurité est la liberté"
[^] # Re: pour linux
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par kiriarat (site web personnel) . Évalué à 1.
Je viens justement de profiter de son boulot d'empaqueteur dans Debian, puisque je poste à partir d'Iceweasel 4.0 β 11!
Le dépôt [[http://mozilla.debian.net]] est un super outil pour pouvoir donner un retour rapide sur les nouvelles versions.
>>> D'ailleurs, je serais très intéressé de savoir quelle serait votre liste de priorité pour Firefox sous Linux. Genre le top 3 features/bug fix que vous voudriez voir arriver.
Ce qui me vient à l'esprit :
- Une bonne gestion des très grosses sessions (j'ai plus de 300 onglets ouverts en même temps sur mon profil principal!), avec par exemple le déchargement automatique des onglets non consultés depuis un certain temps. Actuellement, j'arrive à gérer avec la combinaison des extensions Tree Style Tab ([[https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta(...)]]) pour classer mes onglets en arborescence et BarTab ([[https://addons.mozilla.org/en-US/firefox/addon/bartab/]]) pour qu'ils ne se chargent pas au démarrage. Je vais maintenant pouvoir tester les groupes d'onglets pour aller plus loin.
- Le gestion des extensions entre profils de Firefox : j'ai plusieurs profils, chacun dédié à une tâche et je voudrais que certains réglages soient toujours les mêmes entre plusieurs profils (organisation des barres d'outils, réglages de Tree Style Tab, ...).
- Le support natif du Mozilla Archive Format.
Enfin, j'utilise déjà Firefox avec beaucoup de bonheur et ça n'est pas les nouvelles fonctionnalités de la version 4 qui vont m'inciter à changer. Un grand Merci à tous les contributeurs pour le travail accompli.
Ce message ne contient aucun degré. (sérieusement…! non, mais en vrai !! ok, peut-être un peu parfois mais pas là ☻ )
[^] # Re: pour linux
Posté par CrEv (site web personnel) . Évalué à 10.
Et surtout, tu dois bien en avoir que tu ne consulte pas tout le temps par exemple. D'ailleurs tu utilises de quoi ne pas les charger au démarrage.
En gros, ton usage n'est-il pas en réalité plutôt celui d'un marque ta page ?
[^] # Re: pour linux
Posté par Gniarf . Évalué à 3.
[^] # Re: pour linux
Posté par kiriarat (site web personnel) . Évalué à 1.
Et oui, mon usage est en partie du marque page!
J'ouvre beaucoup d'onglets avec une notion d'arborescence (d'où Tree Style Tab), ce qui me permet de gérer les sources des informations que je récupère. Ensuite, je ne ferme cette arborescence d'onglets que quand j'ai une vue d'ensemble claire sur le sujet.
Donc Firefox me sert beaucoup à garder "en vue" les sujets non-clos.
Pour mon besoin, l'idéal serait d'avoir un "dépôt" d'onglets qui conserve la notion d'arborescence de type groupe d'onglet + arborescence + pas de chargement des onglets au démarrage (un favicon + titre de la page me suffit).
Les marques pages ne me satisfont pas, car je perds la vision graphique et les liens entre sujets.
De même, je n'utilise pas les groupes d'onglets car ils sont assez lents sur ma machine (et oui, 300 onglets!!).
Pour conclure, méthode perso, "un peu" de manque d'organisation, et pas de possibilité de garder la vision arborescente en dehors des onglets de Firefox.
Si quelqu'un a des remarques/indications/conseils, je serais très heureux d'en prendre connaissance.
PS : pour ne pas charger les onglets au démarrage : BarTab
(avec une nette amélioration de la rapidité d'ouverture sous Firefox 4 β)
Ce message ne contient aucun degré. (sérieusement…! non, mais en vrai !! ok, peut-être un peu parfois mais pas là ☻ )
[^] # Re: pour linux
Posté par claudex . Évalué à 3.
J'ai vu sa présentation au Fosdem, c'était très intéressant et je pense que beaucoup de son travail pourrait être repris pour d'autres logiciels.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pour linux
Posté par monde_de_merde . Évalué à 10.
Je me sers constamment de developer.mozilla.org, en particulier de la référence javascript, et l'ensemble de la doc est de très bonne qualité.
Firefox expose bien plus de ses fonctionnalités (en relatif) via une API pour les plugins que la "concurrence".
Je n'ai pas J'ai moins besoin de lire les petits caractères quand Firefox me propose de synchroniser mes préférences/favoris etc... parce que je sais que ça ne sera pas utilisé un jour pour me balancé de la pub.
Et ça marche sur tous mes ordinateurs, sans compter mon mobile.
Bon après si au passage on peu récupérer un peu de rapidité, une meilleur intégration (et que Benoit Jacob continue son bon boulot avec Mesa) je ne serai pas contre...
Ah et c'est toujours une franche rigolade que de lire les commentaires aigris et mal informés sur DLFP au moindre journal/dépêche parlant de Mozilla. ("Bouh ce ne sont que des gens qui parasitent le libre", "C'est un truc libre juste en façade", "Ils promeuvent le standards juste quand ça les arrange").
[^] # Re: pour linux
Posté par Paul Rouget . Évalué à 9.
haaaaaaa, merci \o/
Je me sers constamment de developer.mozilla.org, en particulier de la référence javascript, et l'ensemble de la doc est de très bonne qualité.
Ça reste le plus gros travaille de mon équipe. On a encore embauché récemment, et on va passer plus de temps à encourager les contributions.
J'ai moins besoin de lire les petits caractères quand Firefox me propose de synchroniser mes préférences/favoris etc... parce que je sais que ça ne sera pas utilisé un jour pour me balancé de la pub.
c'est bien dit.
Bon après si au passage on peu récupérer un peu de rapidité, une meilleur intégration (et que Benoit Jacob continue son bon boulot avec Mesa) je ne serai pas contre...
On y travaille.
Ah et c'est toujours une franche rigolade que de lire les commentaires aigris et mal informés sur DLFP au moindre journal/dépêche parlant de Mozilla. ("Bouh ce ne sont que des gens qui parasitent le libre", "C'est un truc libre juste en façade", "Ils promeuvent le standards juste quand ça les arrange").
I love you.
[^] # Re: pour linux
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: pour linux
Posté par Zenitram (site web personnel) . Évalué à -3.
Je le prend pour moi.
Je te rassure tout de suite, je ne pense pas être aigri, je constate juste qu'un standard est écarté par choix politique, et ça ne m’empêche pas de dormir (surtout depuis l'annonce des plugins qui vont bien pour compenser cette empêchement afin que les développeurs et les utilisateurs puissent choisir la meilleure technologie et pas celle qu'on tente d'imposer). Je pointe seulement l’incohérence, la démonstration qu'on ne croit pas assez en l’intérêt du challengeur pour seulement inciter à l'utilisation plutôt que d’empêcher le concurrent "mauvais", c'est ensuite leur choix (et ses conséquences sur l'incompréhension suscitée), le reste je m'en fou complet et agi en tant qu’utilisateur bête qui voudrait virer Flash car il n'aime pas Flash. Je dis aussi que je trouve bien certains choix fait par Mozilla dans d'autres circonstances.
Sinon, dans la liste des priorités, si tu veux qu'on re-trolle sur le sujet, ce serait de ne pas réinventer la roue et utiliser le backend audio/vidéo installé sous Linux (et les autres OS), la philosophie Linux étant plutôt de ré-utiliser ce qui existe déjà plutôt que de ré-inventer la roue.
Sur ce, bon moinssage, c'est toujours mal de critiquer quand un logiciel écarte un standard par choix politique "c'est le bien" même si c'est pour s'écarter d'autres philosophies libristes comme la liberté de choix et la réutilisation de composants. Ne pas critiquer, juste dire "super", quel bonheur. Ce n'est pas ma philosophie, désolé.
[^] # Re: pour linux
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Ensuite, coté framework vidéo, je ne crois pas que gstreamer soit à ce point universel et utilisé partout (vlc ?mplayer ?).
"La première sécurité est la liberté"
[^] # Re: pour linux
Posté par Zenitram (site web personnel) . Évalué à 1.
- Firefox n'a aucun brevet à payer avec les nouvelles conditions du consortium (logiciel gratuit), faux problème. Si ensuite les webmasters ont le choix, ben ils choisissent de payer ou non.
- Utiliser le backend de l'OS ne soumet rien envers le consortium du code, c'est l'OS qui gère. Dire qu'un logiciel est impacté par les capacités de l'OS sous-jacent est à mourir de rire, comme si Firefox devait payer pour les brevets utilisé par l'API qu'il utilisent déjà pour communiquer avec l'OS.
Bref, du gros FUD, inversion des rôles.
Quand au framework video, c'est le problème linuxien, débrouillez-vous avec votre problème linuxien si vous n'arrivez pas à vous mettre d'accord sur une API video commune, ben faut gérer les 1000 back-ends linuxiens.
Je vous laisse au troll cette fois, c'est lassant toujours les même "arguments" archi-faux et qui se démontent en 5 minutes de réflexion. L'argument remonté par Mozilla est plus crédible quand même (celui de ne pas vouloir promouvoir un truc à brevet)
[^] # Re: pour linux
Posté par Albert_ . Évalué à 10.
C'est une vision desole si d'autre personne ne sont pas tellement d'accord avec.
[^] # Re: pour linux
Posté par GeneralZod . Évalué à 8.
L'emphase se suffit à elle-même, comme d'habitude, tu nous sors la même soupe pour défendre l'indéfendable.
[^] # Re: pour linux
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: pour linux
Posté par Paul Rouget . Évalué à 10.
On a un patch pour ça. Ce sera activable à la compilation:
GStreamer backend for HTML5 video element → https://bugzilla.mozilla.org/show_bug.cgi?id=422540
Ce n'est pas ma philosophie, désolé.
Rhoooo, la victime :)
[^] # Re: pour linux
Posté par Zenitram (site web personnel) . Évalué à 1.
Rhooo, tu tues la moitié de ma complainte la (la partie où c'était volontaire de refuser les pachs pour, c'est du moins ce que j'avais lu au début, donc du coup ça, ça saute). Reste que c'est pas dans la release la plus utilisée.
Rhoooo, la victime :)
Si tu veux. Je trouve qu'accuser les gens d'aigri juste parce qu'ils critiquent c'est aussi un peu facile, ça laisse l'idée qu'on ne doit faire qu'applaudir, soit on est dans la case "gentil", soit "méchant", ce système de case me gonfle. Si je critique, c'est parce que je suis le projet que j'aime bien de manière globale (Mozilla a énormément apporté au web, et je l'en remercie. Je critique un seul choix, et applaudit pour tout le reste, surtout par exemple l'interface de FF4 qui est superbe).
[^] # Re: pour linux
Posté par nicolas . Évalué à 3.
Tu crois que les mainteneurs de paquets vont faire quoi ?
[^] # Re: pour linux
Posté par Zenitram (site web personnel) . Évalué à 0.
[^] # Re: pour linux
Posté par Paul Rouget . Évalué à 10.
Pourquoi aimes tu autant h264?
Je vois pas en quoi ça te pose un problème qu'on essaye de pousser un format patent-free pour mettre dehors un format "free as in smokescreen" http://shaver.off.net/diary/2010/08/27/free-as-in-smokescree(...)
On s'inquiète pour le future des vidéos. En bloquant h264, on pense aider les futurs développeurs web.
Si on (nous et Opera) n'avait pas en premier lieu refuser h264, webm serait passé inaperçu et H264 se serait imposer comme un standard de fait. Personne n'aurai aucun choix.
Bref, on est maintenant un navigateur important, on en profite pour imposer certains choix que l'on pense beaucoup plus sain pour le web.
[^] # Re: pour linux
Posté par TImaniac (site web personnel) . Évalué à 0.
Si pour vous aider les développeurs c'est les inciter à continuer d'utiliser Flash... non parcque faut pas rêver, c'est pas webM qui va s'imposer auprès d'un un Apple ou un Microsoft.
Si vous pensiez vraiment aux développeurs, vous seriez pragmatique : il faut mieux un standard, même patent-inside que pas de standard du tout, ce qui pousse à utiliser les solutions à base de plugin actuel (Flash).
[^] # Re: pour linux
Posté par nicolas . Évalué à 2.
[^] # Re: pour linux
Posté par pasScott pasForstall . Évalué à 1.
Bande de faux culs, j'vous dit.
Et tout ca pour quoi?
Pour emmerder apple sur le marche mobile...
Ah ben non, meme pas avec android vient toujours avec le support h264. Faut croire qu'eux n'ont pas le droit au web ouvert.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: pour linux
Posté par nicolas . Évalué à 5.
Parce que tel quel ton commentaire ressemble plus à un courant d’air qu’autre chose…
[^] # Re: pour linux
Posté par pasScott pasForstall . Évalué à 0.
http://blog.mefeedia.com/html5-oct-2010
Qui venait de pairs avec d'autres sources serieuses qui en parlaient a la meme epoque - un peu la flemme de chercher exhaustivement la je t'avouerais.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: pour linux
Posté par nicolas . Évalué à 6.
¹ 54 % des vidéo H.264 (!) peuvent être lue en utilisant html5 ≠ (!) flash a 48 % de part de marché.
[^] # Re: pour linux
Posté par pasScott pasForstall . Évalué à -3.
Ce que ca veut dire, ce que flash commence a etre pousse en tant que solution de secours: on propose le html5 par defaut, si le navigateur ne le comprend pas, on failback sur le flash parce que ca marche bien sur les vieux browser et qu'on peut servir exactement la meme video dans le player flash.
En gros, flash est relegue au niveau "legacy", on le supporte encore parce qu'on peut pas casser la compatibilite de jour au lendemain, mais c'est pas la solution d'avenir.
En clair? 54% des videos sont prevues pour etre servies en html5 par defaut. C'est effectivement pas strictement equivalent a "54% des videos ne sont pas disponibles en flash", mais ca me parait etre un vilain coup au monopole de flash (je te rappelel que ya ne serait ce que 18 mois, 100% des videos etaient prevues pour etre servies en flash et c'est tout).
Apres, libre a toi de minimiser l'impact de ce chiffre pour defendre flash et la mofo, mais lire ca sur un site comme linuxfr, ca me fait doucement rigoler.
Disons que je classe ca dans la derniere discussions sur les "packages repository decentralise par design", un bon double discours novlangue libriste.
Bientot, les beni oui oui vont venir nous expliquer que flash saybien, c'est ouvert, ca ouvre pour la liberte du web et que h264 ca mange de bebes phoques...
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: pour linux
Posté par nicolas . Évalué à 4.
Non, tu racontais que faute à Mozilla, qui n’a pas voulu intégrer H.264, Flash était en train de remonter. Faute de sources tu essaies de noyer le poisson maintenant, en changeant le sujet.
Dommage, c’était un argument qui m’avait presque convaincu… plus maintenant. Je te félicite pour ton exploit !
[^] # Re: pour linux
Posté par pasScott pasForstall . Évalué à 0.
Source?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: pour linux
Posté par nicolas . Évalué à 4.
De rien.
[^] # Re: pour linux
Posté par pasScott pasForstall . Évalué à -4.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: pour linux
Posté par nicolas . Évalué à 3.
Le fil portait sur ce point précis : lorsque Je réponds à TImaniac j’émet l’hypothèse que HTML5 va de toute façon supplanter Flash, quelques soient les choix des navigateurs sur le codage. Et tu me réponds que ça n’est pas le cas… tu t’es peut-être trompé de fil…
[^] # Re: pour linux
Posté par pasScott pasForstall . Évalué à -1.
Tu sais, le monde est pas binaire, c'estpas tout l'un ou tout l'autre...
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: pour linux
Posté par TImaniac (site web personnel) . Évalué à 2.
Pour moi ce n'est aussi qu'une hypothèse. En tout cas un objectif.
Je pensais que Mozilla avait le même, et forcé de constaté que bien qu'annoncant fierement préférer un HTML5 + webM ou HTML5 + Theora, ce qu'ils poussent concrêtement, c'est un HTML5 + flash à la place d'un HTML5 + H264.
En gros à vouloir mieux, ils poussent le moins bien, ce qui me pousse à croire qu'il n'y a derrière tout celà aucune volontée d'aider à l'interopérabilité pour les utilisateurs mais juste un positionnement politique.
On retrouve le même raisonnement politique côté Google, mais eux c'est en phase avec leurs objectifs, qui sont avant tout commerciaux (contrer Apple/Microsoft et mettre la pression sur le MPEG-LA).
[^] # Re: pour linux
Posté par Paul Rouget . Évalué à 7.
Nous on pense qu'on a une chance :)
[^] # Re: pour linux
Posté par zebra3 . Évalué à 1.
Sauf que H264 est un vrai standard, pris en charge partout.
Je viens d'acheter une TV, elle lit H.264. J'ai deux téléphones, ils lisent et filment en H.264. J'ai une N810 (pourtant sous Linux), elle lit H.264. Les vidéos de Youtube sont en H.264.
J'ai un navigateur web. Il ne lit pas H.264.
Et dire que je croyais que le but de Mozilla était de promouvoir les standards…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par GeneralZod . Évalué à 6.
Les standards ouverts, c'est même écrit sur le site de Mozilla.
H264 c'est un standard industriel qui est tout sauf ouvert !
http://guides.mozilla.org/Web_standards
[^] # Re: pour linux
Posté par Zenitram (site web personnel) . Évalué à -2.
http://www.itu.int/rec/T-REC-H.264-201003-I/en
De rien.
Ouvert ne veut pas dire "non soumis à royalties".
Faudrait penser à changer le texte chez Mozilla, car Mozilla refuse un standard ouvert (pour une raison que je comprend même si je ne l'accepte pas, le problème de royalties certes même si Mozilla n'aurait pas à payer, mais le fait qu'il soit soumis à royalties ne fait pas de ce standard un standard fermé)
Tant que vous resterez bloqués en disant que H.264 n'est pas un standard ouvert, vous passerez pour des gens n'ayant rien compris à H.264 et son modèle de développement plus qu'ouvert, et donc on vous rira au nez avec vos arguments faux.
[^] # Re: pour linux
Posté par WhiteCat . Évalué à 4.
- selon la loi française, H.264 pourrait être considéré comme un standard ouvert (quoi que... c’est à voir, car la définition n'est pas très précise sur les brevets et royalties).
- en revanche, selon l'Union Européenne, H.264 n'est clairement pas un standard ouvert.
https://secure.wikimedia.org/wikipedia/en/wiki/Open_standard
[^] # Re: pour linux
Posté par Zenitram (site web personnel) . Évalué à 3.
[^] # Re: pour linux
Posté par Zenitram (site web personnel) . Évalué à 2.
"The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.)."
Faux pour WebM. Il est piloté par une entreprise commerciale, et sont développement n'inclut aucun consensus, Google prend les idées mais et le seul à décider.
Bizarre, Mozilla dit oeuvrer pour un standard ouvert, WebM est ouvert d'accord, mais pas un standard. H.264 est pas ouvert, mais est un standard. Pourquoi accepter par défaut un codec qui remplit un mot sur deux des principes et pas l'autre qui remplit un mot sur deux des principes aussi?
[^] # Re: pour linux
Posté par El Titi . Évalué à 3.
[^] # Re: pour linux
Posté par GeneralZod . Évalué à 3.
Primo, H264 est un standard industriel soutenu par UN consortium industriel et non pas une norme (édicté par un organisme de normalisation).
Secundo, certes webM n'est pas un standard, mais c'est un projet open source qui implique de nombreux acteurs (industriels: nVidia, AMD, ARM, TI, Qualcomm, Rockship etc ..., développeurs: Mozilla, Opera, Gstreamer, FFMPeg, Skype, Logitech, fournisseurs de contenus etc ...). De plus Google a accordé une licence irrévocable et royalty-free des brevets logiciels autour de webM.
Certes, ce n'est pas parfait mais c'est nettement plus clair qu'avec H264 qui après coup, propose une licence gratuite temporaire taillé sur mesures pour les éditeurs de navigateurs web mais envoie chier les fournisseurs de contenus (hein, on parle du web, pas du minitel 2.0, tout le monde est potentiellement un fournisseur de contenu)
[^] # .264
Posté par zebra3 . Évalué à 6.
Cf http://fr.wikipedia.org/wiki/H.264 :
La norme UIT-T H.264 et la norme ISO/CEI MPEG-4 Part 10 (ISO/CEI 14496-10) sont techniquement identiques, et la technologie employée est aussi connue sous le nom AVC, pour Advanced Video Coding. La première version de la norme a été approuvée en mai 2003 et la plus récente date de mars 2005.
SI l'ISO ne te suffit pas, je ne sais pas ce qu'il te faut.
c'est un projet open source qui implique de nombreux acteurs (industriels: nVidia, AMD, ARM, TI, Qualcomm, Rockship etc ..., développeurs: Mozilla, Opera, Gstreamer, FFMPeg, Skype, Logitech, fournisseurs de contenus etc ...)
Et donc, qui le prend réellement en charge à part Google ? Tu connais une seule carte nVidia, AMD, TI ou ARM capable aujourd'hui d'accélérer la lecture de WebM ? Même Mozilla n'a pas intégré le support de WebM dans une version finie.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: .264
Posté par GeneralZod . Évalué à 5.
au temps pour moi, mais une norme non librement réutilisable, ça vaut pas grand chose ...
> Et donc, qui le prend réellement en charge à part Google ?
Skype le propose déjà en production, GStreamer, FFMPeg, MPlayer, VLC également.
> Tu connais une seule carte nVidia, AMD, TI ou ARM capable aujourd'hui d'accélérer la lecture de WebM
Rockship a sorti la première puce matérielle capable de décoder du webM en début d'année (soit environ 6 mois après la libération de webM), ARM, Broadcom, AMD, TI devraient en sortir cette année ...
[^] # Re: .264
Posté par 태 (site web personnel) . Évalué à 2.
Mais Opera l'a fait. (il suffisait de chercher le deuxième de la liste développeurs...)
[^] # Re: .264
Posté par barmic . Évalué à 5.
ISO c'est ceux qui ont normalisé OOXML quelques années après avoir normalisé ODT, c'est ça ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: .264
Posté par zebra3 . Évalué à 3.
Dans ce cadre, la normalisation était nécessaire et s'est faite dans les règles.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: .264
Posté par GeneralZod . Évalué à 1.
Faut juste accepter de cracher les royalties demandées par le MPEG pour pouvoir l'utiliser, exit les logiciels libres, les petites structures etc ...
[^] # Re: .264
Posté par Jerome Herman . Évalué à 5.
Pas de facturation en dessous de 100 000 unités (quelque soit le façon de compter les unités : matériel physique, abonné, paiement au titre, cible pour un broadcast)
Après c'est maximum 0.20$ par unité/abonné/titre supplémentaire.
Pour les logiciels libre distribués gratuitement, c'est gratuit coté AVC (pas coté diffusion par contre, ie si vous diffusez du contenu avec des logiciels libres vous êtes quand même tenu à la redevance).
Donc on va dire que les logiciels libre sont bloqués (pour certains) par leur licence, mais pas par des questions d'argent.
En ce qui concerne les petites structures (même les toutes toutes petites) elles peuvent souvent générer 0.20$ de marge par vente. Surtout quand les 100 000 premières unités par an sont gratuites. Donc au final on est très loin des brevets associés à des sommes pharaoniques, voire bloqués vissés en exploitation que l'on trouve sous tous les autres formats ou presque.
Pour l'instant la seule alternative à H264 est Theora. Les deux codecs progressent de concert, et même si la qualité de Theora (implémentation ffmpeg) est desormais au niveau de H264 http://people.xiph.org/~greg/video/ytcompare/comparison.html http://people.xiph.org/~maikmerten/youtube/ il a encore du mal sur les images les plus complexes à encoder (pluie violente, pan scan avec un ciel étoilé, ressac des vagues sur la plage etc.)
Maintenant il semblerait (je ne suis pas en position pour juger) que Theora soit plus complexe à encoder/decoder que H264. Donc, même pour une petite boite, il faut que cette puissance de calcul supplémentaire nécessaire lui coute moins de 0,20cts par client pour que Theora devienne plus interressant que H264.
Pas facile du tout...
Bref H264 le libre n'en veut pas pour des raisons compréhensibles (avec lesquelles on peut être en désaccord) - mais pas pour un problème d'argent.
[^] # Re: .264
Posté par Shuba . Évalué à 4.
Pour l'instant la seule alternative à H264 est Theora. Les deux codecs progressent de concert, et même si la qualité de Theora (implémentation ffmpeg) est desormais au niveau de H264 http://people.xiph.org/~greg/video/ytcompare/comparison.html http://people.xiph.org/~maikmerten/youtube/ il a encore du mal sur les images les plus complexes à encoder (pluie violente, pan scan avec un ciel étoilé, ressac des vagues sur la plage etc.)
Theora est tout sauf au niveau de h264 hein, cette comparaison elle dit que theora, sur un fichier donné, avec des options choisies aux petits oigons par le dév, et une keyframe toutes les 10 secondes, arrive à rivaliser avec h264 Baseline, avec les paramètres d'encodage de youtube ie pas adaptés à cette vidéo en particulier, et une keyframe toutes les secondes.
C'est pas vraiment une comparaison honnête. Pour les biais dans les comparaisons de codecs, http://x264dev.multimedia.cx/archives/472 en liste un bon nombre. Theora est bien trop loin derrière, et il vaut mieux compter sur vp8 à l'avenir.
Maintenant il semblerait (je ne suis pas en position pour juger) que Theora soit plus complexe à encoder/decoder que H264. Donc, même pour une petite boite, il faut que cette puissance de calcul supplémentaire nécessaire lui coute moins de 0,20cts par client pour que Theora devienne plus interressant que H264.
Apparemment, c'est surtout vp8 qui, actuellement, est affreusement long à encoder par rapport à h264. Vu qu'H264 est une norme et pas une implémentation, cela a permis une saine compétition entre les encodeurs qui a permis d'aboutir à des codecs très optimisés, alors que du côté de vp8, où seule le code de Google fait référence, il n'existe pas ou peu d'encodeurs alternatifs.
[^] # Re: .264
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: .264
Posté par Shuba . Évalué à 2.
[^] # Re: .264
Posté par Jerome Herman . Évalué à 3.
Theora est tout sauf au niveau de h264 hein, cette comparaison elle dit que theora, sur un fichier donné, avec des options choisies aux petits oigons par le dév, et une keyframe toutes les 10 secondes, arrive à rivaliser avec h264 Baseline, avec les paramètres d'encodage de youtube ie pas adaptés à cette vidéo en particulier, et une keyframe toutes les secondes.
Il n'y a pas eu d'options choisies aux petits oignons, il s'agit d'un bête ffmpeg2theora brut de fonderie avec une image clef forcée minimum toutes les 170 images (contre toutes les 61 à l'époque pour Youtube)
Donc oui il y a un avantage donné à Theora mais il n'est pas aussi délirant que ce qu'on peut penser.
Ceci étant Theora reste à la traine sur le très bas bitrate. Mais passé 250kb/s ca n'est plus aussi évident.
Fais le test avec une version récente de ffmpeg2theora tu risques d'être surpris.
Ceci étant les benchmarks sont un véritable problème à mettre en place, surtout sur de la vidéo, surtout sur des codecs qui utilisent de la compression psycho-visuelle.
Généralement on ne s'en sort bien qu'avec une comparaison en double aveugle. Mais c'est compliqué à mettre en place.
[^] # Re: .264
Posté par Zenitram (site web personnel) . Évalué à 5.
Ce test a été maintes fois démonté : distance entre les Keyframe très différentes, ce qui fausse tout (autant mettre que des images Intra avec H.264 et faire une seule Keyframe Avec Theora, mais à ce niveau je peux te démontrer que MPEG Video 1er du nom de 1995 fait mieux que H.264 aussi). Ce test est à mettre à la poubelle.
[^] # Re: .264
Posté par CrEv (site web personnel) . Évalué à 3.
1) et alors ?
2) à part généraliser l'ISO sur la base d'un cas particulier ça avance à quoi ?
[^] # Re: .264
Posté par Albert_ . Évalué à 1.
[^] # Re: .264
Posté par barmic . Évalué à 7.
Un standard notamment dans le domaine des formats de fichiers ça sert à pouvoir partager des fichiers sans problèmes de compatibilité. Bob et Alice veulent s'envoyer un document, il n'y a pas de phase de négociation du format ils utilisent le format normalisé dont on sait que tout le monde peut lire et c'est finis. Si tu multiplie les standards (sans notion de compatibilité avec la précédente) sur un même segment donné ça ne sert plus à rien (sauf à avoir dans un même endroit la description de chacun de ses formats). Dès lors Bob et Alice doivent se mettre d'accord sur quel standard/norme suivre.
Donc oui montrer qu'un organisme qui se veut formel, se vautre sur une règle élémentaire c'est suffisant pour discréditer ou à minima semer le doute sur la procédure de normalisation qu'ils utilisent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: .264
Posté par CrEv (site web personnel) . Évalué à 2.
> Dès lors Bob et Alice doivent se mettre d'accord sur quel standard/norme suivre.
Mais tout à fait oui !
Le but d'une norme (en passant, bien faire la différence entre norme et standard qui sont deux choses différentes !) est justement de pouvoir dire "moi je suis tel norme, respecte la et on peut communiquer ensemble en parlant de la même chose"
Tiré : Normes et standards industriels :
Dans le cas général, un fabricant ou un prestataire de service n'est pas obligé de suivre une norme. Elles peuvent cependant être imposées par un donneur d’ordre pour la réalisation d’un contrat.
Alors oui là on ne parle pas d'info, mais c'est le principe.
Le fait d'avoir une norme n'oblige personne à la suivre (hors lois) et permet _seulement_ à plusieurs de suivre la même.
Et sur le fait d'avoir plusieurs normes couvrant les même besoins, usages : (si j'ai bien compris ce que tu veux dire)
Il y a bien des normes ISO pour C _et_ pour C++. Pourtant, si mon but est de réaliser un soft je peux très bien le faire en C++ ou en C. Et si Bob et Alice veulent s'envoyer les sources d'un programme, il faut bien au préalable choisir dans quel format ils vont coder le programme. Car sinon l'un peu choisir la norme ISO correspondant à C et permettant de faire un soft, et l'autre pour le même usage choisir la norme ISO pour le C++. Tout comme l'un aurait fait un document en odt et l'autre en docx.
On a donc bien plusieurs normes pour des usages similaires, et ça bien avant la gueguerre entre crosoft et odf. Et déjà là il fallait bien
[^] # Re: .264
Posté par barmic . Évalué à 2.
Leur boulot c'est de ne pas avoir de controverse. Demain je peux annoncer la création d'un comité de normalisation dont je serais à la tête, le faire ne sert à rien car ça marche sur la réputation et la prise en compte par le reste du monde.
Ils ont des règles (probablement un standard ISO ^^) qui définis la procédure de normalisation. Cet ensemble de règles est très importants car c'est ce qui défini la qualité d'un standard et ça met donc en jeu, l'image de l'organisme (sachant que s'il a une mauvaise image l'organisme ne sert plus à rien). Si dans ces règles ils ne prennent pas en compte la controverse qu'il y a autour d'un standard, c'est un problème de leur organisation.
Les soupçons de corruptions qui pèsent sur la décision de normaliser OOXML sont extrêmement grave pour ce genre d'organisme et jusqu'à présent rien a était fait pour rassurer.
Quant à vivre dans les normes ISO je sors de réunions sur les normes 14001 et 9000, je sais, au moins en parti jusqu'où vont leurs normes, il n'en reste pas moins qu'ils vont avoir besoin de temps pour se refaire une image au près de beaucoup (dont moi). Ce n'est pas moi qui décide, je sais, mais qu'ils le refassent une fois ou deux dans d'autres domaines et on en reparleras.
Pour ce qui est du C/C++ ça n'a rien à voir, je te parle de format de fichier. Les langages de programmations sont un niveau au dessus. Mais tu as raison de dire qu'il est regrettable d'avoir autant d'encodage unicode (utf7, 8 et 16).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: .264
Posté par CrEv (site web personnel) . Évalué à 2.
Qu'on critique l'ISO pour des histoires de corruption c'est normal. Mais ce n'est pas du tout ce dont tu parlais puisque tu critiques le fait d'avoir la norme ooxml et la norme odf.
Sauf que c'est pas du tout un problème ni la première fois. Et oui C/C++ ont a voir, on a bien deux normes pour un même usage.
D'ailleurs tu parles du même problème pour unicode.
Si on veut se parler mais qu'on ne se met pas d'accord sur la norme d'unicode à utiliser on est mort. Hors c'est la critique que tu faisais sur ooxml - odf.
Par contre, je te rejoins sur ce qui concerne la corruption, mais je ne me baserais tout de même pas dessus pour critiquer l'intégralité d'ISO.
[^] # Re: .264
Posté par dinomasque . Évalué à 1.
Voici 5 formats sandards qui peuvent être utilisés pour s'échanger un document.
Même sans OOXML il en resterait 4.
Tout ça pour dire que quoi qu'il arrive, il est nécessaire pour un usage donné de se mettre d'accord sur le choix du standard à utiliser.
BeOS le faisait il y a 20 ans !
[^] # Re: .264
Posté par barmic . Évalué à -1.
Ou alors tu peut aussi arrêter de jouer au con.
Si Bob, veut mettre à disposition un template de document pour que chacun puisse faire son propre CV "à la Bob" (parce que Bob, il est super bon en mise en page), il commence par envoyer un message à chaque personne qui potentiellement pourrait éventuellement être intéressé par son modèle de CV pour essayer de distinguer un prédominant ? Il fait 4 fois son modèle (avec à la clef l'obligation de maintenir à jour les 4 en parallèle) ?
C'est ce qui se passe tout les jours avec Youtube, les services publiques, etc.. beugler contre eux qu'ils envoient pas des formats de fichiers lisibles sur plus ou moins n'importe quel système c'est bien, mais quels sont leur choix ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: .264
Posté par CrEv (site web personnel) . Évalué à 2.
Pour la première, oui, évidemment, ou plutôt oui il demande aux personnes qu'il pense concernées.
Qu'on parle de langage de programmation, d'échanges de documents, d'encodage pour dialoguer ou n'importe quoi d'autre il le faut. D'autant plus que, comme je te l'ai indiqué, une norme n'oblige en aucun cas quiconque à la suivre. La norme permet seulement d'être sur de se comprendre du moment que tout le monde se fie à la même norme...
[^] # Re: .264
Posté par dinomasque . Évalué à 0.
BeOS le faisait il y a 20 ans !
[^] # Re: .264
Posté par barmic . Évalué à 1.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: .264
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: .264
Posté par pascalc . Évalué à 0.
Firefox 4 l'intègre par défaut, des centaines de millions d'internautes auront dans les mois qui viennent un lecteur webm sur leur machine.
[^] # Re: .264
Posté par zebra3 . Évalué à 2.
C'est pour ça que j'ai parlé de version finie : difficile de pousser un standard avec des betas.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: .264
Posté par barmic . Évalué à 2.
30 novembre : sortie de firefox 5
15 décembre : sortie de firefox 6
31 décembre : sortie de firefox 7
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: pour linux
Posté par GeneralZod . Évalué à 4.
Tu fais exprès ou t'es juste malcomprenant ?
ouvert dans le sens "tout le monde est libre d'utiliser le standard comme bon lui semble et sans aucune restriction".
H264 n'a absolument rien d'un format ouvert, sauf dans le monde // de zenitram.
> le problème de royalties certes même si Mozilla n'aurait pas à payer
C'est drôle, mais ton argumentation n'a pas changé d'un iota depuis le début or tu as toi-même reconnu que cela n'est vrai que depuis le changement du contrat de licence par le MPEG. Je suppose que tu es capable de tordre la réalité voire tu as créé une nouvelle branche de la logique, c'est la seule explication rationnelle (sauf à réfuter l'axiome fondamental régissant l'univers zenitramien: "zenitram n'est jamais de mauvaise foi")
> mais le fait qu'il soit soumis à royalties ne fait pas de ce standard un standard fermé
Dans les univers non-zenitramiens, ça entrave sérieusement l'utilisation de ce standard si on n'est pas une multinationale pété de thunes.
> vous passerez pour des gens n'ayant rien compris à H.264 et son modèle de développement plus qu'ouvert
Mais quel bande de nazistes ces libristes !
> et donc on vous rira au nez avec vos arguments faux
on apprécie l'ironie de ce morceau d'humour pur.
[^] # Re: pour linux
Posté par Jerome Herman . Évalué à 7.
ouvert dans le sens "tout le monde est libre d'utiliser le standard comme bon lui semble et sans aucune restriction".
Loin de moi l'idée de vouloir défendre Zenitram, mais j'ai la (légère) sensation que tu confonds un certain nombre de choses :
- Le standard
- L'implémentation
- La licence de l'implémentation
Le standard c'est soit un standard de fait (ie un truc que tout le monde utilise même si il n'a jamais été normé proprement), soit un standard connu, soit un standard normé. Dans tous les cas c'est une suite de mots qui traduisent un comportement attendu face à un évènement, ou un format de donnée.
Cette suite de mot tu peux en faire ce que tu veux. La publier en affiche 4 par 3 dans le métro, l'imprimer en vert, faire des collages pour une oeuvre d'art ou encore la tagguer sur les murs de ta chambre. Je ne pense pas que qui que ce soit y verra le moindre problème.
Généralement on parle de standard ouvert quand
a - le standard est normé, c'est à dire déposé sous forme de RFC
b - le standard est complet, c'est à dire que l'ensemble des possibilité de la technologie lié directement au standard est disponible dans les doccuments de la norme (par exemple pour le H264 on possède les algorithmes de décodage ET d'encodage)
c - le standard est non encombré, c'est à dire que le standard ne repose pas sur une autre techno qui elle n'est pas normée/connue/publiée. Un standard qui reposerait (par exemple) sur la gestion d'objet OLE par les bibliothèques MS Office ne pourrait pas être considéré comme ouvert.
L'implémentation est un problème technique que doit résoudre le programmeur pour respecter le standard. Cette implémentation n'est que très rarement sans restriction. Déjà elle se doit de fonctionner, de préférence sur des machines qui existent déjà et de façon reproductible. On peut dire que si le standard est bien fait le programmeur a le choix du langage (dans une certaine limite - pas la peine de faire du H264 en MS basic 2.0) et de la plateforme cible (dans une certaine limite aussi - il faut que la plateforme puisse mathématiquement traiter les algos et éventuellement afficher les résultats). Pour le reste il est extrêmement restreint et ne peut pas faire comme bon lui semble, sinon il va sortir du standard. Ses choix principaux vont se limiter à implémenter ou non les fonctionnalités potentielles du standard (quand il s'agit d'un standard publié).
La licence de l'implémentation dépend pour une part de la volonté du programmeur et pour une autre part des brevets et accords qui planent sur les algorithmes et technologies du standard. A titre d'information si le programmeur décide de prendre la GPL comme licence sur un standard sans aucun brevet, ben il y aura là aussi des restrictions et tu ne pourras pas faire comme bon te semble, ni avec le code source, ni avec le compilé...
Après on a tous sa définition du mot ouvert (et on va pas parler du mot libre hein...) Personnellement la seule chose qui me dérange dans le MPEG-Standardisation Group est le somme à payer pour pouvoir rentrer dans le groupe et donc participer aux discussions sur la création et les choix techniques des nouveaux codecs.
[^] # Re: pour linux
Posté par Albert_ . Évalué à 3.
http://linuxfr.org/comments/1206559.html#1206559
Donc ok il a des arguments mais il y en a beaucoup d'autre. Le cote logiciel n'est que une partie de l'equation et c'est probablement la moins importante...
[^] # Re: pour linux
Posté par Zenitram (site web personnel) . Évalué à -1.
Je n'ai même pas eu le courage de répondre à ton message tellement il est à côté de la plaque (mais bon, à +10, faut pas chercher à comprendre) : laisser la possibilité au navigateur de lire du h264 n'enlève pas la possibilité à l'artiste de fournir du WebM. Je n'ai jamais demandé à ne pas inclure WebM, mais bon, faut trouver des arguments faux faute d'arguments justes en stock. Ca ne convainc que les convaincus.
[^] # Re: pour linux
Posté par nicolas . Évalué à 5.
Tu as le droit d’avoir ton avis, mais tu refuses de chercher à comprendre les arguments et les motivations des autres, au mieux tu les trouves « incohérentes » en interprétant faussement une partie du message. Honnêtement je trouve ou trouvais tes arguments tout à fait valables : Webm n’est standard, H.264 est une norme établie, l’effet collatéral de favoriser le Flash dans cette bataille. Mais ça part en troll parce que de ton côté tu refuses de prendre en compte les arguments de tes « adversaires » : entre autres le fait qu’H.264 n’est pas ouvert, dans le sens où Mozilla l’entend (pas toi, Mozilla), sens explicité à plusieurs reprise. Du coup la discussion n’avance pas et on se retrouve chacun de nôtre côté à répéter ad vitam eternam le même troll.
[^] # Re: pour linux
Posté par Zenitram (site web personnel) . Évalué à 1.
plusse alors, car je l'ai bien compris.
"Juste" que je ne suis pas d'accord qu'on passe à une politique de faire comme le concurrent : son produit (WebM) n'est pas assez bien, donc on empêche l'utilisation du concurrent. Ca se rapproche des manière de faire des "méchants".
Mozilla fait son choix, je ne suis pas d'accord mais ils font ce qu'ils veulent. Je critique ceux qui filent des arguments faux pour dire que ce que Mozilla fait est bien.
[^] # Re: pour linux
Posté par Albert_ . Évalué à 2.
Et oui je suis contre le fait de tuer l'innovation quel soit technique ou culturel.
Toi tu te contentes de ce que tu as tant que cela ne te donne pas trop de boulot. Comprehensible mais bon tout le monde n'est pas d'accord avec ce point de vu. Tu n'es visiblement pas capable de comprendre que TON choix pour TES raisons peut etr differents de celui d'autres personnes cela donc cela ne rime a rien de continuer ce troll.
[^] # Re: pour linux
Posté par Axone . Évalué à 3.
Si j'ai bien compris la problématique, c'est que Mozilla refuse d'utiliser h264 même gratuitement car de toutes façons, d'autres utilisateurs de ce format DOIVENT s'acquitter de royalties (c'est la définition même de royalties, elles sont obligatoires). Tout le monde ne peut donc pas l'utiliser librement. Je pense que c'est cela la philosophie de Mozilla.
[^] # Re: pour linux
Posté par nicolas . Évalué à 2.
Je viens d'acheter un ordinateur il lit HTML version IE6, j’ai deux PDA, ils lisent HTML version IE6, les pages web sont hackées en HTML version IE6.
J'ai firexfox 0.7, il ne lit pas le HTML version IE6. »
« Et dire que je croyais que le but de Mozilla était de promouvoir les standards… »
Tu confonds standards de fait/norme/accessibilité.
[^] # Re: pour linux
Posté par zebra3 . Évalué à 3.
Pour une fois que tout le monde s'est réellement mis d'accord sur une norme, c'est quand même dommage de ne pas en profiter.
Grâce à Firefox, si je récupère une vidéo sur une site quelconque, je devrais la transcoder pour la lire avec mes autres équipements. Super.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par Zenitram (site web personnel) . Évalué à 3.
Juste pour un petit bémol : le concurrent DVCPRO HD est en train de mourir certes, donc AVC (via en:AVC-Intra) chez les caméras pro maintenant, par contre les cinéma font quand même de la résistance est ont opté pour JPEG 2000 (qui est libre de droit, c'est mieux déjà, mais pas du tout polyvalent, ne peut pas être adapté aux autre domaines).
Donc presque tout le monde, un autre domaine fait de la résistance (mais ont pour eux que tout les acteurs de ce domaine sont en phase, et sont pas mal dans leur petit monde en autarcie, ce qui est loin d'être le cas pour le web - autant en acteurs du petit monde du web pas en phase et que le web ne peut pas être en autarcie comme le cinéma).
[^] # Re: pour linux
Posté par zebra3 . Évalué à 2.
Donc non, ce n'est pas un standard de fait.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par nicolas . Évalué à 2.
Pour le reste, les arguments ont déjà été exposé et je ne prétends pas en avoir de mieux : le problème se situe du côté de l’accessibilité. Tout le monde ne peut pas librement utiliser cette technologie, et Mozilla, s’y refuse pour cette raison.
[^] # Re: pour linux
Posté par zebra3 . Évalué à 0.
Argument fallacieux s'il en est, puisque même l'utilisateur dispose d'une licence de par son OS, il ne peut pas l'utiliser.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par nicolas . Évalué à 3.
« tout le monde » signifie tous, utilisateur d’un OS disposant d’une licence, utilisateur n’en disposant pas, entreprise et mon chat. Parce que j’aime bien mon chat.
« librement » signifie qu’il en fait absolument ce qu’il en veut sans avoir rendre de compte à personne. Encodage, décodage, triturage, améliorage, … (oui, les libristes sont très chiant avec leur définition du mot « libre »)
Maintenant prenons la Wikipedia :
« On August 26, 2010 MPEG LA announced that H.264 encoded internet video that is free to end users will never be charged for royalties.[11] All other royalties will remain in place such as the royalties for products that decode and encode H.264 video.[12] The license terms are updated in 5-year blocks.[13] »
[^] # Re: pour linux
Posté par pasScott pasForstall . Évalué à 2.
Non pas que ca puisse pas evoluer, mais si ce que tu veux c'est un standard, webm est pas fait pour toi...
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: pour linux
Posté par flagos . Évalué à 3.
C'est vrai qu'H264 est mieux fait sur ce point, mais c'est plus une exception qui confirme la regle qu'autre chose.
[^] # Re: pour linux
Posté par Zenitram (site web personnel) . Évalué à 3.
Quand on me parle de WebM en disant militer pour les standards (même ouverts), je rigole. WebM n'est pas un standard, c'est un format poussé par une seule compagnie qui a fait son encodeur decodeur dans son coin et dont la spec n'existe pas. Google aurait largement pu faire mieux, surtout en ayant 6-7 ans de retard sur le principal concurrent on s'attend à un truc mieux que ça.
C'est rigolo, car pour HTML avant que le W3C accepte de mettre en standard il faut que x navigateurs implémentent dans leur moteur respectif telle balise pour voir si c'est mettable en standard, mais pour la vidéo hop on oublie tout ce qui fait un standard, on a une implémentation, pas de spec, on prend quand même.
Sinon, c'est de moins en moins courant en vidéo : toutes les normes MPEG qui écrasent le marché, VC-1 est standardisé aussi (ancien Microsoft WMV, passé par un organisme de standardisation qui a fait changer le protocole et fait faire une vraie documentation), VC-3 (aka DNxHD) aussi, JPEG-2000 (utilisé par le cinéma) aussi. Bref, la, WebM est plutôt vilain petit canard sur la standardisation et l'inter-opérabilité.
[^] # Re: pour linux
Posté par flagos . Évalué à 7.
Apres dire que Google aurait pu faire mieux, franchement c'est du pur lancé de troll au kilomètre. On2 a été rachetée il y a moins d'un an et il y a urgence a utiliser VP8 si on veut pas que notre avenir informatique soit pourri par les brevets logiciels, cette bataille sur les codecs étant clairement le cheval de Troie des brevets logiciels dans son ensemble.
Google n'avait tout simplement pas le temps d'attendre pour esperer ameliorer ce codec, au moins sur sa doc, sur le cote technique ca me semble etre vraiment difficile de l'améliorer sans tomber sur un énième brevet a la noix tellement la concurrence libre souffre de ceux-ci.
Apres voila, il faut aussi remettre ca dans le contexte: VP8 avait été commercialisée par On2 tel quel, des décodeurs hardwares avaient également été deja deployés, google a a fait qui semble logique: Offrir le decodeur hardware aux fabricants plutot que de prendre le temps de documenter.
Bref, il y a des menaces serieuses sur l'open-source a travers les brevets logiciels. Ce qu'on voit se dessiner jour apres jour c'est que les Microsoft et les Apple sont des spectateurs attentifs de cette bataille sur les codecs et qu'ils se preparent, au cas ou.
[^] # Re: pour linux
Posté par GnunuX (site web personnel) . Évalué à 4.
[^] # Re: pour linux
Posté par Albert_ . Évalué à 6.
[^] # Re: pour linux
Posté par monde_de_merde . Évalué à 2.
Voilà c'est dit. Tu m'en veux pas ?
Par contre je veux bien faire comme tu demandes et te moinser. Pour me faire pardonner.
[^] # Re: pour linux
Posté par grid . Évalué à 2.
Un truc que j'ai jamais compris, c'est pourquoi il n'y a pas de signature des devs sur les extensions, tout à l'air prévu pour.
[^] # Re: pour linux
Posté par GeneralZod . Évalué à 2.
Et GNOME Shell ?
[^] # Re: pour linux
Posté par WhiteCat . Évalué à 7.
[^] # Re: pour linux
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par GeneralZod . Évalué à 3.
[^] # Re: pour linux
Posté par zebra3 . Évalué à 1.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par Nonolapéro . Évalué à 2.
[^] # Re: pour linux
Posté par Infernal Quack (site web personnel) . Évalué à 4.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: pour linux
Posté par Albert_ . Évalué à 4.
[^] # Re: pour linux
Posté par Sekigo . Évalué à 1.
Avoir le choix de changer les raccourcis de manière native dans Firefox.
Parce que, suivant que je suis sur mon netbook ou sur la tour, j'ai une autre manière d'utiliser Firefox. Pour le premier, j'optimise au maximum le clavier, pour le second, j'utilise la souris.
Mais j'aime bien quand même avoir le choix des raccourcis.
[^] # Re: pour linux
Posté par krumtrash . Évalué à 1.
2) Un support correct du 64bits
3) that's all folks!
[^] # Re: pour linux
Posté par zebra3 . Évalué à 4.
5) PROFIT !!!
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par Grunt . Évalué à 2.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: pour linux
Posté par zebra3 . Évalué à 2.
$ epiphany --private-instance --profile /tmp/epiphany-instance
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par claudex . Évalué à 3.
- Comme déjà cité, l'intégration avec xdg-open.
- Une meilleure intégration graphique quand on utilise pas Gnome, je sais qu'il y avait des problèmes avec qt-gtk engine notament.
- Un thread par onglet ou du moins une technique pour que le chargement d'un onglet ne freeze pas les autre, ce qui arrive avec un journal qui a beaucoup de commentaires comme celui-ci.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pour linux
Posté par barmic . Évalué à 4.
1) pouvoir sélectionner du texte contenu dans des SVG
2) pouvoir définir des sites que j'accède automatiquement en mode "navigation privée". C'est à dire qu'aller sur un site de cette liste ne sauvegarde rien en rapport sur mon disque dur (sans pour autant avoir un rechargement complet de firefox que juste l'onglet soit en navigation privée)
3) Un portage de Firefox Mobile sur Symbian.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: pour linux
Posté par reno . Évalué à 3.
1) Electrolysis.
2) Electrolysis.
3) un outil qui permet de voir l'utilisation des ressources (CPU&mémoire) pour chaque page web
[^] # Re: pour linux
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: pour linux
Posté par zebra3 . Évalué à 5.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pour linux
Posté par Yannick (site web personnel) . Évalué à 2.
[^] # Re: pour linux
Posté par MarbolanGos (site web personnel) . Évalué à 1.
Que tout simplement quand on utilise une application qui utilise toute la RAM (oui c'est rare pour certains) Firefox ne parte pas en vrille et ne se mette pas d'un coup à utiliser 100% de cpu et 3 à 4 fois plus de RAM.
J'ai des calculs qui tournent sur ma machine et qui bouffe entre 4 et 6Go de RAM sur les 4Go dispo (augmentation de la RAM sous peu de la machine) et je dois fermer Firefox à chaque fois que le calcul passe dans la partie où je dois utiliser la swap sinon c'est limite plantage. Alors qu'avec chromium j'ai pas ce soucis.
[^] # Re: pour linux
Posté par Nonolapéro . Évalué à 1.
Voilà une bonne raison pour arrêter de mouler !
[^] # Re: pour linux
Posté par pascalc . Évalué à 0.
[^] # Re: pour linux: Firefox HTTPS certificat auto-signé
Posté par Gabin . Évalué à -1.
Non seulement c'est peu intuitif, la page d'avertissement ressemble à une page d'erreur ou une page en chantier et puis c'est lourdingue: j'accepte les risques, je dois demander à voir le certif, le valider et appuyer sur OK pour enfin accèder au site web.
Là où sous chrome/Safari ça se fait en 1 clique avec un pop-up clair.
Peut mieux faire, non?
[^] # Re: pour linux: Firefox HTTPS certificat auto-signé
Posté par Littleboy . Évalué à 3.
Ouais, l'assoc peut sortir 50 euros par an pour s'acheter un certificat chez une autorite dont le certificat racine est distribue avec les principaux navigateurs (c'est pas ca qui manque).
Ils ont choisi CACert, qui pour l'instant n'offre par les garanties de securite requises pour etre inclus directement dans les navigateurs avec les autres certificats racines.
Le jour ou ils seront au niveau, il n'y aura plus de probleme et les utilisateurs n'auront pas besoin de passer par les etapes pour rajouter une exception (a noter que plusieurs distribs incluent deja le certificat racine).
Par ailleurs cette page a ete modifie et les etapes rajoutees justement pour empecher qu'un utilisateur clique rapidement sur OK sans meme lire l'avertissement. C'est donc la pour une bonne raison, pas juste pour faire chier.
[^] # Re: pour linux: Firefox HTTPS certificat auto-signé
Posté par Zenitram (site web personnel) . Évalué à 1.
10€, 0€... plutôt.
http://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_(...)
bref, soit CACert fait le nécessaire pour être validé par Mozilla, Microsoft, Apple, Opera, Google au minimum, soit c'est juste pour embêter le monde que LinuxFr se fait plaisir avec CACert, pour le "promouvoir" quitter a emmerder les visiteurs. C'est un choix (bof de mon point de vue, mais bon, chacun son choix, je suis lire de partir si ça ne me plait pas comme qui dirait)
Par ailleurs cette page a ete modifie et les etapes rajoutees justement pour empecher qu'un utilisateur clique rapidement sur OK sans meme lire l'avertissemen
La façon de faire est quand même gavante quand on veut ajouter une exception pour de bonnes raisons. Warning immense oui, labyrinthe technique à la con, c'est un peu pousser (note : je n'aime pas du tout les certificat autosignés ou signé par une autorité non de confiance, mais c'est pas une raison pour inventer ce labyrinthe)
[^] # Re: pour linux: Firefox HTTPS certificat auto-signé
Posté par Diagonale de Cantor (site web personnel) . Évalué à 8.
Ben ça dépends. Un site en https à deux buts complètement indépendant. L'un est de signer (je suis bien sur le site de ma banque et je peux être sûr qu'il n'y a pas de pishing DNS) et l'autre est d'éviter que des informations passent en clair.
Et effectivement je trouve cela extrêmement chiant qu'il n'y ai aucun moyen simple de dire « mon truc est autosigné, mais on s'en fout, c'est juste pour chiffrer les mot de passes ». Non non, si on veut faire un truc sécurisé, soit on doit passer par un système cher et centralisé (mais pourquoi ?) soit on emmerde le visiteur avec cinq messages du genre « vous vous faites surement attaquer ! Attention si vous cliquez sur continuer vos enfant seront violés, vos femmes égorgés et votre phallus va rétrécir » .
Je caricature, certes, mais le https sous linuxfr c'est juste pour que le mot de passe ne circule pas en clair. Le pishing on s'en fout, donc passer par un organisme de certification devrait être inutile.
[^] # Re: pour linux: Firefox HTTPS certificat auto-signé
Posté par pasScott pasForstall . Évalué à -2.
Clair, quelle catastrophe, t'imagines, un mec pourrait troller a ta place!!!
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: pour linux: Firefox HTTPS ce
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
T'imagines, ton patron pourrait lire tes troll sur linuxfr...
"La première sécurité est la liberté"
[^] # Re: pour linux: Firefox HTTPS certificat auto-signé
Posté par Gabin . Évalué à -1.
Sauf que ce n'est pas l'avertissement qui bloque, ce sont les cliques qui suivent et qui sont clairement inutiles, ils peuvent être proposés mais pas décisifs.
Bref, je n'ai pas dit que je n'aimais pas Firefox juste que certains comportements sont ennuyeux, donc tu peux redescendre ton niveau de défense épidermique.
Le https n'est pas réservé qu'aux sites de ventes ou banques.
Et devoir payé une dîme à Vérisign ou Atos, c'est plutôt moyen.
[^] # Re: pour linux: Firefox HTTPS certificat auto-signé: par l'image
Posté par Gabin . Évalué à -1.
L'avertissement clair et nécessite qu'un clique
Le cas chrome:
http://www.flickr.com/photos/59358188@N03/5434968128/in/phot(...)
Le cas Opera
http://www.flickr.com/photos/59358188@N03/5434356995/in/phot(...)
Le cas IE8
http://www.flickr.com/photos/59358188@N03/5434968092/in/phot(...)
Le cas Firefox qu'on ne peut pas critiquer car on doit surement être un râleur anti-mozilla.
Une tartine, une icône qui ne ressemble à rien et 5 cliques
1
http://www.flickr.com/photos/59358188@N03/5434968220/in/phot(...)
2
http://www.flickr.com/photos/59358188@N03/5434968272/in/phot(...)
3, 4, 5 (il faut "obtenir" le certif, le "voir" et cocher la case "conserver l'exception")
http://www.flickr.com/photos/59358188@N03/5434968306/
Voilou
[^] # Pas spécifiquement sous Linux
Posté par Arthur Accroc . Évalué à 3.
• La fusion des onglets et des signets (et le tout en colonne sur le côté : de toute façon les écrans sont de plus en plus larges... ou de moins en moins hauts), avec la possibilité de passer facilement (en décochant une case ou en faisant glisser) un onglet actif en inactif (pas chargé en mémoire), de le classer dans les signets juste en le glissant et sans perdre l’historique (parce que quand on veut classer une page intéressante pour la lire plus tard, il est possible qu’on n’ait pas non plus pris le temps de lire entièrement la page précédente qui était intéressante aussi, et que bon, s’il faut qu’on remonte tout pour vérifier et faire un signet à chaque fois, ça devient lourd).
Pour l’instant, j’utilise l’extension TabGroups Manager, mais ça oblige à réactiver par groupe complet. Accessoirement, le jour où j’ai tenté d’essayer Firefox 4 qu’elle ne supporte (supportait ?) pas, ça a mis ma bécane sur les genoux pendant plusieurs heures...
• Que ce soit plus rapide à quitter. Quand on a 200 ou 300 onglets, on s’attend bien à ce que ça mette 20 mn à se lancer, mais on aimerait bien quand même pouvoir quitter proprement en moins de 10 mn...
• Moins d’activité rémanente quand on ne touche pas à Firefox : ça ralentit le PC et augmente le bruit du ventilo (OK, il me reste encore plus de 100 onglets actifs, mais NoScript me bloque Javascript sur une bonne partie d’entre eux, donc ce n’est peut-être pas qu’un problème de performance avec Javascript).
• Plus de pause de plusieurs secondes pendant qu’on est dans l’éditeur (ça, c’est m’est venu tout de suite parce que j’y suis ; je suppose que ça ne le fait pas à ceux qui n’ont que trois onglets ouverts...).
Sinon, merci aux développeurs pour tout le boulot déjà fait.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Pas spécifiquement sous Linux
Posté par Arthur Accroc . Évalué à 2.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Pas spécifiquement sous Linux
Posté par patrick_g (site web personnel) . Évalué à 4.
Si tu clique sur la petite étoile dans la barre d'adresse ça t'enregistre le signet dans le répertoire "Marques-pages non classé".
[^] # Re: pour linux
Posté par Arathor . Évalué à 4.
2/ KDE est le bureau que j'ai mis sur la machine de mes parents. Ce qui les fait galérer c'est la boîte de dialogue gtk pour les fichiers. Vraiment, ils ne s'y retrouvent pas, et ça serait un vrai plus de pouvoir leur mettre un firefox avec la boîte de dialogue kde pour les fichiers.
À part ça… merci !
[^] # Re: pour linux
Posté par FreeB5D . Évalué à 2.
(j'ai pas testé si ça marche avec Firefox)
[^] # Re: pour linux
Posté par nomorsad . Évalué à 3.
Je n'arrivait pas à comprendre pourquoi la navigation me semblait si désagréable avec FF4.
En fait, je viens juste de réalisé que quand je passe la souris sur un lien, je doit lever les yeux vers le haut de mon écran.
Une fois que j'ai cliqué, je dois baisser les yeux vers le bas de mon écran pour voir l'avancement de ma connexion (oui, la connexion du boulot rame pas mal!)
Ce va-et-vient constant me file mal au cœur, alors qu'avant non. C'est grave docteur?
# Expand the Open Web Platform to include Apps, Social and Identity
Posté par Paul Rouget . Évalué à 4.
* Identity: Account Manager (https://bugzilla.mozilla.org/show_bug.cgi?id=571409)
* Apps: https://apps.mozillalabs.com/
* Social: https://f1.mozillamessaging.com
[^] # Re: Expand the Open Web Platform to include Apps, Social and Identity
Posté par 태 (site web personnel) . Évalué à 5.
[^] # Re: Expand the Open Web Platform to include Apps, Social and Identity
Posté par Jean B . Évalué à 2.
Pour avoir pas mal bossé autour des différents protocole d'authentification, je me demandait quand est-ce qu'un protocole directement client => service sans le classique "fournisseur d'identité" allait arriver.
Par contre je pensait plus à un protocole à la OpenID, c'est à dire qui défini des attributs standard et surtout qui normalise vraiment la manière dont on s'authentifie sur le Web. Essayer de proposer des solutions à pas mal de mauvaises pratiques, comme par exemple utiliser un échange de clés à la SSH pour arrêter avec les mots de passes en clair dans les bases de données etc.
La je suis un peu déçu par le coté description de l'état des lieux. Autant je comprend bien que c'est pour faciliter l'intégration coté serveur, autant ça donne un protocole beaucoup plus compliqué.
Pour ceux qui veulent se faire une idée, la description et les cas d'usage [https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager] et le protocole lui même [https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager(...)]
Et au passage: sait-tu quel accueil à reçu ce projet de la par des autres éditeurs de navigateur ?
# Dommage pour Debian
Posté par godzom . Évalué à 1.
[^] # Re: Dommage pour Debian
Posté par 태 (site web personnel) . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.