IoT status, as I see it

For the last 5 years, I have worked in a small company that was creating a software to manage data coming from various sources, and that includes IoT devices (but not only).

This is a weird ecosystem.

One would think that this was a booming one, since it was all around the IT news in the past 10 years (a bit less now), but it was mostly hype.

So what is it about, from my little corner of this ecosystem?

This post is certainly not going to provide an in depth analysis of the ecosystem, it's just a feedback of 5 years to tangent this area...

IoT, as I see it used

It was mostly about installing energy sensor (current sensors, temperature sensors, etc). Mostly for the industries, because they were under heavy stress to lower their energy consumption since 2022.

The idea is that if you don't measure, you can't tell where you are wasting resources. So a sensor sounds like a good idea. Except that it's expensive. A current sensor is typically costing a few tens of $, a bit more if you want to have a network able one.

If you want to control a factory, we are talking of tens of sensors, that must be installed, checked regularly, controlled, updated, and supervised. 

Installing such a device is not that complex (it takes a couple of minutes), but you have to take care of many aspects:

• Is it easy to access once installed, because you may want to change its battery

• Is it protected against chocks, water, etc

• Has it a decent network access

The other kind of sensors are pretty intrusive. Typically, if you want to measure water consumption, you need a plumber to install it. Costly...

Or you can install such devices on your counter, but it's a global measure, when you want to know how much water is used by a specific machine, or room.

Bottom line, the cost of a single sensor is really minor compared to the cost of managing it in the long run, questioning the ROI.

Here be dragons

So let's say you have decided to monitor your factory. Good.

I hope you have cautiously selected you sensor providers. Because it's a tough ecosystem. What if it goes bankrupt? Have you a stock of spare devices, just in case?

I see it happening: a superb installation, top notch sensors. Except that when the company went down, those fragile sensors that have a 3 years life expectancy where impossible to replace. So the company had to replace *all* if the sensors, paying the price for that, plus the installation, software modification, etc. Pretty much spending the same money than for the initial setup.

What about security? In another use case, the user wanted to leverage pretty old webcams they payed good money for. For sure, they were still working. But the only supported secured protocol was TLS 1.0, which is now unsupported by all the existing browsers. Typically, embedding the video into today's browser is just difficult (proxy required with a TLS downgrade in the middle, etc...)

What about security, again? So you have deployed tens of sensors, and now you realize that non secured transmission of data is a no go. Do you have a way to install certificates, and to manage them properly (expiration, renewal, etc)? Of course access through a strong password is a must. But what about OTP? Does your device support it? Can it be upgraded remotely? Do you have a centralized system to manage all those updates for all your sensors without having to send someone on site to do it one sensor after the other? Not to mention software updates...

Generally speaking, people tend to think that sensors measuring non critical information like electricity consumption does not require a high level of security. Maybe... Until your factory is destroyed like what happened in Iran.

Also keep in mind that many sensors are used in a non secure environment, using antiquated protocols (just giving an example), managed by brittle pieces of software.

Measure is only one part of the equation!

Ok, so you have measures coming in. Now, what are you going to do with it?

If you don't have a software to leverage the flow of data, well, it's useless. And this is where it's start to be complicated.

Your software platform should be able to build decent dashboards, with alarm. It should also be able to manage the sensors status (battery, software updates, sensors security). More important, adding new sensors should be easy. Last, not least, you should be able to navigate through all the data in an  efficient way (like, comparing data across the years).

This is where things get *very* complicated. You'll spend many times more on setting up such a platform than what you have spent on devices.

First because you have to define precisely what you want to obtain, which is hard. Second because your requirements will change across time, so you'll have to update your dashboards. Third, your platform should be versatile enough to embed new sensors, new measures, etc. Last, not least, this platform should work for years!

All in all, this is complicated and costly.

What about performances?

So you have picked your platform, fine. It works great, just becoming slower and slower...

Why? Because you have added many sensors. Because you have increased the measure frequency. Because the software is not well written...

Let's say you have 1000 sensors, sending a measure every 5 minutes, 24x7. That means:

• 200 measures per minute, a bit more than 3 per second. So far, so good.

• 12 000 measures per hour

• 288 000 measures per day

• Almost 10M per months

• 100M per year

Now we are talking. If your platform is not properly tuned, when you request a sum up  for the year, you bring back millions of data from your database. And generally speaking, your browser is the part in charge of showing the beautiful graph with those millions of dots... Not to mention your database that will be pounded during such a request, and the gigabyte of data crossing the network...

Did I mention the terabytes needed to store years of data?  In the previous list, storing 100M entries requires tens of gigabytes (assuming each measure is encapsulated into a 100 bytes piece of data). Sadly, most of the time those pieces of data are stored as JSON (it's so easy to read and process!!!), increasing the original payload size by a factor 2, 3 or more. Add to that you want indexes to speed up direct access. Many indexes...

One sad example: a user who has designed a dashboard that exposes monthly graphs. The sent requests are fetching all the data from many sensors from the 1st day to the current day. Strange enough, the dashboard and the underlying servers are pretty responsive on the very beginning of the month. Not so much when it comes to doing the same request on the 30th...

The problem is that those dashboards are expecting to be easy to develop: "Even a manager can do it!". Short answer: NO.

Last, not least, and I didn't mentioned it, between your data and your dashboards, there is a piece of software intended to manage the workflow: how to process incoming data, convert them properly, doing something useful out of it (like sending alarms, etc). This is the heart of your system, and you generally don't see it... And this is the most complex part!

What about failures?

Ok, you have a working system. Your sensors are setup, their battery are full, they send you back the data without losing the network connection, the workflow and your dashboard have been carefully designed.

Your 1000 sensors sending data every 5 minutes are easily processed on the flow. All in all, 3 messages per second is not that much!

Except that for some unexpected reason you haven't received any data for a full week-end. Hopefully, all the sensors aren't sending the data directly to your system, there is a gateway in the middle that has a beautiful feature: it can gather the data and keep them available until you connect your middle ware. 

That means during this week-end, 600K messages have been stored in the gateway, and your admin was able to restore the machine which was running your middle ware on Monday morning (somebody has made a mistake and changed a rule in the firewall, damnit!)

And suddenly your middleware is flooded with half a million messages! Not counting the 200 messages per minutes that are also coming. It will take tens of minutes to process all those data, and it will potentially stress the server to a point they might crash. And the manager who have an urgent need to access the dashboard, because he needs to print a beautiful graph for the 10AM presentation he/she gives to the company board... (yeah, I have seen that. Many times!).

Here, I'm talking about non critical measures, but there are many use cases where we are talking about critical data (think about a factory, or a construction site requiring a real time monitoring).

I have not yet mentioned backups, failover, up time, etc.

Miscellanea

I have faced some quite weird issues during those last 5 years... One of the 'funniest' one was when we installed some sensors into a building. They were not connected with wire, but through a LORA network.

(LoRaWan is a dying radio transmission protocol. It was quite everywhere a few years ago, because it's cheap. Anyway, that's not the issue.)

So we had gateways in the building, a square 4 storey one, with a inner patio. The idea was to install a gateway per floor, in one corner.

Except that it never worked properly. We were losing data for half of the sensors. So we had to send someone with a radio monitoring device to understand why we were losing data...

Bottom line, the windows on the patio were using armored glass with a thin layer of metal to protect against the sun shine... Faraday all over!

Another 'funny' story was the insulated site we were installing, with a 128Kb network access. Barely enough to access it on a text monitor, clearly insufficient to expose 10Mb web pages produced by the dashboards...

Conclusion

I have just scrapped the top of the various issues you will face when conducting such projects. Not to mention that when it comes to energy monitoring, you also have some legal and financial constraints (just because there is a CO2 market, so every ton of CO2 you spare has a value, but you have to *prove* you have really spared it...)

This is quite a rich ecosystem, not so mature, still with a LOT to do.

 OSS maintenance, what does it means?

I'm  maintaining (and developing!) a few Apache projects:

• Apache MINA: A Java NIO framework
  
• Apache LDAP API : A LDAP Java API
  
• Apache Directory Server: A LDAP server in Java
  
• Apache Directory Studio : A LDAP browser based on Eclipse
  
• Apache Mavibot : A MVCC database in Java

Those are quite old  projects (Apache Directory Server was created in 2004, and incubated in 2005). 20 years old actually!

What does it means in term of effort?

The language

All those projects are written in Java, and it was started using Java 4 (actually, the reason Alex Karasulu started to develop the LDAP server back in 2003 is that it supported NIO, which allowed an unlimited number of connections, something that was quite a limitation with Java 3 blocking IO when it comes to manage thousands of concurrent connections.

We are now supporting Java 8 to 21, which means Java 4, 5, 6 and 7 are not anymore supported.

The question is: why do we still support Java 8? Back in 2023, around 30% of Java users were running their applications based on this version. This sounds insane, but you have to keep in mind that when it works, don't even try to fix it. Also the recent Java release policy has make it so that releases are way more frequent, otherwise we would be around version 10 or 11 today.

Also there are not so many new features since Java 8 that worth the effort. I mean Java 8 already has lambda, and the added features aren't that critical, up to Java 21, which introduced Virtual Threads.

 Last, not least, Oracle has changed its policy so that it was not anymore free to use Java in production (they reverted back since then).

So we are good to go with older version of the language.

Are we?

Dependencies

When it comes with dependencies, the language version matters. For instance, if you depend on SpringFramework, then suddenly you can't migrate to the latest maintained version, 6.X. It requires java 17 :/

So now we are at a cross road, where some dependencies are evolving faster than we can cope with. What can we do?

First of all, check if the dependency is really that necessary. Regarding SpringFramework, it is used in two MINA modules, one containing some examples, the other one is based on a defunct container project (Apache Geronimo Xbean). 

The question is to keep this dependency (and being incapable of updating the dependency) or removing it from the code base (and breaking the API contract).

The thing is that some very old versions of what we maintain are still being used as of 2024. Here is a snapshot of the MINA download statistics for last month. 5% are for a 12 years old version (2.0.7, released in November, 17, 2012!).

Mina download statistics

 

So we are kind of stuck, and expecting users to upgrade to a more recent version is putting a lot of burden on them.

The other problem with dependencies is that even if we don't include them in the release packages, we may use some for tests. I'm thinking about mock libraries, for instance. Making a choice a decade ago stuck you for a very long time, unless you are willing to migrate potentially thousands of tests.

For instance, I have spent 3 months migrating all the MINA and Directory projects to Junit 5 last year. Not the best usage of my precious time :/

The very same with Log 4J which is stuck in an old version (1.X). Migrating to Log4J 2.X would require a massive effort.

What about projects versions?

We maintain more than one version of each project:

• Apache MINA is supported in three versions, 2.0.X, 2.1.X and 2.2.X
• Apache LDAP API is supported in two versions, 1.0.X and 2.1.X
  

 This requires a lot of effort, with some backportings, releases, documentation, including migration howtos.

Is it necessary?

Yes, and no. yes, because when you are committed with a given version, migrating can really be a burden. The API change, the updated dependencies, all are going into your path.

So as a maintainer, you are going to make a choice at some point: when to deprecate a version and tell the users they *must* migrate. 

OTOH, a feature addition or an API change are not that frequent in decades old projects, so switching to a new version is not that frequent either.

The development environment

Projects are getting older, developers are leaving, and you are still around and in charge. This is a volunteer organization, nobody forces you but still: you have to deal with all those external evolution.

For instance, your projects were using SVN, and it's migrating to Git. Load of effort on you side !

Your favorite IDE is also evolving, and some developers are using an IDE you don't like or you do'nt want to spend days to learn. That's also something to deal with.

What about the build tools? We migrated from Maven 1 (yuk) to Maven 2 (slightly less worse) to Maven 3. Some were pushing to switch to Gradle. Still, you have to learn how to use each of those versions, and each of those tools.

GitHub was a big revolution, and nowadays almost all the tickets are submitted through a PR, while we are still using Jira. That means we have to regularly check both environment, and move PR from GitHub to Jira for a better followup: more work!

Did I mention the web site? In the course of 20 years, we moved from a static web site, to a generated one based on Confluence, then to the (now defunct) ASF CMS system, and lastly to Hugo. Again lots of work!

Is it worth it?

Yes! Because thousands of developers around the world are using those projects. Because it's rewarding. Fixing bugs is always an immediate satisfaction.

Bottom line, maintainers are dedicated persons who like keeping a clean place. And I'm proud of being one of them!

 

L'université Française, dans toute sa splendeur...

Ok, c'est pour bosser 6 h par semaine, donc au final, c'est bien payé ! (mieux vaut en rire...)

Le nouveau ministre de l'enseignement supérieur, Thierry Mendions, a du pain sur la planche. Heureusement qu'on a un gouvernement de gauche !

Allez, voici le mail : 

----------------------------------------------------------------------------- 

*OFFRE D'EMPLOI POUR UN POSTE D'ENSEIGNANT-E CONTRACTUEL**-LE*

*Intitulé :** Anglais 11ème section*

Nombre d’heures : 192  heures équivalent TD (réparties sur toute l’année
universitaire)
Rémunération mensuelle brute sur 12 mois: 1152 euros (sans doctorat) ou
1504 euros (avec doctorat)
Affectation : Université de Cergy-Pontoise, UFR LEI, département d'Anglais
LLCE - RER Cergy-Préfecture

Le département d'anglais de l'Université de Cergy-Pontoise recrute pour
l'année 2015-2016 un-e enseignant-e contractuel-le (contrat mi-temps sur
support vacant du 2nd degré). Les candidats doivent être titulaires (au
minimum) d'un diplôme d'études anglophones de niveau Bac + 5. Les candidats
certifiés ou agrégés devront demander à être détachés de l'enseignement
secondaire.

Les besoins d'enseignement sont principalement dans les spécialités
suivantes:
- civilisation américaine
- traduction (thème et version)
- histoire de l'art
- préparation à l'insertion professionnelle

Les pièces demandées sont les suivantes:
•    une lettre de motivation
•    un curriculum vitae
•    une copie des diplômes universitaires
•    la copie d'une pièce d'identité

Les dossiers sont à adresser par email exclusivement aux adresses
suivantes: xxxxxx@u-cergy.fr,  yyyyyy@u-cergy.fr et
zzzzzz@u-cergy.fr
-----------------------------------------------------------------------------


Pathétique...

Projet de loi relatif au Renseignement

Dans 12 jours, le gouvernement Français, profitant de l'émotion suscité par l'assasinat lâche de journalistes, va mettre aux votes une loi scélérate.

Il est de notre devoir de faire savoir à nos députés que nous n'acceptons pas de devenir citoyens d'un état (potentiellement) totalitaire. 

Le texte de loi est disponible ici.

Vous pouvez consulter ce site pour vous informer de la façon de contacter votre député.

Voici le mail que j'ai envoyé à Mr Goasguen, député du 14ème arrondissement :


Monsieur le Député,
vous avez l'honneur de représenter le 14ème arrondissement de la ville de Paris, dans lequel je suis domicilié. A ce titre, vous me représentez également.


Je me permets donc de vous interpeller sur le projet de loi qui est amené à être voté dans deux semaines. Celui-ci comporte des risques inacceptables sur les libertés fondamentales, tels que spécifiés dans l'article 811-1.

L'article 821-1 précise que l'autorisation de mise en oeuvre du recueillement d'informations relève de sept personnes :
- le premier ministre
- et 6 personnes qui ont délégation du premier ministre

L'exercice de cette commission de contrôle, dont la composition est hautement politique, violerait le principe de séparation des pouvoirs, principe fondateur de notre république, et préambule à notre constitution. Il n'est pas envisageable que cette entité distincte du pouvoir judiciaire puisse remplir un rôle qui est du ressort du judiciaire.

Voter cette loi serait donner raison à toute forme de terrorisme, rangeant la France dans le groupe des nations disposant d'outils de surveillance dignes de systèmes totalitaires. Non, l'assassinat ignoble de journalistes ne saurait justifier la mise en place d'un tel système, que ces journalistes auraient bien évidement rejeté avec la plus grande fermeté.

Je vous demande de faire ce qui est en votre pouvoir pour faire rejeter cette loi liberticide. Il ne s'agit pas ici d'une position politique, mais d'une position de principe. Votre devoir est de défendre les principes fondamentaux qui font la grandeur de notre république, au delà de tout attachement partisan.

Je vous remercie par avance,

Emmanuel Lécharny
7 Square de Chatillon,
Paris 14

I have a dream...

Ce dimanche, il fait un peu gris, la choucroute mijote dans le fait-tout... Il me reste une petite demi-heure avant de passer à table, la famille est en route, j'ai le temps de me laisser aller à une petite rêverie informatique.

Mon camarade Antonio Goncalves, un des organisateurs de Devoxx.fr (pub plug) se plaint de l'incapacité de l'administration à mettre en place une informatique qui fonctionne.

Qu'en dire ? Qu'un programme comme Louvois, lancé en 1996, abandonné en 2013 après avoir foutu à la poubelle dépensé 470 M€ puisse avoir été un tel echec est la preuve que l'état est incapable de gérer son informatique. Et des faillites équivalentes, il y en a : project Chorus (500M€), Dossier Personnel Médicalisé (500M€ pour 400 000 patients...), l'Opérateur National de Paye (750M€).

J'ai également en tête l'informatisation de la DGI, où l'état avait missionné deux énormes sociétés française (sans doute pour les sauver en ces années de bulle internet...), qui facturaient entre 1000 et 2000€ la journée, et qui avaient bien sûr des sous-traîtants, qui eux même prenaient des sous-traîtants... Ceux qui ont effectués leur déclaration par internet la première année se rappellent bien de la totale incapacité du système à ternir la charge à l'époque bien faible. Le project COPERNIC a coûté 1.5G€ (cf le rapport du sénat).

Bref, on se dit qu'il y a des marges de progression. Mais dans quel cadre technique, juridique et surtout organisationel ?

C'est là que je me mets à rêver. Je lisais il y a quelques mois cet article édifiant, où était décrit l'opération commando qui 'sauva' Obamacare. Je me dis qu'il devrait être possible de faire la même chose en France.

Nous avons un vivier d'Open Sourceurs, assez large en plus. Dans des domaines variés, qui couvriraient largement le spectre de l'informatique mise en oeuvre par l'état. Ce sont nos impôts qui financent ces échecs, et ce sont également nos impôts qui (sur)payent les systèmes qui finissent par fonctionner (mal). Ne serait-il pas possible de réunir assez de compétences pour remettre en état un de ces systèmes, à coût nul pour l'état, pour un résultat fonctionnel, mais également moins onéreux en fonctionnement ?

L'idée - le rêve - serait de mettre à disposition d'un des projets en souffrance une équipe pluridisciplinaire compétente, disponible, et cela gratuitement.

La gestion de projet serait totalement collaborative, sans la contrainte temporelle et budgétaire si mortifère dans un cadre contractuel classique : à savoir que l'on se focaliserait sur les fonctionalités, les performances, l'évolutivité et les tests, au lieu de se limiter à livrer dans les temps, à l'aide de stagiaires si besoin (vécu...).

On s'épargnerait la recherche du profit - ou plus souvent la limitation des pertes dans l'espoir de se refaire grâce à de substantiels avenants que le client se voit bien obligé de signer... -, au profit de la satisfaction du 'client' - c'est à dire, le citoyen -.

Il serait possible de dire non, mais également de remettre en cause les choix initiaux, puisque l'objectif est d'aboutir à un système fonctionnel, sans craindre un clash avec le client. La relation avec ce dernier serait de même bien plus confortable, car on éviterait d'accumuler les "preuves" de malfaçons et de non respect des délais et des fonctionalités, puisqu'aucune pénalité de retard ne serait en jeu.

Bien sûr, on ne peut imaginer disposer de quelque dizaines d'informaticiens compétents pendant une période de six mois ou un an sans les payer, alors - second rêve - j'imagine un système de sponsoring, ou de crowdfunding permettant de financer cet effort.

Et pourquoi pas ?

A condition que les lobbies, puissant, des SSII, laisse faire, bien sûr : la fonction publique est une source majeure de revenu récurrents pour ces sociétés. Et que le droit administratif ne vienne pas se mettre au travers d'une telle démarche : comment éviter de passer au travers d'un appel d'offre public?

Dernier point : pourquoi ne pas profiter de ce cadre pour former ? Au lieu d'envoyer des stagiaires achever des projets comme on achève les chevaux, on les enverrait se faire former dans un cadre plus souple, et surtout par des personnes compétentes, et disponibles. Ce serait aussi l'intérêt des SSII de 'sponsoriser' un projet donné, par délégation de personnel : après tout, il n'est pas si fréquent de pouvoir se confronter à des problématiques complexes dans un cadre réel, sans les contraintes habituelles. Un lieu magique où la recherche de solution serait possible, un projet Manhattan à la Française en quelque sorte...

Et pour 50 personnes, payées - soyons généreux - 100 000 € par an, plus 2 M€ de frais de fonctionnement (ordinateurs, locaux, télécom, frais divers), soit 7M€ par an, allez, 10M€ en intégrant les charges sociales, je serai surpris qu'on n'arrive pas à produire quelque chose qui fonctionne, à comparer aux coûts délirants des projets nommés ci-avant...

On pourrait même imaginer les faire tourner dans un cloud Français ! (Ok, là,  je parle d'un vrai cloud, pas d'une sorte de FranceStein du cloud financé par vos impôt, hein !)

Ok, je rêve... Mais après tout ?

Et vous, il vous arrive de rêver aussi ?

Allez, la choucroute m'attend...

About Perfection and OSS

From time to time I feel like we all have our own Moby Dick, and when it comes to OSS, it's name is 'perfection'.

Those shiny moments of pure joy, this warm feeling that surround you, when you can say 'mission accomplished' are rare and vanishing periods when you work on a never ending project. Its more or less when you get a big bug fixed, or when you read some enthusiast review on the project you are working on.

Fixing a bug is probably the best way to get this reward, as you know that you have made some progress.

It's forever shadowed by the constant pain of knowing that there are other bugs, and that in order to get a release done, you had to make some choices, leaving problems behind.

Is it a sad story about being a developer? No. It's not sad. It's tough, it's long, it's an endless job. Would I prefer doing something else? Certainly not ! At least, I know what I'm chasing, and even if I rarely foresee this fading perfection, sometime, I can almost touch it. Not something you can experience when you work in a company, as you don't have the opportunity to polish the project as much as you want, due to time constraints.

Last, not least, you are not alone. When you think that you are turning in circles, you know that the community you are part of will help you. Use it : they have the clues you don't have.

An Arabic proverb says "It's not that the way is painful, it's just that the pain is the way". So you better deal with it.

Free ADSL, où comment ne pas avoir d'ADSL pendant plus d'un mois...

Ne plus avoir d'électricité pendant 2 jours, sauf en cas de tempête, est juste inconcevable en France. Pour une connexion ADSL, vous pouvez rester coupé pendant plus d'un mois sans que cela ne semble soucier votre provider, en l'occurence Free.

On ne parle pas d'un village au fond d'une vallée reculée du haut morvan, là. C'est à Puteaux, dans la proche banlieue parisienne.

Tout commence par une intervention sur une ligne par l'opérateur historique, le 24 septembre 2014. Résultat, une ligne ADSL dont le débit chute brutalement à 500Kbits (54db) au lieu de 10Mbits (42db). Typique d'une ligne abimée, ou d'un signal affaibli par une interaction magnétique ou un cable de mauvaise qualité.

Et là, la boucle infernale commence : ouverture de ticket d'incident chez Free, une semaine de délai avant vérification des équipements (et oui, c'est toujours chez vous que le problème se situe, par défaut !), puis suite à la vérification du bon fonctionnement de l'équipement, on bascule chez l'opérateur historique (entendez FT), par le biais de ce qui s'appelle un GAMOT. C'est encore une semaine d'attente...

Suite à quoi, généralement, FT ne détecte bien sûr aucun problème, et ferme le GAMOT. Vous venez de perdre 2 semaines...

Voilà, vous devez réouvrir un ticket chez FREE, qui va cette fois devoir aller plus loin que de constater que votre matériel fonctionne bien et rouvrir un second GAMOT. Puisque qu'aucun des deux opérateurs ne reconnaît un problème chez lui, c'est qu'il doit y avoir un problème entre les deux...

(Entre temps, votre voisin, qui est abonné chez FT, lui, a été rétabli dans les 2 jours...)

Que se passe-t-il lors de cette "procédure d'expertise" ? Et bien les deux sociétés font intervenir deux techniciens pour tester la connection de bout en bout. Généralement, ils découvrent à cette occasion un mauvais branchement, et le rétablissement a lieu - si tout va bien ! -.

En pratique, il faut compter un bon mois, parfois moins, parfois plus.

Et ce n'est pas normal.

Dans le meilleur des cas, on parlera d'incompétence, mais reste à savoir chez qui. En pratique, la question de la procédure mise en place chez les deux sociétés (et on peut imaginer qu'il en est de même avec d'autres opérateurs tiers) a pour résultat une distortion claire des règles du jeu : si vous êtes chez l'opérateur historique de bout en bout, vous êtes rétabli en 2 jours. Dans le cas contraire, chacun se renvoit la balle pendant un bon mois...

Free n'ouvre un GAMOT qu'après avoir vérifié l'équipement, très certainement à cause des coûts facturés par l'opérateur pour le traitement du GAMOT, dans les cas où le problème viendrait du matériel ou d'un problème de connection au domicile. Pourquoi pas, sauf qu'il faut compter une bonne semaine pour avoir un rendez-vous avec un technicien...
L'opérateur historique va de son côté faire le minimum, à savoir tester la synchro,  puisque généralement cela suffit pour détecter un pb de connection, bien évidemment sans régler votre problème de débit !

La question qui se pose à ce point, c'est de savoir s'il n'y a pas dans ce protocole d'intervention une volonté active ou passive de favoriser les clients de l'operateur historique ? On ne parle pas évidemment de l'incapacité de l'opérateur alternatif à fournir un service après-vente digne de se nom, faute de disposer du personnel suffisant...

A ce point, après un mois sans service, il convient de se poser la question du recours en justice, éventuellement dans le cadre d'une "action de groupe" - puisque c'est aujourd'hui chose possible en France - pour sortir de ces parties de ping-pong infernales ! Mais sauf à condamner lourdement les opérateurs, pour les forcer à réduire ces délais inaceptable, je ne vois pas comment les choses pourraient évoluer.

Mais ne rêvez pas, même dans cette hypothèse, la procédure prendra des années... Il faudra d'abord s'adresser à une société de défense des consommateurs agréée (il y en a 17), et espérer qu'elles acceptent de lancer la procédure. Cela ne préjuge en rien des délais d'obtention d'un jugement - sans compter qu'il peut être rendu en faveur des opérateurs -, sachant que ces derniers peuvent évidemment faire appel, se pourvoir en cassation...

Cela dit, il y a un moment où l'inaction vaut acceptation...

Building castles in the sand...

Now that the fury about OpenSSL is gone, and that we realize first it was not that critical (only 7% of the web sites seemed to be at risk, not two third), and second that it could have been used for two years, but we don't know if it has been (we are waiting for a new Snowden), we can think about what the lessons we can get from this tragic episod.

There are a few, IMHO.

1) OpenSSL is a group of 17 persons, all volunteers. I'm not sure that all of them are active. This is a small bunch of people, for a software that is used at wild. Do people realize that most of the components they are using daily, that they *trust*, are written by such a few developpers?

What if the group decides it's enough ? That family is more important than spending hours on debugging some code, on testing it, and on documenting it ? All of that for the simple feeling of writing good, useful code ?

2) It took 2 years, 2 freaking years, before a company called Google was able to find the issue. What does that mean ? Simply that companies like Yahoo!, which were one of the big IT companies being hit hard by the HeartBleed bug, just didn't do their due diligence.

It's insane to think that those companies are spending BILLIONS of $ buying crappy other companies, trying to improve their load of turd^H^H^H social tools, when they are too cheap to spend a few hundred of thousands dollars to get some expert looking at the code they are using.

Shame on them.

3) Low level components are just left alone. Those days, it's all about the big frameworks, nobody cares about the bricks that are at the very base of our IT.

And that scares the shit out of me, as it should scare any one of you.

We are all expecting that the bricks we are using every day are safe. We are ignoring the risks we are taking, just because we can't check everything. But again, when you look at the commits, you realize you are depending on very few people...


Bottom line : we are building castles in the sand. And I don't even know how we could do any better...

Les développeurs, un atout pour la France ?

Il y a quinze jour, quand j'ai appris que Tariq Krim avait pondu une liste des cents meilleurs développeurs français, je me suis dit - et j'ai dit - que c'était totalement crétin.

Je le pense toujours. Tout d'abord parce qu'il y a officiellement 600 000 informaticiens en France (plus ou moins) et que je ne vois pas comment Tariq a pû tous les rencontrer pour constituer sa liste...

Comme le disait Jean-Laurent Morlhon en réponse à un de ses contacts : "Mais qu'est-ce que tu en as à foutre de pas faire partie de cette liste? Tu l'a jamais rencontré, ce gars...", alors, il y a effectivement de fortes chances qu'il s'agisse d'une liste des 100 meilleurs développeurs que Tariq a rencontrés...

Mais, bon, ne nous arrêtons pas à cette aspect bassement marketing, après tout, ça donne de la visibilité. "Dites-en du bien, dites-en du mal, mais surtout parlez-en autour de vous" !

Tariq a également pondu un rapport à destination de Mme Pellerin (dont on ne sait pas aujourd'hui si elle sera encore ministre dans une semaine, mais c'est une autre histoire ;-). Le contenu de ce rapport est intéressant, et mérite qu'on s'y attarde.

Si on met de côté quelques erreurs factuelles (non, Be Inc n'a pas inventé le Journaled File System, IBM a sorti JFS avant que Be Inc soit créé.), et ce côté "petit village gaulois qui résiste" qui devient agaçant quand ce n'est pas en BD, certains constats et propositions sont pertinents.

Mais revenons deux minutes sur le "village gaulois". Même Asterix essaye de comprendre le monde dans lequel il vit, au lieu de se focaliser sur ce qui se produit "au village". Il faudra un jour qu'on m'explique en quoi un cerveau français est supérieur - ou inférieur - à un cerveau guatemaltèque ou coréen... Surtout que le petit français qui a bossé sur le projet X n'a très certainement pas travaillé tout seul ou qu'avec des français ! Et qu'il y a certainement autant de petits finlandais, allemands, espagnols, etc qui participent aux projets que tout le monde utilise... l'intelligence est distribuée, et peut même agir à distance (même quand des crétins^H^H^Hpremiers ministres décident de couper Twitter ou internet!).

Cela étant dit...

• Un immense marché linguistique : c'et absolument clair. 400 millions de clients potentiels, sans Loi Toubon, ça aide...
• Sur le rôle des VCs, c'est assez ambigu. Voir une boîte qui développe un jeu à la con pour mobile toucher 10M$ de capital risque, ça m'en touche une sans en bouger l'autre. Est-ce que ça favorise l'innovation ? Pas sûr... Quelle est la valeur ajoutée de ce type d'investissement ?
• Le CIR : franchement, c'est la plus grosse arnaque^H^H^Hmartingale de ces 20 dernières années : http://fr.wikipedia.org/wiki/Cr%C3%A9dit_d%27imp%C3%B4t_recherche#Critiques. En dehors d'être une ENORME usine à gaz qui enrichit les banques et leurs conseillers (qui n'hésitent pas à vous proposer une aide pour remplir les dossiers, moyennant jusqu'à 25% du montant de cette aide !!!), c'est également une aide dont bénéficient principalement les banques et les assurances et les très grosses entreprises...
• Les réussites françaises : ok, il y en a peu (Catia ? what else ?). En même temps, combien de leaders mondiaux allemand ou anglais dans le logiciel, à part SAP ?
• Les opportunités d'affaire : là, je suis 100% en accord avec ce qu'écrit Tariq. Les grosses entreprises françaises sont viscéralement attachées à la notion de ROI et de centre de coûts. Sauf à être le fils de X ou le neveu de Y, qui a fait polytechnique et qui est en poste assez haut dans une grosse entreprise, vous ne trouverez pas d'entreprise pour prendre le pari de vous verser 500K€ pour utiliser votre proto, simplement sur votre gueule et 5 slides. Ca n'existe pas. La prise de risque est simplement une notion étrangère pour les grosses entreprises en France.
• La commande publique... Quiconque a rempli les nombreux documents (DC1, DC2, etc) sait que c'est un enfer administratif. Si vous êtes une PME, laissez tomber. De toutes façon, vous serez payé avec 6 mois/un an de retard, si vous êtes sélectionné, bien sûr (et qu'on ne vienne pas me dire que la sélection n'est pas biaisée...)
• La politique des grands groupes vis à vis de l'open source. Alors c'est simple : pour eux, c'est GRA-TUIT. S'ils ont besoin d'une assistance sur un composant et qu'un français est un des développeurs de la solution, et bien si une SSII peut proposer un développeur "spécialiste", pas de soucis : la SSII sera choisie, parce que le service achat a enregistré la grosse SSII ! Parceque ça se passe comme ça : on demande au service achat à qui on  peut s'addresser pour du support sur un composant X ou Y, et on a une liste de contacts (liste pré-établie après négociation annuelle).
• Les développeurs non reconnus ? Oui. Si a 30 ans, tu n'es pas chef de projet, ta Rolex, tu peux aller la chercher chez Swatch...
• Concernant le "grand tournant" technologique à prendre, ou ce qui est appelé "feuille de route technologique", désolé Tariq, mais les technos changent toutes les 3 ans, donc il faut pas venir nous raconter qu'il faut lancer un plan quinquénal sur Node.js ! Par contre, qu'il y ait des centres d'expérimentation avec retour d'expérience au sain de l'administration française, oui, ce serait une super idée...
• Un Github français ? Mais quelle drôle d'idée... Cela dit, ce n'est pas forcément idiot, c'est juste totalement impossible d'imaginer une structure étatique à même de gérer cette infrastructure de façon assez souple et intelligente. Et si on confiait le boulôt à Cloudwatt ??? Je plaisaaaante...
• Je suis 100% d'accord avec l'idée de promouvoir les développeurs dans l'administration. je suis intimement convaincu qu'il y a des milliers de développeurs frustrés dans les services administratifs qui feraient mieux que les prestataires payés à prix d'or. Mais il faudrait aussi laisser percoler vers le haut les meilleurs d'entre eux, sachant qu'ils ne sortent pas tous de X ou de l'ENA ! Une gageure...
• Concernant les "startup disruptives", ça relève du secteur privé. Que les investisseurs français ne souhaitent pas risquer l'argent qu'ils ont planqué à Jersey, ce n'est pas le problème de l'état. De toutes façon, ce ne sont pas les développeurs qui vont toucher le pactole au final...
• La formation... Si on évitait de saboter l'université à coup de coupes budgétaires, déjà... Un maître de conférence de 40 ans va gagner grosso-modo ce que gagne un ingénieur junior avec 2 ans d'expérience. Et il faut s'étonner de la médiocrité de l'enseignement ? (En fait, ce qui est miraculeux, c'est que le niveau de l'enseignement ne soit pas si faible : il faut tenir compte de la passion et de l'abnégation de tout ces enseignants chercheurs, qui se font CHIER toute l'année durant à se faire rembourser avec 9 mois de retard leur chambre d'hôtel à 45€ pour la conférence qu'ils ont donnée l'année dernière, avant que les budgets soient coupés...)
• Visa de travail : why not... C'est vrai que c'est l'enfer d'employer un travailleur qui ne vient pas de la CEE !

Voilà, il y a du boulot mais je ne sais pas pourquoi, j'ai comme m'impression qu'en terme de timing, ce rapport arrive au plus mauvais moment.

Je le trouve tout de même globalement intéressant.

Courteline, 2014...

Cela fait bientôt dix ans que je paye mes impôts sur internet. A part les premières années, où c'était compliqué - surcharge du serveur, mise en place de certificat, etc -, tout fonctionne.

Le gouvernement a lancé ce qu'il appelle un "choc de simplification".

On en voit les conséquences au fur et à mesure. Par exemple, le recensement peut se faire sur Internet.

Mais c'est lent. Très lent...

Typiquement, si vous organisez une conférence en France, et que vous voulez faire venir des intervenants de pays "exotiques" - l'Inde par exemple..., il vous faudra passer par toute une série de mesures vexatoires, mais surtout inutiles, pour bien vous faire sentir que quand même, il y a un énorme risque que l'intervenant demande l'asile politique ou simplement décide de rester en France, ce pays merveilleux où les écoutes téléphoniques sont légales (mais c'est une autre histoire).

Typiquement, vous devez produire la preuve que :

• vous avez de quoi héberger la personne chez vous si vous vous proposez de l'accueillir
• vous gagnez assez d'argent pour assurer sa présence (comptez 50€ par jour, amenez votre feuille d'imposition)
• vous habitez bien là où vous prétendez habiter (prévoir au moins 2 justificatifs de domicile)

Par ailleurs, il vous faudra acquitter la modique somme de 30€ pour ces démarches terriblement utiles, et bien sûr, sous la forme d'un timbre fiscal. Oui, un TIMBRE en papier...

Du côté de l'intervenant, c'est encore pire :

• demande de visa au moins 1 mois à l'avance
• visite au consulat le plus proche (compter 600km en moyenne en Inde, il n'y a que 3 consulats français en Inde)

 Bref...

Ce matin, je décide de faire établir une procuration pour les élections municipales qui arrivent à grand pas. Je n'ai jamais raté une élection, mais là, je serai aux Etats-Unis. Qu'à cela ne tienne...

Donc, hop, choc de simplification en action, suite à une campagne de publicité sur toutes les radios publiques ("Oui, vous pouvez vous simplifier la vie en remplissant votre procuration sur internet". Mon cul !)

Déjà, impossible de le faire en ligne. Il faut se rendre au commissariat de police (ils n'ont que ça à foutre, j'imagine !) ou au tribunal d'instance. En même temps, il y a 2.5 millions fonctionnaires d'état, il faut bien les occuper. Ok, pourquoi pas...

Mais arrivé là-bas avec mon formulaire rempli, on me dit qu'il faut remplir à la main la fiche cartonnée qui n'est que l'exacte reproduction de ce que j'ai apporté.

La raison ? Aucune. "Une circulaire nous interdit d'accepter les formulaires CERFA imprimés mais remplis à la main...".

Ben voyons...

Et me voilà en train de remplir A LA MAIN le formulaire cartonné...

2014... Relire Courteline...

LDAPCon 2013, November 18-19 in Paris, France

The fourth International Conference on LDAP (LDAPCon) will take place in November 18-19 in Paris, France.



The International Conference on LDAP is a technical forum for IT professionals interested in LDAP and related topics like directory servers, directory management applications, directory integration, identity and access management, and meta directories.

It focuses on implementation and integration of LDAP servers and LDAP-enabled client applications. The event will bring together vendors, developers, active and prospective LDAP practitioners to share their experiences about deployment strategies, service operations, interoperability, discuss LDAP usage in new projects and learn about upcoming trends and developments.

A Call for Papers has been raised. You have up to September 8th 2013 to submit your talk. You can find all details, important dates or topic ideas on the LDAPCon CFP page.

Clueless...

Sometime, when moderating some Apache mails, you find jewels like this one :

LinkedIn 
------------    

Apache,  

I'd like to add you to my professional network on LinkedIn. 
 
- Chris  

Chris XXX Lead XXXXXX Technical Recruiter at YYYYY 
San Francisco Bay Area 

Release issue...

We are facing this issue for months (years ?), and I still don't understand why...

One upon a time, we cut a release on one of my favorite projects (Apache MINA, Apache Directory Server, Apache LDAp API, Apache LDAp Studio), and we regularly get a message like :

#mvn release:prepare
...
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) on project project: Unable to tag SCM
[ERROR] Provider message:
[ERROR] The svn tag command failed.
[ERROR] Command output:
[ERROR] svn: No such revision 1138066

which is simply a nonsense. We have a workaround, it's a mater of running :
svn up
and replay the release command, which will succeed.

However, this is just an annoyance that I would like to see removed from our path.

Does anyone has a clue about what's going on ? I would be grateful (even if I just have an explanation like "it's a referenced bug in SVN").

LDAPCon 2011 : Call for papers !

LDAPCon 2011

The third International Conference on LDAP (LDAPCon) will take place in
October 10 – 11 in Heidelberg, Germany.

The International Conference on LDAP is a technical forum for IT professionals interested in LDAP and related topics like directory servers, directory management applications, directory integration, identity and access management, and meta directories.

It focuses on implementation and integration of LDAP servers and LDAP-enabled client applications. The event will bring together vendors, developers, active and prospective LDAP practitioners to share their experiences about deployment strategies, service operations, interoperability, discuss LDAP usage in new projects and learn about upcoming trends and developments.

The conference language is english.

Call for papers : http://www.daasi.de/ldapcon2011/index.php?site=cfp

La SNCF, non, ce n'est pas possible...

Pourquoi les voyageurs préfèrent-ils prendre une voiture plutôt que le train ?

Dire que la SNCF fait des efforts pour rendre le voyage en train plus facile et moins coûteux, c'est simplement une vue de l'esprit, au mieux.

Aujourd'hui, dans le cadre d'un week-end de geeks au mois d'avril, nous nous sommes mis d'accord pour réserver 4 places dans un TGV, 2 mois à l'avance. 3 d'entre nous sont pères de famille nombreuse, donnant le droit à 30% ou 40% de réduction.

Prix unitaire du billet Paris/Grenoble ? 22€ à l'aller.
Prix pour 4 places ? 140 € ...
Prix unitaire pour le même billet mais en indiquant une remise Famille Nombreuse ? 35 € !!!

Alors je pose la question : de la gueule de qui se fout-on à la SNCF?

C'est bien la peine de passer à Drupal si c'est pour offrir des tarifs aussi totalement débiles !

Oracle, Javacle et l'ASF, ma vision du problème.

Donc The Apache Software Foundation a décidé de quitter l'Executive Community du JCP , conformément à sa position clairement exprimée en novembre.

La raison? Oracle a décidé unilatéralement de ne pas respecter les termes du contrat qui le lie à l'ASF (le fameux JSPA), et plus spécifiquement le paragraphe 5.C :

"Other than as set forth above, the Spec Lead agrees not to impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations."

En clair, ne pas fournir à l'ASF l'accès au TCK sans y ajouter une restriction d'usage (FOU) est une violation de ce contrat.

On peut bien évidemnt arguer que OpenJDK couvre le besoin d'un Java libre, puisque GPL et disposant d'un TCK sans FOU.
Sauf que si vous forkez OpenJDK, Oracle se réserve le droit de faire un procès pour violation de Patent (bien sûr, Oracle n'est pas assez stupide pour attaquer une fondation comme l'ASF, cela ne lui rapporterai rien, quand il suffit de pratiquer à grande échelle le FUD, en menaçant implictement les utilisateurs de ce fork).

Tout cela est bien résumé (en anglais) dans ce post : http://skife.org/java/jcp/2010/12/07/the-tck-trap.html.

Alors, OpenJDK, une issue de secours? Non. Un miroir aux alouettes, un cache-sexe. En tant que tel, OpenJDK est effectivement une solution temporaire pour ceux qui travaillent sur un Mac, par exemple. Le problème, c'est qu'il n'y a aucune garantie sur le long terme qu'Oracle et ses affidés ne laissent pas OpenJDK dépérir, au profit d'une version bien évidement plus puissante du langage, mais payante.

Procès en sorcellerie ? Certainement pas. Il faut ouvrir les yeux : Oracle n'est pas une entreprise philantropique, elle ne respcte aucune règle, elle les créés ! Pourquoi se priver d'exercer son pouvoir quand il n'y a pas de shérif ?

Cela touche du doigt l'origine du problème : la confusion entretenue par ces sociétés sur la signification de l'Open Source. Pour elles, Open Source = Source - IP. Vous pouvez regarder, utiliser, éventuellement contribuer, mais tous les bénéfices reviennent à la société qui gère le projet.

C'est la privatisation du profit et la mutualisation du travail.

L'open source, c'est d'abord une question de gouvernance, et c'est ce pour quoi l'ASF se bat. Il n'y a pas de liberté sans une gouvernance partagée. En politique, ça s'appelle la démocratie, en opposition à la dictature, la ploutocratie, l'oligarchie ou tout autre système de captation de pouvoir. Ce n'est pas pour rien que la devise de l'ASF est :

Community over code

Qu'est-ce que cela signifie pour Java ? Pour l'instant, pas grand chose. Tout un chacun peut l'utiliser, mais cela ne durera pas. Mais il est temps de penser la suite, et cette suite devra être totalement indépendante de sociétés comme Oracle.

L'ASF peut-elle être force de proposition ? Harmony peut-il devenir la base universelle et réellement open-source que Java aurait dû être? Sans aucun doute. Mais il y a du travail.

Alors, laissont agir la communauté :

3000 committers Apache ne peuvent pas se tromper !

Bye bye summer time...

So we switched (in Europe) from summer time to winter time. At 3am, it's 2 am again. So what ?

Well, I was running some tests on my computer before crashing, and I was quite surprised to get an error in a part I didn't modified today and which was running fine this afternoon. What was wrong ?

We use some class to generate CSN (Change Sequence Number), and obviously we have some tests for this class. One of them failed for one hour...

Here is the test :

public class CsnTest
{
private SimpleDateFormat sdf = new SimpleDateFormat( "yyyyMMddHHmmss.123456'Z'" );

@Test
public void testCSN()
{
long ts = System.currentTimeMillis();

Csn csn = new Csn( sdf.format( new Date( ts ) ) + "#123456#abc#654321" );

assertEquals( ts/1000, csn.getTimestamp()/1000 ); <<---- This assert fails.

Why did I get an error ? Because the way we create the CSN is simply wrong : we don't take into account the fact that the computer is not necessarily always using the same time zone, and that some operation assumes that it got a GMT based time, when other uses the Locale.

Be extremely cautious when dealing with dates and time zones : you may get a very bad surprise in production, instead of experimenting those errors by chance, just because you are running tests at 2:30 am a Saturday before going to bed !

Maven community is sometime a strange world ...

3 years ago, I submitted a patch for the Maven antlr plugin. Something quite simple that took me 1 hour to whip, test and to send as a JIRA [1]

It took 6 months for this patch to be applied, something I can understand.

However, 3 years after the code has been patched, I can't get the plugin from the Apache repository, where it was before. Why ? Because the project has been moved from Apache to Mojo. The reason ?

"A release could be done shortly but I would like to move the maven-antlr-plugin and maven-antlr3-plugin (in sandbox) to Mojoproject.

During the last year, I am the main committer on this project. Recently, David Holroyd provided a new plugin that supports Antlr v3, and submitted some patches. Unfornately, he is not an ASF committer. I could take care of David's patches but I think it should be good to give a new life of this project in the Mojo land. It would be more easy to give access to David, so he could maintain it as he wants. " [2]

What's wrong in the Maven community if they can't make someone who is obviously proposing patches and is a wanna-be committer if they have to move the project out of Apache to get this guy working on the project ? Voting process is too complex ?

Seriously, I don't get it ...

PS : of course, I can get the plugin from the Apache repo, but not at the same place. It's now available on [3].


[1] http://jira.codehaus.org/browse/MANTLR-14
[2] http://maven.40175.n5.nabble.com/vote-Move-the-maven-antlr-plugin-to-the-mojo-project-td204608.html#a204608
[3] http://repo1.maven.org/maven2/org/codehaus/mojo/antlr-maven-plugin/2.1/

Twitter failures...

It seems that Twitter has reached is limits a few weeks ago, with daily failures since then.

I'm just wondering if Twitter's developpers are french, with a project manager named Domenech, and a top developper named Anelka.

Or maybe I'm mixing failures : in any case, if we use the french soccer team as a base to measure other teams failure, then Twitter is just experiencing small bumps on the road atm...

Microsoft is shooting itself in the foot

So today I received a phone call from the Microsoft 'client support' (so called) entity.

It's pretty clear that they are more into following a process, even if it's totally stupid, than helping customers. (remind me Dr Strangelove, when the guy can break a CocaCola machine to get the 10 cents he needed to give a phone call that would have saved the world ...).

Instead of solving my simple issue with a simple solution (namely, providing me the KEY that is associated with the installed product, which is different from the product we bought - a Windows 7 premium. Probably because the DVD was badly stamped before being put into the box), they keep going insisting that we install a new version, losing 2 more hours plus having to reinstall all the side products.

Seriously, it's time to think about switching to some more friendly system, people. Ubuntu is quite usable, so is Mac OSX (but you might face the exact same problem). In any case, making 25% margin is just a shame when the UQOS (unquality of service) provided is so high : basically, you are on your own.

Coupled to the fact that they have delegated the first level support to external companies in low cost countries (profits, it's all about profits), it makes it pretty obvious that Microsoft is equivalent to what IBM was back in the 1990.

The butterfly is now just an elephant, not a dancing one... Sea elephant on the shore.