Shared posts

05 Mar 21:01

Understanding And Overcoming Coder's Block

by Lorenzo Pasqualis

This post was first published on CoderHood as Understanding And Overcoming Coder’s Block. CoderHood is a blog dedicated to the human dimension of software engineering.

What is Coder's Block?

Coder's block is a period during which a developer struggles to write good code or any code at all. During a block, ideas don't materialize, and the overall goal of a project seems far and out of reach.

Writing code is a creative pursuit that requires using a combination of both the left and the right brain. All such activities sometimes run into a block that can be described as a lack of creative energy; this is a well-known issue with writing (it's called writer's block), but it affects coding just as much.

In my experience, coder's block is caused mainly by one of five root causes. I am going to examine each one of them, giving you strategies to recognize and overcome it.

Cause #1: You are not 100% clear what is the goal that you are trying to achieve

Coding is a creative activity, but it must be focused toward the accomplishment of a goal or the resolution of a problem. When the target or the problem is not clear, it is difficult to get started.

To recognize if this is the problem you are experiencing, think about what you are trying to achieve. In particular, can you answer two fundamental questions?

Two fundamental questions

  1. What goal are you trying to achieve?
  2. Why are you trying to achieve it?

Sometimes you might be tempted to answer "I am trying to get my project done" or "My goal is to keep my job," but that's not the type of goal I am referring to. Take yourself out of the picture. What you need to think about is the project itself. What is the purpose? Why is the project vital if you take yourself out of the equation?

If you can't answer the questions, try the following:

Turn off your computer

Do not even try to start writing code until you understand the goal that you are trying to achieve. Close your code editor and turn off your computer. It is a distraction, and it won't help. Instead, grab paper and pen and start thinking about the goal. Don't worry about how to achieve it, for now, just concentrate on what you are trying to do and why it needs to be done. Don't worry about the "how" yet.

The freedom of pen and paper

Pen and paper give you a freeform way of thinking and taking notes; it releases you from the annoying constraints and limitations of software tools. Avoid staring at the white page; instead, write down everything you know about the problem. Describe the goal, and why you should try to achieve it.

Draw pictures if you want to, and take notes on anything that comes to mind. The act of jotting things down will get your creative juices flowing. Pen and paper stimulate both the left and the right brain, priming the creative process.

Get up and talk to someone

When you have done some thinking with pen and paper, get up and talk to somebody. Ideally, the person you speak to is someone familiar with the project, but it is not necessary. You could use a friend or a family member, explaining that you need to describe something you are trying to do and that you'd like to get their thoughts. The simple act of expressing something to someone is often enough to get your brain moving in the right direction.

If you don't have someone to talk to, explain the problem to your pet or a stuffed animal. It doesn't matter who you are talking to, or if they understand you. The important thing is that you describe your goal out-loud. Keep talking about it until it is more evident in your head.

Rinse and repeat

Go back to pen and paper, and think about the goal some more. Review your notes, and see if you can answer the two fundamental questions mentioned above. If you can't, talk to someone again. Repeat the process until you feel that you can describe confidently what the goal is and why you need to achieve it.

The time invested in thinking about the goal might seem like a waste of time, and it won't feel like making progress toward a solution. However, let that thought go; it is a fallacy. You can't write code to implement "how" if the "what" and "why" is unclear.

Cause #2: You keep changing your mind on how to approach the problem

If the "what" and "why" are clear, you might be stuck on the "how" because you keep on finding reasons why your solutions are not good enough; this is a common problem that I call "the self-doubt loop."

The self-doubt loop

It occurs when you see issues with every solution that come to mind, and you can't settle for anything. As a result, you think in circles and make no progress.

It gets particularly bad when you start implementing a solution, and you find problems with it and change direction only to see more problems. You keep changing path until you get back to the first solution, and the cycle starts again. It feels like madness.

Take a break

The best way to break that loop is to stop thinking about the problem for a little while. Get up, go for a walk, talk to someone, eat something, have a cup of coffee, do something else or sleep on it overnight. After a break, get back to the problem, list all the possible solutions that come to mind, list pros and cons for each and see if you can settle on one.

Look at the goal from different angles

If you get stuck in the vicious loop again, go back to thinking about the purpose and make sure you understand it. Try to look at it from different angles. Try to re-define it and re-examine it. Ask yourself how you'd resolve the problem if you had to do it by hand and see if that helps. Think about it in practical terms, and with concrete examples to prevent over-abstraction or over-engineering.

Do not let perfect be the enemy of good

It is entirely possible that a problem doesn't have a perfect solution. Choosing a path, even an imperfect one, is often matter of making a decision and sticking with it and dealing with problems as they surface.

Do not let "perfect" be the enemy of "good." Perfection does not exist, and most solutions are a compromise. That is normal and expected.

Cause #3: The amount of work in front of you seems daunting, and you don't know where to start

When you look at a project in its entirety, you might feel like the end is not in sight. Getting stuck on the enormity of the goal is a typical cause of coder's block.

Split a large goal in sub-goals

Overcome this issue by putting the five fundamental problem-solving skills of software developers into action. Start by breaking down the overall goal into small sub-goals. Write them down in the order they come to mind. Once you have a list, make sure that they are well defined.

When you have a list, sort the sub-goals in the order you think you need to accomplish them. If any of them is too large, split it into smaller ones.

Work on the first sub-goal

Once your problem is split into multiple smaller parts, tackle the first one and finish it. Focus on it entirely, without getting distracted by the overall goal.

Remember to think parallel, abstract but avoid over-abstracting, consider re-using existing solutions and think in terms of data flows.

Calibrate and do more sub-goal splitting, if necessary

Concentrating on one sub-goal at the time will get the coding process moving, and you won't feel so overwhelmed. Use the time spent achieving the first sub-goal as a measuring stick to calibrate how large the other sub-goals are.

Each sub-goals should be no more than one week worth of work; if any of them takes longer, you might want to split them into smaller ones. Avoid large sub-goals as they tend to cause coder's block for the same reasons that large goals do.

Cause #4: You are not excited about the purpose

We discussed how knowing what you need to implement and why you are doing it is essential to make progress. However, even if you have the answers to those questions, you might not be convinced that the project is worth your time. That could be due to tedious work, or because the goal is to solve a problem that you don't find attractive or essential. Lack of excitement for a project is one of the most common causes of coder's block.

What can you do about it?

Use the project to learn something new

Maybe the project is not fun or exciting, but perhaps there are ways to transform it into a learning opportunity. For example, you could choose to use some new library or framework that you haven't used before. Or you could try to apply techniques or design patterns that you want to learn. There are countless ways to build the same piece of software, and learn something new can make even a dull project exciting.

Find reasons why your work is essential for the customer

Sometimes better understanding the needs of the customer can make a dull project more interesting. Take an opportunity to talk to some of the customers that are interested in the work you are doing, and find why it is important to them. If you don't have an opportunity to talk to customers, talk to customer-facing people in your organization, and find out why your work is essential.

Take the opportunity to tackle technical debt as part of the project

Are there ways to tackle some of the technical debt as part of the work to get the project done? If the job you need to do requires integration with an existing system, perhaps you can use it as an opportunity to fix some old issue that has been looming for a long time. Find ways to inject some work you want to do in the mix of work you have to do.

Cause #5: Something in your life or the work environment is bothering you, and you can't concentrate on your work

Creative work requires focus; distracting thoughts could be the cause of your coder's block. Is something bothering you? Do you have personal problems that are interfering with your concentration? Or perhaps the work environment is creating unhealthy stress levels that are getting in your way?

There are several things you can do to overcome this kind of coder's block:

Make a list of the things that are bothering you

Sometimes you can't focus because you are concerned that you'll forget about something important you need to do. Make a list of whatever is on your mind, with the intent of getting back to it at a better time. The act of writing down your distractors is sometimes enough to get you out of a coder's block situation.

Resolve the issues that are getting in your way

In some cases, you might need to take a break and prioritize fixing the issues that are bothering you. If the problems are personal, take a few days off to deal with it. Resolving something that is weighing on you, if possible, might be the best solution for your coder's block.

If the issues are work-related, take some time to deal with them. Talk to your boss, your coworkers, Human Resources, or whoever might be able to help you. Letting problems linger makes it difficult to break a coder's block.

Seek help

If you cannot resolve quickly the issues that are bothering you, seek help. Letting worries or anxiety linger is exhausting and terrible for your productivity and health. It is best not to let it go for too long. There is nothing wrong with seeking professional help or help from friends and family.


Coder's block is a nuisance that you can overcome. It is similar to being stuck in the mud with your car. The natural instinct of stepping on the accelerator is going to make it worse. You need to be smarter than that.

The first step is to realize that you are experiencing coder's block. The second is to try to understand the cause. The third is to choose the best strategy to overcome it.

If you enjoyed this article, keep in touch!

04 Mar 16:02

Why Your Android Phone Isn’t Getting Operating System Updates and What You Can Do About It

by Chris Hoffman

Back in the early days of Android, system updates were very random: they would roll out at different times, and often several times per year. Now, Google has taken a much more streamlined approach, releasing one major Android update per year and much smaller, security-focused updates once per month.

Read This Article on How-To Geek ›

21 Jan 19:18

Baisse du marché PC : Un marché qui s’entête dans les mêmes erreurs

by Pierre Lecourt

Alors certes le PC n’est pas mort, il se porte toujours aussi bien et les centaines de millions de machines en activité aujourd’hui montrent que le format est totalement indispensable à notre société.


Ceux qui prédisaient la mort du marché PC en faveur de celui de la tablette doivent en être revenus désormais. Ceux qui insistent pour dire que leur téléphone peut remplacer leur PC n’ont jamais fait une photo RAW de leur vie, encore moins essayé d’écrire un livre ou de faire un tant soit peu de 3D. Le marché PC est donc toujours à la dérive. En déclin, en nette perte de vitesse depuis l’arrivée de solutions concurrentes. Il faut dire que les constructeurs font le maximum pour nous en dégoûter.


IDC confirme donc une année 2017 en baisse pour les expéditions de PC, la sixième de suite. Alors, certes, c’est une petite baisse par rapport à 2016. Et les deux acteurs leaders se portent bien avec une légère croissance en fin d’année. 0.2 % d’expéditions en moins cela ne semble pas si terrible mais c’est à additionner aux 5 années de baisse précédentes. Cela veut dire que le marché ne se renouvelle pas, les gens font durer leurs machines et ne les changent que contraints et forcés. Un PC classique, sous Windows 7, continue de bien fonctionner pour les usages basiques. On ne fera pas tourner de gros jeux avec ce type de machine assez ancienne mais pour un usage bureautico-web, c’est largement suffisant.

Je vois l’exemple de mon frère, toujours sous Windows 7 avec un vieux coucou qui doit flirter avec l’âge de la retraite depuis bien longtemps maintenant. Alors, certes, il s’en plaignait un peu, notamment parce que pas mal de trucs lui sont interdits par l’ancienneté de ses composants. Mais sa machine continue pourtant à faire tourner de nombreux programmes et reste adaptée à son usage. Il se décide enfin à regarder vers une machine neuve car il a fait rentrer un nouveau joujou sous son toit. Il s’est offert une imprimante 3D. Et son portable ne veut pas vraiment entendre parler de programmes de création 3D et a même du mal à piloter certains outils indispensables pour sa Creality CR-10. Il est donc décidé à changer son vieux portable sous Windows 7. Sans l’arrivée de l’imprimante, l’engin aurait sans doute pu tenir quelques années de plus…

D’ailleurs, on le voit bien, les seuls marchés en croissance sont les machines de jeu et, dans une moindre mesure, les PC convertibles. Des marchés qui, pour le premier, exigent un fort taux de renouvellement par leur nature et pour le second proposent une alternative aux machines existantes. Mais les utilisateurs restent très circonspects devant l’intérêt de faire évoluer une machine qui marche pour une autre aux performances annoncées supérieures mais pas forcément plus utiles pour leur propre usage. Surtout quand ces nouvelles machines ont perdu leur âme de PC.

Lenovo ThinkPad X380 Yoga

“On veut faire ressembler nos portables à des tablettes”

Ça a été le credo de la plupart des fabricants ces dernières années. Les tablettes se vendent, faisons ressembler nos PC à des tablette. On a vu débarquer des portables à écran tactile, puis des écrans qui se détachaient des clavier et des charnières souples à 360° Au final pour quel usage réel ? Je pense qu’on utilise plus un PC de type Yoga dans des positions classiques ou d’affichage qu’en mode tablette au quotidien, au final.

L’offre évolue dernièrement avec l’arrivée des Always Connected PC et de leur connexion 4G même quand la machine est en pseudo veille. Je n’ai toujours pas compris le réel intérêt de la prochaine vague de machines de ce type. Le partage d’une connexion sur mobile est déjà une solution efficace qui va évidemment faire une grosse ombre à cette proposition.

HP Envy X2

De la flexibilité mais zéro évolutivité

Cela va être le grand truc de 2018 je suppose, ça et l’arrivée de portables encore plus fins. Comme si la possibilité de glisser un PC portable dans une bibliothèque de Bédés sans casser son harmonie visuelle était l’Alpha et l’Oméga de ce que recherchent les utilisateurs. Pour rappel, plus fin ne veut pas forcément dire plus léger. Et surtout, il faut contraster cette finesse du produit par rapport aux accessoires qui sont rendus nécessaires par la disparition d’une connectique universelle suffisante.


Il n’y a pas si longtemps, les portables offraient la possibilité d’accéder à tous leurs composants

La petite trappe de mise à jour…

Sans parler de l’essence même de ce qui faisait un PC autrefois, LA différence qui a totalement disparu. La possibilité d’une mise à jour.

Un mouvement qui a touché évidemment les portables mais également de nombreux PC de bureau de petit format qui ne justifiaient pas cette décision : Quand on achète une solution extrêmement compacte comme un NUC d’Intel, on sait que l’on va sacrifier la possibilité de changer les composants. Mais pourquoi réserver le même sort au tours de grandes marques ? Les Mini tours sont de plus en plus imbriquées, cartes et composants soudés. Alimentation systématiquement calculée au plus juste et parfois non standard. Les fabricants ont utilisé tous les artifices possibles pour rendre toute mise à jour difficile. Démonter un PC de marque ressemble aujourd’hui à un spectacle d’Houdini qui s’échapperait de Fort Knox.


Quand la question est posée aux fabricants, les réponses sont assez significatives. Par exemple, la demande du pourquoi les accès qui permettaient de changer le stockage ou à la mémoire vive d’un portable ont disparu ? La réponse classique, après l’excuse de l’infaisabilité pratique dûe à la finesse de l’appareil, est du genre : “De toutes façons les gens ne s’en servaient pas”.

Et c’est vrai, dans leur majorité, les gens n’en avaient pas l’usage. Il faut dire qu’il y a quelques années, avant l’arrivée des ultrabooks et la disparition de ces précieuses trappes d’accès, la mémoire vive et les SSD coûtaient bien plus cher qu’aujourd’hui. Et souvent les utilisateurs ne voyaient pas bien l’intérêt de ces mises à jour. Passer d’un disque mécanique en 5400 tours à un modèle 7200 tours n’était pas franchement bluffant. Les systèmes limitaient souvent la quantité de mémoire vive gérée…  Les choses ont drôlement évolué aujourd’hui, et la mécanique proposée par les fabricants également.

La grosse différence entre un ultrabook entrée de gamme et l’offre en haut du panier vient souvent de quelques détails. La quantité de mémoire disponible ainsi que la capacité des SSD sont les éléments les plus marquants d’un modèle à l’autre avec la définition de l’écran. D’un point de vue performances, ben, entre un Core i5 U et un Core i7 U, on ne peut pas dire qu’il y ait beaucoup de remous dans l’usage final possible de la machine.

De fait, cette limitation d’évolution des composants a servi un projet bien plus large de création de gamme. Avoir 8 Go de mémoire passe obligatoirement par les étapes annexes “avoir plus de stockage” et “avoir un processeur plus rapide” même si ces postes ne sont finalement pas utiles. Evidemment, cela veut dire aussi “payer plus cher” même si le besoin n’est, encore une fois, pas forcément là. Et c’est décourageant pour l’acheteur. Ils passeraient d’un PC assez vieux mais fonctionnel doté de 8 Go de mémoire vive et 500 Go de stockage mécanique sous Core i5 d’ancienne génération à une nouvelle machine en 4 Go et 128 Go de SSD toujours en Core i5 pour le même prix de base. Pour retrouver leur 8 Go, ben il faut accepter de prendre les options obligatoire : 256 Go de SSD et un plus gros Core. Et faire gonfler l’enveloppe du prix évidemment.


… et son effet placebo

Mais le point que beaucoup de constructeurs n’ont pas compris est plus subtil. Ce n’est pas parce que la majorité des utilisateurs n’envisageaient pas réellement de faire des mises à jour de leur mémoire ou de leur stockage du temps où les trappes étaient présentes qu’ils se fichaient de pouvoir le faire. La présence de la trappe les rassurait en leur offrant la possibilité théorique d’une mise à jour et cela déclenchait l’achat. C’est comme si vous disiez à un futur client d’une concession automobile qu’il ne pourra pas remplacer sa batterie ou réparer son moteur sur sa future voiture. Ce n’est pas tant qu’il espère avoir une panne qu’il souhaite garder le contrôle sur la durée de vie de son investissement.

Du reste cet effet “placebo” que représente la trappe d’accès aux composants, mythique possibilité “jamais utilisée” par les clients de mettre à jour leurs machines, a eu largement le temps d’être transformée en un “je te l’avais bien dit” de la part de celui qui avait insisté sur ce point.

Depuis 6 ans que les machines évoluent vers un enfermement de plus en plus complet, les acheteurs précautionneux qui avaient exigé la présence d’une de ces trappes d’accès aux composants ont eu largement le temps de mettre les mains dans le cambouis. L’accès qui ne devait statistiquement pas servir a eu le temps de permettre une optimisation de leur machine. Rajout de mémoire vive, passage d’un disque mécanique à un SSD… Mon billet sur les mises à jour de SSD reste un des plus lus de 2017 même si il est sorti en… 2014.

Avec l’ajout d’un peu de mémoire et le passage vers un SSD, un vieux portable retrouve une seconde jeunesse. Et la foi dans la petite trappe présente sur les anciennes machines est passée d’assurance hypothétique à règle d’or. Bon courage à ceux qui voudront faire acheter des engins cadenassés à ce type de clients sauvés d’un investissement inutile par le truchement d’un simple coup de tournevis.

Si on résume le mouvement, depuis 6 ans que les expéditions de PC baissent, on a perdu beaucoup sur le marché portable : Du poids sur nos machines ainsi que de l’épaisseur. De la connectique, beaucoup de connectique. Et la possibilité de mettre à jour la mémoire, le stockage ou de changer les batteries. Bien sur,  on a gagné sur d’autres postes. Les écrans sont meilleurs, plus lisibles et plus denses en pixels. Des gadgets biométriques sont apparus ainsi que des connectiques intéressantes comme le Thunderbolt 3.0 et l’USB type-C en général. Mais pas sur que 2018 s’en sorte mieux avec cette équation dans la balance que s’en sont sorties les années précédentes.


Spectre et Meltdown vont t-il booster les ventes en 2018 ?

C’est la question à laquelle je réponds en boucle en ce moment. Fournisseurs, fabricants, revendeurs et clients s’interrogent sur les effets de bords de ces graves failles. A vrai dire, la réponse est en demi teinte. Certains vont enfin se poser la question du “PC-de-la-compta-qu’est-toujours-sous-XP”, d’autres vont se dire que c’est l’occasion de voir ce qu’il y a d’autre de disponible aujourd’hui. A condition qu’ils comprennent bien ce qui se passe sur le marché justement.

Car les espoirs de beaucoup peuvent être douchés par le manque d’alternative matérielle à ces failles. Quelle solution capable de contrer Meltdown ou Spectre ? Personne ne va sérieusement abandonner son portable pour monter un PC bricolé sous Raspberry Pi 3 non ? Alors il reste quoi ? Toutes les puces sont impactées, celui qui va en grande surface pour acheter un PC à cause de Spectre ne repartira avec un PC sous le bras que si le vendeur est extrêmement incompétent en lui indiquant que ce dernier ne devrait pas souffrir de ces failles. Il faudra attendre quelque temps avant que des solutions corrigées ne soient disponibles sur le marché. Et il faudra également attendre que les productions actuelles soient écoulées pour que les revendeurs les laissent apparaître à leur catalogue.

Un rebond plus tard dans l’année ? Probablement. Pour des acheteurs craintifs pour leur sécurité. En attendant, on vient de vivre un CES 2018 où la faille Spectre a magnifiquement illustré son nom. Planant au dessus de tous mais parfaitement invisible. Personne n’a communiqué sur ces machines qui sentaient bon le plastique neuf mais qui étaient toutes matériellement vulnérables.


La part du gâteau

Je reste pour ma part toujours aussi étonné par la volonté des marques de ne pas comprendre l’évolution des usages de l’informatique. Si je prends les gammes de portables actuellement en vente en grande distribution, quasiment toutes marques confondues, je vois un panel absolument délirant de machines se battant pour la plus grosse part du gâteau : Le PC de monsieur et madame tout le monde. Celui sans relief mais qui est censé mettre tout le monde d’accord. Celui qui ne fait pas de vague, qui n’a pas de vrai point faible mais qui n’a que des points mous. Celui  qui est décliné à tous les parfums possibles et imaginables.

Un engin avec un peu de mémoire vive, un peu de stockage, des performance moyennes et un affichage classique. On fera tout avec mais rien de manière très poussée. On pourra monter ses films de vacances mais inutile de penser à faire un clip de 15 minutes en UltraHD. On pourra jouer avec mais inutile de penser à faire tourner le dernier jeu 3D  tous détails à fond. On pourra faire de la musique avec mais impossible d’enregistrer et de mixer un album complet.

Bref, c’est la grosse part du gâteau qui est visée, là où tout le monde se bat pour essayer de grappiller 1% de part de marché aux autres chaque année parce que cette part représente des millions d’unités.

Et personne pour regarder que si les expéditions des PC déclinent, c’est parce que les usages de base se sont effectivement déplacés sur les smartphones : Plus personne ne veut de PC mous. On n’allume plus sa machine systématiquement pour surfer ou lire un email. Quand on l’allume, c’est pour des usages plus experts qu’une tablette ou qu’un smartphone ne peuvent pas exécuter.


Qu’est ce qui pourrait sauver le marché PC ? Des usages différents. Plus spécialisés et plus efficaces.

Oh mais que vois-je justement, le secteur en forme du marché qu’est le PC de jeu est un secteur hyper (trop) spécialisé. Des PC ultra chers en croissance, avec pourtant des looks à repousser toutes les ménagères de moins de 150 ans. L’autre secteur qui semble bien fonctionner ? Les PC ultra portables qui se transforment en pseudo tablettes. Encore un marché spécialisé.


Et quoi d’autre ? Des machines comme les solutions de GPD qui permettent à la marque de lever des millions de dollars dans les pires conditions de vente qui soient. Des engins hyper spécialisés qui réussissent à fédérer des centaines de clients. La marque vient tout juste de lancer un nouveau financement participatif. La GPD Win 2, un engin minuscule qui ne vise pas la grosse part du gâteau mais une niche d’acheteurs. La marque récolte déjà la mise. En quelques heures, c’est près d’un million de dollars qui sont investis dans ce projet par des particuliers. Les précédentes expérimentations de la marque se sont aussi bien vendues avec un modèle économique encore une fois basé sur autre chose que sur la machine de monsieur et madame tout le monde. Leur précédent PC du genre, le GPD Pocket, a levé 3.5 millions de dollars dans les mêmes conditions l’année dernière avant d’atterrir dans les magasins pour une distribution classique.


Lâcher les 649$ demandés par GPD dans un système de financement participatif pour voir la machine débarquer – si tout va bien – en Mai 2018, c’est plus que de l’investissement. C’est du courage désespéré. Les solutions de GPD ne se battent contre personne, la part du gâteau est très mince mais ils sont tout seuls à la proposer et évidemment, ils font forcément mouche. Vous imaginez la même machine proposée par une marque comme HP ou Lenovo avec leur réseau de distribution ? Disponible immédiatement en magasin ? Quelles ventes espérer pour un engin de ce type dans ces conditions ?

Acer Swift 7 2018

L’Acer Swift 7 2018, son argument principal : 9 mm d’épaisseur pour 14″ de diagonale.

Le pire dans cette histoire c’est que le retour en arrière va être très difficile pour les constructeurs. A force de vanter la finesse comme seul argument fort pour leurs engins au détriment de tout le reste, les marques se retrouvent enfermées dans un véritable piège. Leurs machines ne peuvent plus évoluer en terme de performances. Coincés qu’ils sont dans cette course absurde d’être toujours plus minces pour épater la galerie, les portable ne peuvent plus espérer accueillir des processeurs plus puissants. La seule issue est donc de réduire la voilure encore et encore. De passer de 9 à 8 mm d’épaisseur d’une année sur l’autre. Puis de se remettre au travail pour atteindre les 7 mm ou les 6. Peut importe, après tout cela ne change rien à l’usage de la machine. Plus elle sort des composants de son châssis, plus puisqu’à 7 mm, il n’est plus possible de coller un port USB plein format, plus possible de lui glisser un port HDMI classique ou encore moins un port Ethernet, plus il faut rajouter des ports externes via des adaptateurs. Mais il n’est plus non plus possible de monter en fréquence et en possibilités de calcul. Les machines s’affinent et finalement les usages baissent.

Il est temps que les constructeurs réfléchissent au marché différemment. Qu’ils arrêtent de proposer du plus “beau” ou des arguments de vente à court terme et se réapproprient ce qui a fait le succès du monde PC depuis toujours, sa réalité. C’est un outil. Un outil qui a longtemps été considéré comme un outil à tout faire et qu’il faut désormais spécialiser un peu plus pour séduire.

Les ingrédients sont là, il existe une tonne de possibilités pour fabriquer des machines dédiées à des usages plus orientés. Les marques ont su le faire pour le jeu car c’était l’évidence. Pourquoi ne pas le faire pour la création 3D ? La musique ? La retouche d’image ou la création de vidéo. Pourquoi ne pas proposer du fanless systématiquement dans les machines dédiées à la bureautique ou au web ? Pourquoi disposer d’un énorme chaudron de milliers d’ingrédients et y plonger toujours la même louche ? Pourquoi produire d’une marque à l’autre des machines quasi identiques ? Démarquez-vous, c’est à c’est à cela que vous devez servir.

Baisse du marché PC : Un marché qui s’entête dans les mêmes erreurs © 2017

21 Jan 19:15

Everything you need to know about HTTP security headers

Some physicists 28 years ago needed a way to easily share experimental data and thus the web was born. This was generally considered to be a good move. Unfortunately, everything physicists touch — from trigonometry to the strong nuclear force — eventually becomes weaponized and so too has the Hypertext Transfer Protocol.

What can be attacked must be defended, and since tradition requires all security features to be a bolted-on afterthought, things… got a little complicated.

This article explains what secure headers are and how to implement these headers in Rails, Django, Express.js, Go, Nginx, Apache and Varnish.

Please note that some headers may be best configured in on your HTTP servers, while others should be set on the application layer. Use your own discretion here. You can test how well you’re doing with Mozilla’s Observatory.

Did we get anything wrong? Contact us at [email protected].

HTTP Security Headers


X-XSS-Protection: 0;
X-XSS-Protection: 1;
X-XSS-Protection: 1; mode=block


Cross Site Scripting, commonly abbreviated XSS, is an attack where the attacker causes a page to load some malicious javascript. X-XSS-Protection is a feature in Chrome and Internet Explorer that is designed to protect against “reflected” XSS attacks — where an attacker is sending the malicious payload as part of the request1.

X-XSS-Protection: 0 turns it off.
X-XSS-Protection: 1 will filter out scripts that came from the request - but will still render the page
X-XSS-Protection: 1; mode=block when triggered, will block the whole page from being rendered.

Should I use it?

Yes. Set X-XSS-Protection: 1; mode=block. The “filter bad scripts” mechanism is problematic; see here for why.


Platform What do I do?
Rails 4 and 5 On by default
Express.js Use helmet
Go Use unrolled/secure
Nginx add_header X-XSS-Protection "1; mode=block";
Apache Header always set X-XSS-Protection "1; mode=block"
Varnish set resp.http.X-XSS-Protection = "1; mode=block";

I want to know more

X-XSS-Protection - MDN

Content Security Policy

Content-Security-Policy: <policy>


Content Security Policy can be thought of as much more advanced version of the X-XSS-Protection header above. While X-XSS-Protection will block scripts that come from the request, it’s not going to stop an XSS attack that involves storing a malicious script on your server or loading an external resource with a malicious script in it.

CSP gives you a language to define where the browser can load resources from. You can white list origins for scripts, images, fonts, stylesheets, etc in a very granular manner. You can also compare any loaded content against a hash or signature.

Should I use it?

Yes. It won’t prevent all XSS attacks, but it’s a significant mitigation against their impact, and an important aspect of defense-in-depth. That said, it can be hard to implement. If you’re an intrepid reader and went ahead and checked the headers returns2, you’ll see that we don’t have CSP implemented yet. There are some rails development plugins we’re using that are holding us back from a CSP implementation that will have an actually security impact. We’re working on it, and will write about it in the next instalment!


Writing a CSP policy can be challenging. See here for a list of all the directives you can employ. A good place to start is here.

Platform What do I do?
Rails 4 and 5 Use secureheaders
Django Use django-csp
Express.js Use helmet/csp
Go Use unrolled/secure
Nginx add_header Content-Security-Policy "<policy>";
Apache Header always set Content-Security-Policy "<policy>"
Varnish set resp.http.Content-Security-Policy = "<policy>";

I want to know more

HTTP Strict Transport Security (HSTS)

Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload


When we want to securely communicate with someone, we face two problems. The first problem is privacy; we want to make sure the messages we send can only be read by the recipient, and no one else. The other problem is that of authentication: how do we know the recipient is who they say they are?

HTTPS solves the first problem with encryption, though it has some major issues with authentication (more on this later, see Public Key Pinning). The HSTS header solves the meta-problem: how do you know if the person you’re talking to actually supports encryption?

HSTS mitigates an attack called sslstrip. Suppose you’re using a hostile network, where a malicious attacker controls the wifi router. The attacker can disable encryption between you and the websites you’re browsing. Even if the site you’re accessing is only available over HTTPS, the attacker can man-in-the-middle the HTTP traffic and make it look like the site works over unencrypted HTTP. No need for SSL certs, just disable the encryption.

Enter the HSTS. The Strict-Transport-Security header solves this by letting your browser know that it must always use encryption with your site. As long as your browser has seen an HSTS header — and it hasn’t expired — it will not access the site unencrypted, and will error out if it’s not available over HTTPS.

Should I use it?

Yes. Your app is only available over HTTPS, right? Trying to browse over regular old HTTP will redirect to the secure site, right? (Hint: Use letsencrypt if you want to avoid the racket that are commercial certificate authorities.)

The one downside of the HSTS header is that it allows for a clever technique to create supercookies that can fingerprint your users. As a website operator, you probably already track your users somewhat - but try to only use HSTS for good and not for supercookies.


The two options are

  • includeSubDomains - HSTS applies to subdomains
  • preload - Google maintains a service that hardcodes3 your site as being HTTPS only into browsers. This way, a user doesn’t even have to visit your site: their browser already knows it should reject unencrypted connections. Getting off that list is hard, by the way, so only turn it on if you know you can support HTTPS forever on all your subdomains.
Platform What do I do?
Rails 4 config.force_ssl = trueDoes not include subdomains by default. To set it:

config.ssl_options = { hsts: { subdomains: true } }

Rails 5 config.force_ssl = true
Django SECURE_HSTS_SECONDS = 31536000
Express.js Use helmet
Go Use unrolled/secure
Nginx add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; ";
Apache Header always set Strict-Transport-Security "max-age=31536000; includeSubdomains;
Varnish set resp.http.Strict-Transport-Security = "max-age=31536000; includeSubdomains; ";

I want to know more

HTTP Public Key Pinning (HPKP)

Public-Key-Pins: pin-sha256=<base64==>; max-age=<expireTime>;
Public-Key-Pins: pin-sha256=<base64==>; max-age=<expireTime>; includeSubDomains
Public-Key-Pins: pin-sha256=<base64==>; max-age=<expireTime>; report-uri=<reportURI>


The HSTS header described above was designed to ensure that all connections to your website are encrypted. However, nowhere does it specify what key to use!

Trust on the web is based on the certificate authority (CA) model. Your browser and operating system ship with the public keys of some trusted certificate authorities which are usually specialized companies and/or nation states. When a CA issues you a certificate for a given domain that means anyone who trusts that CA will automatically trust the SSL traffic you encrypt using that certificate. The CAs are responsible for verifying that you actually own a domain (this can be anything from sending an email, to asking you to host a file, to investigating your company).

Two CAs can issue a certificate for the same domain to two different people, and browsers will trust both. This creates a problem, especially since CAs can be and are compromised. This allows attackers to MiTM any domain they want, even if that domain uses SSL & HSTS!

The HPKP header tries to mitigate this. This header lets you to “pin” a certificate. When a browser sees the header for the first time, it will save the certificate. For every request up to max-age, the browser will fail unless at least one certificate in the chain sent from the server has a fingerprint that was pinned.

This means that you can pin to the CA or a intermediate certificate along with the leaf in order to not shoot yourself in the foot (more on this later).

Much like HSTS above, the HPKP header also has some privacy implications. These were laid out in the RFC itself.

Should I use it?

Probably not.

HPKP is a very very sharp knife. Consider this: if you pin to the wrong certificate, or you lose your keys, or something else goes wrong, you’ve locked your users out of your site. All you can do is wait for the pin to expire.

This article lays out the case against it, and includes a fun way for attackers to use HPKP to hold their victims ransom.

One alternative is using the Public-Key-Pins-Report-Only header, which will just report that something went wrong, but not lock anyone out. This allows you to at least know your users are being MiTMed with fake certificates.


The two options are

  • includeSubDomains - HPKP applies to subdomains
  • report-uri - Inavlid attempts will be reported here

You have to generate a base64 encoded fingerprint for the key you pin to, and you have to use a backup key. Check this guide for how to do it.

Platform What do I do?
Rails 4 and 5 Use secureheaders
Django Write custom middleware
Express.js Use helmet
Go Use unrolled/secure
Nginx add_header Public-Key-Pins 'pin-sha256="<primary>"; pin-sha256="<backup>"; max-age=5184000; includeSubDomains';
Apache Header always set Public-Key-Pins 'pin-sha256="<primary>"; pin-sha256="<backup>"; max-age=5184000; includeSubDomains';
Varnish set resp.http.Public-Key-Pins = "pin-sha256="<primary>"; pin-sha256="<backup>"; max-age=5184000; includeSubDomains";

I want to know more


X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM


Before we started giving dumb names to vulnerabilities, we used to give dumb names to hacking techniques. “Clickjacking” is one of those dumb names.

The idea goes like this: you create an invisible iframe, place it in focus and route user input into it. As an attacker, you can then trick people into playing a browser-based game while their clicks are being registered by a hidden iframe displaying twitter - forcing them to non-consensually retweet all of your tweets.

It sounds dumb, but it’s an effective attack.

Should I use it?

Yes. Your app is a beautiful snowflake. Do you really want some genius shoving it into an iframe so they can vandalize it?


X-Frame-Options has three modes, which are pretty self explanatory.

  • DENY - No one can put this page in an iframe
  • SAMEORIGIN - The page can only be displayed in an iframe by someone on the same origin.
  • ALLOW-FROM - Specify a specific url that can put the page in an iframe

One thing to remember is that you can stack iframes as deep as you want, and in that case, the behavior of SAMEORIGIN and ALLOW-FROM isn’t specified. That is, if we have a triple-decker iframe sandwich and the innermost iframe has SAMEORIGIN, do we care about the origin of the iframe around it, or the topmost one on the page? ¯\_(ツ)_/¯.

Platform What do I do?
Rails 4 and 5 SAMEORIGIN is set by default.

To set DENY:

config.action_dispatch.default_headers['X-Frame-Options'] = "DENY"
Django MIDDLEWARE = [ ... 'django.middleware.clickjacking.XFrameOptionsMiddleware', ... ]
This defaults to SAMEORIGIN.


Express.js Use helmet
Go Use unrolled/secure
Nginx add_header X-Frame-Options "deny";
Apache Header always set X-Frame-Options "deny"
Varnish set resp.http.X-Frame-Options = "deny";

I want to know more


X-Content-Type-Options: nosniff;


The problem this header solves is called “MIME sniffing”, which is actually a browser “feature”.

In theory, every time your server responds to a request it is supposed to set a Content-Type header in order to tell the browser if it’s getting some HTML, a cat gif, or a Flash cartoon from 2008. Unfortunately, the web has always been broken and has never really followed a spec for anything; back in the day lots of people didn’t bother to set the content type header properly.

As a result, browser vendors decided they should be really helpful and try to infer the content type by inspecting the content itself while completely ignore the content type header. If it looks like a gif, display a gif!, even though the content type is text/html. Likewise, if it looks like we got some HTML, we should render it as such even if the server said it’s a gif.

This is great, except when you’re running a photo-sharing site, and users can upload photos that look like HTML with javascript included, and suddenly you have a stored XSS attack on your hand.

The X-Content-Type-Options headers exist to tell the browser to shut up and set the damn content type to what I tell you, thank you.

Should I use it?

Yes, just make sure to set your content types correctly.


Platform What do I do?
Rails 4 and 5 On by default
Express.js Use helmet
Go Use unrolled/secure
Nginx add_header X-Content-Type-Options nosniff;
Apache Header always set X-Content-Type-Options nosniff
Varnish set resp.http.X-Content-Type-Options = "nosniff";

I want to know more


Referrer-Policy: "no-referrer" Referrer-Policy: "no-referrer-when-downgrade" Referrer-Policy: "origin" Referrer-Policy: "origin-when-cross-origin"
Referrer-Policy: "same-origin" Referrer-Policy: "strict-origin" Referrer-Policy: "strict-origin-when-cross-origin" Referrer-Policy: "unsafe-url"


Ah, the Referer header. Great for analytics, bad for your users’ privacy. At some point the web got woke and decided that maybe it wasn’t a good idea to send it all the time. And while we’re at it, let’s spell “Referrer” correctly4.

The Referrer-Policy header allows you to specify when the browser will set a Referer header.

Should I use it?

It’s up to you, but it’s probably a good idea. If you don’t care about your users’ privacy, think of it as a way to keep your sweet sweet analytics to yourself and out of your competitors’ grubby hands.

Set Referrer-Policy: "no-referrer"


Platform What do I do?
Rails 4 and 5 Use secureheaders
Django Write custom middleware
Express.js Use helmet
Go Write custom middleware
Nginx add_header Referrer-Policy "no-referrer";
Apache Header always set Referrer-Policy "no-referrer"
Varnish set resp.http.Referrer-Policy = "no-referrer";

I want to know more

Cookie Options

Set-Cookie: <key>=<value>; Expires=<expiryDate>; Secure; HttpOnly; SameSite=strict


This isn’t a security header per se, but there are three different options for cookies that you should be aware of.

  • Cookies marked as Secure will only be served over HTTPS. This prevents someone from reading the cookies in a MiTM attack where they can force the browser to visit a given page.

  • HttpOnly is a misnomer, and has nothing to do with HTTPS (unlike Secure above). Cookies marked as HttpOnly can not be accessed from within javascript. So if there is an XSS flaw, the attacker can’t immediately steal the cookies.

  • SameSite helps defend against Cross-Origin Request Forgery (CSRF) attacks. This is an attack where a different website the user may be visiting inadvertently tricks them into making a request against your site, i.e. by including an image to make a GET request, or using javascript to submit a form for a POST request. Generally, people defend against this using CSRF tokens. A cookie marked as SameSite won’t be sent to a different site.

It has two modes, lax and strict. Lax mode allows the cookie to be sent in a top-level context for GET requests (i.e. if you clicked a link). Strict doesn’t send any third-party cookies.

Should I use it?

You should absolutely set Secure and HttpOnly. Unfortunately, as of writing, SameSite cookies are available only in Chrome and Opera, so you may want to ignore them for now.


Platform What do I do?
Rails 4 and 5 Secure and HttpOnly enabled by default. For SameSite, use secureheaders
Django Session cookies are HttpOnly by default. To set secure: SESSION_COOKIE_SECURE = True.

Not sure about SameSite.

Express.js cookie: { secure: true, httpOnly: true, sameSite: true }
Go http.Cookie{Name: "foo", Value: "bar", HttpOnly: true, Secure: true}

For SameSite, see this issue.

Nginx You probably won’t set session cookies in Nginx
Apache You probably won’t set session cookies in Apache

I want to know more

Thanks to @wolever for python advice.

Thanks to Guillaume Quintard for Varnish comands.

21 Jan 17:09

Never accept an MDM policy on your personal phone

by Christopher Demicoli
Never accept an MDM policy on your personal phone

In this new age of BYOD (Bring Your Own Device), employees can bring personally owned devices (laptops, tablets, smartphones, etc...) to their workplace, and to use those devices to access privileged company information and applications. The intent of MDM is to optimize the functionality and security of these devices while minimizing cost and downtime.

MDM stands for Mobile Device Management, and is a way to ensure employees stay productive and do not breach corporate policies. There are various MDM solutions available, but the most common ones right now are:

  • Google Apps Mobile Managment
  • VMware AirWatch
  • IBM MaaS360
  • Microsoft Intune

In essence, there is nothing wrong with MDM. In fact, I would say, it is a vital part of the infrastructure to keep an organization's data secure. However, this comes at a cost: it invades your personal privacy.

Invasion of Personal Privacy

Once an MDM Policy is installed on your phone, regardless of which third-party software you are using, it has the highest privileges on your phone if you're using Android (Device Administrator) or Supervised mode in iOS.

Some policies are configured server-side and can be pushed any time to your phone without consent or notification. So, yes, an organization may state that even though they are installing an MDM policy on your phone, they are only going to use it for creating a separate work profile and enforcing a password policy. Except, there is no way to verify that and to stop them from changing that in the future.

How does it invade your privacy?

One of the big advantages of MDM, is that users do not even know how much the administrator actually knows.

Depending if you have an Android or Supervised iOS phone, once an MDM Policy is installed on your phone, administrators may:

  • Track your phone (and you) in real-time by using the phone's GPS on Android and some iOS MDMs
  • Read text messages (on Android) by deploying routing text messages through an SMS Gateway
  • See private photos and videos, at least, by intercepting your cloud backups through VPN and organization forced SSL Decryption (both on unsupervised iOS and Android)
  • Check your browsing history, same as above
  • Browse list of Apps Available on your phone such as dating applications on Androids
  • Perform an SSL MITM Attack which exposes your banking details, private conversations, credit card information, medical searches and all of your internet traffic through VPN and organization forced SSL Decryption (both on unsupervised iOS and Android)
  • Stop you from rooting/jailbreaking your personal phone
  • Remotely wipe your personal phone whenever they feel there is a need
  • Remotely lock your personal phone whenever they feel there is a need
  • Restrict or disable backups like iCloud.
  • Force you to stop using some apps

As you can see, once an MDM Policy is installed on your personal phone, your phone is no longer yours.

As some people on reddit have pointed out, iOS and Android handle MDM very differently, with iOS being more sensitive towards user privacy. On iOS, to achieve most of these things, you phone has to be supervised, which would mean a total wipe of your personal phone.

Yes, organizations will often use the excuse that although they know they can perform all this, they won't and that you have to trust them. You shouldn't. Even if you actually trust your sysadmins:

  • Your organization's policies might change in the future
  • Your sysadmins might change in the future
  • Your organization might force sysadmins to do stuff
  • Your sysadmins might get compromised
  • Their systems might get compromised

So, in essence, it is irrelevant which of these spying features your organization promises not to use, once an MDM profile is installed, they can do whatever they want and it's just humans that dictate where the line should be drawn.

There is no outcome in which it is worthwhile for someone to accept an MDM policy on his personal phone.

What is the solution?

I believe that the solution to this is quite simple. If the company has a strict policy on their data, it is irresponsible of you to keep your organization's data on your personal phone without the company having handle on that data. This means remove all your emails, chats, pictures of whiteboards, passwords and everything that is your organization's property.

However, this doesn't mean that you should allow your organization to invade your personal privacy just because you need to have company data on your phone; just get a company phone.

According to a report by bitglass, which examined perspectives on BYOD gathered from 2,242 end users and mobile security administrators, 57 percent of employees and 38 percent of IT professionals chose not to participate in BYOD programs because they did not want their employer’s IT department to have visibility into their personal data and applications.

What's more, employee privacy represents a significant issue in more than a third of organizations that had deployed MDM or MAM solutions. Privacy is even an issue for security administrators - while many IT leaders want the same freedom to access corporate data from personal devices 40% chose not to participate in the very mobile policies they were helping their organisations enforce.

Never accept an MDM policy on your personal phone


BYOD to work is not going away anytime soon, but someone needs to have a serious look at how the both can co-exist together without invading user privacy.

Personally, unless the MDM Specifications change to block these privacy invading techniques at the lowest level possible, I will never trust an MDM policy on my phone, and so should you!

21 Jan 13:44

Une limite à CRISPR ?

by Rémi Sussan

Se pourrait-il que CRISPR, la nouvelle technologie d’ingénierie génétique au potentiel révolutionnaire, soit moins efficace qu’on ne le pense ? En tout cas, chez les humains. C’est ce que suggère la Technology Review, qui a repéré un papier sur le sujet dans Biorxiv.

En cause, la protéine cas9 qui sert de « ciseau » dans le processus CRISPR (pour voir comment fonctionne cette technologie, le plus simple est de regarder ces courtes vidéos). En effet, cet enzyme est présent au sein de deux bactéries très répandues, S. aureus et S. pyogenes. En conséquence les personnes infectées possèdent des anticorps contre cette molécule. Les chercheurs ont effectué un test sur des échantillons sanguins de 22 nouveaux nés et douze adultes, et ont découvert la présence de ces anticorps dans 65 % des cas. Cela pourrait rendre la thérapie inefficace, et serait même susceptible, selon les auteurs du papier, de « se révéler d’une toxicité significative pour les patients ».

Faut-il abandonner tout espoir d’application de CRISPR aux humains ? Pas forcément car Cas9 n’est pas le seul candidat pour les possibles « ciseaux ». Il existe, précise la Technology Review, des systèmes CRISPR susceptibles d’être découverts au sein de bactéries bien plus rares et qui ont peu infecté des personnes. Et il serait aussi possible continue la revue, de « sortir » des cellules de l’organisme, de les traiter avec CRISPR loin de tout anticorps, puis de les réinjecter dans le corps du patient.

21 Jan 13:17

The Effective Remote Developer (video+slides)

David Copeland talks about what one can do to be at their best as a remote team member, as well as what one needs from environment, team, and company. It's not about technical stuff—it's the human stuff. He also talks about how one can be present and effective when not physically there.
21 Jan 13:17

[video] CppCon 2017: David Sankel “So, you inherited a large code base...”

This is a talk about solving the most difficult problem a software engineer ever faces, converting a large codebase with antiquated designs and spotty quality into a state-of-the-art, modern system. We'll be covering clang-based refactoring, mnemonic reasoning methods, safe rewrites, coding standards, and, oh yes, migration paths. If you've ever been tasked with making a legacy codebase the best-in-class, or think you might, then this talk is for you. — David Sankel: Bloomberg David Sankel is a professional software developer/architect based in the USA and an active member of the C++ Standardization Committee. His prolific software developments have included CAD/CAM, computer graphics, visual programming languages, web applications, computer vision, and cryptography. He is a frequent speaker at the C++Now conferences and is especially well known for his advanced functional programming in C++ talks. David’s interests include large-scale development, dependently typed languages, semantic domains, EDSLs, and functional reactive programming. David's current research interests include dependently typed languages, semantic domains, EDSLs, and functional reactive programming. He currently works for Bloomberg.
21 Jan 11:52

Virement : un simple numéro de téléphone pour remplacer l’IBAN, c’est pour bientôt

by Olivier
Les services bancaires connaissent actuellement une vraie révolution. Les néobanques poussent comme des champignons et elles ont bien l’intention de […]
21 Jan 11:26

Littlewing : Améliorer le Boot sous Debian 9

by Littlewing

Je ne sais pas trop ce qui m’a pris, je me suis mis en tête d’ optimiser la durée du boot de mon PC équipé de Debian 9.3.

J’en été resté à l’utilisation de bootchart qui était pas mal mais pas pratique du tout. Aujourd’hui, heureusement, il y a systemd.

Voici les quelques commandes qui m’ont servis à optimiser ( un tout petit peu ) mon boot

Récupérer le temps du boot

$ systemd-analyze time
Startup finished in 2.187s (kernel) + 8.919s (userspace) = 11.107s

Voir le temps de démarrage des services

$ systemd-analyze blame
8.096s NetworkManager-wait-online.service
           964ms networking.service
           264ms colord.service
           216ms dev-sda1.device
           162ms systemd-timesyncd.service
            87ms ModemManager.service
            82ms autofs.service
            79ms NetworkManager.service
            75ms keyboard-setup.service
            72ms systemd-fsck@dev-disk-by\\x2duuid-7b7fe11e\\x2dfe4f\\x2d4c8f\\x2da71f\\x2d39a6298428d5.service
            67ms accounts-daemon.service
            45ms systemd-udevd.service
            45ms bluetooth.service
            44ms systemd-modules-load.service
            42ms systemd-udev-trigger.service
            37ms geoclue.service
            37ms packagekit.service
            36ms upower.service
            36ms systemd-journald.service

Analyser le chemin critique ( c.-à-d. voir où ça coince )

$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character. @8.907s
└─ @8.907s
  └─autofs.service @8.823s +82ms
    └─ @8.821s
      └─NetworkManager-wait-online.service @724ms +8.096s
        └─NetworkManager.service @644ms +79ms
          └─dbus.service @616ms
            └─ @615ms
              └─ @615ms
                └─dbus.socket @615ms
                  └─ @612ms
                    └─systemd-backlight@backlight:acpi_video0.service @1.079s +7
                      └─system-systemd\\x2dbacklight.slice @1.079s
                        └─system.slice @125ms
                          └─-.slice @114ms

Récupérer un graphique du boot

$ systemd-analyze plot > plot.svg

Désactivation des services inutiles ( du moins au boot )

Par exemple, j’ai désactivé mongodb et virtualbox du démarrage

$ systemctl disable vboxdrv.service
$ systemctl disable vboxballoonctrl-service.service
$ systemctl disable vboxweb-service.service
$ systemctl disable mongodb.service

Analyser les logs d’un service

$ journalctl -b -u NetworkManager.service


Je n’ai pas encore réussi à optimiser le démarrage du network manager. ça prend quand même 8 secondes. Ce n’est pas trop la mort, mais bon en ce moment, je ne vois pas trop comment mieux. Le gros est dans la négociation DHCP et je ne souhaite pas mettre une IP fixe.










Gravatar de Littlewing
Original post of Littlewing.Votez pour ce billet sur Planet Libre.

20 Jan 13:08

Comment optimiser simplement le Wi-Fi de votre box Internet

François BEDIN



Comment optimiser simplement le Wi-Fi de votre box Internet

Inscrivez-vous à la Newsletter Actualités

11 Jan 16:23

When Somebody Texts You [Comic]

by Geeks are Sexy

Did you know that dropping a full stop at the end of a sentence when texting can add a negative meaning to your message?

[Source: Einstein’s mama on Facebook]

The post When Somebody Texts You [Comic] appeared first on Geeks are Sexy Technology News.

11 Jan 14:28

Multiplicative Idiocy

by Matthew Inman
Multiplicative Idiocy

An immutable law of design.

View on my website

10 Jan 20:26

What's the difference between data science, machine learning, and artificial intelligence?

by /u/variance_explained
10 Jan 20:02

Wi-Fi security overhaul coming with WPA3

by John E Dunn
Nearly 14 years after it ratified the Wireless Protected Access 2 (WPA2), the Wi-Fi Alliance has given the world a peek at what might be coming next for wireless security.
10 Jan 19:55

Limitation de vitesse à 80 km/h : les fondements scientifiques d'une mesure

by Erwan Lecomte
La réduction de la limite maximale de vitesse de 90 à 80 km/h sur le réseau routier secondaire en France a été annoncée le 9 janvier 2018 à l'issue d'un comité interministériel de sécurité routière. Sciences et Avenir fait le point sur un débat houleux.
01 Jan 18:10

Agile is bullsh*t

by /u/RobertVandenberg
01 Jan 18:02

Say hello to security.txt

by Scott Helme
Say hello to security.txt

Security is a difficult process and organisations don't always get it right, I think everyone can agree on that. What's important though is that when things inevitably do go wrong, those who want to contact you and let you know there is a problem can do so quickly and easily. This is what security.txt aims to allow.

Responsible Disclosure

I've been doing security research for a few years now and in that time I've had to reach out and contact numerous organisations to let them know they have a serious problem. I've found issues in ISP issued hardware like the EE BrightBox router (twice), holiday booking websites like Hotel Hippo and even utility providers like Ecotricity. Bad things happen and organisations need to respond quickly to resolve them but one things that's always slowed down the process was me not being able to find who I should speak to. I've been through call centres, online chats, support tickets systems, social media and who knows what else just to try and raise an issue with the right person. The process is a nightmare, consumes significant amounts of my time and ultimately leaves the website and users vulnerable for even longer. I'd love a simple way to be able to know who to contact in such incidents, and now we have one.


The security.txt file is a simple text file, much like robots.txt, that contains crucial information on who to contact or where to look for security related information about a website. You can read the RFC and check out the website for more details. Here are the contents of security.txt on my blog:


That simple little piece of information gives a researcher exactly the information they need should they ever want to contact me. I also have the same files setup on Security Headers and Report URI. You can see all of my files at their addresses here:

The file is only supposed to be in the /.well-known/ path but I figured I'd put them alongside robots.txt in the root too for good measure. If you or your organisation do have an email address that should be used for reporting security related matters then I'd highly recommend setting up a security.txt file. It's simple and easy to do, it's really not going to cost anything and it could save crucial time in the event of a researcher needing to get through to the appropriate person to report a serious problem. I did try to add a check to my crawler fleet to look for security.txt in the official /.well-known/ path but boy is there a lot of weird stuff going on out there!

The security.txt file hasn't been around long and there are already some really weird configurations out there! Here's a few:

— Scott Helme (@Scott_Helme) January 1, 2018

For now I need to find a better way of reliably detecting a proper security.txt file but the raw data is available in my crawler data if you're interested.

29 Dec 19:52

Wumo 14. Dec 2017

29 Dec 19:47

Concours de la photo animale la plus amusante de 2017 : et le gagnant est…

by Ophelie B.

Il y a un mois, nous vous présentions les finalistes du Comedy Wildlife Photogragraphy dans la catégorie photo animale la plus drôle de 2017. Fort de son succès, le collectif avait réitéré son concours lancé en 2015 qui rassemble toujours plus d’adeptes. Cette année encore, les photos lauréates sont à hurler de rire !

10. Mudskippers Got Talent de Daniel Trim

9. WTF de George Cathcart

8. Hitching A Ride de Daisy Gilardini

7. Must Have Three-Putted de Douglas Croft

6. Caught in the Act de Bence Mate

5. All Dressed and Ready fort Church de Carl Henry

4. Slap de Troy Mayne

3. Duck Speed de John Threlfall

2. The Laughing Dormouse de Andrea Zampatti

1. Help de Tibor Kerccz

L’article Concours de la photo animale la plus amusante de 2017 : et le gagnant est… est apparu en premier sur GOLEM13.FR.

29 Dec 19:41

The Real Cause of Extinction

29 Dec 19:36

No boundaries for user identities: Web trackers exploit browser login managers

In this second installment of the No Boundaries series, we show how a long-known vulnerability in browsers’ built-in password managers is abused by third-party scripts for tracking on more than a thousand sites.

by Gunes Acar, Steven Englehardt, and Arvind Narayanan

We show how third-party scripts exploit browsers’ built-in login managers (also called password managers) to retrieve and exfiltrate user identifiers without user awareness. To the best of our knowledge, our research is the first to show that login managers are being abused by third-party scripts for the purposes of web tracking.

The underlying vulnerability of login managers to credential theft has been known for years. Much of the past discussion has focused on password exfiltration by malicious scripts through cross-site scripting (XSS) attacks. Fortunately, we haven’t found password theft on the 50,000 sites that we analyzed. Instead, we found tracking scripts embedded by the first party abusing the same technique to extract emails addresses for building tracking identifiers.

The image above shows the process. First, a user fills out a login form on the page and asks the browser to save the login. The tracking script is not present on the login page [1]. Then, the user visits another page on the same website which includes the third-party tracking script. The tracking script inserts an invisible login form, which is automatically filled in by the browser’s login manager. The third-party script retrieves the user’s email address by reading the populated form and sends the email hashes to third-party servers.

You can test the attack yourself on our live demo page.

We found two scripts using this technique to extract email addresses from login managers on the websites which embed them. These addresses are then hashed and sent to one or more third-party servers. These scripts were present on 1110 of the Alexa top 1 million sites. The process of detecting these scripts is described in our measurement methodology in the Appendix 1. We provide a brief analysis of each script in the sections below.

Why does the attack work? All major browsers have built-in login managers that save and automatically fill in username and password data to make the login experience more seamless. The set of heuristics used to determine which login forms will be autofilled varies by browser, but the basic requirement is that a username and password field be available.

Login form autofilling in general doesn’t require user interaction; all of the major browsers will autofill the username (often an email address) immediately, regardless of the visibility of the form. Chrome doesn’t autofill the password field until the user clicks or touches anywhere on the page. Other browsers we tested [2] don’t require user interaction to autofill password fields.

Thus, third-party javascript can retrieve the saved credentials by creating a form with the username and password fields, which will then be autofilled by the login manager.

Why collect hashes of email addresses? Email addresses are unique and persistent, and thus the hash of an email address is an excellent tracking identifier. A user’s email address will almost never change — clearing cookies, using private browsing mode, or switching devices won’t prevent tracking. The hash of an email address can be used to connect the pieces of an online profile scattered across different browsers, devices, and mobile apps. It can also serve as a link between browsing history profiles before and after cookie clears. In a previous blog post on email tracking, we described in detail why a hashed email address is not an anonymous identifier.

Scripts exploiting browser login managers
List of sites embedding scripts that abuse login manager for tracking
Smart Advertising Performance” and “Big Data Marketing” are the taglines used by the two companies who own the scripts that abuse login managers to extract email addresses. We have manually analyzed the scripts that contained the attack code and verified the attack steps described above. The snippets from the two scripts are given in Appendix 2.

The scripts that use login manager to extract email addresses present on a total of 1110 of the top 1 Million Alexa sites.

The scripts that use login manager to extract email addresses present on a total of 1110 of the top 1 Million Alexa sites.

Adthink ( After injecting an invisible form and reading the email address, Adthink script sends MD5, SHA1 and SHA256 hashes of the email address to its server ( Adthink then triggers another request containing the MD5 hash of the email to data broker Acxiom (

The Adthink script contains very detailed categories for personal, financial, physical traits, as well as intents, interests and demographics. It is hard to comment on the exact use of these categories but it gives a glimpse of what our online profiles are made up of:

The categories mentioned in the Adthink script include detailed personal, financial, physical traits, as well as intents, interests and demographics (Link to the code snippet).
birth date, age, gender, nationality, height, weight, BMI (body mass index), hair_color (black, brown, blond, auburn, chestnut, red, gray, white), eye_color (amber, blue, brown, grey, green), education, occupation, net_income, raw_income, relationship states, seek_for_gender (m, f, transman, transwoman, couple), pets, location (postcode, town, state, country), loan (type, amount, duration, overindebted), insurance (car, motorbike, home, pet, health, life), card_risk (chargeback, fraud_attempt), has_car(make, model, type, registration, model year, fuel type), tobacco, alcohol, travel (from, to, departure, return), car_hire_driver_age, hotel_stars

OnAudience ( The OnAudience script is most commonly present on Polish websites, including newspapers, ISPs and online retailers. 45 of the 63 sites that contain OnAudience script have “.pl” country code top-level domain.

The script sends the MD5 hash of the email back to its server after reading it through the login manager. OnAudience script also collects browser features including plugins, MIME types, screen dimensions, language, timezone information, user agent string, OS and CPU information. The script then generates a hash based on this browser fingerprint. OnAudience claims to use anonymous data only, but hashed email addresses are not anonymous. If an attacker wants to determine whether a user is in the dataset, they can simply hash the user’s email address and search for records associated with that hash. For a more detailed discussion, see our previous blog post.

OnAudience marketing material that advertises "billions of user profiles".

OnAudience marketing material that advertises “billions of user profiles”.

Is this attack new? This and similar attacks have been discussed in a number of browser bug reports and academic papers for at least 11 years. Much of the previous discussion focuses on the security implications of the current functionality, and on the security-usability tradeoff of the autofill functionality.

Several researchers showed that it is possible to steal passwords from login managers through cross-site scripting (XSS) attacks [3,4,5,6,7]. Login managers and XSS is a dangerous mixture for two reasons: 1) passwords retrieved by XSS can have more devastating effects compared to cookie theft, as users commonly reuse passwords across different sites; 2) login managers extend the attack surface for the password theft, as an XSS attack can steal passwords on any page within a site, even those which don’t contain a login form.

How did we get here? You may wonder how a security vulnerability persisted for 11 years. That’s because from a narrow browser security perspective, there is no vulnerability, and everything is working as intended. Let us explain.

The web’s security rests on the Same Origin Policy. In this model, scripts and content from different origins (roughly, domains or websites) are treated as mutually untrusting, and the browser protects them from interfering with each other. However, if a publisher directly embeds a third-party script, rather than isolating it in an iframe, the script is treated as coming from the publisher’s origin. Thus, the publisher (and its users) entirely lose the protections of the same origin policy, and there is nothing preventing the script from exfiltrating sensitive information. Sadly, direct embedding is common — and, in fact, the default — which also explains why the vulnerabilities we exposed in our previous post were possible.

This model is a poor fit for reality. Publishers neither completely trust nor completely mistrust third parties, and thus neither of the two options (iframe sandboxing and direct embedding) is a good fit: one limits functionality and the other is a privacy nightmare. We’ve found repeatedly through our research that third parties are quite opaque about the behavior of their scripts, and at any rate, most publishers don’t have the time or technical knowhow to evaluate them. Thus, we’re stuck with this uneasy relationship between publishers and third parties for the foreseeable future.

The browser vendor’s dilemma. It is clear that the Same-Origin Policy is a poor fit for trust relationships on the web today, and that other security defenses would help. But there is another dilemma for browser vendors: should they defend against this and other similar vulnerabilities, or view it as the publisher’s fault for embedding the third party at all?

There are good arguments for both views. Currently browser vendors seem to adopt the latter for the login manager issue, viewing it as the publisher’s burden. In general, there is no principled way to defend against third parties that are present on some pages on a site from accessing sensitive data on other pages of the same site. For example, if a user simultaneously has two tabs from the same site open — one containing a login form but no third party, and vice versa — then the third-party script can “reach across” browser tabs and exfiltrate the login information under certain circumstances. By embedding a third party anywhere on its site, the publisher signals that it completely trusts the third party.

Yet, in other cases, browser vendors have chosen to adopt defenses even if necessarily imperfect. For example, the HTTPOnly cookie attribute was introduced to limit the impact of XSS attacks by blocking the script access to security critical cookies.

There is another relevant factor: our discovery means that autofill is not just a security vulnerability but also a privacy threat. While the security community strongly prefers principled solutions whenever possible, when it comes to web tracking, we have generally been willing to embrace more heuristic defenses such as blocklists.

Countermeasures. Publishers, users, and browser vendors can all take steps to prevent autofill data exfiltration. We discuss each in turn.

Publishers can isolate login forms by putting them on a separate subdomain, which prevents autofill from working on non-login pages. This does have drawbacks including an increase in engineering complexity. Alternately they could isolate third parties using frameworks like Safeframe. Safeframe makes it easier for the publisher scripts and iframed scripts to communicate, thus blunting the effect of sandboxing. Any such technique requires additional engineering by the publisher compared to simply dropping a third-party script into the web page.

Users can install ad blockers or tracking protection extensions to prevent tracking by invasive third-party scripts. The domains used to serve the two scripts ( and are blocked by the EasyPrivacy blocklist.

Now we turn to browsers. The simplest defense is to allow users to disable login autofill. For instance, the Firefox preference signon.autofillForms can be set to false to disable autofilling of credentials.

A less crude defense is to require user interaction before autofilling login forms. Browser vendors have been reluctant to do this because of the usability overhead, but given the evidence of autofill abuse in the wild, this overhead might be justifiable.

The upcoming W3C Credential Management API requires browsers to display a notification when user credentials are provided to a page [8]. Browsers may display the same notification when login information is autofilled by the built-in login managers. Displays of this type won’t directly prevent abuse, but they make attacks more visible to publishers and privacy-conscious users.

Finally, the “writeonly form fields” idea can be a promising direction to secure login forms in general. The briefly discussed proposal defines ways to deny read access to form elements and suggests the use of placeholder nonces to protect autofilled credentials [9].


Built-in login managers have a positive effect on web security: they curtail password reuse by making it easy to use complex passwords, and they make phishing attacks are harder to mount. Yet, browser vendors should reconsider allowing stealthy access to autofilled login forms in the light of our findings. More generally, for every browser feature, browser developers and standard bodies should consider how it might be abused by untrustworthy third-party scripts.

End notes:

[1] We found that login pages contain 25% fewer third-parties compared to pages without login forms. The analysis was based on our crawl of 300,000 pages from 50,000 sites. [2] We tested the following browsers: Firefox, Chrome, Internet Explorer, Edge, Safari.


[8] “User agents MUST notify users when credentials are provided to an origin. This could take the form of an icon in the address bar, or some similar location.”
[9] Originally proposed in


Appendix 1 – Methodology

To study password manager abuse, we extended OpenWPM to simulate a user with saved login credentials and added instrumentation to monitor form access. We used Firefox’s nsILoginManager interface to add login credentials as if they were previously stored by the user. We did not otherwise alter the functionality of the password manager or attempt to manually fill login forms. This allowed us to capture actual abuses of the browser login manager, as any exfiltrated data must have originated from the login manager.

We crawled 50,000 sites from the Alexa top 1 million. We used the following sampling strategy: visit all of the top 15,000 sites, randomly sample 15,000 sites from the Alexa rank range [15,000 100,000), and randomly sample 20,000 sites from the range [100,000, 1,000,000). This combination allowed us to observe the attacks on both high and low traffic sites. On each of these 50,000 sites we visited 6 pages: the front page and a set of 5 other pages randomly sampled from the internal links on the front page.

The fake login credentials acted as bait, allowing us to introduce an email and password to the page that could be collected by third parties without any additional interaction. Detection of email address collection was done by inspecting JavaScript calls related to form creation and access, and by the analysis of the HTTP traffic. Specifically, we used the following instrumentation:

  1. Mutation events to monitor elements inserted to the page DOM. This allowed us to detect the injection of fake login forms. When a mutation event fires, we record the current call stack and serialize the inserted HTML elements.
  2. Instrument HTMLInputElement to intercept access to form input fields. We log the input field value that is being read to detect when the bait email (autofilled by the built-in password manager) was sniffed.
  3. Store HTTP request and response data, including POST payloads to detect the exfiltration of the email address or password.

For both JavaScript (1, 2) and HTTP instrumentation (3) we store JavaScript stack traces at the time of the function call or the HTTP request. We then parse the stack trace to pin down the initiators of an HTTP request or the parties responsible for inserting or accessing a form.

We then combine the instrumentation data to select scripts that:

  1. inject an HTML element containing a password field (recall that the password field is necessary for the built-in password manager to kick in)
  2. read the email address from the input field automatically filled by the browser’s login manager
  3. send the email address, or a hash of it, over HTTP

To verify the findings of the automated experiments we manually analyzed sites that embed the two scripts that match these conditions. We have verified that the forms that the scripts inserted were not visible. We then opened accounts on the sites that allow registration and let the browser store the login information (by clicking yes to the dialog in Figure 1). We then visited another page on the site and verified that browser password manager filled the invisible form injected by the scripts.

Appendix 2 – Code Snippets

Code snippets from OnAudience (left) and Adthink (right) that are responsible for the injection of invisible login forms.

Code snippets from OnAudience (left) and Adthink (right) that are responsible for the injection of invisible login forms.

20 Dec 21:46

RFC 8297: An HTTP Status Code for Indicating Hints

Lorsqu'un serveur HTTP répond, la réponse contient souvent des liens vers d'autres ressources. Un exemple typique est celui de la page Web dont le chargement va déclencher le chargement de feuilles de style, de JavaScript, etc. Pour minimiser la latence, il serait intéressant de prévenir le client le plus tôt possible. C'est le but de ce RFC, qui décrit le code de retour intérimaire 103, qui prévient le client qu'il peut tout de suite commencer à charger ces ressources supplémentaires.

Il existe un type de lien pour cela, preload, décrit par ses auteurs et enregistré dans le registre des types de liens (cf. RFC 8288). Il peut être utilisé dans la réponse « normale » :

HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </main.css>; rel="preload"; as="style"
Link: </script.js>; rel="preload"; as="script"    

Mais cela ne fait pas gagner grand'chose : une toute petite fraction de seconde après, le client HTTP verra arriver le source HTML et pourra y découvrir les liens. On voudrait renvoyer tout de suite la liste des ressources à charger, sans attendre que le serveur ait fini de calculer la réponse (ce qui peut prendre du temps, s'il faut dérouler mille lignes de Java et plein de requêtes SQL…)

Le nouveau code de retour, 103, lui, peut être envoyé immédiatement, avec la liste des ressources. Le client peut alors les charger, tout en attendant le code de retour 200 qui indiquera que la ressource principale est prête. (Les codes de retour commençant par 1, comme 103, sont des réponses temporaires, « pour information », en attendant le succès, annoncé par un code commençant par 2. Cf. RFC 7231, sections 6.2 et 6.3.) La réponse HTTP utilisant le nouveau code ressemblera à :

HTTP/1.1 103 Early Hints
Link: </main.css>; rel="preload"; as="style"
Link: </script.js>; rel="preload"; as="script"

HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </main.css>; rel="preload"; as="style"
Link: </script.js>; rel="preload"; as="script"    

Les détails, maintenant (section 2 du RFC). 103 indique au client qu'il y aura une série de liens vers des ressources supplémentaires qu'il peut être intéressant, par exemple, de charger tout de suite. Les liens finaux seront peut-être différents (dans l'exemple ci-dessus, ils sont identiques). 103 est juste une optimisation, pas une obligation. (Hint = suggestion.) Les liens qu'il indique ne font pas autorité. Le serveur peut indiquer des liens supplémentaires, ne pas indiquer des liens qui étaient dans la réponse 103, indiquer des liens différents, etc.

Il peut même y avoir plusieurs 103 à la suite, notamment si un relais sur le trajet ajoute le sien, par exemple en se basant sur une réponse qu'il avait gardée en mémoire. 103 n'est en effet pas toujours envoyé par le serveur d'origine de la ressource, il peut l'être par un intermédiaire. Voici un exemple qui donne une idée des variantes possibles :

HTTP/1.1 103 Early Hints
Link: </main.css>; rel="preload"; as="style"

HTTP/1.1 103 Early Hints
Link: </style.css>; rel="preload"; as="style"
Link: </script.js>; rel="preload"; as="script"

HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </main.css>; rel="preload"; as="style"
Link: </newstyle.css>; rel="preload"; as="style"
Link: </script.js>; rel="preload"; as="script"

On voit que la réponse finale n'est ni la première suggestion, ni la deuxième (ni une union des deux).

Note pour les programmeurs Python/WSGI. Je ne suis pas arrivé à utiliser ce code « intérimaire » avec WSGI, cela ne semble pas possible en WSGI. Mais on trouvera sans doute d'autres implémentations…

Le code 103 est désormais dans le registre IANA des codes de retour.

26 Nov 13:11

Le chemin vers une informatique éthique

by framasoft

Le logiciel « open source » a gagné, tant mieux, c’est un préalable pour une informatique éthique, explique Daniel Pascot, qui a tout au long d’une carrière bien remplie associé enseignement et pratique de l’informatique, y compris en créant une entreprise.

Du côté de nos cousins d’Outre-Atlantique, on lui doit notamment d’avoir présidé aux destinées de l’association libriste FACIL (c’est un peu l’April du Québec) et milité activement pour la promotion de solutions libres jusqu’aux instances gouvernementales.

On peut se réjouir de l’ubiquité du logiciel libre mais les fameuses quatre libertés du logiciel libre (merci Mr Stallman) ne semblent en réalité concerner que les créateurs de logiciels. Les utilisateurs, peu réceptifs au potentiel ouvert par les licences libres, sont intéressés essentiellement par l’usage libre des logiciels et les services proposés par des entreprises intermédiaires. Hic jacet lupus… Quand ces services échappent à la portée des licences libres, comment garantir qu’ils sont éthiques ? La réflexion qu’entame Daniel Pascot à la lumière d’exemples concrets porte de façon très intéressante sur les conditions d’un contrat équilibré entre utilisateurs et fournisseurs de services. Les propositions de charte qu’il élabore ressemblent d’ailleurs plutôt à une liste des droits des utilisateurs et utilisatrices ;-)

Chez Framasoft, nous trouvons que ce sont là des réflexions et propositions fort bien venues pour le mouvement de CHATONS qui justement vous proposent des services divers en s’engageant par une charte.

Comme toujours sur le Framablog, les commentaires sont ouverts…

Le logiciel « open source » a gagné, oui mais…

Photo Yann Doublet

Les « libristes »1 se rendent progressivement compte que bien des combats qu’ils ont livrés étaient une cause perdue d’avance car ils sous-estimaient les conséquences de la complexité des logiciels. Quels que soient les bienfaits des logiciels libres, les utiliser exige une compétence et un entretien continu qui ne sont pas envisageables pour la grande majorité des individus ou organisations2.

Richard Stallman a fait prendre conscience de la nécessité de contrôler les programmes pour garantir notre liberté. La dimension éthique était importante : il parlait du bon et du mauvais logiciel. L’importance de ce contrôle a été mise en évidence par Lawrence Lessig avec son « Code is law »3. La nature immatérielle et non rivale du logiciel faisait que les libristes le considéraient naturellement comme un bien commun. Il leur semblait évident qu’il devait être partagé. Comme on vivait alors dans un monde où les ordinateurs étaient autonomes, la licence GPL avec ses libertés offrait un socle satisfaisant sur lequel les libristes s’appuyaient.

J’ai depuis plus de 20 ans enseigné et milité pour le logiciel libre que j’utilise quotidiennement. Comme tout bon libriste convaincu, j’ai présenté les quatre libertés de la GPL, et je reconnais que je n’ai pas convaincu grand monde avec ce discours. Qu’il faille garder contrôle sur le logiciel, parfait ! Les gens comprennent, mais la solution GPL ne les concerne pas parce que ce n’est absolument pas dans leur intention d’installer, étudier, modifier ou distribuer du logiciel. Relisez les licences et vous conviendrez qu’elles sont rédigées du point de vue des producteurs de logiciels plus que des utilisateurs qui n’envisagent pas d’en produire eux-mêmes.

Mais un objet technique et complexe, c’est naturellement l’affaire des professionnels et de l’industrie. Pour eux, la morale ou l’éthique n’est pas une préoccupation première, ce sont des techniciens et des marchands qui font marcher l’économie dans leur intérêt. Par contre, la liberté du partage du code pour des raisons d’efficacité (qualité et coût) les concerne. Ils se sont alors débarrassés de la dimension éthique en créant le modèle open source4. Et ça a marché rondement au point que ce modèle a gagné la bataille du logiciel. Les cinq plus grandes entreprises au monde selon leurs capitalisations boursières, les GAFAM, reposent sur ce modèle. Microsoft n’est plus le démon privatif à abattre, mais est devenu un acteur du libre. Enlevez le code libre et plus de Web, plus de courrier électronique, plus de réseaux sociaux comme Facebook, plus de service Google ou Amazon, ou de téléphone Apple ou Android. Conclusion : le logiciel libre a gagné face au logiciel propriétaire, c’est une question de temps pour que la question ne se pose plus.

Oui, mais voilà, c’est du logiciel libre débarrassé de toute évidence de sa dimension éthique, ce qui fait que du point de vue de l’utilisateur qui dépend d’un prestataire, le logiciel libre n’apporte rien. En effet, les prestataires de services, comme les réseaux sociaux ou les plates-formes de diffusion, ne distribuent pas de logiciel, ils en utilisent et donc échappent tout à fait légalement aux contraintes éthiques associées aux licences libres. Ce qui importe aux utilisateurs ce ne sont pas les logiciels en tant qu’objets, mais le service qu’ils rendent qui, lui, n’est pas couvert par les licences de logiciel libre. Circonstance aggravante, la gratuité apparente de bien des services de logiciel anesthésie leurs utilisateurs face aux conséquences de leur perte de liberté et de l’appropriation de leurs données et comportements (méta données) souvent à leur insu5.

Pourtant, aujourd’hui, nous ne pouvons plus nous passer de logiciel, tout comme nous ne pouvons pas nous passer de manger. Le logiciel libre c’est un peu comme le « bio » : de plus en plus de personnes veulent manger bio, tout simplement parce que c’est bon pour soi (ne pas s’empoisonner), bon pour la planète (la préserver de certaines pollutions) ou aussi parce que cela permet d’évoluer vers une économie plus humaine à laquelle on aspire (économie de proximité). Le « bio » est récent, mais en pleine expansion, il y a de plus en plus de producteurs, de marchands, et nos gouvernements s’en préoccupent par des lois, des règlements, des certifications ou la fiscalité. Ainsi le « bio » ce n’est pas seulement un produit, mais un écosystème complexe qui repose sur des valeurs : si le bio s’était limité à des « écolos » pour auto-consommation, on n’en parlerait pas. Eh bien le logiciel c’est comme le bio, ce n’est pas seulement un produit mais aussi un écosystème complexe qui concerne chacun de nous et la société avec tous ses acteurs.

Dans l’écosystème logiciel, les éditeurs et les prestataires de service qui produisent et opèrent le logiciel, ont compris que le logiciel libre (au sens open source) est bon pour eux et s’en servent, car ils le contrôlent. Par contre il n’en va pas de même pour ceux qui ne contrôlent pas directement le logiciel. La licence du logiciel ne suffit pas à leur donner contrôle. Mais alors que faire pour s’assurer que le service rendu par le logiciel via un prestataire soit bon pour nous, les divers utilisateurs dans cet écosystème numérique complexe ?

Je vais ici commenter la dimension éthique de deux projets de nature informatique qui s’appuient sur du logiciel libre sur lesquels je travaille actuellement en tentant d’intégrer ma réflexion de militant, d’universitaire et de praticien. PIAFS concerne les individus et donc le respect de nos vies privées pour des données sensibles, celles de notre santé dans un contexte de partage limité, la famille. REA vise à garantir à une organisation le contrôle de son informatisation dans le cadre d’une relation contractuelle de nature coopérative.

Deux cas qui ont alimenté ma réflexion

PIAFS : Partage des Informations Avec la Famille en Santé

PIAFS est projet qui répond à un besoin non satisfait : un serveur privé pour partager des données de santé au sein d’une unité familiale à des fins d’entr’aide ( Cette idée, dans un premier temps, a débouché sur un projet de recherche universitaire pour en valider et préciser la nature. Pour cela il nous fallait un prototype.

Au-delà de la satisfaction d’un besoin réel, je cherchais en tant que libriste comment promouvoir le logiciel libre. Je constatais que mes proches n’étaient pas prêts à renoncer à leurs réseaux sociaux même si je leur en montrais les conséquences. Il fallait éviter une première grande difficulté : changer leurs habitudes. J’avais là une opportunité : mes proches, comme beaucoup de monde, n’avaient pas encore osé organiser leurs données de santé dans leur réseau social.

Si ce projet avait dès le départ une dimension éthique, il n’était pas question de confier ces données sensibles à un réseau social. J’étais dès le départ confronté à une dimension pratique au-delà de la disponibilité du logiciel. De plus, pour les utilisateurs de PIAFS, l’auto-hébergement n’est pas une solution envisageable. Il fallait recourir à un fournisseur car un tel service doit être assuré d’une manière responsable et pérenne. Même si l’on s’appuyait sur des coopératives de santé pour explorer le concept, il est rapidement apparu qu’il fallait recourir à un service professionnel classique dont il faut alors assumer les coûts6. Il fallait transposer les garanties apportées par le logiciel libre au fournisseur de service : l’idée de charte que l’on voyait émerger depuis quelques années semblait la bonne approche pour garantir une informatique éthique, et en même temps leur faire comprendre qu’ils devaient eux-mêmes assurer les coûts du service.

REA : Pour donner au client le contrôle de son informatisation

J’ai enseigné la conception des systèmes d’information dans l’université pendant près de 40 ans (à Aix-en-Provence puis à Québec), et eu l’occasion de travailler dans des dizaines de projets. J’ai eu connaissance de nombreux dérapages de coût ou de calendrier et j’ai étudié la plupart des méthodologies qui tentent d’y remédier. J’ai aussi appris qu’une des stratégies commerciales de l’industrie informatique (ils ne sont pas les seuls !) est la création de situations de rente pas toujours à l’avantage du client. Dans tout cela je n’ai pas rencontré grande préoccupation éthique.

J’ai eu, dès le début de ma carrière de professeur en systèmes d’information (1971), la chance d’assister, sinon participer, à la formalisation de la vision de Jean-Louis Le Moigne7 : un système d’information consiste à capturer, organiser et conserver puis distribuer et parfois traiter les informations créées par l’organisation. Cette vision s’opposait aux méthodologies naissantes de l’analyse structurée issues de la programmation structurée. Elle établissait que l’activité de programmation devait être précédée par une compréhension du fonctionnement de l’organisation à partir de ses processus. L’approche qui consiste à choisir une « solution informatique » sans vraiment repenser le problème est encore largement dominante. J’ai ainsi été conduit à développer, enseigner et pratiquer une approche dite à partir des données qui s’appuie sur la réalisation précoce de prototypes fonctionnels afin de limiter les dérapages coûteux (je l’appelle maintenant REA pour Référentiel d’Entreprise Actif, le code de REA est bien sûr libre).

Mon but est, dans ma perspective libriste, de redonner le contrôle au client dans la relation client-fournisseur de services d’intégration. Si ce contrôle leur échappe trop souvent du fait de leur incompétence technique, il n’en reste pas moins que ce sont eux qui subissent les conséquences des systèmes informatiques « mal foutus ». Là encore le logiciel libre ne suffit pas à garantir le respect du client et le besoin d’une charte pour une informatique éthique s’impose8 .

Photo EOI (CC-BY-SA 2.0)

Vers une charte de l’informatique libre, c’est-à-dire bonne pour l’écosystème numérique

Dans les deux cas, si l’on a les ressources et la compétence pour se débrouiller seul, les licences libres comme la GPL ou une licence Creative Commons pour la méthodologie garantissent une informatique éthique (respect de l’utilisateur, contribution à un bien commun). S’il faut recourir à un hébergeur ou un intégrateur, les garanties dépendent de l’entente contractuelle entre le client-utilisateur et le fournisseur.

Il y a une différence fondamentale entre le logiciel et le service. Le logiciel est non rival, il ne s’épuise pas à l’usage, car il peut être reproduit sans perte pour l’original, alors que le service rendu est à consommation unique. Le logiciel relève de l’abondance alors que le service relève de la rareté qui est le fondement de l’économie qui nous domine, c’est la rareté qui fait le prix. Le logiciel peut être mis en commun et partagé alors que le service ne le peut pas. L’économie d’échelle n’enlève pas le caractère rival du service. Et c’est là que la réalité nous rattrape : la mise en commun du logiciel est bonne pour nous tous, mais cela n’a pas de sens pour le service car aucun fournisseur ne rendra ce service gratuitement hormis le pur bénévolat.

Des propositions balisant un comportement éthique existent, en voici quelques exemples :

  • dans Le Manifeste pour le développement Agile de logiciels, des informaticiens ont proposé une démarche dite agile qui repose sur 4 valeurs et 12 principes. Sans être explicitement une charte éthique, la démarche est clairement définie dans l’optique du respect du client. Ce manifeste est utile dans le cas REA ;
  • la charte du collectif du mouvement CHATONS concerne les individus, elle est pensée dans un contexte d’économie sociale et solidaire, elle est inspirante pour le cas PIAFS ;
  • la charte de Framasoft définit un internet éthique, elle est inspirante pour le cas PIAFS mais aussi pour la définition d’un cadre global ;
  • dernièrement sous forme de lettre ouverte, un collectif issu du Techfestival de Copenhague propose une pratique éthique, utile pour les deux cas et qui permet de réfléchir au cadre global.

Les libristes, mais dieu merci ils ne sont pas les seuls, ont une bonne idée des valeurs qui président à une informatique éthique, bonne pour eux, à laquelle ils aspirent lorsqu’ils utilisent les services d’un fournisseur. Les exigences éthiques ne sont cependant pas les mêmes dans les deux cas car l’un concerne un service qui n’inclut pas de développement informatique spécifique et l’autre implique une activité de développement significative (dans le tableau ci-dessous seuls des critères concernant l’éthique sont proposés) :

Critères pour le client Dans le cas de PIAFS Dans le cas d’un projet REA
Respect de leur propriété Les données qu’ils produisent leur appartiennent, ce n’est pas négociable Tout document produit (analyse, …) est propriété du client
Respect de leur identité Essentiel Le client doit contrôler la feuille de route, ce sont ses besoins que l’on doit satisfaire par ceux du fournisseur
Respect de leur indépendance vis à vis du fournisseur Important, préside au choix des logiciels et des formats Critique : mais difficile à satisfaire.
Proximité du service : favoriser l’économie locale et protection contre les monopoles Important Important
Pérennité du service Important, mais peut être tempéré par la facilité du changement Essentiel : le changement est difficile et coûteux, mais la « prise en otage » est pire
Payer le juste prix Important Important
Partage équitable des risques Risque faible Essentiel car le risque est élevé
Mise en réseau Essentiel : la connexion « sociale » est impérative mais dans le respect des autres valeurs Plus aucune organisation vit en autarcie
Contribution (concerne le fournisseur) Non discutable, obligatoire Important mais aménageable

Entente sur le logiciel

Le client, individu ou organisation, doit avoir l’assurance que les logiciels utilisés par le fournisseur de services font bien et seulement ce qu’ils doivent faire. Comme il n’a pas la connaissance requise pour cette expertise, il doit faire confiance au fournisseur. Or, parce que celui-ci n’offre pas toute la garantie requise (volonté et capacité de sa part), il faut, dans cette situation, recourir à un tiers de confiance. Cette expertise externe par un tiers de confiance est très problématique. Il faut d’une part que le fournisseur donne accès aux logiciels et d’autre part trouver un expert externe qui accepte d’étudier les logiciels, autrement dit résoudre la quadrature du cercle !

Le logiciel libre permet de la résoudre. Il est accessible puisqu’il est public, il est produit par une communauté qui a les qualités requises pour jouer ce rôle de tiers de confiance. Ainsi, pour une informatique éthique :

  • tout logiciel utilisé par le fournisseur doit être public, couvert par une licence libre, ce qui le conduit à ne pas redévelopper un code existant ou le moins possible,
  • s’il est amené à produire du nouveau code,
    • le fournisseur doit le rendre libre. C’est à l’avantage de la société mais aussi du client dans un contexte de partage et de protection contre les situations de rente qui le tiennent en otage,
    • ou du moins le rendre accessible au client,
  • garantir que seul le code montré est utilisé,
  • utiliser des formats de données et documents libres.

L’éthique est complexe, il est difficile sinon impossible d’anticiper tous les cas. L’exigence de logiciel libre peut être adaptée à des situations particulières, par exemple si le prestataire est engagé pour un logiciel que le client ne désire pas partager il en prend alors la responsabilité, ou si la nécessité de poursuivre l’utilisation de logiciels non libres est non contournable temporairement.

Entente sur le bien ou service

Le critère du coût est propre au service. Dans une approche éthique le juste coût n’est pas la résultante du jeu de l’offre et de la demande, ni d’un jeu de négociation basé sur des secrets, et encore moins le résultat d’une rente de situation. Il s’agit pour le fournisseur de couvrir ses coûts et de rentabiliser son investissement (matériel, formation…). Une approche éthique impose  de la transparence, le client  :

  • doit savoir ce qu’il paye,
  • doit avoir la garantie que le contrat couvre tous les frais pour l’ensemble du service (pas de surprise à venir),
  • doit être capable d’estimer la valeur de ce qu’il paye,
  • doit connaître les coûts de retrait du service et en estimer les conséquences.

Le partage équitable du risque concerne essentiellement les projets d’informatisation avec un intégrateur. Il est rare que l’on puisse estimer correctement l’ampleur d’un projet avant de l’avoir au moins partiellement réalisé. Une part du risque provient de l’organisation et de son environnement, une autre part du risque provient des capacités du fournisseur et de ses outils. Ceci a un impact sur le découpage du projet, chaque étape permet d’estimer les suivantes :

  • tout travail réalisé par le fournisseur contributif au projet :
    • doit être payé,
    • appartient au client,
    • doit pouvoir être utilisé indépendamment du fournisseur.
  • le travail dont le volume est dépendant du client est facturé au temps,
  • le travail sous le contrôle du fournisseur doit si possible être facturé sur une base forfaitaire,
  • le client est maître de la feuille de route,
  • tout travail entamé par le fournisseur doit être compris et accepté par le client,
  • la relation entre le client et le fournisseur est de nature collaborative, le client participe au projet qui évolue au cours de la réalisation à la différence d’une relation contractuelle dans laquelle le client commande puis le fournisseur livre ce qui est commandé.

Conclusion : l’informatique éthique est possible

Pour tous les utilisateurs de l’informatique, c’est à dire pratiquement tout le monde et toutes les organisations de notre société numérique, il est aussi difficile de nier l’intérêt d’une informatique éthique que de rejeter le « bio », mais encore faut-il en être conscient. Le débat au sein des producteurs de logiciels reste difficile à comprendre. Ce qui est bon pour un libriste c’est un logiciel qui avant tout le respecte, alors que pour les autres informaticiens, c’est à dire la grande majorité, c’est un logiciel qui ne bogue pas. Fait aggravant : la vérité des coûts nous est cachée. Cependant au-delà de cette différence philosophique, l’intérêt du logiciel partagé est tel qu’un immense patrimoine de logiciel libre ou open source est disponible. Ce patrimoine est le socle sur lequel une informatique éthique est possible. Les deux cas présentés nous montent que les conditions existent dès maintenant.

Une informatique éthique est possible, mais elle ne sera que si nous l’exigeons. Les géants du Net sont de véritables états souverains devant lesquels même nos états baissent pavillon. La route est longue, chaotique et pleine de surprises, comme elle l’a été depuis la naissance de l’ordinateur, mais un fait est acquis, elle doit reposer sur le logiciel libre.

Le chemin se fait en marchant, comme l’écrivait le poète Antonio Machado, et c’est à nous libristes de nous donner la main et de la tendre aux autres. Ce ne sera pas facile car il faudra mettre la main à la poche et la bataille est politique. Il nous faut exiger, inspirés par le mouvement « bio », un label informatique éthique et pourquoi pas un forum mondial de l’écosystème numérique. La piste est tracée (à l’instar de la Quadrature du Net), à nous de l’emprunter.


  1. J’ai utilisé ce mot de libriste pour rendre compte de la dimension militante et à certains égards repliée sur elle-même, qu’on leur reproche souvent à raison.
  2. Voir sur ce point le blog NullPointerException, « Que faut-il pour XXX ? Du logiciel libre ! Non, une gouvernance éthique », 21/02/2017.
  3. Dans un article paru en 2000, Lawrence Lessig -auquel on doit les licences Creative Commons- a clairement mis en lumière que l’usage d’internet (et donc des logiciels) nous contraint, tout comme nous sommes contraint par les lois. Il nous y a alerté sur les conséquences relatives à notre vie privée. Voir la traduction française sur Framablog « Le code fait loi – De la liberté dans le cyberespace » (publié le 22/05/2010),
  4. Dans l’optique open source, un bon logiciel est un logiciel qui n’a pas de bogue. Dans l’optique logiciel libre, un bon logiciel est un logiciel éthique qui respecte son utilisateur et contribue au patrimoine commun. Dans les deux cas il est question d’accès au code source mais pour des raisons différentes, ce qui au plan des licences peut sembler des nuances : « Né en 1998 d’une scission de la communauté du logiciel libre (communauté d’utilisateurs et de développeurs) afin de conduire une politique jugée plus adaptée aux réalités économiques et techniques, le mouvement open source défend la liberté d’accéder aux sources des programmes qu’ils utilisent, afin d’aboutir à une économie du logiciel dépendant de la seule vente de prestations et non plus de celle de licences d’utilisation  ». Voir la page Wikipédia, « Open Source Initiative ».
  5. Voir par exemple Tristan Nitot, « Surveillance:// Les libertés au défi du numérique : comprendre et agir », C&F éditions, 2016. L’interview de T. Nitot sur le Framablog. Le site « Social Cooling » (« Les données conduisent au refroidissement social »).
  6. La question de recourir à une organisation de l’économie sociale et solidaire s’est posée et ce n’est pas exclu.Cela n’a pas été retenu pour des raisons pratiques et aussi parce que la démarche visait à promouvoir une informatique éthique de la part des fournisseurs traditionnels locaux.
  7. Avant d’être connu comme un constructiviste Jean-Louis Le Moigne, alors professeur à l’IAE d’Aix-en-Provence, créait un enseignement de systèmes d’information organisationnels et lançait avec Huber Tardieu la recherche qui a conduit à la méthode Merise à laquelle j’ai participé car j’étais alors assistant dans sa petite équipe universitaire et il a été mon directeur de doctorat.
  8. Cela se dégage par exemple de la thèse de Balla Diop que j’ai dirigée. Il a comparé des implantations de ERP libres et propriétaires : du point de vue du client hormis les coûts il y a peu de différence. Voir Balla Diop, L’effet de la stratégie logicielle (ERP open source vs ERP commercial) sur le développement du capital humain des PME, Thèse de doctorat dirigée par D. Pascot, Université Laval, 2015.
25 Nov 13:21

La sécurité, l'obsolescence et la maintenance des systèmes embarqués

by Renault

Il est assez banal de dire que de plus en plus d'équipements modernes sont connectés au réseau. Cela apporte de nouvelles fonctionnalités, la possibilité d'améliorer le produit même une fois vendu par des mises à jour mais aussi des problèmes de confidentialité et de sécurité.

Les systèmes embarqués sont particulièrement concernés par ces problématiques, que les industriels traitent parfois mal et dont les consommateurs sont rarement dans le vrai également.

C'est de cette problématique dont on va parler.

Obsolescence programmée ?

Ce terme revient souvent dans ce genre de discussions. Que l'abandon du support d'un produit, comme par exemple l'absence d'une mise à jour Android, ou que justement la mise à jour de trop rend le système trop lent (cas de certains iPhone) serait une pratique digne de l'obsolescence programmée.

Globalement c'est faux. L'obsolescence programmée est une pratique supposée où un constructeur fragilise **volontairement** son produit afin de nécessiter un remplacement régulier pour augmenter ses ventes.

Le mot clé est donc l'aspect volontaire. Qui est difficile en réalité à constater. Et certains oublient aussi l'aspect de l'équilibre entre le prix et la qualité. Un produit bas de gamme va minimiser la qualité des matériaux par exemple pour que cela coûte moins cher au client. Il est donc normal que le produit dure moins longtemps. Cette question du compromis dans la réalisation du produit est l'essence même du travail d'un ingénieur et de la création de différentes gammes de produits, on ne peut assimiler cela à de l'obsolescence programmée qui consiste en un sabotage.

Je ne vais pas m'étendre beaucoup sur le sujet, il y a trois articles de blog (ici, et là-bas) qui traitent bien de la question de l'obsolescence programmée qui reste une pratique à priori confidentielle. Mais le célèbre reportage d'Arte sur le sujet a mis en lumière cette pratique avec de mauvais exemples et certains le voient du coup... partout.

En tout cas on ne m'a jamais demandé de saboter mon propre produit, et aucun de mes collègues ou connaissances non plus. ;-) Par contre il arrive que certains bogues ne soient jamais corrigés, faute de temps ou de ressources financières pour les traiter.

De la question du progrès logiciel

Certains produits, comme nos ordinateurs ou téléphones portables, peuvent vivre des années sans problèmes. Et ces outils à usage assez génériques peuvent exécuter du logiciel conçu bien après la réalisation du produit.

Mon ordinateur portable personnel actuel date de 2011, il est passé de Fedora 16 à 27, de Windows 7 à 10, de Firefox 7 à Firefox 56, de GNOME 3.0 à GNOME 3.26, de Linux 3.1 à Linux 4.14, etc.

Ce sont des millions de lignes de code ajoutées depuis, le Web a beaucoup grossi entre temps avec du JavaScript devenu omniprésent et des sites devenant de plus en plus des applications complètes. Le contenu multimédia s’alourdit, passant du 720p à 4K pour les vidéos ou les photos. Le chiffrement s'est généralisé également dans les communications ou le stockage.

J'ai constaté peu à peu un ralentissement de ma machine, la consommation de la mémoire a monté (j'ai du rajouter 4 Gio récemment) alors que mon usage, fondamentalement n'a pas changé.

Ce phénomène n'a rien de nouveau, cela suit la loi de Wirth.

C'est un phénomène naturel. Les logiciels évoluent pour ajouter des fonctionnalités (pour répondre à des besoins des utilisateurs). Il est impossible de proposer du logiciel plus moderne tout en espérant une consommation en ressource identique indéfiniment. Soit il faut utiliser un produit qui n'évoluera plus fonctionnellement (cas de beaucoup d'outils simples et légers), ou alors il faudrait beaucoup de ressources financières et humaines pour maintenir plusieurs déclinaisons du logiciel dans le temps. Ce que l'on abordera plus tard.

Ce que la loi de Wirth n'explique pas ou mal, c'est que l'évolution du matériel se produit de manière globale, mais localement un produit a un matériel plutôt figé. Si le matériel évolue mais que les logiciels n'exploitent pas cette puissance supplémentaire, ce serait du gâchis. Donc la consommation des programmes évoluent pour bénéficier de ces ressources disponibles. Et forcément cela se fait au détriment des machines qui accusent d'un certain âge. Cela est encore plus visible sur les téléphones qui ont fait un saut de performances spectaculaire en très peu d'années.

Certains veulent exploiter la machine le plus longtemps possible (donc disons 10-15 ans) tout en bénéficiant de ces évolutions. Ce n'est pas possible sans concession. Il faut faire des choix, en payant cher des produits pour les maintenir longtemps, en renonçant partiellement à ce progrès, en changeant de machine ou renoncer à des usages. Typiquement, aller sur le Web avec une machine de 2002 doit être possible, mais cela ne doit pas être une expérience très agréable en dehors de quelques sites très légers.

Et pour un téléphone bas de gamme, conçu pour être tout juste capable de lancer les applications populaires de l'époque, ne peut pas soutenir la charge d'une mise à jour des dites applications sur le long terme.

Et après toute cette explication, comment associer cela à de l'obsolescence programmée alors que cette lourdeur progressive provient de logiciels extérieurs à la conception du matériel ? Ce n'est pas Intel qui a rendu Firefox plus lourd avec le temps. :-)

La sécurité

La sécurité est devenue depuis quelques années un sujet de premier plan pour tout un nouveau panel de produits. Avec une connexion accessible depuis Internet, il devient possible d'essayer d'infiltrer ces produits qui peuvent être accessibles non stop pendant des années et sans maintenance active (il n'y a pas un administrateur système pour surveiller le réseau domestique d'un particulier).

Du coup, pour combler les failles, il devient nécessaire de mettre à jour le produit. Parfois changer l'outil interne, ou le protocole employé (le MD5 n'est plus un moyen fiable pour vérifier l'intégrité d'un fichier ou d'un certificat).

Du coup pour améliorer la sécurité, on doit les faire évoluer. Ce qui peut nous faire revenir sur le point précédent où le logiciel devient trop lourd pour le matériel considéré ce qui rend compliqué la conciliation des deux.

L'autre problème est... le coût. Quand on achète un produit type téléphone, un réfrigérateur connecté, un modem ou autre, nous achetons le produit à un prix fixe, parfois très dérisoire car très bas de gamme. Sauf que d'assurer une maintenance sur 10-15 ans, cela coûte très cher. Car il devient nécessaire de maintenir plusieurs versions du logiciel (suivant l'âge du matériel et de ses successeurs à maintenir), de tester chaque mise à jour sur chaque produit, tester son déploiement, corriger les éventuels ratés auprès des clients, communiquer auprès d'eux (manuels explicatifs, mise à jour d'un site Web possiblement en plusieurs langues, courriers / courriels envoyés en nombre).

Admettons que pour maintenir un modèle d'un téléphone portable pendant 15 ans il faut une équipe de 10 personnes à temps plein (ce qui n'est pas irréaliste car cela demande beaucoup de travail pour corriger la moindre faille ou les bogues découverts, sachant que le logiciel dépend également du lieu vendu pour des raisons de contraintes légales). En admettant qu'ils ne sont pas mal payés (et qu'il leur faut du matériel adéquat), cela peut revenir par employé à un coût annuel pour l'employeur d'environ 100 000€. Donc 1 million d'euros par an. Sachant qu'un modèle lambda d'un téléphone peut être vendu auprès du million d'unités au total, cela reviendrait a un coût de 10-15 millions d'euros rien que pour la maintenance une fois le produit vendu. Pour des téléphones à 100€, cela représente 10% du budget global du produit ! Ce n'est clairement pas négligeable. Et je ne parle pas des cas de produits moins vendus qui méritent pourtant la même maintenance.

Le Libre comme solution ?

Certains pensent qu'un produit embarqué, s'il est fait avec du logiciel libre, il est aisé de le maintenir pour proposer des mises à jour du produit pendant des années après l'abandon par son constructeur. La réalité est plus complexe.

Pour les projets assez puissants pour accueillir un système d'exploitation Linux (cas des téléphones par exemple), le système est rarement compilé de zéro à la main. Pour gagner du temps, il existe des solutions comme Yocto ou buildroot (et ses déclinaisons OpenWRT ou ptxdist) pour compiler l'ensemble des logiciels (dont le noyau) pour notre système afin d'obtenir une image qu'on pourra installer sur la cible. Je les présenterais dans un autre article.

Seulement, chaque processeur ou plateforme a ses spécificités. C'est pourquoi, les concepteurs des puces (Qualcomm, Texas Instrument, Broadcom, Freescale / NXP et autres) fournissent les solutions citées plus haut avec les changements nécessaires pour exploiter la plateforme. Très souvent le noyau Linux et le chargeur de démarrage U-Boot accueillent une grande liste de correctifs maison (plusieurs centaines).

Cela est bien, car nous n'avons pas à développer nous même les pilotes pour exploiter les fonctions du processeur (notamment pour la couche graphique) et dans l'essentiel cela reste du code libre. Cependant ces correctifs sont gros et souvent… mal réalisés. Faute de temps et de ressources, les constructeurs ne cherchent pas à concevoir des correctifs qui finiront dans le projet officiel. Leur but est que cela fonctionne avec le noyau fourni aux développeurs / intégrateurs. Du coup nous nous retrouvons avec un noyau et un chargeur de démarrage figé, car Linux évolue très vite et il est très difficile de porter ces correctifs pour une autre version. Et comme cela est trop souvent trop mal fait (utilisation d'une pile logicielle différente que celle du noyau pour une fonction donnée, comme le SPI ou le réseau par exemple, code spaghetti avec lien fort entre le tronc commun et leur pilote, etc.) il est difficilement imaginable de porter cela sur le noyau officiel directement.

Pas mal de personnes essayent pourtant de porter le nécessaire sur le noyau officiel. Mais cela demande beaucoup de temps (aujourd'hui le support du téléphone N900 est quasiment complet, mais il aura fallu 8 ans après sa sortie !) et c'est souvent au prix de fonctionnalités partielles (performances graphiques ou réseaux plus faibles, gestion de l'énergie douteuse). Sans collaboration du fondeur, c'est une tâche globalement vouée à l'échec étant donné le rythme de sortie des composants. Puis le fabricant de la puce bosse déjà sur la plateforme suivante. Ils n'ont pas le temps, ni l'envie, de s'attarder sur un produit qui n'a plus d'avenir.

Et même dans le cas où ce serait possible, il y a des sacs de nœuds dans l'architecture du système. Si vous souhaitez profiter par exemple des dernières tablettes Wacom sur votre machine, il faudra un noyau récent. En admettant que vous avez un noyau LTS un peu ancien comme la 3.4, il faudra rétro-porter cette fonctionnalité. Cela signifie récupérer le pilote mais souvent d'autres commits sur le sous-systèmes des périphériques entrées. Mais le noyau ne fait pas tout, il faut également que l'interface graphique propose de quoi configurer et exploiter le matériel. Donc par exemple en récupérant du travail effectué sur les versions récentes de GTK+ et de GNOME. Cela peut donc représenter beaucoup de travail, sur beaucoup de composants, et il faudra tester bien sûr du bon fonctionnement, de la sécurité et de la maintenance de tout ceci.

Bref, l'aspect libre peut aider bien sûr à maintenir un produit plus longtemps. D'ailleurs les initiatives du genre OpenWRT, CyanogenMod / LineageOS permettent de maintenir à jour certains produits embarqués plus longtemps que le support officiel du constructeur. Mais cela se fait souvent au détriment de certaines fonctionnalités matérielles.

Solutions ?

Je pense que la solution ne peut se passer de l'aide des industriels, qui eux-mêmes ne peuvent pas se permettre à un coût fixe d'une maintenance complexe sur une très longue durée. Imposer légalement une durée minimale de support conduirait à une hausse de prix d'achat inévitable de tous ces biens.

Une autre solution serait d'évoluer vers une tarification en tant que service. À savoir payer pour une durée de maintenance souhaitée. Si l'utilisateur souhaite 10 ans de maintenance, il le pourra, au prix d'un abonnement ajusté en conséquence. Je pense que c'est la seule solution, notamment pour les produits vendus à un volume moyen ou faible, d'avoir une maintenance dans le temps à la hauteur, sans rendre le produits inutilisable ou trop cher à l'achat.

La solution libre et gratuite me semble difficilement possible. Il suffit de voir qu'aucune distribution purement communautaire gratuite pour x86 n'arrive à gérer une maintenance de plus de 5 ans. Pourtant la plateforme est plus simple et plus standard. Donc aller au delà me paraît difficile. Car ce n'est pas une tâche aisée, ni très passionnante. Il faut en effet du savoir faire du matériel et beaucoup de temps.

Après bien entendu, les constructeurs ont leur part à jouer, en s'impliquant d'avantage dans le noyau officiel (qui pourrait lui également avoir une politique plus adaptée à ces besoins, en ayant une API interne plus stable). Il faut également réduire la surface d'attaque au maximum, n'offrir l'accès au réseau que lorsque la plus valu est réelle. Ce genre de décisions aideraient à avoir une meilleure sécurité dans le temps de ces plateformes.

16 Nov 23:06

MySQL Workbench 6.3.10 GA has been released

by MySQL Release Team

Dear MySQL users,

The MySQL developer tools team announces 6.3.10 as our GA release for
MySQL Workbench 6.3.

For the full list of changes in this revision, visit

For discussion, join the MySQL Workbench Forums:

Download MySQL Workbench 6.3.10 GA now, for Windows, macOS 10.11+,
Oracle Linux 7, Fedora 26 and 27, Ubuntu 16.04 and 17.10
or sources, from:


Changes in MySQL Workbench 6.3.10 (2017-11-15)
Bugs Fixed

* Performance information within the Administration –
Dashboard tab demonstrated a slow rate of refresh on
hosts running macOS High Sierra. (Bug #26921498)

* Tooltips within the Administration – Dashboard tab did
not display when the mouse pointer was paused over each
performance graph and the host was running macOS High
Sierra. (Bug #26921467)

* Table objects did not display with the Show Selection
button during the migration process on hosts running
macOS High Sierra. As a result, source objects could not
be selected for inclusion or exclusion. (Bug #26921431)

* Queries executed with the Limit Rows value set to “Don’t
Limit” did not display rows in the result grid on hosts
running macOS High Sierra. (Bug #26921372)

* Executing a query in MySQL Workbench on a host running
macOS High Sierra failed to load the result grid
completely, which prevented result data from appearing
within the Result Grid tab. (Bug #26826418, Bug #87714)

* Performing a keyword search in the EER Diagram Editor on
hosts running macOS High Sierra caused MySQL Workbench to
exit unexpectedly. (Bug #26428849, Bug #87020)

* Forward engineering a physical database design did not
operate as expected on hosts running macOS High Sierra.
(Bug #25979928, Bug #86146)

On Behalf of the MySQL/Oracle Release Engineering Team,
Hery Ramilison

14 Nov 21:43

Seven (More) Deadly Sins of Microservices

14 Nov 21:33

The uncertain future of handwriting

Will the ability to wield a pen die out altogether?
14 Nov 21:31

Why driverless cars will be the next battlefield in the culture war

Investors and companies globally have sunk nearly $100 billion into developing self-driving vehicles over the past few years. And with good reason: Self-driving cars are real, they're going to be spectacular, and they're going to happen a lot sooner than you think.

Just last week, Waymo, the driverless car subsidiary of Google-parent Alphabet, announced it would begin a robo-taxi service in Phoenix. The city has been a hotbed of autonomous vehicle testing due to its regulatory friendliness and predictably pleasant weather.

Of course this doesn't mean highways will soon be filled with swarming packs of autonomous vehicles zooming along at 80 miles per hour, just inches from each other's bumper. It's one thing to be able to purchase a fully autonomous car (maybe within a few years) that works in certain places under certain conditions; it's quite another for many or most cars on the road to be driverless (maybe a few decades) anywhere, anytime. One recent gone-viral prediction comes from Bob Lutz, a former top executive and design guru at General Motors. In an essay for Automotive News, Lutz wrote that "in 15 to 20 years — at the latest — human-driven vehicles will be legislated off the highways."

And that forecast, whatever its accuracy, may have inadvertently predicted the next great battleground of America's culture wars.

Some social media users were thrilled by Lutz's prediction, commenting on the technology's potential safety aspects and how it could make commuting easier. But plenty of others were horrified at the prospect. Lots of "… from my cold, dead hands" tweets, for instance, a reference to the well-known National Rifle Association slogan. For these people, such knee-jerk opposition to driverless cars is all about maintaining personal autonomy and withstanding yet another elite assault on their lifestyle.

So you can see how this is going to play out, right? Just wait until Fox & Friends notices this issue, which means it will immediately land on President Trump's radar. And then the tweets will begin. Maybe something like: "First guns, now the elites want to rip the steering wheel from your hands! Banning human drivers is wacko! I WON'T LET THEM!"

Of course it's unlikely this issue will become legislatively relevant during Trump's presidency. But that might not stop the Trumpopulists from trying to preemptively turn it into a wedge issue, one potentially even more powerful than gun control given the mythopoetic place of cars in American postwar culture. Much of Bruce Springsteen's oeuvre, for instance, is built around the idea of the car as a vehicle of escape for working-class woes. And those folks are the hardcore Trumpers.

Will it work? Of course there's no constitutional right to manually drive your car, unlike the right to bear arms. So the freedom argument might not be as compelling as with guns. And the dream of hitting the open road in a new car for parts unknown is probably far from the minds of most drivers slogging their way home after work through heavy traffic. Plus driving, or even merely getting a driver's license, apparently isn't so important to millennials. Universal driverless car sharing might be a lot more appealing to them than their parents or grandparents. They'd probably rather Instagram the car than drive it.

Then there's the tremendous upside to driverless cars. Not everyone may personally know a gun victim, but who hasn't been in a nasty car accident or doesn't know someone who has? Widespread adoption of autonomous driving tech could reduce roadway deaths by at least 90 percent — saving some one million lives a year globally — making it one of the great public health achievements in human history. Now factor in enhanced mobility for the disabled and elderly, shorter commute times, and an end to all those wasted hours staring at the brake lights right in front of you. The potential economic benefits outweigh those of any tax bill that might come out of Congress. (Don't worry, the truck drivers will be fine.)

But those are just the obvious first order effects. There are others, which while important are less predictable. For instance: Tech analyst Benedict Evans points out that gas stations will be going bye bye, just like the combustion engine. And that means big changes in American smoking habits since half of U.S. tobacco sales happen at gas stations, and are often impulse buys. "Car crashes kill 35,000 people a year in the U.S.A., but tobacco kills 500,000," Evans writes.

So the evidence and data support moving to driverless cars ASAP, even if that means only the robots get to drive. No wonder it might be an unexpectedly tough sell in the Age of Trump.

31 Oct 08:31


The Front-End Checklist is an exhaustive list of all elements you need to have / to test before launching your site / HTML page to production.