Kalenx a écrit 171 commentaires

En effet, ce n'est pas nouveau, mais on ne se dirige pas vers la solution. Comme expliqué très clairement sur la page de Libreboot :

Before version 6.0 (that is, on systems from 2008/2009 and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. […] ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include "ME Ingition" firmware that performs some hardware initialization and power management. If the ME's boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.

Cela fait en sorte qu'il est virtuellement impossible d'avoir un système entièrement libre sur tout PC datant d'après 2009. Pour le moment, le T400 offert n'est pas encore "ridicule" en termes de capacité (bien que nettement en deça des autres machines du marché), mais va inévitablement le devenir, puisqu'il est impossible de le remplacer—à tout le moins sur x86 :

Basically, all Intel hardware from year 2010 and beyond will never be supported by libreboot. The libreboot project is actively ignoring all modern Intel hardware at this point, and focusing on alternative platforms. […] The libreboot project recommends avoiding all modern AMD hardware. If you have an AMD based system affected by the problems described below, then you should get rid of it as soon as possible.

Bref, on est loin d'être tournés vers l'avenir avec ça, même si l'effort est louable.

Par ailleurs, au-delà de ces constatations, le problème du microcode reste entier : il est en l'état impossible de savoir si MOV EAX, EBX transfère uniquement le contenu de EBX dans EAX, tel que la documentation l'indique, ou si cette instruction a aussi comme effet de bord de sauvegarder le contenu de EBX quelque part… C'est effectivement extrêmement far fetched, comme diraient les Anglais, mais pas formellement impossible : même dans ces portables "100% libre", une partie du logiciel est un blob binaire chiffré (à même le CPU, d'accord, mais blob binaire illisible néanmoins)…

En effet, et rétrospectivement j'aurais probablement dû en parler dans mon journal, c'est très pertinent.

En particulier, peu de gens savent qu'il existe, dans leur PC, certaines sections de la RAM auxquelles même le processeur (!!) n'a pas accès. On ne parle même pas de l'OS…

À grande échelle et de manière généralisée je n’y crois pas. Ça aurait fini par se voir.

Je ne pense pas non plus que chaque processeur envoie périodiquement un rapport concernant son utilisation, ce serait effectivement beaucoup trop visible. Mais je crois qu'on ne peut pas exclure qu'il puisse le faire sous certaines conditions. Comme je le disais, ça peut par exemple être un simple pattern de bits particulier (et suffisamment long pour ne pas arriver par hasard) : lorsque ce patron est rencontré, alors le processus d'envoi se déclenche. Il suffit pour cela que l'utilisateur regarde une page web contenant une image dont les bits les moins significatifs sont soigneusement ajustés, ou d'envoyer un paquet invalide, mais d'apparence innocente à la machine…

Je pense que ce genre de code malicieux doit pouvoir être détecté à l’analyseur logique et que certains ne se privent pas d’y jeter un œil.

Que certaines personnes y jettent un oeil, possible, mais je doute très fortement de la capacité de quiconque de détecter ce genre de choses. Par expérience, déboguer une communication USB3 on ne peut plus standard est déjà l'enfer, alors je n'imagine même pas ce que doit être analyser un processeur complet, avec tous les états internes possibles… Non, bien franchement, à part trouver les cas les plus patents d'erreur, une analyse logique ou liée à un programme ne peut pas révéler grand chose.

Je suis peut-être totalement dans l'erreur, mais n'est-il pas logique que le pourcentage de joueurs sous Linux soit directement corrélé au pourcentage d'utilisateurs (en général) de Linux? Il y a effectivement une vague de linuxiens qui ont adopté Steam, mais de manière assez logique, cette vague ne peut pas être plus haute que le nombre total de linuxiens…

Comme GNU à sa naissance, tu veux dire ;-)

On lance un troll?

The MIT license opens up a lot of possibilities, which are simply not plausible with, say, the GPL. We wanted to encourage the use, modification, and packaging of Redox in absolutely all realms. Open source should be open, for everyone. We do not desire limiting the usage of the software. Therefore, MIT was the license of choice.

(source)

Ça débat déjà ferme sur LWN (j'ai l'impression qu'on y parle plus de ça que du projet en soi d'ailleurs)…

Sinon, je ne connais pas la taille exacte de l'équipe de développement, mais mon petit doigt me dit qu'elle n'est probablement pas suffisante pour les "side-projects" voulus :
- Un système de fichier ZFS (mais pas l'implémentation de Sun, non, la leur)
- Un serveur d'affichage
- Un gestionnaire de paquet
- Un shell
- Un éditeur
- Un toolkit graphique

C'est beau la motivation mais bon… un peu de réalisme ne serait pas de trop je crois.

Mais qu'est-ce qu'on s'en fout du "noyau dur", qui ne sera jamais satisfait de toutes façons

Bah non justement, on ne s'en fout pas : c'est précisément cette insatisfaction permanente qui fait avancer certains aspects du libre. C'est parce que certaines personnes ne font pas que se contenter d'un logiciel propriétaire qu'on peut intégrer sans trop de difficulté (encore que…) dans un écosystème libre qu'on a de nouveau logiciels libres pour répondre aux nouveaux besoins. Si les brevets logiciels n'ont pas bonne presse, c'est aussi parce que ce "noyau dur" les rejette sans compromis au lieu de les voir "pragmatiquement" comme une sorte de mal nécessaire. C'est précisément parce que ce groupe considère que les formats et protocoles devraient être ouverts qu'on a vu la fin du embrace, extend, extinguish qui a marqué les années 80-90.

Bref, bien sûr qu'il faut des pragmatiques. Une boîte entièrement idéologique ne durerait pas bien longtemps. Mais oui, il faut aussi des idéalistes, des gens qui refusent les arrangements qui compromettent leurs principes.

Tu as un exemple de cela ? Si tu veux trier, tu dois forcement pouvoir définir un ordre, au moins arbitraire. Tu peux te contenter de <= pour établir une relation d'ordre. Il y a un mapping bijectif entre key et cmp, du moins je pense.

Je te l'accorde, je suis allé un peu vite pour résumer ceci. L'idée est qu'il possible de ne pas pouvoir comparer certains objets, tout en supportant de manière générale la comparaison avec ce type, ce qui rend l'utilisation de cmp (et de son pendant, l'attribut _ _ cmp _ _) beaucoup moins logique que les opérateurs de comparaison tels que lt, gt, eq, etc. Ces derniers faisant double emploi avec cmp, il a été décidé de retirer la "vieille" manière de procéder.

Pour ce qui est de la mémoire, formellement je pense que tu as raison, mais j'émets l'hypothèse qu'en pratique ce n'est pas très problématique, pour deux raisons. Premièrement, parce que la plupart des clés de comparaison sont des types simples et consommant donc peu de mémoire, si bien qu'à moins d'avoir d'immenses listes, l'overhead mémoire risque d'être faible. Par ailleurs, il est toujours possible de revenir au comportement de cmp, à savoir d'appeler la fonction passée en argument key à chaque fois sans conserver le résultat. En bref, en utilisant key, on peut se comporter similairement à cmp, mais l'inverse n'est pas vrai.

Je t'accorde cependant que je m'obstine sur des broutilles. In fine, je crois que la raison principale qui a motivé ce retrait est le principe suivi par Python selon lequel il ne doit y avoir qu'une et une seule façon de faire une tâche. En l'occurrence, cmp et key remplissaient grosso modo le même office, donc l'utilisation de l'un d'entre eux a été retiré.

Très intéressant comme journal, mais, pointilleux comme je le suis, je ne peux m'empêcher de faire remarquer que :

Cette example de code est équivalent au code python suivant, qui ne marche plus qu'en python 2, l'attribut cmp de sorted ayant disparu en python 3, ce que je regrette.

N'est pas tout à fait exact. Effectivement, l'argument cmp a été retiré en Python 3, mais il y a plusieurs raisons derrière ce choix :
1. Fonctionnellement, tout ce qui pouvait être réalisé avec cmp le peut encore avec key. Il y a d'ailleurs une fonction dans functools qui remplit exactement cet office automatiquement : cmp_to_key
2. L'utilisation d'une telle fonction de comparaison qui doit choisir entre "plus grand", "plus petit" ou "égal" est loin d'être aisé dans le cas général où on peut être "aucun des trois".
3. Ce modèle de comparaison faisait double emploi avec les fonctions lt, gt, eq, etc.
4. Finalement, comme plusieurs l'ont fait remarquer, utiliser key est généralement plus efficace que cmp, puisque key est appelé une seule fois par élément (O(n) donc), puis la comparaison (O(n log n) pour ordonner) est effectuée en C si les clés sont des type de base. À l'opposé, utiliser cmp fait en sorte que ces O(n log n) comparaisons impliqueront toutes un appel d'une fonction Python.

Bref, pour toutes ces raisons, je ne pense pas que ce soit dommage que cet argument ait été retiré, au contraire, cela apporte une meilleure cohérence au langage.

Il est possible que je ne sois pas bien renseigné en effet. Cependant, mon opinion s'appuie sur des cas de ce genre (on peut aussi voir ici pour un point de vue un peu plus neutre et professionnel). Jusqu'à preuve du contraire, il semble donc néanmoins y avoir un lien pour le moins ténu entre les choix de l'académie et l'acceptation générale.

Bien franchement, la question n'est pas tant de se demander "qui parle un meilleur français" que de distinguer l'approche de création des néologismes en France et au Québec. Comme le spécifie très bien la "Québécoise rigolote", la langue écrite québécoise contient beaucoup moins d'anglicismes qu'en France.

La manière dont l'OQLF (Office québécois de la langue française) accueille et propose des nouveaux mots est bien plus dynamique que le status quo perpétuel de l'académie, qui prend 20 plombes à décider de la "bonne" façon d'écrire (ou de féminiser) un mot, si bien qu'au final tout le monde est passé à autre chose et utilise le mot anglais…

En attendant, Windows 10 est à 10% de part de marché desktop après moins d'un an de vie pendant que Linux (toutes versions confondues) se traine à 1-2%.
C'est beau les fantasmes… Qui ne tiennent pas face aux stats.

Sauf qu'il n'a pas dit qu'il venait de trouver le moyen pour faire passer tout le monde à Linux, ça c'est ce que tu en as retenu. Il a dit "C'est une belle opportunité pour informer les gens et aider ceux qui veulent essayer GNU/Linux."

(Note : je crois que ce "Linux ça va le faire sur le desktop", je l'ai depuis que je m'interesse à l'informatique. Mais il y a encore des gens pour y croire et se dire que ça va le faire, c'est beau, continuez d'y croire sans rien changer, ça va changer comme par magie)

Ceux qui croient la chose impossible sont priés de cesser de déranger ceux qui sont en train de le faire.

Que tu prétendes sérieusement qu'il n'y a eu aucun changement sur Linux côté desktop depuis que tu t'intéresses à l'informatique, c'est… révélateur, disons.

Certes, sauf que le blindage en question sert essentiellement à protéger les circuits qu'il contient, et non à protéger l'environnement extérieur, de la même manière que les blindages et ferrites que l'on retrouve sur les câbles : https://en.wikipedia.org/wiki/Electromagnetic_shielding

Après, je ne dis pas qu'il ne faut jamais se soucier des champs EM émis par un appareil, juste que de soutenir que "c'est préoccupant pour la santé des enfants présents", eux qui passent peut-être individuellement une ou deux heures par semaine au maximum devant ce bidule, c'est peut-être un tantinet exagéré.

Personnellement, je considère bien plus dangereux le fait qu'il y ait des fils partout et que rien ne soit protégé des petites mains qui s'y aventureront inévitablement…

Oui, c'est pour ça aussi qu'historiquement le 3/4 des iMac étaient en plastique, que jusqu'à tout récemment tous les PC portables avaient des coques en plastique, que les mobiles sont en plastique alors que, proportionnelement à la distance jusqu'à l'humain, ils émettent bien plus de CEM (même en ne tenant compte que de l'aspect ordinateur et en excluant les ondes cellulaires), etc…

Comme toujours, ce qui me braque n'est pas le message, mais bien l'enrobage, et le manque de cohérence extrême qu'on retrouve dans ce genre de brulots.

Le journal accuse les gens d'afficher du mépris, mais en même temps traite ses interlocuteurs comme des sous-merdes qui méritent à peine qu'on leur adresse la parole, il reproche aux autres d'être intolérants tout en refusant la moindre microscopique concession dans ses positions, s'indigne de la diffamation dont il est l'objet, mais qualifie dans le même paragraphe l'entièreté des membres de LinuxFr de faire "partie des classes supérieures, et leurs habitus est celui des classes supérieures : entre-soi, mépris de l’interlocuteur confinant à l’insulte et à la haine, sentiment de supériorité, conservatisme et respect de l’ordre, drappage derrière la science, les sachants, etc.",

Je ne comprends pas vraiment l'intention des gens qui postent ce genre de messages. Qu'est-ce qu'ils se disent? Que la meilleure façon de convaincre des gens est de les insulter? Que changer les choses passe par gueuler sur le 9/10 de la planète en les accusant de maux aussi divers qu'imaginaires?

Je loue votre calme (sans ironie) dans ce genre de situations. Personnellement, autant je suis ouvert à discuter de n'importe quoi (vraiment), et de façon sérieuse, autant quelqu'un qui commence la discussion en me traitant d'imbécile d'entrée de jeu, sans même avoir pris le temps de m'écouter, ne mérite pas grand chose d'autre que du mépris de ma part.

Non, il n'insinue pas que vous voyez des soraliens partout. Il constate que vous voyez des soraliens partout.

je ne l'ai pas fait à la lecture de la fin du billet.

Dommage, il y a quand même beaucoup à dire (en bien comme en mal) sur le modèle de fonctionnement de Wikipédia. Mais bon, le ton et la fin du journal sont juste tellement hors sujet que je me demande si tout cela n'est qu'un prétexte de l'auteur pour râler sur tout et n'importe quoi. En plus on n'est même pas vendredi.

En même temps, si je dis ça, ça doit être parce que je suis un pur exemple de soumission aux intérêts du pouvoir tenu par les classes supérieures.

Je sais qui est ridicule, et ce n'est pas moi.

Moi aussi, je sais! C'est Mozilla! D'ailleurs, ce n'est pas pour rien que leur mascotte est un animal incontrôlable et à abattre!

(en fait je vais vous donner mon truc : c'est facile, c'est toujours la faute de Mozilla)

Oui, c'est une excellente question. Moi aussi j'aimerais savoir quel pourcentage des extensions le font, ça fait partie des choses que j'aurais aimé que Mozilla communique, justement. Pour l'instant, tout ce qu'on a, c'est :

We will also continue supporting SDK add-ons as long as they don’t use require(‘chrome’) or some of the low-level APIs that provide access to XUL elements.

Puisqu'ils prennent le temps de le mentionner, j'imagine que ça ne concerne pas 0.001% des extensions, d'où le vague terme "beaucoup" de mon précédent message. Ceci étant dit, combien exactement? Je n'en ai aucune idée, comme tout le monde ici.

Je note cependant que les devs de Mozilla eux-mêmes disaient, en 2012, que :

The ability of developers using the SDK to get chrome authority and access xpcom services is a key feature. The SDK was designed from the start with the assumption that some developers will always need access to the underlying Mozilla platform.

Donc ça ne me parait pas si rarissime que ça comme utilisation…

Soyons clair (parce que j'ai l'impression qu'il y a un petit problème de perception ici) :

1. Je n'approuve ni ne cautionne ce genre de réactions sur le site de WebExtension
2. En aucun cas je n'ai dit ni même insinué que vous "parliez, votez, insultez ou criez sans savoir quoi que ce soit et sans réfléchir. Soyez d'ailleurs assuré que ce n'est absolument pas le cas.

Ceci étant dit, autant je réprouve les posts débiles que vous avez cités, autant je considère qu'il n'y a pas lieu pour autant de refuser toute critique. J'ai écrit mon point de vue, accompagné d'une argumentation (non, je n'ai pas seulement écrit "Stop fucking shit up"), j'ai passé du temps à répondre aux contre-argumentaires dans les commentaires. Après, chacun est libre de considérer si ma position est la bonne ou non. J'aimerais juste qu'on évite d'associer systématiquement ceux qui sont contre quelque chose à ceux qui sont juste des bouffons. On peut très bien être contre et avoir une position réfléchie, ce sont deux choses distinctes.

Ce que j'aime dans votre commentaire, c'est qu'il est tout en nuance, absolument pas stéréotypé et n'appelle pas à la haine envers qui que ce soit. Dommage que tous ne soient pas aussi raisonnables et posés que vous…

L'uniformisation de l'API d'extension ne peut au contraire qu'apporter de nouvelles choses. Car même si Firefox est le mieux doté en terme d'add-on, il n'est pas exclu que des extensions Chrome soit portés vers Firefox si les API sont très proche.

Oui, à terme cela peut aider, tout comme n'importe quel travail de nettoyage d'un logiciel. Seulement, sur le court terme, les résultats sont généralement négatifs et il faut donc les pondérer avec les gains potentiels à long terme.

Pour ma part, j'ai développé des extensions Firefox et Thunderbird avant et après Jetpack SDK et je peux te dire que c'est le jour et la nuit. L'API Jetpack ce n'est que du bonheur par rapport justement à XUL/XPCOM (qui est tjrs utilisable actuellement mais plus obligatoire).

Pour m'y être essayé du temps de Firefox 2, développer des extensions en XUL n'avait rien de simple, donc j'imagine que ça ne s'est pas amélioré aujourd'hui. Le SDK a été une très bonne idée qui a permis entre autre de grandement faciliter la compatibilité ascendante des extensions. Mais, comme tu le soulignes, l'ancien modèle, plus puissant, est toujours utilisable. Par rapport aux extensions développées avec Jetpack, il faut également souligner que beaucoup d'extensions utilisent le fatidique "require('chrome')" qui permet d'accéder au modèle précédent, ne serait-ce que pour effectuer une seule action précise, ce qui ne sera pas possible avec WebExtension.

Une solution serait d'accepter de faire quelque changement dans l'ergonomie et d'utiliser une sidebar couplé à mécanisme de masquage des onglets (ils sont en train de travailler là dessus). Mais ce n'est qu'une hypothèse.

Oui, j'ai lu le billet de blog moi aussi. Mais ça, c'est une solution potentielle pour une extension…

Mais parce que tu cris au loup à propos d'un sujet qui est à l'étude, en attente de retour https://webextensions.uservoice.com/ et qui va apporter beaucoup (E10S, sécurité, …).

Je t'invite à relire mon journal où j'ai très clairement spécifié les côtés bénéfiques d'un tel changement, en prenant justement Electrolysis et la sécurité des extensions comme exemples… Par ailleurs, oui, le sujet est "à l'étude" en ce qui concerne les détails d'implémentation, mais le billet de Mozilla indique clairement que la décision a été prise et que ça ne changera pas.

En plus, toi qui dit défendre la MoFo régulièrement, tu devrais savoir qu'ils ont mainte fois prouvé être les seuls parmi les principaux fabriquant de navigateur à défendre nos libertés, non ?

Tout à fait. Je n'ai d'ailleurs absolument pas dit que cela restreindrait la liberté des utilisateurs.

tu devrais savoir qu'il n'est pas dans leur style de faire les choses à la hussarde

Là-dessus, j'en suis moins certain, pour être franc…

Le danger que j'y vois c'est le fait qu'on puisse colporter ces infos alors qu'elles sont fausses. Car clairement "La fin du "permissive add-on model" chez Mozilla, ou comment flinguer une base d'extensions", c'est faux.

Je suis désolé que tu vois les trucs ainsi. Le titre était volontairement provocateur, je l'admets, (c'était vendredi après tout), mais j'aimerais que l'on me dise en quoi le fond est faux. Pour la partie "la fin du permissive add-on model", c'est écrit tel quel dans le billet de la MoFo, en grands caractères :

Deprecation of XUL, XPCOM, and the permissive add-on model

(oui, on peut arguer que "fin" n'est pas tout à fait la traduction de "deprecation" mais bon, c'est vraiment jouer sur les mots)

Ensuite, "comment flinguer une base d'extensions" bah… j'espère que ce sera faux, mais :
1. Le fait est que tout changement d'API est dommageable pour la diversité des extensions de n'importe quel logiciel. Attention, je ne dis pas qu'ils ne doivent pas le faire, ni qu'ils n'ont pas de bonnes raisons pour, ni que c'est exclusif à Mozilla : je dis juste que c'est déjà limitatif, d'autant plus qu'on ne parle pas d'un changement dans 2-3 fonctions de l'API, mais bien d'une réécriture complète dans un langage différent.
2. Je me suis basé sur les propos de développeurs d'extension (DownThemAll, mais aussi d'autres sur la page de commentaires HackerNews portant sur le sujet). Par ailleurs, comme je l'ai répété, redit et réitéré, Mozilla est face à un dilemme, et même le billet de McCloskey sur le sujet ne résout rien : soit ils introduisent dans WebExtension les API permettant d'accéder aux mêmes ressources que via XUL/XPCOM aujourd'hui, soit ils limitent l'API aux fonctions de haut niveau, sans permettre de jouer dans les tripes de Firefox. Dans le premier cas, mon titre est en effet faux, sauf que par définition la nouvelle API ne règle alors aucun des problèmes soulevés par Mozilla pour justifier ce même changement d'API. Dans le second cas, bah oui, ça signifie que certaines extensions (pas toutes évidemment) ne pourront plus fonctionner avec WebExtension…

Bien sûr tout cela n'est pas binaire : Mozilla peut décider de réintroduire certaines sous-parties de son ancienne API dans WebExtension, en jugeant que la complexité supplémentaire apportée au développement du navigateur vaut la chandelle. C'est juste que présentement, bah on ne sait pas, et dans ces situations, il y a deux positions : soit dire "attendez de voir et on en reparlera", au risque de se retrouver avec quelque chose de complètement inadapté au final, soit expliciter les craintes des développeurs, même si celles-ci ne sont pas toutes avérées (par définition, puisque le produit n'est pas encore sorti…), au risque de se faire qualifier son journal de FUD…

Je ne suis pas trop sûr de ce qu'est la meilleure position, pour être franc.

T'es juste entrain d'expliquer que la simple idée de faire un changement dans l'API mérite d'être blâmé ?

Non (j'essaie d'être concis ce coup là).

Tu es certains que l'API actuel permet de tout faire ?

Elle permet d'accéder à tout ce que l'interface "standard" peut accéder.

par exemple on ne peux pas vraiment changer le moteur de rendu web

Hum… comment dire…

passer firefox en Qt,

Non, mais on peut facilement faire un thème qui change les boîtes de dialogue (en particulier celle de sélection/enregistrement de fichiers) pour passer à celles de Qt et qui intègre automatiquement le thème de bureau actuellement utilisé avec KDE.

Bien sûr qu'on ne peut pas tout faire, mais je ne prendrai pas plus de temps à répondre à ton message puisque je sais que tu as très bien compris ce que je voulais dire (et sinon, je t'invite à relire mes pavés, même si, je l'admets, leur longueur n'est pas très invitante à l'oeil).

Bah en fait j'aurais pu répondre :

Ce billet est très flou et ne répond pas à plusieurs questions techniques pertinentes.

Mais j'imagine que d'aucuns auraient alors trouvé mon argumentaire un peu trop minimaliste :)