damaki a écrit 389 commentaires

Ça n'est pas un fantasme, ni à mon sens un processus conscient ou volontaire. C'est plutôt un ajustement naturel à ce que les consommateurs paient pour acheter.

Les consommateurs veulent des produits pas chers, donc nécessairement, on va s'orienter vers des composants moins chers. À part certaines marques qui font l'objet d'un véritable culte, il n'y a aucun intérêt à fidéliser les clients avec des produits bons sur le long terme. Les produits ont une durée de vie moyenne attendue par le marché, grosso modo supérieure de quelques années à la garantie + l'extension de garantie moyenne. Les assureurs ne sont pas idiots et les extensions de garantie sont statistiquement rentables et bien calculées.
Les consommateurs veulent des produits sexy lors de l'achat. Une fois que c'est vendu, le fait que les qualités cosmétiques perdurent, ça n'est pas souvent le problème du fabricant. Le métal luisant du robinet disparaît, l'impression des touches s'efface sur le clavier, etc… Le but est de vendre à un instant T et rarement de fidéliser.

La réparabilité ne rapporte quasiment rien aux fabricants. Au contraire, ça les oblige à maintenir une logistique horriblement complexe pendant des années, d'obtenir les composants compatibles au même format, c'est un gros investissement. Donc tant qu'ils ne sont pas contraints par la loi, leur image de marque, la gamme visée ou le type de produit, ils n'ont aucun intérêt à faire d'effort là dessus. Et il n'y a guère que des pros qui paieront pour des contrats de maintenance de longue durée, le consommateur préfère lui payer peu et directement à l'achat. Et en plus, l'apparence des produits va continuer à se dégrader et donc à dégrader l'image de marque, vu que les consommateurs ne paient pas pour des réparations cosmétiques.

À mon sens donc, il n'y a aucun intérêt côté constructeurs de favoriser les réparations.

Je sais pas vous, mais moi je vis en appartement. Et en appartement, si vous laissez hurler votre bébé pendant 30 minutes, les voisins débarquent, quand c'est pas directement les flics. Comme tout ce qui touche aux enfants, il n'y a pas de règle universelle miraculeuse.

Le sujet d'éduquer les parents n'est pas une mauvaise idée, mais j'ai la sensation qu'on tombe vite dans la théorie stérile et dans un les autres sont nuls, d'autant plus prégnant si vous n'avez jamais eu de gosse ou si vous avez été un/une miraculé(e) avec un enfant facile qui obéit directement sans trop insister. La psychologie humaine, c'est complexe, même pour les enfants et il n'y a jamais de truc universel qui marche partout, jamais. S'il n'y avait plus du tout de gens en prison parce qu'on a réussi à corriger leurs mauvais comportements, ça se saurait.

Les médias traditionnels sont aussi une bulle médiatique, assez homogène en idéologie, de plus. Donc ça n'est effectivement pas magique. Mais ça n'est qu'une des idées pour sortir de la bulle techno/informatique. Est-ce que suivre le foot ou les news people est un enrichissement personnel ? Ça dépend de la valeur que vous accordez aux gens avec lesquels ça peut vous permettre de discuter. S'il le but est carriériste, ça peut être intéressant de lire des bouquins de management, par exemple.

Si on remplace le terme jargon, connoté, par vocabulaire métier, ça change l'idée. Le vocabulaire métier sert à utiliser le même vocabulaire quand on parle d'une même chose. Le fait qu'il soit anglais n'est qu'un détail. Le but d'un langage commun est d'être précis, pas inné. Et s'il n'est pas inné c'est parce qu'il faut l'apprendre.
Le but n'est pas d'être élitiste mais d'être précis. Avoir un langage commun précis, c'est un peu la base de la communication en entreprise.

Le principe même de l'amitié, des relations sociales c'est de regrouper les gens par classe sociale et/ou centres d'intérêts. Donc comment pourrait-on facilement réaliser en ligne ce qui est aussi difficile à accomplir au quotidien ?

Pour savoir où trouver du contenu en dehors de ta bulle, il faudrait définir ladite bulle. Si t'es une personne de la technique informatique, lis ou écoute des médias généraliste, regarde la télé et parle à des gens non techos. Si t'es de droite, lis des médias de gauche, genre mediapart et inversement si t'es de gauche, butine du contenu de droite. Ouvrir ses horizons, ça consiste à mon avis à picorer soi même en choisissant des cibles inconnues, voire du hasard
Les réseaux sociaux privateurs décident à ta place ce que tu vas consommer comme médias et personnes, il faut donc lutter contre ça en bougeant soi même, en étant moteur dans le choix de ses médias et contacts.

Si ton appareil n'est pas à jour, cette interdiction t'empêche de l'utiliser pour le mettre à jour par internet.
Deadlock !!
Ou alors ça oblige à avoir un deuxième appareil pour mettre à jour le premier. Mais si les deux appareils se retrouvent en retard d'une version (ce qui arrive à chaque nouvelle version), alors encore deadlock. Ou alors il te faut un troisème appareil, etc.

D'où mon principe de réponse graduée. D'abord on prévient le détenteur de la connexion internet qu'une machine n'est pas à jour, en fournissant les informations qui ont permis de l'identifier. Puis quelques temps plus tard, on met en demeure la personne physique ou morale de mettre à jour son appareil, puis on coupe si la personne refuse.
C'est à combiner avec de l'information pour expliquer comment mettre à jour ses appareils, comment retirer leur accès à Internet, voire une liste de prestataires agréés pour aider les gens à mettre à jour.

Que tu les publies pu pas, il est déjà interit d'exploiter des failles de sécurité

À part si t'es un service d'intelligence d'un état, auquel cas t'as zéro chance d'être jugé. Et c'est justement le cœur de mon point.

C'est un peu étrange comme interdiction, et difficile à mettre en oeuvre (à moins que la formulation soit maladroite ?)

Non, c'est exactement mon point. Je suis pour des mécanismes de détection des failles, les mêmes utilisées par les botnets (scan), mais façon riposte graduée de l'Hadopi. Ça n'enlèverait pas 100% des machines exploitables, mais au moins celles exploitables facilement à distance.

Je dois pouvoir décider si je continue à utiliser un produit/service qui présenterait un risque dès que le trou est découvert.

Non, parce que dans ce cas là c'est faire encourir un risque à d'autres personnes, comme une voiture qui ne passe pas le contrôle technique. Ton appareil pollue le net et met en danger d'autres machines, il est enlevé du net. Et si tu refuses de l'enlever, on te coupe ta connexion, même pour une entreprise.
Mon point est que personne ne devrait consciemment pouvoir décider d'affaiblir le tout qu'est Internet en risquant d'agrandir un ou plusieurs botnets, parce que ça l'arrange.

Ce document est plein de bonnes intentions, mais sans détails concrets législatifs contraignants, ça reste du vent.

Ce qui serait concret :
- Interdiction à la vente/location des appareils (Internet of Things/Shit) et des logiciels qui n'ont pas de garantie de mise à jour pendant 5 ans
- Interdiction de vendre des appareils de la part des fabricants ne respectant pas leurs garanties de mise à jour, ainsi qu'une amende en pourcentage du CA et deux ans d'emprisonnement du CEO/PDG
- Interdiction d'exploiter des failles de sécurité sans les publier publiquement ;
- Interdiction d'utilisation d'appareils non mis à jour sur Internet. Une amende dans le cas où on se fait chopper dans ce cas là ;
- Un registre international, public et centralisé de failles de sécurité découvertes depuis plus de 6 mois et/ou corrigées. Avec un système de soumission de failles de sécurité de façon anonymes.

Rien qu'avec tout ça, on serait bien.

Salut,
Ça fait des lustres que je pensais à coder ça mais que j'avais une grosse flemme de le faire. Donc un gros merci ! Je vais tester ça.

Etant en train de passer mes servers persos à Docker, et avec un objectif de faire ça proprement et sans Kubernetes (parce que c'est de l'overkill si t'es pas une entreprise), effectivement la doc et les tutos Docker, il y a un cercle de l'enfer pour ça.
La doc officielle est pas mal, mais elle est totalement insuffisante pour faire des déploiements dans la vraie vie, et elle suggère de vraies mauvaises pratiques (auto-restart, je te regarde). Je rêve d'une doc qui t'explique de façon centralisée :
- comment faire des Dockerfile en respectant les bonnes pratiques
- comment tester des Dockerfile en local sans avoir trop d'écart avec ta prod
- comment écrire des unit systemd pour démarrer les containers, avec gestion des dépendances entre containers sur une même machine
- comment scripter le déploiement et la mise à jour de containers sur un petit lot de serveurs, proprement
- bonnes et mauvaises pratiques d'administration système avec Docker sur une petite install (moins de 5 serveurs)
- comment bien utiliser les volumes dockers et les différents plugins dispos, ainsi que les contexes d'utilisation
- comment déployer un registry docker privé et pourquoi
- comment et pourquoi migrer d'une install serveur par serveur vers une install distribuée à la Kubernetes, Swarm, Nomad et compagnie.

Pratiquement toutes les docs que j'ai pu voir donnent l'impression d'être écrites par ou pour des devs et non pas des administrateurs système ce qui les rend difficiles à utiliser pour un vrai déploiement.

J'espère que leur "Updated for Docker 1.13." n'est qu'une erreur, parce qu'il s'est passé un gros paquet de trucs depuis cette version. Et les bonnes pratiques ont beaucoup changé (Dockerfile multi stage, par exemple).

J'ai eu à peu près le même soucis récemment ; j'ai repéré les 2 Go du SDK de flatpack dans /var/lib/flatpack parce que j'ai du avoir le malheur de télécharger une appli qui avait tiré ça en dépendance.
Flatpack n'est pas le problème, le soucis est plutôt du côté des mainteneurs des paquets qui ne comprennent pas ce qu'ils font. Il y a le même soucis avec certains paquets de distro qui tirent la terre entière comme dépendances, par flemme ou impossibilité d'avoir des dépendances optionnelles.

Les trucs de sandbox contraignantes pour l'écriture de fichiers, c'est toujours pareil pour les applis sur des OS Desktop, ça finit désactivé dans quasiment toutes les applis parce que c'est trop chiant à gérer pour écrire des fichiers utilisateur. J'ai vu le même souci avec les Snaps de Ubuntu (utilisables aussi sur d'autres OS).

Ma conclusion à moi est qu'AppImage reste la meilleure solution. Ça n'est pas efficace niveau espace disque et libs à jour, mais pour fournir une appli fonctionnelle et ses dépendances, ça reste le meilleur moyen. Les vertus :
- ça marche ailleurs que chez soi
- ça culpabilise les devs de faire un livrable qui dépend de 2000 paquets et donc ça réduit la taille des livrables+deps.
C'est ni original, ni efficace, mais des années d'expérience sous Windows montrent que ça marche plutôt bien.

La pertinence du standard n'a qu'une faible importance dans son adoption. Prenons Excel, par exemple. Il est connu dans les milieux développeurs et/ou scientifiques pour être source d'erreurs de calcul. Prenons maintenant les milieux économiques et managériaux, eh bien ils s'en servent pour des calculs monétaires et de budget. C'est absurde qu'un outil inadapté soit le standard, mais ça reste le standard de facto en dépit du bon sens.
J'ai choisi d'illustrer d'abord avec le cas des tableurs, mais regardez aussi le protocole IP en unicast pour la diffusion vidéo, le HTTP pour la SOA moderne. Le monde est rempli de standards inefficaces.

Les standards ne naissent pas du néant. Soit on se met d'accord pour définir un standard et on définit un process pour valider qu'il est respecté, soit il n'y a pas de standard. Le simple mime du standard ne suffit pas à le respecter ; même les standards de facto ont une définition.

Pourquoi poserais-je une brique jaune dans un mur rouge si les briques rouges sont 4 fois plus chères ? Eh bien si j'ai établi un devis pour poser de nouvelles briques rouges et que le client l'a accepté, elles seront rouges.

Si vous souhaitez que des standards émergent, définissez-les, portez-les, partagez-les et surtout faites-les respecter.

Nous sommes dans un monde où on sait développer un service accessible depuis l'extérieur, un CRUD qui tape en base en minutes, le tout avec des perfs raisonnables. Alors oui, on peut développer la même chose en C ou C++ en une journée avec le vent dans le dos (et des segfaults) ou en une semaine en assembleur. Donc on développe plus vite des choses plus testables et mieux testées qu'avant.

Là où l'article vire dans la mauvaise foi c'est que nous sommes dans un monde où on veut toujours plus de complexité. Évidemment que Windows 10 est plus lent que Windows 95, il y a beaucoup plus de fonctionnalités dedans qu'on prend désormais comme des acquis. Idem pour un téléphone, on veut une appli de photos, une appli de streaming de musique, gestion de contacts, accès aux mails, services de streaming vidéo et le tout avec de la synchro au cloud parce qu'on a la flemme de faire des copier-coller de fichiers. Combinez la complexité avec les stacks logicielles citées ci-avant qui facilitent le dev et vous avez la réponse à la question "pourquoi cette lourdeur ?". C'est parce que c'est la seule réponse possible à ce que les gens demandent. Une ampoule à LED est largement plus complexe qu'une ampoule à filament ; est-ce que ça les rend mauvaises pour autant ?

Si la réponse ne vous plait pas, changez de question en "pourquoi veut-on autant de fonctionnalités ?".

Ce qui attire en premier les chercheurs de faille, aux intentions criminelles ou non, c'est la quantité de machines exploitables. Le parc de machine étant ridiculement petit (IOS exclu), ça ne présente pas grand intérêt comme cible de faille. Moins d'intérêt pécunier, donc moins de chercheurs intéressés économiquement donc moins de failles découvertes.
Ça n'est donc pas à mon sens qu'il y a moins de failles, c'est juste qu'il y a moins de failles découvertes. Et vu les ramifications de l'utilisation de Windows et Linux dans les gouvernements, j'aurais tendance à penser qu'elles deviennent publiques plus rapidement. Avoir une faille sous le coude, c'est bien, mais être vulnérable soi même, c'est moche.

C'est connu que tous les européens blancs descendent de ces quelques esclaves, évidemment. Dans le cas des Antilles, tous les descendants antillais noirs descendent littéralement des esclaves.
Merci donc de comparer des situations comparables et de ne pas sombrer dans le troll.

Non, ce qui offense les humains, c'est que ces termes qui rappellent des traumatismes culturels et familiaux pas encore résolus socialement ni politiquement de nos jours soient présents partout dans certains domaines sans aucune bonne raison. Et ça n'a rien d'américano-américain, suffit de remonter aux exactions commises par la France il n'y a pas si longtemps ou encore ça, qui ne sont que la suite de l'esclavage et du manque de considération encore présents de nos jours.
Les seuls raisons de conserver ce vocabulaire sont :
- Les gens concernés en informatiques savent ce que ça veut dire, c'est du vocabulaire établi ;
- Les devs, sysadmins et universitaires des pays où a lieu le débat sont majoritairement blancs et donc pas concernés.
Franchement, je ne trouve qu'aucune des deux raison soit suffisantes pour conserver ce vocabulaire. C'est comme dit que c'est acceptable de continuer à appeler tête de nègre un gâteau, parce que c'est comme ça plutôt que de remettre en question ces relents d'esclavage et de colonialisme.

J'ai créé quelques modules simples pour Dokku et franchement, c'est loin d'être facile.
- C'est difficile à tester, pas évident à déboguer.
- Chaque module est dans un fichier séparé et indépendant ; je n'ai toujours pas trouvé s'il y a un moyen pour mutualiser du code à part de générer le code avec un préprocesseur ou un moteur de template.

Bref, autant, en tant que sysadmin du dimanche, c'est bien, mais quand tu commences à vouloir factoriser tes scripts et à remplacer des copier-coller de tâches par des modules, la fête est finie. Il manque vraiment une philosophie de modules en fractales, façon Terraform.

Les deux ont leurs avantages et inconvénients. Mais honnêtement, dans les deux cas la taille est tellement petite que ça n'a plus trop d'importance. Surtout une fois compressé pour déposer sur un repo. Et une fois décompressée, on s'en fiche vu que chaque image intermédiaire n'est stockée qu'une fois sur chaque serveur.
A noter qu'Alpine est de base incompatible avec le JRE Oracle qui est compilé pour la glibc. Et inversement, avec stretch-slim, pour installer l'openjdk-jre il faut bidouiller (créer un dossier man manquant).

J'avais effectivement réussi à faire ça sous d'anciennes version d'Android, mais tous les guides que j'ai pu voir à ce sujet ne fonctionnent pas avec oreo. En effet, sous oreo, ça n'est plus une simple recherche mais c'est google assistant.
En contrepartie, on peut désormais virer la barre de recherche Google sous oreo. Plus besoin de changer de launcher pour ça.

Ce n'est pas l'industrie IT qui crée les monopoles, ce sont les gouvernements qui acceptent de laisser les créer. Le monopole de Google sur la recherche est arrivé en genre 5 ans, celui d'Android sur les smartphones (en volume, pas en valeur), je dirais 8 ans à la louche. 5 ans, c'est déjà très long. Je pense donc que c'est plutôt le laxisme et la corruption le lobbying qui provoquent ces lenteurs, ce ne sont pas les spécificités de l'IT.

Si seulement ils avaient aussi stimulé concurrence des moteurs de recherche et pas juste celle des OS. J'attends toujours de pouvoir remplacer intégralement les recherches Google, y compris vocales, par des services tiers. Oui, même le raccourci quand on laisse enfoncé le bouton home.

Pour avoir déjà eu l'intention de mettre du code à disposition en entreprise et abandonné, faute de moyens, c'est loin d'être gratuit. La question devient donc : vaut-il mieux ne pas mettre à disposition du code que de mal le faire ? Bref, on a un fork de dbdeploy compatible avec SQL Server qui ne sera jamais partagé.
Hors entreprise, j'avoue aussi avoir mis en ligne pas très exploitable sur github. On en revient au même problème : publier du code coûte du temps et/ou de l'argent. Si l'argent ne sort pas d'une stratégie de communication, de recrutement ou d'une volonté d'attirer des contributions externes gratuites, ça me semble frêle.

Cependant, là il faut être un peu positif ; ça n'est pas parce que le code n'est pas directement utilisable qu'il ne le sera jamais. Il est souvent possible de demander un peu d'aide aux mainteneurs du repo ou du projet, puis de leur offrir la doc qu'on a ainsi faite. Et s'il n'y a ni doc ni mainteneurs actifs, eh bien qu'il crève ce code. C'est tout ce qu'il mérite.

En tant que membre d'une équipe utilisant du Team Chat, nos trois plus gros problèmes sont :
1. Le Team Chat n'est qu'un canal de plus, donc il ne résout pas forcément les problèmes liés à la multiplicité des canaux malgré ses connecteurs. On a des sources d'info qu'on ne peut pas y connecter ;
2. Des gens se parlent dans la vraie vie et ça ne sera jamais sur le Team Chat. C'est normal et positif, mais on perd la trace de certaines info ;
3. Le Team Chat ne sert à quelque chose que si les gens l'utilisent. Ceux qui ne veulent qu'envoyer des mails (sans mailing list) ou ajouter des pages sur un Confluence continueront à faire ça.