il faut bien sur partir du principe que le but premier de Mozilla, c'est de nuire à ses utilisateurs le plus possible
Non, et si tu lis mon journal, tu t'apercevras que j'y écris très spécifiquement qu'il y a de très bonnes raisons pour Mozilla de faire les changements qu'ils proposent, dans le but d'améliorer l'expérience utilisateur.
quand ils disent qu'ils vont etendre l'API pour permettre aux extensions les plus populaires de fonctionner, il ne faut surtout pas les croire.
Ce n'est pas une question de croire ou de ne pas croire, c'est une question de possibilités techniques, comme je l'ai expliqué à maintes reprises.
Ben forcement, quand on annonce un truc qu'il est prevu de faire dans le futur, c'est toujours des voeux pieux. Tu voudrais qu'ils fassent quoi ? Qu'ils n'annoncent rien tant que tout n'est pas terminé ?
À tout le moins qu'ils en discutent un minimum avec les développeurs d'extensions populaires avant de sortir qu'ils vont tout supprimer. À en lire le message des devs de DownThemAll (au moins), rien n'a été fait en ce sens. Qu'ils produisent des statistiques, même minimalistes, du genre : avec WebExtension et le SDK, x% des extensions actuelles ayant plus de 100 utilisateurs pourront fonctionner. Avec des ajouts triviaux à WebExtension, on passe à y%. Rien que ça diminuerait considérablement la grogne.
Avant qu'on me le fasse remarquer : bien sûr qu'ils n'y sont pas forcés. Il n'y a pas de loi contre les changements d'API, et Mozilla n'a signé aucun contrat spécifiant qu'ils s'engageaient à conserver l'API actuelle. Ils peuvent aussi bien réécrire Firefox en brainfuck si ça leur chante. C'est juste qu'il y a des façons de présenter les choses qui portent moins à controverse.
Si ton proprio vient te voir en te disant qu'il va augmenter ton loyer de 103%, tu vas gueuler. Si par après il te dit "ah oui mais je ne te l'ai pas dit, en fait maintenant j'assume la moitié du coût de ton loyer", bah forcément que la pilule est plus facile à passer. Mais il aurait peut-être pu le dire avant?
C'est la même chose pour Mozilla (ou n'importe quel logiciel en fait). Lorsque les devs annoncent des changements futurs, les contradicteurs peuvent toujours se faire répondre "attends de voir, ce ne sera peut-être pas si mal en fait"! Sauf que le but de ce genre de discussions est justement d'éviter de développer des trucs inutiles et mal conçus au départ (et attention, je ne dis pas que c'est le cas ici)…
J'ai volontairement laissé le mot en anglais (d'où les guillemets), parce qu'on parle vraiment du sens de ce mot là, pas de sa traduction. Après, deprecation se traduirait par "rendre obsolète", je pense.
Tout est une question de définition du mot "deprecation". Par exemple, dans un autre billet, Mozilla titre "Deprecating Non-Secure HTTP" Est-ce que cela veut dire que les sites HTTP vont continuer à fonctionner, mais que ce n'est plus recommandé (comme certains pourraient interpréter le terme "deprecating")? Non, ça indique :
Setting a date after which all new features will be available only to secure websites and gradually phasing out access to browser features for non-secure websites, especially features that pose risks to users’ security and privacy.
Même chose pour la "deprecation" des certificats avec SHA-1.
Donc oui, mon interprétation est peut être un peu alarmiste, d'autant plus que le billet de Mozilla précise bien qu'ils n'ont pas encore de timeline précise, mais je me demande quand même jusqu'à quel point ils vont attendre les devs des extensions avant de faire des changements majeurs.
J'aimerais d'abord spécifier que lorsque j'ai posté ce journal, il n'y avait pas le paragraphe "Update" en bas du billet de Mozilla :
A lot of people have been asking what WebExtensions will deliver, and how. Bill McCloskey has posted an update on where we want to take them, and how you can contribute ideas and be part of the process. It’s a must-read for people who are concerned about how the addons they develop, use, and love will continue to be part of Firefox.
Je dis ça comme ça, mais ce n'aurait pas été une bonne idée de mentionner ça avant? Et surtout, pour l'instant, tout ça ce sont des voeux pieux. Je l'ai dit, et d'autres l'ont également dit, que ce soit dans les commentaires du billet de Mozilla, sur HackerNews ou ici, ces deux positions sont pratiquement inconciliables :
we are implementing a new, Blink-compatible API in Firefox called WebExtensions. Extension code written for Chrome, Opera, or, possibly in the future, Microsoft Edge will run in Firefox with few changes as a WebExtension.
Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible.
Soit tu acceptes que les extensions jouent dans les tripes de ton navigateur, soit tu ne l'acceptes pas… Soit tu es compatible avec ce qui se fait ailleurs (un accès très superficiel), soit tu ne l'es pas. Oh bien sûr, tu peux ajouter d'autres interfaces en plus de ce qui se fait ailleurs, mais dans ce cas les extensions développées pour Firefox ne pourront pas marcher ailleurs (Blink-compatible), et leur argumentaire est caduc.
Bref, si les devs de Mozilla réussissent le tour de force de pondre une API à la fois découplée des structures internes de Firefox et aussi puissante que ce que permet XUL présentement, je serai le premier à applaudir—et à être heureux, parce que Firefox a toujours été mon navigateur et j'espère bien qu'il le reste. Pour le moment, je demande tout de même à voir…
Tant mieux. Je n'avais pas vu ce billet, je l'admets. Cependant, deux réserves :
Comme je l'ai mentionné, il est tout à fait possible pour Mozilla d'implémenter son API WebExtension de telle façon à ce que toutes les extensions actuelles puissent y être portées. Aucun doute là-dessus. Cependant, dans ce cas, on ne règle aucun des problèmes qui sont à l'origine du passage à WebExtension. La question est donc de savoir jusqu'à quel point Mozilla acceptera que les extensions aillent jouer dans les tripes de son navigateur. Si j'ai une extension d'accessibilité qui modifie le rendu des pages, est-ce que Mozilla va laisser implémenter des hooks sur Gecko pour le permettre? Si oui, est-ce que ces hooks vont être conçus de telle façon à ne pas interférer avec les changements sur Gecko? Pas facile du tout. Si mon extension doit faire redémarrer le navigateur, est-ce que ça va être possible? Dans le billet que tu cites, le gars donne en exemple l'utilisation d'une "SideBarAPI" pour implémenter TreeStyleTab. C'est bien beau, sauf que ce genre de chose existe déjà dans Chrome, et qu'on n'y retrouve pourtant aucune extension similaire. Pourquoi? Parce qu'il y a une différence entre faire une sidebar quelconque (présentant l'historique de manière différence par exemple) et une sidebar qui interagit aussi profondément avec le navigateur. Le billet donne lui-même un exemple : il faudrait avoir moyen de cacher les "vrais" onglets via WebExtension. Je peux t'en donner plusieurs autres : il faut être en mesure d'arrêter le chargement d'une ou plusieurs pages (lorsque l'utilisateur ferme un onglet ou un groupe), d'annuler la fermeture d'un onglet, d'actualiser un ou plusieurs onglets à la fois, de gérer le glisser-déposer de liens ou d'onglets d'autres fenêtres, etc. Encore une fois, ce n'est pas impossible, mais dire "on va juste laisser les extensions créer une sidebar et ça va permettre de réimplémenter TreeStyleTab" est très réducteur, et dire "ne vous inquiétez pas, rien ne va changer pour vous" est quasi-impossible pour Mozilla sans revenir en arrière sur ses objectifs avec WebExtension.
Admettons que Mozilla réussit à conserver les extensions les plus populaires (qualificatif qui reste à définir, soit dit en passant). Quid des autres extensions, des trucs qui pourraient être développées et avoir besoin du support d'une API particulière pour le faire? J'ai vu plusieurs extensions vraiment intéressantes (d'un point de vue hacker) qui décomposaient par exemple le rendu d'une page et l'affichage des éléments, et, même au-delà de ces cas d'école, il y a formellement plein de choses qu'on peut vouloir faire pour améliorer un navigateur; supposer que les usages actuels seront toujours suffisant, c'est très limite. Le gars semble d'ailleurs le savoir, puisqu'il écrit :
We want people to be able to experiment with new ideas, and they shouldn’t have to wait for us to design, implement, and finalize a new API. However, we don’t want this to become another feature like require('chrome') in Jetpack, which is used by virtually every add-on. We’re still trying to figure out how to avoid that fate. We know that we need to be more proactive about providing APIs that add-ons need. But is that enough?
En gros, ils ne savent pas vraiment encore.
Bref, génial pour les extensions actuelles, mais j'attends quand même de voir ce que les discussions avec les devs des extensions vont donner et le bénéfice réel pour le développement de Firefox en bout de ligne.
Si tu consultes mes commentaires (je sais, personne ne fait ça), tu verras que j'ai l'habitude de défendre systématiquement Mozilla sur à peu près tous les sujets. Ça ne m'empêche pas forcément d'écrire du FUD au sujet de Mozilla, mais bien franchement ce n'est absolument pas mon but, bien au contraire.
Je suis un peu en décalage avec l'horaire de la plupart des commentateurs ici, mais je vais repasser sur les différents fils et préciser certaines choses; dans tous les cas, de manière générale, on peut dire que si ce que le journal mentionne est faux, c'est que la communication a été horriblement défaillante du côté du blog officiel de Mozilla.
Non c'est faux, la licence accordée par Microsoft permet la réinstallation complète sur le même ordinateur, en autant qu'elle ait été activée avant la fin de l'offre de gratuité.
Oui c'est "libre", sauf que tu n'as pas le droit de toucher à un octet du code (enfin, tu peux mais tu n'es dans ce cas plus couvert par la licence souscrite pas Cisco)…
Cependant, ça a déjà l'avantage de pouvoir être étudié (on peut comparer le binaire utilisé dans firefox avec une compilation perso pour s'assurer que rien n'a été ajouté ou modifié).
Ceci étant dit, merci pour la précision, c'était effectivement une erreur de ma part.
Posté par Kalenx .
En réponse à la dépêche Sortie de Firefox 40.
Évalué à 10.
Dernière modification le 14 août 2015 à 21:00.
Du point de vue du code, Firefox est aussi libre que Chrome, pas plus, pas moins (on peut arguer sans fin sur les bénéfices de la MPL vis à vis du BSD/LGPL, mais ça reste deux licences libres).
Pour le reste, la seule chose propriétaire intégrée sans que Mozilla y ait été forcé, c'est Pocket :
- La publicité ciblée n'a rien à voir avec proprio/libre
- Le décodeur H.264, tout comme le DRM EME, sont des modules propriétaires parce qu'il est impossible de faire autrement. Pour contenter à la fois la base des utilisateurs qui veulent pouvoir écouter des vidéos sur leur navigateur et que "ça juste marche" tout comme les libristes, je trouve que Mozilla a au contraire fait un super bon boulot, qui n'a été fait dans aucun autre navigateur : intégrer une sandbox permettant de limiter (et éventuellement restreindre) ce qui entre et sort des modules privateurs. Ils offrent par ailleurs une version de Firefox exempte de ces modules privateurs.
- Même chose pour les modules communiquant avec les services anti-malware de Google (voir les autres commentaires de la dépêche).
- Toutes ces décisions sont prises publiquement (et abondamment discutées), au contraire de Chrome (y compris Chromium) qui réserve parfois certaines "surprises"
- Mozilla s'est toujours battu pour les libertés de l'utilisateur. Par exemple, au sujet des DRM, Mozilla a toujours été vertement opposé à la mise en place de ces systèmes, et n'a finalement accepté à regret de l'intégrer qu'après que ce DRM soit devenu une spécification officielle du W3C, grâce au soutien de Microsoft, Apple, Google, Netflix, etc.
Bref, oui, je crois que ce que Mozilla fait est plus libre que ce que l'équipe de Chromium fait. Pourquoi les parts de marché de Mozilla s'effritent-elles alors?
Parce que Chrome/Chromium est meilleur techniquement et évolue plus rapidement?
Parce que les autres navigateurs (même IE/Edge) ne sont plus risibles en comparaison de Firefox?
Parce que c'est IE, Safari et Chrome qui sont installés par défaut, Mozilla refusant de payer pour ça (et c'est encore plus marqué sur mobile)?
Mais certainement pas parce que les libristes se sont dit "hey, Firefox a intégré Pocket, c'est intolérable et je vais donc passer sur Chrome qui représente mieux mes idéaux de L.L."…
Dans les années 90, un navigateur pouvait être le projet d'une semaine. Aujourd'hui, faire un navigateur moderne et le maintenir est une toute autre affaire. Entre les gazillions de standards à respecter (et à faire évoluer), la course à la performance dans l'interprétation de langages douteux (qui fait entre autre que le javascript est parfois plus rapide que le C/C++ pour un code équivalent…), les interfaces qu'il faut maintenant offrir aux sites web tout en veillant à ce qu'il n'y ait pas de failles de sécurité (accès au GPU, à la caméra, aux capteurs de position/GPS, à des sockets, des fichiers locaux, etc.), les nombreux standards de sécurité de plus en plus complexes et dont l'implémentation doit être vérifiée au compte-goutte, le temps et le budget requis sont sans commune mesure avec ce qui prévalait dans les débuts de Mozilla.
Deuxièmement, je ne vois pas pourquoi "aimer le libre" implique de "ne pas aimer la pub". Ce sont deux choses orthogonales (d'ailleurs, si tu veux modifier Firefox pour exclure tout ça, ça tombe bien, tu peux le faire).
Finalement, l'effritement de leurs parts de marché est aussi dû au fait que maintenant les autres navigateurs sont aussi de bons navigateurs. Et, bien franchement, autant je veux bien que l'on veuille passer à Chrome pour des raisons de performance ou d'usabilité, autant on ne viendra pas me faire croire que les libristes purs et durs quittent Firefox pour Edge/Chrome/Safari/Opera parce que Firefox "n'est plus assez libre"…
Firefox 40: Firefox warns about signatures but doesn't enforce them.
Firefox 41: Firefox will have a preference that allows signature enforcement to be disabled (xpinstall.signatures.required in about:config).
Firefox 42: Release and Beta versions of Firefox will not allow unsigned extensions to be installed, with no override.
Peut-être que s'ils arrêtaient de faire du caca et écoutaient leurs utilisateurs (conso de mémoire, version 64 bits officielle pour Windows) ils se feraient moins critiquer…
Ah, ces chers "utilisateurs". Je ne connais pas un seul logiciel (libre ou pas) qui ne serait pas mieux si son éditeur arrêtait de "faire du caca" et écoutait les utilisateurs qui savent bien mieux ce qu'il faut faire que les programmeurs de ce logiciel…
Posté par Kalenx .
En réponse au journal Cisco annonce Thor.
Évalué à 4.
Dernière modification le 13 août 2015 à 10:00.
Je n'ai JAMAIS critiqué les personnes qui aiment le libre pour l'esprit de partage. Tu inventes des reproches qui n'existent pas. Pourquoi as-tu besoin d'inventer? Généralement, c'est qu'on n'est pas bien à l'aise avec la critique qu'on a reçu…
Tout à fait. En fait, en ce moment même, je défaille devant mon écran. Non, plus prosaïquement, je répondais à ça :
Linux soutenu par des GUL est un échec complet. Linux sur le desktop est un échec complet, l'exemple de ce qu'il ne faut pas faire. Linux sur les serveur a gagné absolument pas pour son éthique, mais pour son prix, n'en déplaise au fantasmes de libristes qui s'y croient. Ton idéal n'apporte rien.
Bon et après je n'irai pas plus avant dans la discussion parce que manifestement tu ne veux pas comprendre :
un peu de sérieux… Mozilla est à fond dans le business et essaye tout ce qu'il peut pour avoir de la thune (faut voir toutes les tentatives de récupérer de l'argent sans trop énerver les utilisateurs), et Linux marche grâce à de la thune de plein d'entreprises (Argent de Linux fundation?)… Quand à GNU, d'autres projets auraient fait le taf si il n'avait pas existé malgré les tentatives "GNU/Linux"…
Et qu'est-ce que j'ai dit?
S'il n'y avait pas eu les gens de GNU, de BSD, de Netscape/Mozilla, du noyau Linux, qui, au départ, ne travaillaient clairement pas en vue de gains pécuniaires
Bien sûr que Linux marche avec la thune de plein d'entreprises—même si les contributeurs indépendants sont encore nombreux, mais ça n'a tout simplement aucun rapport avec ce que j'ai dit. Linux ne serait même pas né si tout le monde avait seulement tenu compte des économies potentielles. Mozilla (sur qui il semble être à la mode de cracher parce qu'ils veulent obtenir un revenu pérenne) a commencé sur un simple idéal, succédant à une entreprise qui s'était lamentablement fait écraser; les gens qui ont lancé Mozilla ne l'ont certainement pas fait en se disant "quel bon moyen de faire de la thune!". Non, en 2000, le bon moyen de faire de la thune, c'était de passer sur IE et d'y rester.
Évidemment que d'autres projets auraient plus ou moins remplacé GNU si ce dernier n'avait pas existé, mais ça revient à dire Nelson Mandela n'a rien fait puisque "d'autres l'auraient remplacé s'il n'avait pas été là". Le fait est que GNU a été d'une importance capitale dans le développement du libre et ce, encore une fois, pas parce que Stallman a décidé de faire le plus de pognon.
Sans les économies qui vont avec le libre, il n'y aurait pas de libre, que ça plaise ou pas.
Peu importe le domaine d'activité, il est évident qu'un mouvement qui ne génère strictement aucun revenu ne risque pas de prospérer. Bien évidemment que l'argument économique est important pour le libre, mais, encore une fois, dire que l'essence du libre et son existence entière se résument à une histoire de comptables et de rapports financiers est plus que discutable.
Je pourrais parler du côté philosophique, mais d'autres l'ont déjà fait avant moi (et probablement mieux que moi). Je trouve tout de même triste que tu ne puisses admettre que certaines personnes aient des principes mais qu'elles soient aussi capables d'être pragmatiques. On peut vouloir acheter local et bio (c'est un principe), mais tout de même être pragmatique et accepter d'acheter du gingembre dont on ne connait pas forcément la provenance.
C'est la même chose pour la plupart des libristes : demander à un libriste de hurler lorsqu'on lui demande d'utiliser VP9 sous prétexte que sinon "tout ton argumentaire sur l'éthique tomberait à l'eau", c'est juste du n'importe quoi. Faut arrêter de demander à tout le monde de laver plus blanc que blanc, parce qu'en l'état, j'ai surtout l'impression de lire un caméo de Caligula de Camus, qui, à un intendant lui ayant dit que le Trésor était capital, donne l'ordre de :
[tuer tous les patriciens pour obtenir leur fortune.] Écoute-moi bien, imbécile. Si le Trésor a de l'importance, alors la vie humaine n'en a pas. Cela est clair. Tous ceux qui pensent comme toi doivent admettre ce raisonnement et compter leur vie pour rien puisqu'ils tiennent l'argent pour tout.
Donc la prochaine fois que quelqu'un dit qu'il aime le libre pour l'esprit de partage et non pour les économies qu'il lui fait réaliser, serait-il possible d'éviter de sortir des requêtes absurdes et totalement hors sujet (rendu là, tu pourrais aussi demander s'il serait prêt à mourir pour le libre, sinon ce n'est pas "un vrai libriste")?
Pour le reste, choisir simplement la solution la moins chère est aussi fallacieux techniquement. S'il n'y avait pas eu les gens de GNU, de BSD, de Netscape/Mozilla, du noyau Linux, qui, au départ, ne travaillaient clairement pas en vue de gains pécuniaires, eh bien il n'y aurait pour ainsi dire pas de libre, et, par conséquent, pas les économies qui vont maintenant avec…
Je ne dis pas que c'est mal de choisir le libre sur des critères comptables (au contraire), juste qu'il faut arrêter de penser que c'est le seul critère possible pour quiconque étant le moindrement raisonnable. Tu considères qu'il n'y a pas de meilleure éthique en ce domaine, et c'est ton choix, mais ce n'est pas celui de tous.
Posté par Kalenx .
En réponse à la dépêche Sortie de Firefox 40.
Évalué à 10.
Dernière modification le 13 août 2015 à 04:33.
En fait, si on lit le passage que tu as cité, ça me semble assez clair :
Firefox asks Google’s Safe Browsing service if the file is safe by sending it some of the download’s metadata (file type, name, size, hash, URL, locale)
Donc a priori, oui, ça envoie des données à Google.
Cependant, tu as coupé la citation en deux (en fait tu as littéralement coupé une phrase en deux). Voici ce qui est dit entre les deux blocs de texte que tu as cités :
When downloading a file of a type that usually contains Windows or Mac executable code (for example, .com, .exe, .msi, .app, .dmg), Firefox asks […]
Bref, je comprends les préoccupations que peuvent avoir certaines personnes et je respecte ça, je dois même dire que ce genre de systèmes ne me plait guère personnellement, mais il est clairement faux de dire que "la liste de tous les fichiers qu'on télécharge est envoyée à Google".
Non il ne faut pas "attendre 3 mois pour sortir un truc plutôt que le sortir quand il est prêt".
Ce que je dis, c'est que si tu ne peux pas envisager de pousser le driver dans le noyau 3 mois avant la sortie de ton bidule, c'est que c'est que ce driver est loin d'être terminé. S'il est loin d'être terminé, alors tu ne peux pas le tester (oh, j'imagine que tu peux rouler quelques tests unitaires ici et là, mais aucun test d'intégration ou quoi que ce soit de plus poussé), donc tu te laisses moins de 3 mois pour tester, déboguer et publier ton driver. Si c'est le cas, alors oui je pense qu'il y a un problème—encore une fois si c'est un truc tout con du genre un driver qui lit un device série virtuel dans un certain format, alors en effet tu n'as pas besoin de 3 mois pour tester ça, mais justement tu n'as pas non plus à passer par le noyau…
Après, je me fiche effectivement que ce soit 3 mois ou 2½ ou 4, j'ai pris 3 mois en particulier parce que c'était ce que tu mentionnais dans ta précédente réponse.
2 jours non, je suis sensé le finir 6 mois avant aussi ? A chaque update je dois attendre 6 mois ? Sur des projets dont le cycle est de moins de 6 mois, on va dire que c'est pas top.
6 mois, c'est effectivement trop long dans la plupart des cas (même si il y en a certains à qui ça convient, comme par exemple Intel). Ceci étant, je n'ai aucune statistique sur le délai moyen entre un premier pull request dans stagging et une inclusion dans le mainline.
Par contre, si tu es dans le kernel, non, tu n'as pas à attendre 6 mois pour chaque update; une fois le driver inclus, les itérations sont beaucoup plus rapides.
Par ailleurs, je réitère : beaucoup de périphériques n'ont pas à avoir un driver en espace noyau. C'est particulièrement vrai pour la plupart des périphériques d'acquisition de données ou de contrôle. Dès que tu peux passer par l'USB et que tu n'as pas à contourner le contrôleur standard de Linux pour gérer les bugs de ton périphérique, alors ton driver peut tout à fait résider en espace utilisateur (privilégié) et utiliser l'API/ABI USB standard et stable pour communiquer avec le périphérique.
Je donne un exemple, je ne dis pas que c'est le plus pertinent, mais c'est le premier qui me vient en tête vu mon occupation actuelle : Phidgets, qui est une boîte dont le coeur de métier est la commercialisation de senseurs et contrôleurs faciles à interfacer (autant au niveau hardware que software). Leur driver est une simple librairie qui supporte C/C++, C#, Python, Java, VB.NET, etc. et qui est binairement compatible avec pour ainsi dire toutes les distributions (en autant que libusb soit installé, ce qui est un prérequis acceptable je crois).
Et ça tombe très bien pour eux : effectivement, lorsqu'ils sortent un nouveau produit (par exemple un nouveau thermocouple), ils n'ont pas envie d'attendre plusieurs mois pour qu'il soit pris en charge par les systèmes Linux, mais il leur suffit de mettre à jour leur librairie et ça marche automatiquement partout.
Je ne dis pas que tout le monde peut faire ça, mais pour la plupart des boites dont l'écriture de drivers n'est pas le coeur de métier (par exemple des compagnies qui veulent commercialiser un nouveau produit dont le driver n'est qu'une interface, l'innovation étant vraiment dans le produit en soi), il n'y a aucun problème avec le modèle actuel.
Pour les boites plus grosses, pour qui les drivers représentent en soi un atout important, oui, j'espère que ceux-ci sont terminés 3 mois avant la sortie du produit qu'ils accompagnent, et que les développeurs sont passés à l'écriture du driver de la génération suivante.
Ce qui ne résoud absolument rien à la problématique d'avoir les drivers sur les distribs déjà sorties. Le problème n'est pas d'écrire le driver, je l'ai fini le driver, le problème c'est le faire tourner sur les distribs existantes, s'assurer qu'il est updaté quand une update du kernel est installée sur ces distribs, etc…
Et le driver, tu l'as fini 2 jours avant de devoir livrer le produit? Parce que fondamentalement, c'est ça le problème…
Pour ce qui est de le faire tourner sur les distribs existantes, si tu tiens absolument à rester hors de l'arbre principal du kernel, tu fais comme tous les fabricants de matériel : tu certifies le fonctionnement sur certaines distros commerciales (RedHat, Suse, Ubuntu, etc.) et si l'utilisateur veut l'installer sur son Damn Small Linux, ben c'est son problème (ou plutôt le tien, puisque cet utilisateur là, pour qui tout aurait bien fonctionné si tu avais empaqueté ton driver dans le kernel, n'achèteras probablement plus tes produits).
Par ailleurs, pour ta gouverne, les grosses boîtes (au moins RedHat et Suse) garantissent une ABI stable dans les révisions mineures (regarde par exemple le paquet kabi-whitelists dans RHEL), donc rendu là tu n'as pas à te soucier des updates.
Encore une fois, non ce système n'est pas parfait. Par exemple, une amélioration possible (il me semble que ça s'était discuté sur LWN, je ne retrouve plus le lien) serait d'empaqueter les drivers dans le main line, dès leur inclusion dans stagging, sous réserve qu'il soit démontré qu'ils n'affectent pas le reste du système, mais avec potentiellement un tag spécial pour indiquer que ce sont encore des drivers expérimentaux. Ça réduirait drastiquement le temps requis pour être inclus dans les principales distros (y compris celles déjà sorties, puique toutes les distros backportent les drivers dans leurs révisions mineures…)
Après, effectivement, si tu es une boîte qui compte distribuer planétairement un produit dont le driver a été terminé une semaine avant la sortie commerciale, le modèle de Windows convient mieux.
La question que je me pose, c'est surtout de savoir si je veux acheter ce genre de produits…
Encore une fois, je ne prétends pas que le modèle de développement des drivers sous Linux soit la meilleure chose que la Terre ait connue après le scotch-tape double face, mais plutôt qu'il faut pondérer les avantages et inconvénients de chaque modèle.
C'est certain que si une entreprise développe des bidules pour Windows depuis 15 ans et qu'elle se met soudain au développement sous Linux, alors ses devs vont probablement râler. Cela veut-il dire que l'approche est fondamentalement mauvaise? Je ne crois pas.
Il y a en fait encore beaucoup d'idées reçues à propos du développement de drivers sous Linux, et, autant je ne suis clairement pas un expert de la certification WHQL et du développement sous Windows, autant je pense que tu ne l'es pas non plus sous Linux. Par exemple :
Linux ? Ben à moins de se mettre à parler a Ubuntu, Suse, etc… 6 mois-1 an avant la sortie, ce qui est absolument énorme, c'est impossible, et ils ne pourront pas non plus avoir une sortie synchronisée sur les diffèrentes distribs
Régler ce problème est exactement le but visé par le Driver Backport Workgroup de la Linux Foundation.
leurs concurrents vont voir le module kernel apparaitre des mois avant la sortie finale du produit, avoir le temps de faire du reverse engineering dessus et réagir
On revient à la bonne vieille critique du libre : "bouh mais mon concurrent va pouvoir copier sur moi…". Sinon, il est tout à fait possible de travailler de manière confidentielle un bon moment avec les développeurs du noyau, grâce au Linux Foundation NDA Program.
Et encore, je ne parle pas du Linux Driver Project, qui (je cite) :
[Permet aux fabricants de] get their driver written for free by volunteer kernel developers. The IHV provides a specification that describes how their device works, the email address of an engineer willing to answer questions, and (ideally) a few sample devices. An expert developer team of volunteers led by Greg Kroah-Hartman returns a complete and working Linux driver that is added to the mainline Linux kernel source tree.
The driver (like all Linux drivers) is automatically kept up to date and working through all Linux kernel API changes. The driver will work with all of the different CPU types supported by Linux, the largest number of CPU types supported by any operating system ever. At the IHV's option, the work can be done under LF NDA program.
Je ne parle pas non plus de l'appel explicite des développeurs centraux aux mainteneurs à merger le plus rapidement possible les drivers, tant que ces derniers n'affectent pas le reste du noyau.
Je passe par ailleurs sur tous les aspects techniques favorisés par les changements d'ABI possible (simplicité du code, sécurité, augmentation des performances "gratuite" dans certains cas, etc.)
Bref, bien sûr qu'il y a matière à critique, mais il ne faut pas amplifier cette dernière sous prétexte que les éditeurs tiennent absolument à rester à un mode de développement qui avait cours à la sortie de Windows XP…
Les tests WHQL que les drivers doivent passer pour etre signé par MS sont largement plus aboutis que ce qui se trouve sur Linux pour tester les modules kernel, et de très très loin.
Ah non, mais ça ça ne va pas du tout! Parce que vois-tu, les tests WHQL bloquent clairement à lui seul nombre de développements. Parce que l'insertion dans mainline la certification WHQL, ça prend du temps, le produit il doit sortir hier, il doit supporter autant de systèmes que possible (ça inclut donc devoir faire signer le driver par Microsoft, sinon le noyau ne veut même pas le lancer sur les systèmes 64 bits), et il faut que ce soit pas cher à maintenir (ça inclut refaire les tests WHQL à chaque itération du driver, même une révision mineure), etc., etc.
En fait, c'est un peu la même chose que l'insertion dans mainline : et si je ne veux pas moi, faire certifier mon driver? C'est exactement la même problématique que : et si je ne veux pas moi, open-sourcer mon driver et l'inclure dans le kernel?
Bah si tu ne veux pas, tu te débrouilles…
Note que je n'ai aucun problème envers la certification WHQL en soi, je pense que c'est déjà un bon système qui a limité grandement le nombre de drivers pourrave, mais je veux juste te faire remarquer à quel point il est facile de descendre un système à grand coup de "les entreprises n'aiment pas ça"…
Un store ne sera effectivement jamais 100% sur, mais c'est tout à fait vrai pour les depots aussi.
Oui, tout comme il est vrai que "une relation sexuelle non protégée ne sera jamais 100% sur, mais c'est tout à fait vrai pour les relations avec préservatif aussi"…
Par ailleurs, oui, les sandbox limitent les dégâts, mais ça n'a rien à voir avec le mode de distribution et je répondais à ta remarque :
Le Windows store evite tous ces problèmes.
Sinon :
Pour Linux et les drivers, le scenario que j'ai donné plus haut je ne l'ai pas sorti de mon chapeau hein, et il bloque à lui seul nombre de développements. Parce que l'insertion dans mainline, ça prend du temps, le produit il doit sortir hier, il doit supporter autant de systèmes que possible, et il faut que ce soit pas cher à maintenir.
À t'entendre, on jurerait que tu soutiens que le modèle de Windows encourage les développements à la va-vite, avec une avalanche de modifications à la dernière minute "parce qu'il faut sortir le produit hier", et qui ne vont surtout pas prendre du temps pour corriger les bugs et limitations du driver parce que sinon c'est trop cher à maintenir…
Un contre-argument serait de me répondre que si les boîtes veulent faire des drivers moisis et pas aboutis, ce n'est pas le problème de Microsoft, et ce n'est pas formellement faux, mais ça ne me ravit pas pour autant.
Cependant, il y a nombre d'initiatives pour faciliter l'inclusion de drivers dans Linux (à commencer par la branche staging), et, bien que je n'ai honnêtement pas de statistiques pour confirmer la chose, je doute qu'un driver bien conçu et relativement simple (comprendre : pas un nouveau driver de carte vidéo) requiert tant de temps pour entrer dans le kernel; une fois qu'il y est, la maintenance "de base" (e.g. suivre les changements d'API et d'ABI internes) est pour ainsi dire gratuite…
Je peux voir l'avantage économique que peut avoir le modèle de Microsoft, mais je ne suis quand même pas certain que c'est ainsi que je veux voir développer des bouts de code capables potentiellement d'accéder à pas mal de choses dans mon ordinateur…
Soyons sincères (et ça vaut pour Android et iOS aussi) : de la manière dont ils fonctionnent (avec comme principe de base qu'il faut tout avoir, parce que sinon l'utilisateur ne sera pas content et ira ailleurs), aucun store ne peut prétendre à régler les problèmes de bloatwares, spywares, logiciels dangereux et autres scams.
Je ne dis pas que c'est pire qu'avant, mais je ne vois sincèrement pas d'énorme amélioration…
Pour les drivers, Linux n'est effectivement pas le paradis des indolents qu'est Windows (où tu peux littéralement faire n'importe quoi et t'attendre à ce que les devs de Microsoft se débrouillent pour que tes produits marchent encore, il suffit d'aller faire un tour sur le par ailleurs très instructif blog theoldnewthing pour en voir d'excellents exemples), mais, bien franchement, pour beaucoup de produits, ça n'a rien d'incroyablement complexe. Si tu produis un périphérique pour lequel des standards existent (ex. UVC pour les caméras, Postscript pour les imprimantes—même si dans ce dernier cas je simplifie un peu) alors ça marche direct. Si tu produis un périphérique simple (comme beaucoup de petites boîtes), pour lesquels une liaison série virtuelle ou un simple driver codé avec l'API USB du kernel suffit, alors ça va aussi.
De plus, lorsqu'une compagnie accepte de libérer son driver et de l'inclure dans le kernel, alors les cassages d'ABI (voir d'API interne) ne sont plus un problème puisque tout peut être modifié d'un coup par les devs du kernel : ton driver fonctionne alors peu-importe la version du kernel.
Bref, je ne prétends pas que Linux soit le meilleur des mondes pour le fabricant qui veut juste sortir son produit et faire du pognon avec pendant 15 ans sans toucher à une ligne de code, mais il ne faut pas exagérer dans l'autre sens non plus et faire croire que les devs s'amusent à changer l'ABI à tous les deux jours rien que pour énerver les gens…
Pour envoyer bouler le mec agressif qui vient te voir, c'est que tu te sens au dessus des autres
Si quelqu'un vient vous crier dessus au taf en vous disant que vous êtes un incompétent et une sombre merde et que vous l'envoyez bouler, c'est vous qui êtes en tort? C'est une vraie question, hein, je suis sincèrement curieux.
Pour le reste, non, je ne suis pas d'accord. Je me fiche que le mec soit 10 fois plus intelligent, compétent ou expérimenté que moi, il y a des façons de présenter les choses, et ce, peu importe du côté duquel tu te trouves (chez les devs ou chez les users). Ulrich Drepper est un excellent programmeur et très intelligent, ça ne m'empêche pas de trouver que c'était un con. Même chose pour Theo de Raadt et, plus rarement, pour Linus.
Ça n'empêche pas d'être direct : on peut sans problème critiquer vertement un logiciel ou un framework, mais 1) ça doit être appuyé sur autre chose que la nostalgie du bon vieux temps, sans autre preuve et 2) ça doit être fait en respectant les gens qui y bossent. Sinon, ça a autant d'intérêt pour moi qu'un morceau de lichen sibérien (à savoir assez peu).
Appelez cela prendre les gens de haut si ça vous chante, mais bien franchement, il n'y a aucun élément de domination ou d'égocentrisme dans ma réflexion. Seulement un profond ennui…
Et entre nous le vrai con, c'est pas celui qui gueule qu'il est pas content, c'est celui qui te prend de haut sans comprendre.
Et ceux qui font les deux (non, je ne parle pas de vous)?
Pour le reste, je dois dire que votre dernière phrase aurait tout à fait pu être écrite par Zenitram :
Alors je ne me sens pas supérieur aux autres, mais je n'accepte pas de me faire marcher sur les pieds par plus con que moi.
Tant que c'est vous qui décidez qui est con et qui ne l'est pas, c'est certain que ça arrange…
C'est vrai. Sauf que… parfois il y a les bonnes pratiques, et les pratiques pratiques…
Le but de se logger par clé SSH est d'éviter de taper un mot de passe (et donc devoir taper sans cesse le mot de passe SSH n'est pas vraiment intéressant). Avec le recul, j'aurais dû mettre en place un ssh-agent mais bon… c'est facile de dire ça par après. En attendant je suis bon pour une petite leçon, et je n'ai que moi à blâmer là-dessus (bon, un peu Mozilla aussi, quand même) ;-)
Si j'en crois votre réponse, le simple fait qu'il ne puisse mettre "un putain de lien avec icône dans la barre des tâches" est suffisant pour titrer "Comment mon expérience Linux est en train de tourner au fiasco". Intéressant…
Je ne commenterai pas plus avant du côté technique, je l'avais déjà fait dans le précédent journal et ça n'avait rien donné, d'autant plus que in fine, le problème n'est pas technique, il est humain.
Certains considèrent que d'enguirlander quelqu'un et de les traiter d'incompétents est la réponse adéquate lorsqu'on n'est pas satisfait, même si c'est seulement "ne pas pouvoir mettre un raccourci avec le bon icone dans la barre des tache, un truc de malade il est vrai."
Je ne crois pas que ce soit la bonne manière de procéder, mais chacun ses goûts.
Oh, et soit dit en passant, je n'ai jamais "taper sur la gueule de ceux qui se plaignent" ou "traité l'auteur de sombre con". J'ai simplement dit que 1) lui pourrait arrêter de traiter les devs du monde entier de décérébrés sous prétexte que les devs de KDE ont viré Konqueror ou que KCalc n'accepte plus le "." du pavé numérique et que 2) il y a une différence entre critique et critique constructive et qu'il n'est pas étonnant que les gens ne veuillent pas lui "expliquer le problème technique" quand il vient de démontrer par ailleurs qu'il se fiche totalement des raisons techniques, il veut juste gueuler le plus fort possible.
[^] # Re: Et le bordel monstre qu'est devenu le magasin d'applications ?
Posté par Kalenx . En réponse au journal La fin du "permissive add-on model" chez Mozilla, ou comment flinguer une base d'extensions. Évalué à 1.
Non, et si tu lis mon journal, tu t'apercevras que j'y écris très spécifiquement qu'il y a de très bonnes raisons pour Mozilla de faire les changements qu'ils proposent, dans le but d'améliorer l'expérience utilisateur.
Ce n'est pas une question de croire ou de ne pas croire, c'est une question de possibilités techniques, comme je l'ai expliqué à maintes reprises.
À tout le moins qu'ils en discutent un minimum avec les développeurs d'extensions populaires avant de sortir qu'ils vont tout supprimer. À en lire le message des devs de DownThemAll (au moins), rien n'a été fait en ce sens. Qu'ils produisent des statistiques, même minimalistes, du genre : avec WebExtension et le SDK, x% des extensions actuelles ayant plus de 100 utilisateurs pourront fonctionner. Avec des ajouts triviaux à WebExtension, on passe à y%. Rien que ça diminuerait considérablement la grogne.
Avant qu'on me le fasse remarquer : bien sûr qu'ils n'y sont pas forcés. Il n'y a pas de loi contre les changements d'API, et Mozilla n'a signé aucun contrat spécifiant qu'ils s'engageaient à conserver l'API actuelle. Ils peuvent aussi bien réécrire Firefox en brainfuck si ça leur chante. C'est juste qu'il y a des façons de présenter les choses qui portent moins à controverse.
Si ton proprio vient te voir en te disant qu'il va augmenter ton loyer de 103%, tu vas gueuler. Si par après il te dit "ah oui mais je ne te l'ai pas dit, en fait maintenant j'assume la moitié du coût de ton loyer", bah forcément que la pilule est plus facile à passer. Mais il aurait peut-être pu le dire avant?
C'est la même chose pour Mozilla (ou n'importe quel logiciel en fait). Lorsque les devs annoncent des changements futurs, les contradicteurs peuvent toujours se faire répondre "attends de voir, ce ne sera peut-être pas si mal en fait"! Sauf que le but de ce genre de discussions est justement d'éviter de développer des trucs inutiles et mal conçus au départ (et attention, je ne dis pas que c'est le cas ici)…
[^] # Re: Timeline
Posté par Kalenx . En réponse au journal La fin du "permissive add-on model" chez Mozilla, ou comment flinguer une base d'extensions. Évalué à 2.
J'ai volontairement laissé le mot en anglais (d'où les guillemets), parce qu'on parle vraiment du sens de ce mot là, pas de sa traduction. Après, deprecation se traduirait par "rendre obsolète", je pense.
[^] # Re: Timeline
Posté par Kalenx . En réponse au journal La fin du "permissive add-on model" chez Mozilla, ou comment flinguer une base d'extensions. Évalué à 1.
Tout est une question de définition du mot "deprecation". Par exemple, dans un autre billet, Mozilla titre "Deprecating Non-Secure HTTP" Est-ce que cela veut dire que les sites HTTP vont continuer à fonctionner, mais que ce n'est plus recommandé (comme certains pourraient interpréter le terme "deprecating")? Non, ça indique :
Même chose pour la "deprecation" des certificats avec SHA-1.
Donc oui, mon interprétation est peut être un peu alarmiste, d'autant plus que le billet de Mozilla précise bien qu'ils n'ont pas encore de timeline précise, mais je me demande quand même jusqu'à quel point ils vont attendre les devs des extensions avant de faire des changements majeurs.
[^] # Re: Et le bordel monstre qu'est devenu le magasin d'applications ?
Posté par Kalenx . En réponse au journal La fin du "permissive add-on model" chez Mozilla, ou comment flinguer une base d'extensions. Évalué à 8. Dernière modification le 22 août 2015 à 17:17.
J'aimerais d'abord spécifier que lorsque j'ai posté ce journal, il n'y avait pas le paragraphe "Update" en bas du billet de Mozilla :
Je dis ça comme ça, mais ce n'aurait pas été une bonne idée de mentionner ça avant? Et surtout, pour l'instant, tout ça ce sont des voeux pieux. Je l'ai dit, et d'autres l'ont également dit, que ce soit dans les commentaires du billet de Mozilla, sur HackerNews ou ici, ces deux positions sont pratiquement inconciliables :
Soit tu acceptes que les extensions jouent dans les tripes de ton navigateur, soit tu ne l'acceptes pas… Soit tu es compatible avec ce qui se fait ailleurs (un accès très superficiel), soit tu ne l'es pas. Oh bien sûr, tu peux ajouter d'autres interfaces en plus de ce qui se fait ailleurs, mais dans ce cas les extensions développées pour Firefox ne pourront pas marcher ailleurs (Blink-compatible), et leur argumentaire est caduc.
Bref, si les devs de Mozilla réussissent le tour de force de pondre une API à la fois découplée des structures internes de Firefox et aussi puissante que ce que permet XUL présentement, je serai le premier à applaudir—et à être heureux, parce que Firefox a toujours été mon navigateur et j'espère bien qu'il le reste. Pour le moment, je demande tout de même à voir…
[^] # Re: Tree Style Tab, NoScript, Pentadactyl, etc ...
Posté par Kalenx . En réponse au journal La fin du "permissive add-on model" chez Mozilla, ou comment flinguer une base d'extensions. Évalué à 6.
Tant mieux. Je n'avais pas vu ce billet, je l'admets. Cependant, deux réserves :
En gros, ils ne savent pas vraiment encore.
Bref, génial pour les extensions actuelles, mais j'attends quand même de voir ce que les discussions avec les devs des extensions vont donner et le bénéfice réel pour le développement de Firefox en bout de ligne.
[^] # Re: FUD !
Posté par Kalenx . En réponse au journal La fin du "permissive add-on model" chez Mozilla, ou comment flinguer une base d'extensions. Évalué à 0.
Si tu consultes mes commentaires (je sais, personne ne fait ça), tu verras que j'ai l'habitude de défendre systématiquement Mozilla sur à peu près tous les sujets. Ça ne m'empêche pas forcément d'écrire du FUD au sujet de Mozilla, mais bien franchement ce n'est absolument pas mon but, bien au contraire.
Je suis un peu en décalage avec l'horaire de la plupart des commentateurs ici, mais je vais repasser sur les différents fils et préciser certaines choses; dans tous les cas, de manière générale, on peut dire que si ce que le journal mentionne est faux, c'est que la communication a été horriblement défaillante du côté du blog officiel de Mozilla.
[^] # Re: Survie
Posté par Kalenx . En réponse au journal Et si la gratuité de Windows 10 n'était qu'un moyen pour déstabiliser Linux ?. Évalué à 3.
Non c'est faux, la licence accordée par Microsoft permet la réinstallation complète sur le même ordinateur, en autant qu'elle ait été activée avant la fin de l'offre de gratuité.
[^] # Re: Et le Expanded Malware Protection?
Posté par Kalenx . En réponse à la dépêche Sortie de Firefox 40. Évalué à 2.
Oui c'est "libre", sauf que tu n'as pas le droit de toucher à un octet du code (enfin, tu peux mais tu n'es dans ce cas plus couvert par la licence souscrite pas Cisco)…
Cependant, ça a déjà l'avantage de pouvoir être étudié (on peut comparer le binaire utilisé dans firefox avec une compilation perso pour s'assurer que rien n'a été ajouté ou modifié).
Ceci étant dit, merci pour la précision, c'était effectivement une erreur de ma part.
[^] # Re: Et le Expanded Malware Protection?
Posté par Kalenx . En réponse à la dépêche Sortie de Firefox 40. Évalué à 10. Dernière modification le 14 août 2015 à 21:00.
Du point de vue du code, Firefox est aussi libre que Chrome, pas plus, pas moins (on peut arguer sans fin sur les bénéfices de la MPL vis à vis du BSD/LGPL, mais ça reste deux licences libres).
Pour le reste, la seule chose propriétaire intégrée sans que Mozilla y ait été forcé, c'est Pocket :
- La publicité ciblée n'a rien à voir avec proprio/libre
- Le décodeur H.264, tout comme le DRM EME, sont des modules propriétaires parce qu'il est impossible de faire autrement. Pour contenter à la fois la base des utilisateurs qui veulent pouvoir écouter des vidéos sur leur navigateur et que "ça juste marche" tout comme les libristes, je trouve que Mozilla a au contraire fait un super bon boulot, qui n'a été fait dans aucun autre navigateur : intégrer une sandbox permettant de limiter (et éventuellement restreindre) ce qui entre et sort des modules privateurs. Ils offrent par ailleurs une version de Firefox exempte de ces modules privateurs.
- Même chose pour les modules communiquant avec les services anti-malware de Google (voir les autres commentaires de la dépêche).
- Toutes ces décisions sont prises publiquement (et abondamment discutées), au contraire de Chrome (y compris Chromium) qui réserve parfois certaines "surprises"
- Mozilla s'est toujours battu pour les libertés de l'utilisateur. Par exemple, au sujet des DRM, Mozilla a toujours été vertement opposé à la mise en place de ces systèmes, et n'a finalement accepté à regret de l'intégrer qu'après que ce DRM soit devenu une spécification officielle du W3C, grâce au soutien de Microsoft, Apple, Google, Netflix, etc.
Bref, oui, je crois que ce que Mozilla fait est plus libre que ce que l'équipe de Chromium fait. Pourquoi les parts de marché de Mozilla s'effritent-elles alors?
Mais certainement pas parce que les libristes se sont dit "hey, Firefox a intégré Pocket, c'est intolérable et je vais donc passer sur Chrome qui représente mieux mes idéaux de L.L."…
[^] # Re: Et le Expanded Malware Protection?
Posté par Kalenx . En réponse à la dépêche Sortie de Firefox 40. Évalué à 10.
Dans les années 90, un navigateur pouvait être le projet d'une semaine. Aujourd'hui, faire un navigateur moderne et le maintenir est une toute autre affaire. Entre les gazillions de standards à respecter (et à faire évoluer), la course à la performance dans l'interprétation de langages douteux (qui fait entre autre que le javascript est parfois plus rapide que le C/C++ pour un code équivalent…), les interfaces qu'il faut maintenant offrir aux sites web tout en veillant à ce qu'il n'y ait pas de failles de sécurité (accès au GPU, à la caméra, aux capteurs de position/GPS, à des sockets, des fichiers locaux, etc.), les nombreux standards de sécurité de plus en plus complexes et dont l'implémentation doit être vérifiée au compte-goutte, le temps et le budget requis sont sans commune mesure avec ce qui prévalait dans les débuts de Mozilla.
Deuxièmement, je ne vois pas pourquoi "aimer le libre" implique de "ne pas aimer la pub". Ce sont deux choses orthogonales (d'ailleurs, si tu veux modifier Firefox pour exclure tout ça, ça tombe bien, tu peux le faire).
Finalement, l'effritement de leurs parts de marché est aussi dû au fait que maintenant les autres navigateurs sont aussi de bons navigateurs. Et, bien franchement, autant je veux bien que l'on veuille passer à Chrome pour des raisons de performance ou d'usabilité, autant on ne viendra pas me faire croire que les libristes purs et durs quittent Firefox pour Edge/Chrome/Safari/Opera parce que Firefox "n'est plus assez libre"…
[^] # Re: Signature
Posté par Kalenx . En réponse à la dépêche Sortie de Firefox 40. Évalué à 1. Dernière modification le 13 août 2015 à 22:26.
Ben oui, sauf qu'il faut se renseigner aussi avant de parler…
Bref…
[^] # Re: Et le Expanded Malware Protection?
Posté par Kalenx . En réponse à la dépêche Sortie de Firefox 40. Évalué à 10.
Ah, ces chers "utilisateurs". Je ne connais pas un seul logiciel (libre ou pas) qui ne serait pas mieux si son éditeur arrêtait de "faire du caca" et écoutait les utilisateurs qui savent bien mieux ce qu'il faut faire que les programmeurs de ce logiciel…
[^] # Re: VP9
Posté par Kalenx . En réponse au journal Cisco annonce Thor. Évalué à 4. Dernière modification le 13 août 2015 à 10:00.
Tout à fait. En fait, en ce moment même, je défaille devant mon écran. Non, plus prosaïquement, je répondais à ça :
Bon et après je n'irai pas plus avant dans la discussion parce que manifestement tu ne veux pas comprendre :
Et qu'est-ce que j'ai dit?
Bien sûr que Linux marche avec la thune de plein d'entreprises—même si les contributeurs indépendants sont encore nombreux, mais ça n'a tout simplement aucun rapport avec ce que j'ai dit. Linux ne serait même pas né si tout le monde avait seulement tenu compte des économies potentielles. Mozilla (sur qui il semble être à la mode de cracher parce qu'ils veulent obtenir un revenu pérenne) a commencé sur un simple idéal, succédant à une entreprise qui s'était lamentablement fait écraser; les gens qui ont lancé Mozilla ne l'ont certainement pas fait en se disant "quel bon moyen de faire de la thune!". Non, en 2000, le bon moyen de faire de la thune, c'était de passer sur IE et d'y rester.
Évidemment que d'autres projets auraient plus ou moins remplacé GNU si ce dernier n'avait pas existé, mais ça revient à dire Nelson Mandela n'a rien fait puisque "d'autres l'auraient remplacé s'il n'avait pas été là". Le fait est que GNU a été d'une importance capitale dans le développement du libre et ce, encore une fois, pas parce que Stallman a décidé de faire le plus de pognon.
Peu importe le domaine d'activité, il est évident qu'un mouvement qui ne génère strictement aucun revenu ne risque pas de prospérer. Bien évidemment que l'argument économique est important pour le libre, mais, encore une fois, dire que l'essence du libre et son existence entière se résument à une histoire de comptables et de rapports financiers est plus que discutable.
[^] # Re: VP9
Posté par Kalenx . En réponse au journal Cisco annonce Thor. Évalué à 8.
Je pourrais parler du côté philosophique, mais d'autres l'ont déjà fait avant moi (et probablement mieux que moi). Je trouve tout de même triste que tu ne puisses admettre que certaines personnes aient des principes mais qu'elles soient aussi capables d'être pragmatiques. On peut vouloir acheter local et bio (c'est un principe), mais tout de même être pragmatique et accepter d'acheter du gingembre dont on ne connait pas forcément la provenance.
C'est la même chose pour la plupart des libristes : demander à un libriste de hurler lorsqu'on lui demande d'utiliser VP9 sous prétexte que sinon "tout ton argumentaire sur l'éthique tomberait à l'eau", c'est juste du n'importe quoi. Faut arrêter de demander à tout le monde de laver plus blanc que blanc, parce qu'en l'état, j'ai surtout l'impression de lire un caméo de Caligula de Camus, qui, à un intendant lui ayant dit que le Trésor était capital, donne l'ordre de :
Donc la prochaine fois que quelqu'un dit qu'il aime le libre pour l'esprit de partage et non pour les économies qu'il lui fait réaliser, serait-il possible d'éviter de sortir des requêtes absurdes et totalement hors sujet (rendu là, tu pourrais aussi demander s'il serait prêt à mourir pour le libre, sinon ce n'est pas "un vrai libriste")?
Pour le reste, choisir simplement la solution la moins chère est aussi fallacieux techniquement. S'il n'y avait pas eu les gens de GNU, de BSD, de Netscape/Mozilla, du noyau Linux, qui, au départ, ne travaillaient clairement pas en vue de gains pécuniaires, eh bien il n'y aurait pour ainsi dire pas de libre, et, par conséquent, pas les économies qui vont maintenant avec…
Je ne dis pas que c'est mal de choisir le libre sur des critères comptables (au contraire), juste qu'il faut arrêter de penser que c'est le seul critère possible pour quiconque étant le moindrement raisonnable. Tu considères qu'il n'y a pas de meilleure éthique en ce domaine, et c'est ton choix, mais ce n'est pas celui de tous.
[^] # Re: Et le Expanded Malware Protection?
Posté par Kalenx . En réponse à la dépêche Sortie de Firefox 40. Évalué à 10. Dernière modification le 13 août 2015 à 04:33.
En fait, si on lit le passage que tu as cité, ça me semble assez clair :
Donc a priori, oui, ça envoie des données à Google.
Cependant, tu as coupé la citation en deux (en fait tu as littéralement coupé une phrase en deux). Voici ce qui est dit entre les deux blocs de texte que tu as cités :
Bref, je comprends les préoccupations que peuvent avoir certaines personnes et je respecte ça, je dois même dire que ce genre de systèmes ne me plait guère personnellement, mais il est clairement faux de dire que "la liste de tous les fichiers qu'on télécharge est envoyée à Google".
[^] # Re: Tu peu même élargir ...
Posté par Kalenx . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 3.
Non il ne faut pas "attendre 3 mois pour sortir un truc plutôt que le sortir quand il est prêt".
Ce que je dis, c'est que si tu ne peux pas envisager de pousser le driver dans le noyau 3 mois avant la sortie de ton bidule, c'est que c'est que ce driver est loin d'être terminé. S'il est loin d'être terminé, alors tu ne peux pas le tester (oh, j'imagine que tu peux rouler quelques tests unitaires ici et là, mais aucun test d'intégration ou quoi que ce soit de plus poussé), donc tu te laisses moins de 3 mois pour tester, déboguer et publier ton driver. Si c'est le cas, alors oui je pense qu'il y a un problème—encore une fois si c'est un truc tout con du genre un driver qui lit un device série virtuel dans un certain format, alors en effet tu n'as pas besoin de 3 mois pour tester ça, mais justement tu n'as pas non plus à passer par le noyau…
Après, je me fiche effectivement que ce soit 3 mois ou 2½ ou 4, j'ai pris 3 mois en particulier parce que c'était ce que tu mentionnais dans ta précédente réponse.
[^] # Re: Tu peu même élargir ...
Posté par Kalenx . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 5.
6 mois, c'est effectivement trop long dans la plupart des cas (même si il y en a certains à qui ça convient, comme par exemple Intel). Ceci étant, je n'ai aucune statistique sur le délai moyen entre un premier pull request dans stagging et une inclusion dans le mainline.
Par contre, si tu es dans le kernel, non, tu n'as pas à attendre 6 mois pour chaque update; une fois le driver inclus, les itérations sont beaucoup plus rapides.
Par ailleurs, je réitère : beaucoup de périphériques n'ont pas à avoir un driver en espace noyau. C'est particulièrement vrai pour la plupart des périphériques d'acquisition de données ou de contrôle. Dès que tu peux passer par l'USB et que tu n'as pas à contourner le contrôleur standard de Linux pour gérer les bugs de ton périphérique, alors ton driver peut tout à fait résider en espace utilisateur (privilégié) et utiliser l'API/ABI USB standard et stable pour communiquer avec le périphérique.
Je donne un exemple, je ne dis pas que c'est le plus pertinent, mais c'est le premier qui me vient en tête vu mon occupation actuelle : Phidgets, qui est une boîte dont le coeur de métier est la commercialisation de senseurs et contrôleurs faciles à interfacer (autant au niveau hardware que software). Leur driver est une simple librairie qui supporte C/C++, C#, Python, Java, VB.NET, etc. et qui est binairement compatible avec pour ainsi dire toutes les distributions (en autant que libusb soit installé, ce qui est un prérequis acceptable je crois).
Et ça tombe très bien pour eux : effectivement, lorsqu'ils sortent un nouveau produit (par exemple un nouveau thermocouple), ils n'ont pas envie d'attendre plusieurs mois pour qu'il soit pris en charge par les systèmes Linux, mais il leur suffit de mettre à jour leur librairie et ça marche automatiquement partout.
Je ne dis pas que tout le monde peut faire ça, mais pour la plupart des boites dont l'écriture de drivers n'est pas le coeur de métier (par exemple des compagnies qui veulent commercialiser un nouveau produit dont le driver n'est qu'une interface, l'innovation étant vraiment dans le produit en soi), il n'y a aucun problème avec le modèle actuel.
Pour les boites plus grosses, pour qui les drivers représentent en soi un atout important, oui, j'espère que ceux-ci sont terminés 3 mois avant la sortie du produit qu'ils accompagnent, et que les développeurs sont passés à l'écriture du driver de la génération suivante.
[^] # Re: Tu peu même élargir ...
Posté par Kalenx . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 10.
Le Driver Backport Workgroup s'est concrétisé dans le projet Backports, qui, comme tu peux le constater, a une mailing list relativement conséquente et toujours bien active et supporte les kernels depuis le 2.6.26.
Non, ils ne supportent pas tous les types de drivers (pour le moment), c'est vrai. Mais c'est déjà un bon début.
Et le driver, tu l'as fini 2 jours avant de devoir livrer le produit? Parce que fondamentalement, c'est ça le problème…
Pour ce qui est de le faire tourner sur les distribs existantes, si tu tiens absolument à rester hors de l'arbre principal du kernel, tu fais comme tous les fabricants de matériel : tu certifies le fonctionnement sur certaines distros commerciales (RedHat, Suse, Ubuntu, etc.) et si l'utilisateur veut l'installer sur son Damn Small Linux, ben c'est son problème (ou plutôt le tien, puisque cet utilisateur là, pour qui tout aurait bien fonctionné si tu avais empaqueté ton driver dans le kernel, n'achèteras probablement plus tes produits).
Par ailleurs, pour ta gouverne, les grosses boîtes (au moins RedHat et Suse) garantissent une ABI stable dans les révisions mineures (regarde par exemple le paquet kabi-whitelists dans RHEL), donc rendu là tu n'as pas à te soucier des updates.
Encore une fois, non ce système n'est pas parfait. Par exemple, une amélioration possible (il me semble que ça s'était discuté sur LWN, je ne retrouve plus le lien) serait d'empaqueter les drivers dans le main line, dès leur inclusion dans stagging, sous réserve qu'il soit démontré qu'ils n'affectent pas le reste du système, mais avec potentiellement un tag spécial pour indiquer que ce sont encore des drivers expérimentaux. Ça réduirait drastiquement le temps requis pour être inclus dans les principales distros (y compris celles déjà sorties, puique toutes les distros backportent les drivers dans leurs révisions mineures…)
Après, effectivement, si tu es une boîte qui compte distribuer planétairement un produit dont le driver a été terminé une semaine avant la sortie commerciale, le modèle de Windows convient mieux.
La question que je me pose, c'est surtout de savoir si je veux acheter ce genre de produits…
[^] # Re: Tu peu même élargir ...
Posté par Kalenx . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 7.
Encore une fois, je ne prétends pas que le modèle de développement des drivers sous Linux soit la meilleure chose que la Terre ait connue après le scotch-tape double face, mais plutôt qu'il faut pondérer les avantages et inconvénients de chaque modèle.
C'est certain que si une entreprise développe des bidules pour Windows depuis 15 ans et qu'elle se met soudain au développement sous Linux, alors ses devs vont probablement râler. Cela veut-il dire que l'approche est fondamentalement mauvaise? Je ne crois pas.
Il y a en fait encore beaucoup d'idées reçues à propos du développement de drivers sous Linux, et, autant je ne suis clairement pas un expert de la certification WHQL et du développement sous Windows, autant je pense que tu ne l'es pas non plus sous Linux. Par exemple :
Régler ce problème est exactement le but visé par le Driver Backport Workgroup de la Linux Foundation.
On revient à la bonne vieille critique du libre : "bouh mais mon concurrent va pouvoir copier sur moi…". Sinon, il est tout à fait possible de travailler de manière confidentielle un bon moment avec les développeurs du noyau, grâce au Linux Foundation NDA Program.
Et encore, je ne parle pas du Linux Driver Project, qui (je cite) :
Je ne parle pas non plus de l'appel explicite des développeurs centraux aux mainteneurs à merger le plus rapidement possible les drivers, tant que ces derniers n'affectent pas le reste du noyau.
Toutes les références sont sur cette page de la Linux Foundation, par ailleurs très facile à trouver soit dit en passant.
Je passe par ailleurs sur tous les aspects techniques favorisés par les changements d'ABI possible (simplicité du code, sécurité, augmentation des performances "gratuite" dans certains cas, etc.)
Bref, bien sûr qu'il y a matière à critique, mais il ne faut pas amplifier cette dernière sous prétexte que les éditeurs tiennent absolument à rester à un mode de développement qui avait cours à la sortie de Windows XP…
[^] # Re: Tu peu même élargir ...
Posté par Kalenx . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 8.
Ah non, mais ça ça ne va pas du tout! Parce que vois-tu, les tests WHQL bloquent clairement à lui seul nombre de développements. Parce que
l'insertion dans mainlinela certification WHQL, ça prend du temps, le produit il doit sortir hier, il doit supporter autant de systèmes que possible (ça inclut donc devoir faire signer le driver par Microsoft, sinon le noyau ne veut même pas le lancer sur les systèmes 64 bits), et il faut que ce soit pas cher à maintenir (ça inclut refaire les tests WHQL à chaque itération du driver, même une révision mineure), etc., etc.En fait, c'est un peu la même chose que l'insertion dans mainline : et si je ne veux pas moi, faire certifier mon driver? C'est exactement la même problématique que : et si je ne veux pas moi, open-sourcer mon driver et l'inclure dans le kernel?
Bah si tu ne veux pas, tu te débrouilles…
Note que je n'ai aucun problème envers la certification WHQL en soi, je pense que c'est déjà un bon système qui a limité grandement le nombre de drivers pourrave, mais je veux juste te faire remarquer à quel point il est facile de descendre un système à grand coup de "les entreprises n'aiment pas ça"…
[^] # Re: Tu peu même élargir ...
Posté par Kalenx . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 10.
Oui, tout comme il est vrai que "une relation sexuelle non protégée ne sera jamais 100% sur, mais c'est tout à fait vrai pour les relations avec préservatif aussi"…
Par ailleurs, oui, les sandbox limitent les dégâts, mais ça n'a rien à voir avec le mode de distribution et je répondais à ta remarque :
Sinon :
À t'entendre, on jurerait que tu soutiens que le modèle de Windows encourage les développements à la va-vite, avec une avalanche de modifications à la dernière minute "parce qu'il faut sortir le produit hier", et qui ne vont surtout pas prendre du temps pour corriger les bugs et limitations du driver parce que sinon c'est trop cher à maintenir…
Un contre-argument serait de me répondre que si les boîtes veulent faire des drivers moisis et pas aboutis, ce n'est pas le problème de Microsoft, et ce n'est pas formellement faux, mais ça ne me ravit pas pour autant.
Cependant, il y a nombre d'initiatives pour faciliter l'inclusion de drivers dans Linux (à commencer par la branche staging), et, bien que je n'ai honnêtement pas de statistiques pour confirmer la chose, je doute qu'un driver bien conçu et relativement simple (comprendre : pas un nouveau driver de carte vidéo) requiert tant de temps pour entrer dans le kernel; une fois qu'il y est, la maintenance "de base" (e.g. suivre les changements d'API et d'ABI internes) est pour ainsi dire gratuite…
En bref, je pense qu'on peut résumer la chose par ces constatations. Le modèle de Microsoft, c'est "faites n'importe quoi tant que ça marche dans une configuration donnée de Windows, et on vous couvrira jusqu'à la mort", alors que celui de Linux, c'est "Linux doesn’t support external modules, if you use an external module, you are own your own."
Je peux voir l'avantage économique que peut avoir le modèle de Microsoft, mais je ne suis quand même pas certain que c'est ainsi que je veux voir développer des bouts de code capables potentiellement d'accéder à pas mal de choses dans mon ordinateur…
[^] # Re: Tu peu même élargir ...
Posté par Kalenx . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 10.
Oui, c'est d'ailleurs parce que ça marche tellement bien que Microsoft essaie de tout nettoyer avant que les utilisateurs de Windows 10 ne bloatent leur système…
Soyons sincères (et ça vaut pour Android et iOS aussi) : de la manière dont ils fonctionnent (avec comme principe de base qu'il faut tout avoir, parce que sinon l'utilisateur ne sera pas content et ira ailleurs), aucun store ne peut prétendre à régler les problèmes de bloatwares, spywares, logiciels dangereux et autres scams.
Je ne dis pas que c'est pire qu'avant, mais je ne vois sincèrement pas d'énorme amélioration…
Pour les drivers, Linux n'est effectivement pas le paradis des indolents qu'est Windows (où tu peux littéralement faire n'importe quoi et t'attendre à ce que les devs de Microsoft se débrouillent pour que tes produits marchent encore, il suffit d'aller faire un tour sur le par ailleurs très instructif blog theoldnewthing pour en voir d'excellents exemples), mais, bien franchement, pour beaucoup de produits, ça n'a rien d'incroyablement complexe. Si tu produis un périphérique pour lequel des standards existent (ex. UVC pour les caméras, Postscript pour les imprimantes—même si dans ce dernier cas je simplifie un peu) alors ça marche direct. Si tu produis un périphérique simple (comme beaucoup de petites boîtes), pour lesquels une liaison série virtuelle ou un simple driver codé avec l'API USB du kernel suffit, alors ça va aussi.
De plus, lorsqu'une compagnie accepte de libérer son driver et de l'inclure dans le kernel, alors les cassages d'ABI (voir d'API interne) ne sont plus un problème puisque tout peut être modifié d'un coup par les devs du kernel : ton driver fonctionne alors peu-importe la version du kernel.
Bref, je ne prétends pas que Linux soit le meilleur des mondes pour le fabricant qui veut juste sortir son produit et faire du pognon avec pendant 15 ans sans toucher à une ligne de code, mais il ne faut pas exagérer dans l'autre sens non plus et faire croire que les devs s'amusent à changer l'ABI à tous les deux jours rien que pour énerver les gens…
[^] # Re: Aigritude, remâchage, tout ça...
Posté par Kalenx . En réponse au journal Comment mon expérience Linux est en train de tourner au fiasco. Évalué à 5. Dernière modification le 08 août 2015 à 06:29.
Je dois admettre que je ne comprends pas :
Si quelqu'un vient vous crier dessus au taf en vous disant que vous êtes un incompétent et une sombre merde et que vous l'envoyez bouler, c'est vous qui êtes en tort? C'est une vraie question, hein, je suis sincèrement curieux.
Pour le reste, non, je ne suis pas d'accord. Je me fiche que le mec soit 10 fois plus intelligent, compétent ou expérimenté que moi, il y a des façons de présenter les choses, et ce, peu importe du côté duquel tu te trouves (chez les devs ou chez les users). Ulrich Drepper est un excellent programmeur et très intelligent, ça ne m'empêche pas de trouver que c'était un con. Même chose pour Theo de Raadt et, plus rarement, pour Linus.
Ça n'empêche pas d'être direct : on peut sans problème critiquer vertement un logiciel ou un framework, mais 1) ça doit être appuyé sur autre chose que la nostalgie du bon vieux temps, sans autre preuve et 2) ça doit être fait en respectant les gens qui y bossent. Sinon, ça a autant d'intérêt pour moi qu'un morceau de lichen sibérien (à savoir assez peu).
Appelez cela prendre les gens de haut si ça vous chante, mais bien franchement, il n'y a aucun élément de domination ou d'égocentrisme dans ma réflexion. Seulement un profond ennui…
Et ceux qui font les deux (non, je ne parle pas de vous)?
Pour le reste, je dois dire que votre dernière phrase aurait tout à fait pu être écrite par Zenitram :
Tant que c'est vous qui décidez qui est con et qui ne l'est pas, c'est certain que ça arrange…
[^] # Re: Potentiellement très sérieux
Posté par Kalenx . En réponse au journal Faille critique sous Firefox: faut-il changer ses mots de passe?. Évalué à 2.
C'est vrai. Sauf que… parfois il y a les bonnes pratiques, et les pratiques pratiques…
Le but de se logger par clé SSH est d'éviter de taper un mot de passe (et donc devoir taper sans cesse le mot de passe SSH n'est pas vraiment intéressant). Avec le recul, j'aurais dû mettre en place un ssh-agent mais bon… c'est facile de dire ça par après. En attendant je suis bon pour une petite leçon, et je n'ai que moi à blâmer là-dessus (bon, un peu Mozilla aussi, quand même) ;-)
[^] # Re: Aigritude, remâchage, tout ça...
Posté par Kalenx . En réponse au journal Comment mon expérience Linux est en train de tourner au fiasco. Évalué à 9.
Si j'en crois votre réponse, le simple fait qu'il ne puisse mettre "un putain de lien avec icône dans la barre des tâches" est suffisant pour titrer "Comment mon expérience Linux est en train de tourner au fiasco". Intéressant…
Je ne commenterai pas plus avant du côté technique, je l'avais déjà fait dans le précédent journal et ça n'avait rien donné, d'autant plus que in fine, le problème n'est pas technique, il est humain.
Certains considèrent que d'enguirlander quelqu'un et de les traiter d'incompétents est la réponse adéquate lorsqu'on n'est pas satisfait, même si c'est seulement "ne pas pouvoir mettre un raccourci avec le bon icone dans la barre des tache, un truc de malade il est vrai."
Je ne crois pas que ce soit la bonne manière de procéder, mais chacun ses goûts.
Oh, et soit dit en passant, je n'ai jamais "taper sur la gueule de ceux qui se plaignent" ou "traité l'auteur de sombre con". J'ai simplement dit que 1) lui pourrait arrêter de traiter les devs du monde entier de décérébrés sous prétexte que les devs de KDE ont viré Konqueror ou que KCalc n'accepte plus le "." du pavé numérique et que 2) il y a une différence entre critique et critique constructive et qu'il n'est pas étonnant que les gens ne veuillent pas lui "expliquer le problème technique" quand il vient de démontrer par ailleurs qu'il se fiche totalement des raisons techniques, il veut juste gueuler le plus fort possible.