Renault a écrit 7161 commentaires

C’est comme pour un fichier de configuration, utiliser XML n’apporte rien (à part de la verbosité inutile) la plupart du temps.

Bah justement, c'est super pertinent pour les fichiers de confs un peu complexes où tu souhaites t'assurer que tous les champs sont bien saisis et renseignés comme prévu.

C'est assez puissant pour ce genre de cas d'usages.

Pareil en Belgique, on dirait qu'il n'y a que la France qui essaye de ralentir les virements IBAN

Ça dépend de la banque en France. Avec Boursorama (sur Internet) c'est très rapide par exemple. Je ne trouve pas cela très différent que Belfius sur ce point.

C'est peut être car leur système de connexion au site de la banque ne sont pas super secure (clavier virtuel…)

Mouais, je pense que c'est bien suffisant et à le mérite de ne pas être trop chiant (non, honnêtement, le lecteur de carte de Belfius c'est juste insupportable de l'utiliser systématiquement).

Durant un moment ma banque demandait une confirmation par SMS pour un nouveau destinataire étranger mais c'est plus le cas.

Boursorama demande de valider via un code envoyé par SMS. Plus simple et rapide je trouve que le lecteur de carte et cela me semble suffisamment sécurisé.

Le gros problème reste l'authentification assez misérable de beaucoup de banques (genre code à 6 chiffre max…)

Avec un nombre limité d'essais (en général 3), cela me paraît plus sécurisé qu'un mot de passe très long avec tentatives illimitées. ;)

Et surtout cela permet à la banque et à l'utilisateur de voir que quelque chose anormal se passe si les 3 essais ont été épuisés.

C'est chiant mais j'aime bien la banque pop pour ça, avec un boitier dédié qui peut nécéssiter l'introduction de la CB. Il faut donc pouvoir se connecter au compte, avoir la carte et le boitier sur soit plus le code de la carte. Ça commence à être pas mal. Certains cas peuvent être convertis en sms mais pas tous, il y a plusieurs niveaux.

Bah moi je n'aime pas du tout.
Je me suis installé en Belgique il y a peu et globalement elles semblent utiliser ces procédures ici. C'est très contraignant pour un gain en sécurité que je n'estime pas énorme (c'est mieux, mais je pense que la situation d'avant était acceptable). Je préfère utiliser l'application mobile qui ne requiert qu'un mot de passe que de passer par le site Web qui me demande ces démarches. Surtout qu'en plus je galère à allumer le dit boîtier (et le manuel d'utilisation n'est pas très explicite).

Les prix de l'itinérance que tu cites sont ceux de gros, entre opérateurs. Pour le consommateur ce sera gratuit dès juin 2017.

"dans un avion, les calculateurs sont redondants, voire ils sont triplés ou quintuplés")

En l’occurrence dans un avion la redondance doit se faire avec des équipes / entreprises différentes et bien sûre la question des risques liés aux technologies employés de chaque côté est analysé pour pas que ce soit fait pour rien. ;-)

Cela ne résout pas tous les soucis, mais un bon paquet quand même.

J'ai l'impression qu'on ne se comprend pas très bien. ;) J'ai jamais dit que docker n'avait aucun intérêt, il y a plusieurs intervenant du thread qui s'en servent et qui assurent que c'est utile pour eux (dont toi), très bien je n'ai rien contre (et je comprends bien l'exemple du vieux compilo pas de soucis) !

Je te rappelle que c'est toi qui a commencé l'enfilade en me demandant pourquoi j'utilise ça et que tu essayes de me dire que c'est une mauvaise solution.

C'est quand ça arrive sur mon PC perso ou sur mes serveurs que ça me pose un problème, parce que j'estime que dans ce cas la sécurité est moins bonne avec ce type de solution qu'avec un dépôt centralisé classique.

Précise-le que tu parles de ton cas depuis le début, car honnêtement vu comment le fil a débuté, je ne trouve pas cela évident que tu ne souhaites pas ces solutions chez toi.

On en reparlera quand ton frigo avec ses 10000 voisins sera en train de faire un ddos sur le site de ta banque. Pour mémoire : https://fr.wikipedia.org/wiki/Mirai_(logiciel_malveillant)

Pourtant la plupart des machines de ce monde ne sont pas maintenus par des professionnels, voire pas du tout en fait, loin de là et vont aussi sur Internet. Devons-nous couper l'accès à Internet à tous ces négligeant sur ce prétexte ?

Ce n'est vraiment pas spécifique au monde des objets connectés, le problème existe depuis longtemps. Et gage aux responsables de ces gros systèmes de trouver une parade pour se protéger. Car avant que tous les ordinateurs reliés au Net soient sécurisés pour éviter le botnet, tu peux rêver longtemps. Cela ne signifie pas pour autant que la sécurité des objets connectés ne doit pas exister.

Les applications lourdes sur poste de travail c'est justement ce que je développe. Et la plupart se connectent à un serveur SQL à l'extérieur. D'autres se connectent en SSH pour déposer des documents via SFTP. D'autres encore récupèrent des documents via http.

Je peux te dire que j'en développé aussi qui n'ont pas besoin de réseaux, et des tas de programmes qui sont soient dans des labos (tu sais, le programme pour manipuler l'instrument de mesure super cher mais dont seul l'ordi qui y est branché y a accès, pas de réseau) ou même dans les entreprises (bancs d'essais par exemple).

Celles qui sont non visibles de l'extérieur ne risquent pas de compromission depuis l'extérieur, mais elles en risquent quand même depuis l'intérieur.

Pas toutes les machines ne sont reliés au réseau interne de la structure. Ou ont un réseau dédié qui ne risque rien. Après si tu as peur de l'attaque par accès physique, on n'y peux plus grand chose.

Les 3 premiers n'ont pas (pas encore plutôt) de prise réseau, la sécurité n'a pas d'importance donc.

Oui, mais il faut programmer ces machins avec des technos hyper anciennes. D'où l'intérêt d'avoir la possibilité d'un environnement de travail différent que celui que propose ta distribution.

C'est pas le langage qui implique la sécurisation. Leur COBOL tourne probablement sur un noyau écrit en C qui n'est pas non plus le langage considéré comme le plus sécurisé, et alors ? Une des vraies solutions pour la sécurité, c'est d'être à jour. C'est sûr, il y a les 0 day, c'est pas une solution absolue, mais pas être à jour c'est courir à la catastrophe.

Utiliser un langage que peu de monde connaissent, sur des applications ayant souvent un lourd héritage technique et qui en plus souffre des limitations de son époque, c'est augmenter le risque qu'un problème soit présent dans le système.

Et non la sécurité ne repose pas que sur le fait d'être à jour, je dirais même qu'une bonne sécurité doit prendre en compte l'exploitation d'une faille quelconque pour en limiter ses conséquences. C'est d'ailleurs ce qui se fait en embarqué souvent pour pallier le manque de possibilités pour mettre à jour le système. Genre signature des firmware, cryptographie dans les communications, cloisonnement des applications, réduction des applications au strict minimum ou encore firmware en lecture seule seulement.

Le problème c'est qu'elles sont sur le même réseau. Il va bien falloir trouver une solution sinon l'avenir est bien sombre.

Je trouve que tu mélanges beaucoup de choses en sécurité.
La sécurité absolue n'existe pas, d'abord, il me semble illusoire de vouloir l'atteindre systématiquement.

Ensuite, ce n'est pas parce qu'ils sont sur le même réseau que tout doit être sécurisé de la même façon. J'espère bien que l'interface Web de ma banque est bien plus sécurisée que les accès à Linuxfr. Pourtant ils sont sur le même réseau. Et si Linuxfr se fait niquer, honnêtement je m'en fiche (je serais déçu mais ça serait supportable), ma banque pas vraiment.

Donc les objets connectés n'ont pas à avoir la même sécurité que l'application de ta banque, que les accès depuis l'extérieur aux données sensibles d'une grande structure via un VPN, etc. Cela ne signifie pas qu'il ne faut pas traiter la question, mais tu ne peux pas en exiger la même chose. Cela n'a pas d'intérêt.

Pour moi le cas général à l'heure actuelle c'est les applications dont l'interface est accessible via le réseau (web en général). C'est ça que les utilisateurs utilisent le plus.

Ça me paraît un poil exagéré.
Les applications lourdes sur chaque poste de travail, les applications d'entreprises non visibles de l'extérieur sans oublier les systèmes embarqués existent et je pense que l'ensemble surpasse ce que tu décris en quantité.

Effectivement certains utilisateurs (qui sont des devs embarqués) doivent utiliser des vieux compilos pour de bonnes raisons, mais tu vas être d'accord avec moi que c'est une petite proportion des utilisateurs de l'informatique ?

Il n'y a pas que les développeurs embarqués hein… Tout développeur peut être confronté à une situation où un Docker est bien utile pour reproduire localement un environnement de développement ou de tests. Cela n'a peut être pas été ton cas, mais je t'assure que cela arrive très souvent. Je dirais même que c'est une bonne pratique pour reproduire au mieux l'application sur l'environnement cible (comme un serveur) sans pour autant avoir le même système.

D'autres aussi utilisent des ordinateurs non reliés au net. Mais c'est devenu une petite proportion des utilisateurs également et cette petite proportion devient de plus en plus petite non ?

Des ordinateurs en entreprises qui ont des fonctions très minimalistes et sans accès au net, il y en a une armée dans la nature.

Je ne sais pas où tu bosses, mais cette situation est très fréquente. Tu as déjà été dans un labo de recherches aussi ? Tu en pleurerais vu ce que tu dis ici.

Cette grande proportions d'utilisateurs utilisent facebook, google, youtube, le site de leur banque, le site des impôts, des forums divers et variés etc…

Ils utilisent aussi une machine à café, un lave linge ou lave vaisselle, une télé ou un téléphone… Qui ont été programmés par quelqu'un.
Bref, oui pas mal de gens utilisent ce que tu dis, mais ce n'est que la partie émergée des applications existantes et utilisées au quotidien aujourd'hui.

Le cas général ça me semble donc être ça. Et pour ce cas général je pense que la solution d'un unique dépôt centralisé est la meilleure.

Mais même pour ton cas général ceux qui le développent ont intérêt à utiliser Docker. Il est même probable qu'ils le fassent sans que tu ne le saches.

Si le mainteneur du site de ta banque te dit que la version d'aujourd'hui est trouée mais t'inquiète pas, ils sont en train de développer la correction qui arrivera semaine 53 ça te pose pas de soucis ?

Tu sais que les banques et assurances, ces grosses structure, ont beaucoup de code écrit en COBOL ? Tu sais, ce langage hyper moderne et probablement hyper sécurisé.
Je doute que la sécurité des applications qu'ils manipulent reposent uniquement sur la mise à jour du système. Je suis convaincu qu'ils ont beaucoup de choses dans leur infrastructure pour que si faille il y a l'impact soit la plus faible possible.

Pour beaucoup de services la coupure peut coûter plus cher que de laisser tourner malgré les failles (cela dépend évidemment de ce que fait l'application et la machine hein).

On entend beaucoup parler en ce moment de la sécurité des objets connectés et ça a pas l'air folichon. Certes c'est pas la faute des solutions comme docker mais cette façon de se dire "l'image faite par le dev embarque toute les dépendances sinon c'est pas assez pratique / on a pas le temps" ça va pas dans le bon sens selon moi.

Propose mieux.
La question de la sécurité des applications embarquées est fondamentale, mais il faut comprendre que ses contraintes font que les raisonnements provenant de développement d'applications dans une infra haute disponibilité ne tiennent pas.

On parle de produits qui ont les caractéristiques suivantes :

• Des performances souvent faibles, ce qui t'empêche de faire pas mal de choses (notamment d'utiliser des frameworks ou langages de haut niveau) ;
• Des accès à l'énergie ou à Internet intermittent, voire inexistant pour le second cas ;
• Souvent des machines difficiles à déboguer, tester ou n'ayant pas un opérateur humain disponible pour le réparer (donc pour les mises à jour il faut des garanties que cela se fasse de manière autonome dans tous les cas) ;
• Le produit se paye en une fois, tu fais la maintenance combien de temps du produit ? Comment tu gères le fait que tes logiciels peuvent rendre inopérant le matériel à cause du surpoids qu'il prend avec le temps ?

Car bon, pour les applications Web ou d'entreprise, comme le développement est continue sur des années, les rentrées d'argent sont aussi continues. Tu peux mettre à jour l'infra aussi pour tenir compte du fait qu'avec le temps un logiciel (et ses dépendances) prennent du poids.

Un système embarqué, en général tu le payes une fois à l'achat. Le constructeur ne te vend pas pour ce prix un support illimité (même MS, RH ou Apple ne proposent pas ça pour leur OS). Pourtant moult appareils embarqués tiennent bien au delà des espérances et au delà parfois de la vie de leur propre fabricant. Ton application de la banque, elle va évoluer tant qu'il y a des clients et que la banque est en vie. Et elle peut facilement le faire et facturer tout ça tout le long. Et quand la banque meurt, le service avec donc pas de soucis. Ce raisonnement ne peut pas marcher avec un système embarqué où le constructeur peut disparaître alors que des produits tournent encore, et dont la maintenance pendant 20 ans n'est pas compatible avec une seule facturation du produit (ou alors ce sera exorbitant).

Puis il faut comprendre comment fonctionne le doux univers du matériel. Qualcomm par exemple te sort une puce en 2015. Pour pouvoir l'exploiter et le vendre, ils conçoivent ce que l'on appelle le BSP, qui contient en gros un noyau, un chargeur de démarrage, des bibliothèques, firmwares ou applications pour l'exploiter. Pour des raisons de propriétés intellectuelles et économiques, ils ne maintiennent que très peu le dit BSP.

Les patchs sont de mauvaise qualité, impossible d'envoyer upstream (et si tu essayes de le corriger toi, le processeur ne sera plus vendu quand tu auras fini) et le constructeur s'en fout. Dans 2 ans, il vendra un nouveau modèle, donc quel intérêt il a à porter ses patchs de versions en versions de Linux si peu de temps après son premier jet il fera autre chose ?

On râle, on râle, mais ça ne fait rien changer à l'affaire. J'aimerais aussi que ce soit autrement. De toute façon si on les contraint à faire cette qualité, ça va faire monter les prix des consommables. Et pas mal de gens n'en voudraient pas à un tel prix. Surtout qu'on parle de systèmes peu évolutifs, dont globalement l'application est faite une fois et les mises à jour très rares car difficiles voire impossibles.

Économiquement, il y a donc un soucis pour un support de sécurité pour ces appareils, il y a donc aussi des contraintes techniques, qui rendent ce qui est banal ailleurs en terme de bonnes pratiques, très difficiles à mettre en œuvre.

Je ne rêve pas de cette situation et oui, il y a des discussions en cours sur le sujet qui est bouillonnant. Faut pas croire que c'est un soucis simple à régler et qu'il suffit de faire une application portable ou maintenable pour résoudre tous les cas de figures. Faut pas croire que tout le monde s'en fout. Mais on ne peut pas en l'état actuel des choses garantir la même sécurité à l'application de la banque et de ta lampe connectée.

On est d'accord, mais c'est un autre cas particulier. Un truc non relié au réseau c'est devenu rare et demain ça sera encore plus rare.

Cas particulier + cas particulier + …
Pour moi, ce ne sont plus des cas particuliers, à la fin cela représente un taux non négligeable.

Donc avant d'être portée l'appli est déjà en prod ? trouée ?

Tu sais il y a pas mal d'applications qui restent en vie très longtemps, plus longtemps que plusieurs versions de PHP ou de Python. Quand c'est un peu gros, la transition n'est pas immédiate. Donc tu peux avoir une application qui tourne mais avec des solutions obsolètes oui. On fait quoi dans ce cas ? On coupe tout ?

Ok, cas particulier qui concerne les dev.

Les développeurs ne sont qu'un cas particulier ? En fait c'est quoi ton cas général car ça commence à faire beaucoup.

Dans l'embarqué c'est peut-être le cas je ne sais pas, mais dans le cas général la portabilité est considérée comme une qualité.

Quand ton langage change de syntaxe ou d'écosystème, le portage n'est pas trivial. 10 ans après le début de Python 3 de nombreuses applications n'en ont pas fini avec Python 2 encore (près de 33% des applications ayant une dépendance avec Python dans Fedora dépendent de Python 2). Quand ton compilateur change les normes par défaut ce qui flingue certains codes aux comportements anciens dont tu n'as pas toujours le plein contrôle tu ne peux pas le prévoir non plus.

Tu peux faire la portabilité maximale que tu ne peux pas te prémunir de ce genre de changements.

Notre désaccord vient de là je pense : dans l'embarqué c'est selon toi une excellente solution et je veux bien te croire, mais dans l'informatique "classique" ce n'en est pas une selon moi. On est formaté par nos domaines d'application respectifs.

Pas du tout, je viens de te montrer que le reste de l'informatique aussi était concernée par ces questions (moins, mais quand même). Je l'ai vu en vrai ces situations aussi. Les applications ne sont pas tous des Hello world à porter tu sais.

Mais pour conclure je préférerai que ce genre de techno restent où elles sont utiles et donc pas sur mes serveurs.

On parle d'offrir le choix aux utilisateurs d'utiliser le dépôt ou les applications tout en un et toi tu me parles de serveurs ? Je comprends pourquoi tu me réponds à côté aussi.

Hum, aisément est un adverbe et non une préposition comme à, du coup je ne vois pas la pertinence de ta remarque : ma phrase est correcte.

Je suis pas sûr de comprendre l'argument ; tu parles par exemple d'une appli web quelconque qui ne fonctionnerait qu'avec une vieille version de php (probablement trouée donc) ? Si oui, il faut modifier l'appli pour qu'elle fonctionne avec les versions actuelles. Faire autrement me semble suicidaire au niveau de la sécurité. Et si on peut pas modifier l'appli pour une raison de budget ou autre, on se dirige dans tous les cas vers des problèmes. Qui mettrait en prod une application web plus maintenue ?

Tu oublies quatre choses :

• Des versions supportées simultanément, il y en a parfois plusieurs. Les distributions proposent rarement tous les supports d'un coup.

• Il y a parfois des outils, non reliés au réseau, qui sont utiles et dont le portage coût cher par rapport au gain. Car ici les considérations de sécurité sont absentes et donc il faut se coltiner un peu les vieux trucs tant que c'est possible.

• Il y a un temps entre le moment où tu débutes le portage et la fin, et parfois il faut une fonctionnalité ou la correction d'un bogue. Puis il te faut une copie de l'environnement initial pour vérifier que tu n'as pas changé le comportement de l'application dans le portage.

• Pour bien tester et développer, il faut minimiser les différences entre la machine de prod et la machine du développeur. Utiliser Docker ou une VM permet de s'abstraire de tout ceci sans être contraignant (avoir la même distribution sur le serveur et les machines de développement ne me paraît pas judicieux).

Pour tout ça, sans être en systèmes embarqués, Docker et autres sont de bonnes solutions. Ce ne sont pas des solutions universelles, mais les distributions traditionnelles non plus… Au bout d'un moment, il faut accepter de faire cohabiter les solutions suivant les besoins.

"Oh làlà! C'est obsolète tout ce bazar, et pas fiable! Et même pas bien sécurisé!
Monsieur je pense qu'il vaut mieux tout réécrire. Je vous prépare le devis?"

Cela peut être pertinent pour un serveur Web ou un logiciel traditionnel, cela l'est moins quand on parle du support d'une puce précise dont le constructeur de la dite puce a fait un bon gros patch dégueulasse pour le noyau, le chargeur de démarrage et potentiellement d'autres trucs pour des versions précises de ces composants et basta tu te débrouilles avec.

Oui on peut réécrire et adapter l'ensemble, le projet ne prendra pas 1 an mais 5 ans. Demandera des compétences différentes. Ne coûtera pas le même prix non plus et sans garanties de fonctionner mieux (d'autant qu'on n'a pas accès aux documentations ayant servi à concevoir ce gros patch). En plus quand tu auras fini ce travail, tu seras en retard pour les évolutions qui ont eu lieu entre temps. C'est sans fin.

Ou alors tu utilises Docker en 10 minutes et tout le monde est content. Au bout d'un moment il faut être pragmatique et arrêter de croire qu'on peut toujours faire la solution idéale partout. Ça se saurait.

Je ne comprends pas ton idée de cache binaire.
Si je devine ce que tu veux dire, cela implique que le paquet existe déjà pour la distribution. Ce qui n'est pas toujours le cas (je dirais même que ce sont les paquets absents des dépôts qui sont les plus concernés par les dispositifs qu'on décrit).

Tu mets sous le tapis plusieurs problèmes :

• Comment la recette devine le nom de la dépendance qui manque (les noms de paquets diffèrent pour un même paquet) ? Comment il gère le cas où une distribution fournit la dépendance et une autre pas ? Comment il gère le cas où deux distributions ont des options de compilations qui diffèrent fondamentalement ce qui peut induire qu'une dépendance soit inutilisable car avec des trucs en moins ?

• Quid des licences ? Fedora Copr permet par exemple de faire des équivalents de PPA et qui pourraient, d'un point de vue architecture, ressembler à ce que tu proposes. Mais Fedora refuse que ce système soit utilisé par autre chose que des paquets libres non couverts par des brevets.

Bref, tu ne réponds pas vraiment à ces questions. Il ne faut pas se mentir, sur la question de dépôts contre les solutions tout en un, aucun n'est parfait. Suivant le contexte l'un sera plus adapté que l'autre.
Il est selon moi important que les distributions proposent les deux modèles simplement, pour prendre en compte tous les cas de figures. Ensuite à l'utilisateur de choisir ce qui est le mieux pour lui au cas par cas.

Car cela ne répond pas forcément au besoin ?
Je veux dire, quand tu utilises un utilitaire comme buildroot, Yocto ou similaires, pour travailler il va utiliser au départ des éléments de ta machine : ton compilateur, les en-têtes et les bibliothèques.

Et souvent, si tu travailles sur de vieilles versions ce qui est courant, ta distribution ne propose pas ce qu'il faut. Un symbole introuvable, une en-tête manquante, ou un outil qui a changé de comportement ce qui casse tout (GCC en particulier qui a activé par exemple C++11 par défaut).

La compilation statique ne résout que partiellement ce genre de soucis. Et cela reste contraignant pour le déploiement. Avec Docker, le gars débarque, en 10 minutes montre en main il a les outils d'opérationnels. Combien de temps pour s'il doit récupérer et placer au bon endroit les outils ? Sans compter qu'il devra aussi chercher dans sa distribution ce qui marche manuellement dans les dépôts.

Et comment tu gères aussi les différences entre Python, PHP tout ça ? La compilation ne suffit pas, il faut potentiellement récupérer tout l'écosystème en entier. Une distribution offre rarement ce genre de choses nativement, Docker pallie aisément à ce besoin.

En tant que développeur je vais te répondre, parfois on n'a pas le choix et cela simplifie grandement la vie.

Dans mon boulot, il m'arrive de devoir travailler (en systèmes embarqués) sur des programmes antédiluviens, qui nécessitent des programmes ou bibliothèques non maintenues dans les distributions principales. On fait quoi ? On jette tout et on dit merde au client et au fournisseur ?

Docker et assimilés permettent de contourner les limitations de notre système pour développer sur ce projet ce qui économise une VM ou éventuellement un boot dédié pour développer dessus. Cela permet aussi très facilement de s'abstraire des différences entre distributions. Tiens un sous-traitant débarque avec un système différent sur sa machine, pas grave, il va avoir facilement les outils pour développer dessus de manière identique aux autres. La production a un serveur sous Debian X quand les développeurs sont sur Debian Y ? Pas de soucis, tout le monde pourra avoir la même version que la prod localement pour tester.

Bref, n'en veux pas forcément aux dev, pour bien faire notre travail, Docker ou autres peuvent être vraiment indispensables. Je ne dis pas que cela doit être fait pour tout et n'importe quoi, mais cela fait sens dans ce contexte.

Il y a des solutions qui existent depuis longtemps. Dans Debian et toutes les distributions basées dessus, tu as l'outil "alien" qui permet d'installer des RPM. Comme ça, le développeur fournit un RPM, et il peut s'installer partout. Par contre, c'est difficile d'avoir un RPM avec les bonnes dépendances et qu'on arrive quand même à installer.

En fait la question des RPM, DEB ou autres n'est pas réellement pertinente, à part ceux qui font les paquets qui ce sont qui vont subir la difficulté (ou pas) d'en concevoir un proprement. On le voit avec en effet alien qu'il ne suffit pas de convertir de format pour résoudre le soucis.

Car ce qui diffère vraiment entre les distributions, ce sont les conventions de nommages des paquets (httpd pour Fedora et assimilés, apache pour Debian et similaires), les numéros de version (faire fonctionner un RPM de Fedora flambant neuf sur une Debian pourrait échoué à cause des différences de versions) sans compter les options de compilations attribués à chaque paquet ou d'autres choses comme de l'intégration à des composants systèmes comme SELinux qui est fait par la distribution.

Et ces aspects là sont fondamentaux et insolubles. Pour vraie du vrai cross-distribution il faut donc soit :

• Repartir systématiquement des sources, mais bon on n'est pas chez Gentoo ici ;
• Inclure un maximum de dépendances dans le paquet pour que cela passe partout (modulo un noyau et une base suffisamment compatibles mais c'est assez faisable).

Beaucoup de distributions comme Fedora gèrent les mises à jour par delta nativement (c'est même souvent le mode par défaut). Rien n'empêche donc de le généraliser, notamment à ces applications contenant tout ce qui est nécessaire.

Ils ont poussé des trucs comme PulseAudio à une époque où c'était Rock'n'Roll pourtant et je pense qu'il y a plus de gens qui savent changer de navigateur que de gens qui savent bypasser PA.

Fedora a changé depuis cette époque, la QA a pris énormément d'importance depuis. Cela se voit avec Wayland qui a été maintes fois repoussé et avec conservation de la roue de secours quand cela a été envoyé.

Mais bon c'était une boutade, ils font bien ce qu'ils veulent. Ça m'a surpris parce que je trouve Mozilla assez méticuleux sur le sujet et que c'est une fonctionnalité assez attendue.

Mozilla fait attention, c'est vrai, mais comme indiqué, le calendrier de Mozilla est rarement identique pour tous les systèmes d'une part (Windows a quand même bien plus de testeurs) et les distributions ont leur propre politique (n'oublions pas que c'est cela le but d'une distribution aussi, potentiellement différer sur la source pour avoir un tout cohérent).

Il faut dire que Mozilla et les distributions sont rarement en phases pour ce genre de changements importants. Chaque OS a plus ou moins son propre calendrier. On l'a vu pour GTK+3 où Linux (et Fedora en tête) ont été en avance par rapport à Windows, mais Linux a été en retard sur la question de l'accélération matérielle et pour les bibliothèques multimédias, etc.

Fedora est certes une vitrine technologique mais avec un minimum de QA derrière. Je suppose qu'étant donnée l'importance de Firefox (navigateur principal et par défaut) et les potentiels soucis qui peuvent apparaître le mainteneur a dû être frileux. On verra bien. :)

C'est probablement Fedora qui a décidé de couper par défaut pour tout le monde ce mode, le temps de vérifier son bon fonctionnement.

mais autant que je sache les prix/taxes/remises sont bien toujours locaux.

C'est pire que ça, les prix en France sont libres.
Rien n'empêche à un supermarché de vendre un produit donné à 500€ et que la même enseigne à 30 km le fasse à 600€. En fait c'est hyper courant comme approche.

Sans compter les supermarchés ou fast foods qui sont les rois des réductions ciblées, du genre offre valable sur 1 ou 2 départements.

Bref, cela se passe au sein de la France, aucune raison que cela ne se fasse pas entre frontières politiques.

Ah oui, je n'avais pas fait attention, je n'ai pas suivi cette procédure et chez moi cela marche.

J'ai crée la clé browser.tabs.remote.force-enable que j'ai mis à True puis j’ai relancé. Tu devrais essayer.

Tu as redémarré Firefox après ta manipulation ?

Tous les retours ont été positifs, c’est pourquoi avec Firefox 51, Electrolysis sera activé sauf si présence d’une extension marquée explicitement incompatible.

Ce n'est pas vrai. C'est l'inverse. Cela ne s'active que si toutes les extensions possédées sont déclarées comme compatibles. La différence est que beaucoup d'extensions n'ont pas de status à ce sujet, cela sera donc considéré comme incompatible même si ce n'est pas vrai.

J'en profite pour dire que Mozilla ne peut deviner seules les extensions qui sont compatibles ou non. Cela repose donc sur les développeurs et utilisateurs des extensions de le signaler.

Si vous souhaitez accélérer le déploiement par défaut de Electrolysis dans Firefox vous pouvez consulter la page listant les extensions et leurs status.
Vérifiez que toutes vos extensions soient marquées comme compatibles. Si non, installez l'extension recommandée sur cette page. Forcez Electrolysis sur votre configuration et testez. Faites ensuite un rapport d'activité via l'extension après un usage raisonnable de l'extension et du navigateur (donc quelques jours probablement). Et si ce n'est pas compatible, n'hésitez pas à contacter les développeurs des extensions concernées.

Plus il y aura de retours, plus vite la situation évoluera pour un déploiement total et sans casse.

Le Logiciel Libre, c'est aussi s'impliquer pour que cela avance. ;-)

Cela ne répond pas vraiment à la question, quelle est la température du système ? Il y a-t-il beaucoup de processus qui sollicitent la machine ?