Loi de Leess et syndrome de l’usine à gaz

Si l’on considère l’évolution de la performance des ordinateurs au cours du temps, on prétend qu’elle double tous les 18 mois.

Mais si l’on considère l’évolution de la performance des logiciels, on constate qu’elle reste stable (dans le meilleur des cas).

D’où la loi de Leess qui constate que la performance des programmeurs (maintenant appelés développeurs) est divisée par 2 tous les 18 mois.

On pointe ici du doigt les programmeurs mais c’est toutes les couches sous-jacentes qui sont concernées : système d’exploitation, langages de programmation et méthodes.

L’illusion de l’amélioration des performances

A l’occasion d’une mise à jour (imposée) du système d’exploitation d’un serveur utilisé dans un contexte de travail réel, il a été nécessaire d’adapter les accès à la base de données en langage “orienté objet”. La préparation de ces adaptations a été faite sur un serveur plus récent dont les performances sont objectivement meilleures. Un gain de temps pour les tests était naturellement espéré. Et bien, non : c’est plus lent.

En comparant les temps de traitement de l’extraction la plus complexe de l’application portée entre le serveur de développement installé avec la “vieille version” et le nouveau, plus performant, installé avec la nouvelle version, tous les autres aspects restants identiques par ailleurs on constate une augmentation de ces temps de traitement de plus de 50 % !

Le syndrome de l’usine à gaz

En quoi cela consiste ?

Laissez un développeur s’attarder sur un sujet. Après en avoir résolu les fondamentaux, plutôt que de consolider et optimiser son code, il va s’attaquer aux fioritures (les petits plus au mieux superflus, voire inutiles ou même préjudiciables). Un jour son truc fini par devenir impossible à maintenir, même pas par son auteur original. Alors, celui qui se dévoue pour poursuivre jette tout et recommence (le cycle complet : une première solution simple et efficace, puis les fioritures, etc.).

On trouve un raffinement supplémentaire dans les options de commande en ligne et, encore mieux, dans les fichiers de configuration. Ah, ces fichiers de configuration, un régal !

Les exemples sont nombreux. Un des premier à qui on pourrait attribuer le syndrome de l’usine à gaz, c’est sendmail. Le type qui s’en est occupé a réussi à créer un langage de développement qui s’exprime dans les fichiers de configuration !

Et avec l’installation d’un nouveau serveur utilisé avec le système d’exploitation le plus récent, on observe une tendance qui se confirme : protéger son serveur des pirates est de plus en plus passionnant.

  • les processus de base changent et, surtout, ils deviennent de plus en plus diserts sur les journaux système,
  • cela en devient presque un travail d’IA de repérer les informations pertinentes pour la sécurité du serveur tellement elles sont noyées dans un flot d’informations inutiles,
  • la configuration par défaut des systèmes de protection est plus permissive,
  • l’organisation et la syntaxe de leurs fichiers de configuration est plus complexe et incompatible avec celles des versions précédentes.

Le must, c’est de voir que les regex sont encore plus illisibles qu’avant ; on n’aurait pas cru que ce serait possible !

Ah oui, on apprécie un détail croustillant : on ne trouve plus de vraie documentation…

Et dire que non seulement tous ces petits jeunes qui réinventent la roue donnent du boulot à tous les administrateurs mais en plus ils le font gratuitement !

 

Hôtel, location, copropriété : les différents types d’hébergement web

Si si, on parle bien d’hébergements “web” ici : de solutions pour profiter d’un espace de traitement et de stockage “en ligne” c’est à dire connecté à Internet.

Le clin d’œil aux différents types d’hébergement au sens plus classique est à la fois une métaphore pour donner une indications imagée sur les particularités des choix possibles et aussi parce que leur équivalents techniques (mutualisés, virtuels, dédiés) sont nettement moins lisibles.

Hébergement mutualisé (l’hôtel)

Un hébergement mutualisé, c’est comme une chambre d’hôtel : on s’occupe de tout à votre place en contrepartie d’une liberté et d’une confidentialité limitées. Et il y a aussi plusieurs niveaux de conforts (et de prix).

Les principaux inconvénients d’un hébergement mutualisé sont d’avoir des choix techniques imposés et un accès limité aux systèmes sous-jacents. La première limite est à considérer lorsque l’on choisit l’hébergement pour s’assurer que ses caractéristiques sont compatibles avec les configurations minimales exigées pour ce que l’on souhaite faire. La deuxième limite apparaît en cas de problème, lorsque les possibilités et moyens d’investigations font défaut où lorsqu’on veut déménager.

Le deuxième inconvénient d’un hébergement mutualisé est le risque de “voisins bruyants” et là les termes techniques et classiques coïncident. En effet, les ressources (processeur, mémoire, disque, réseau) sont partagées entre plusieurs utilisateurs. Si l’un d’entre eux se met à faire des traitements lourds avec des accès aux disques fréquents et d’importants échanges par le réseau alors tous les autres voient les performances de leur hébergement fortement dégradées. Bien sûr il y a des limitations mais elles ne suffisent pas toujours à prévenir les abus.

Pour ce qui concerne la confidentialité d’un hébergement mutualisé, c’est simple : elle est tout à fait correcte entre utilisateurs et nulle vis à vis de l’hébergeur.

Un hébergement mutualisé présente quand même un avantage considérable : tous les aspects techniques sont pris en charge par l’hébergeur : installation, configuration, sauvegardes, surveillance et dépannages.

Le serveur dédié (la copropriété)

A l’opposé de l’hébergement mutualisé, le serveur dédié offre les libertés maximales autant pour les choix techniques que pour les accès au système. On dispose d’un ordinateur pour soi tout seul et on peut en faire ce que l’on veut. La contre partie évidente est qu’il faut tout faire soi-même et tout assumer.

Il y a quand même des “parties communes” d’où l’analogie avec la copropriété dont notamment la connexion en réseau avec Internet et le “data centre” (bâtiment, alimentation électrique, …) qui reste toujours sous le contrôle et la maîtrise du fournisseur de même que les interventions physiques sur la machine comme par exemple un changement de disque, de mémoire ou d’autres composants de l’ordinateur.

Par contre la confidentialité est maximale. Elle n’est cependant pas totale puisque l’hébergeur dispose d’un accès physique à la machine : une petite panne fortuite et hop on en profite pour faire une copie du disque. L’interruption sera visible pour le propriétaire du serveur dédié mais pas ce qui s’est passé pendant l’anesthésie générale.

Le serveur virtuel (la location)

C’est une solution mixte des deux précédentes. On dispose des mêmes avantages (et contraintes) que celle d’un serveur dédié mais celui-ci est en réalité une fraction partagée d’un serveur dédié.

On retrouve les inconvénients d’un hébergement mutualisé : les conséquences potentielles de “voisins bruyants” et une confidentialité limitée, les espaces de stockage étant librement (et discrètement) accessibles à l’administrateur de la machine. En revanche, si les pannes matérielles peuvent toujours avoir des conséquences néfastes, elles sont gérées par l’hébergeur.

Lequel choisir ?

Le choix entre un hébergement mutualisé, un serveur virtuel ou dédié est d’abord une question de compétences plus qu’une question de prix. Il faut disposer des compétences d’un informaticien professionnel pour être capable de gérer un serveur dédié ou virtuel. Donc pour celui qui ne les a pas, le choix est vite fait.

Ensuite c’est une question d’exigence : si l’on recherche une confidentialité maximale, par exemple pour la gestion de données personnelles sensibles, il est de loin préférable de choisir un serveur dédié, quitte à devoir s’appuyer sur les compétences d’un prestataire professionnel de l’informatique. Ce qui reste intéressant dans tous les cas.

sms2mail : une passerelle entre SMS et mails

Un service tout simple (en apparence) : transformer un SMS en mail (et réciproquement).

Tout est expliqué sur la page d’accueil du site et, pour ceux qui préfèrent le français, en voici la traduction :

SMS à mail

Ce service convertit les SMS en courrier électroniques.

Envoyez simplement, au +33755512496, un SMS qui commence par une adresse de courriel valide suivie d’un espace et de votre message. Il sera transmis par courrier électronique au destinataire.

Le destinataire peut répondre par mail. Sa réponse vous sera renvoyée par SMS.

Politique de confidentialité

Les courriels ou les numéros de téléphone mobile traités par ce service ne seront jamais partagés avec personne. Ils peuvent quand même être utilisés humainement pour contacter les utilisateurs de ce service.

Les données privées seront conservées jusqu’à 12 mois:

  • les SMS reçus sont supprimés 12 mois après leur réception.
  • les SMS envoyés en réponse sont supprimés 12 mois après leur envoi.
  • les données des utilisateurs ne contenant plus de SMS reçus ou envoyés et aucune mise à jour depuis 12 mois sont supprimées.

L’identifiant pour accéder aux données privées correspond au numéro de téléphone mobile de l’utilisateur dans son format international, sans le signe ‘+’ ni l’espace; par exemple. : 33612345678

Pour définir un mot de passe pour cette connexion, envoyez simplement un SMS au +33755512496 avec votre mot de passe (sans espace).

Limites

Le contenu des SMS doit être authentique et licite. Les utilisateurs réputés utiliser ce service de manière inappropriée peuvent être interdits sans préavis ni justification.

Ce service est offert avec certaines limites :

  • jusqu’à la fin du mois du premier SMS traité
  • longueur maximale d’un SMS (adresse email et message): 1024
  • longueur maximale d’une adresse email: 256
  • 32 SMS convertis en mail max par utilisateur
  • 8 réponses par mail converties en SMS max par utilisateur; seuls
  • les 140 premiers caractères de la réponse sont envoyés par SMS

Il est possible de dépasser certaines de ces limites en demandant un service payant.

Questions remarques, commentaires ou suggestions sont les bienvenus à @lbarme.

CE SERVICE EST FOURNI PAR l’EURL Barme “TEL QUEL”. L’EURL Barme DÉCLINE SPÉCIFIQUEMENT TOUTE GARANTIE, Y COMPRIS, MAIS SANS S’Y LIMITER, LES GARANTIES IMPLICITES DE QUALITÉ MARCHANDE ET D’ADÉQUATION À UN USAGE PARTICULIER. L’EURL Barme N’A AUCUNE OBLIGATION DE FOURNIR UNE MAINTENANCE, UN SUPPORT, DES MISES À JOUR, DES AMÉLIORATIONS OU DES MODIFICATIONS. L’EURL Barme NE PEUT EN AUCUN CAS ÊTRE TENU RESPONSABLE DE TOUT DOMMAGE DIRECT, INDIRECT, ACCESSOIRE, SPÉCIAL, EXEMPLAIRE OU CONCECUTIFS (Y COMPRIS, MAIS SANS S’Y LIMITER, L’ACQUISITION DE MARCHANDISES OU DE SERVICES SUBSTITUTIFS, LA PERTE D’UTILISATION, DE DONNÉES OU DE BÉNÉFICES, OU D’INTERRUPTION COMMERCIALE. ) QUELLES QU’EN SOIENT LES CAUSES ET SELON TOUTE THÉORIE DE RESPONSABILITÉ, QUE CE SOIT UN CONTRAT, UNE RESPONSABILITÉ STRICTE OU UN TORT (INCLUANT LA NÉGLIGENCE OU AUTREMENT), DÉCOULANT DE TOUTE SORTE D’UTILISATION DU PRÉSENT SERVIVE, MÊME SI AVISÉE DE LA POSSIBILITE DE CES DOMMAGES.

Guerre des robots : victoire de numerunique

Après avoir résolu le problème du harcèlement téléphonique à titre privé, les appels importuns à titre professionnel devenaient de moins en moins supportable. Surtout les appels qui tombent dans le vide ; personne au bout du fil et en plus ça raccroche.

Le contexte d’un poste professionnel est plus délicat. Il s’agit quand même d’accueillir les clients et prospects et de ne pas rejeter les appels administratifs. Finalement la solution est encore plus simple :

  • Message d’accueil : “Bonjour, si vous n’êtes pas un robot, faites le 6, merci !”
  • 6 : ça sonne.

Et ça marche. Au point que l’on peut enfin accueillir aimablement même les démarchages authentiques (comprendre : non robotisés).

Et apparemment, cela ne surprend aucune des personnes légitimes qui appellent numerunique : on y a pas encore entendu la moindre remarque au sujet de l’annonce d’accueil.

C’est donc un système robotisé (le Serveur Vocal Interactif) qui neutralise un autre système robotisé (les centres d’appels de démarchage téléphonique).

C’est donc une victoire de numerunique mais une victoire avec un goût amer ;  quelque part, c’est triste de devoir en arriver là…

 

L’IPv4 a encore plein d’avenir !

6 485 : c’est le nombre de quelques unes des adresses IPv4 bannies aujourd’hui pour tentative de piraterie sur quelques serveurs surveillés par numerunique.

Il s’agit juste des IP bannies pour une partie des attaques possibles, il y en a d’autres mais un inventaire complet serait plus fastidieux qu’utile : on a la un indice suffisant.

Il s’agit juste aussi de serveurs peu exposés et d’attaques systématiques, peu évoluées et sans intention manifeste à l’encontre des serveurs visés.

En fait, il y juste une gigantesque armée de robots qui cherchent en permanence des failles sur tous les serveurs de la planète, histoire d’en prendre le contrôle pour ajouter d’autres recrues à cette armée.

Et tous ces serveurs compromis utilisent chacun une adresse IP qui pourrait être mieux employée.

Alors la pénurie des adresses IPv4 annoncée depuis la fin du millénaire précédent est une bonne blague :  on pourrait déjà commencer par récupérer toutes celles qui sont utilisées par des pirates 🙂

Mais qui est Laurent Barme ?

Photo de Laurent Barme

Comme pour la plupart des personnes aujourd’hui, on peut se faire une idée de la réponse à cette question en parcourant la trace qu’il laisse sur Internet, volontairement ou non. Mais ici on trouvera la seule source d’information autorisée et authentique.

Donc, qui est Laurent Barme ? En un mot, c’est un informartiste – c’est la tendance actuelle de créer de nouveaux mots en en fusionnant plusieurs, mais en l’occurrence c’est parfaitement adapté 🙂 !

Passionné d’informatique depuis sa rencontre avec une hp 25 en 1980, il vend en 1984, pour la première fois de sa carrière d’informaticien, un programme (pour la sauvegarde de programme sous la forme de code-barres pour la hp 41) qu’il a imaginé, conçu et réalisé en toute autonomie.

Autodidacte par nécessité à une époque ou les formations en informatique sont presque inexistantes, il acquiert néanmoins un diplôme d’Ingénieur en génie électrique en 1990 (major de l’option informatique de l’ESIGELEC), un DEA (Diplôme d’Etude Approfondie, l’équivalent d’un Master aujourd’hui) en informatique fondamentale en 1992 puis achève sa formation par un Doctorat d’Informatique de l’Université des Sciences et Technologies de Lille obtenu en 1996 avec la mention Très Honorable sur “Le Son dans les Systèmes Informatiques pour le Travail Coopératif”.

Laurent Barme reste actif durant ses études sur des sujets très divers dont le fil conducteur reste l’informatique :

  • 1988 :
    • conception et réalisation d’un logiciel d’aide à l’analyse d’expériences de laboratoire sur PC,
    • impression d’informations d’une base de données Oracle sur un IBM AS 400 en utilisant SQL,
  • 1989 : conception et développement d’un système d’archivage de programmes d’automates avec dBase III+ et C sur PC
  • 1988 – 1989 : Initiateur et responsable d’un projet informatique et électronique :
    • conception et réalisation d’un serveur Vidéotexte fonctionnant sur un PC et gérant jusqu’à 16 Minitels
    • encadrement d’une dizaine d’élèves Ingénieurs,
    • mise en œuvre du système à l’occasion du Salon de l’Etudiant, du Marathon International Jeanne d’Arc et des Voiles de la liberté (premier rassemblement de vieux gréements à Rouen)
  • 1990 : stage de fin d’étude  d’ingénieur de trois mois en Angleterre avec la mise en valeur du travail d’un service d’assistance technique,  réalisée en C sous Unix, transfert des données d’Unix sur PC et création de graphiques sur PC.

Il occupe ensuite les fonctions salariées suivantes :

  • 1990 – 1991 : Ingénieur développement pour la maintenance évolutive d’un logiciel de gestion et d’affichage en temps réel d’informations financières sur station de travail en C sous Unix et Xwindows (toolkit Xview)
  • 1992 – 1996 : Enseignant Chercheur en Informatique à l’Université de Lille (postes de Moniteur puis d’ATER) :
    • 7 publications dans des actes de colloques scientifiques,
    • conception, réalisation et évaluation d’un système expérimental d’audioconférences assistées par ordinateur : ergonomie, programmation orientée objets, C++, Windows NT, Multimédia, systèmes Client/Serveur (TCP/IP),
    • mise en œuvre et administration d’un serveur et d’un parc de stations Windows NT,
    • enseignement du Pascal et du Scheme (dialecte de LISP) en premier cycle universitaire,
    • conception et enseignement d’un cours sur Internet en formation continue,
    • enseignement d’un cours d’architecture et réseaux en formation continue,
    • encadrement de six stagiaires.
  • 1997 – 2001 : Chef de projets à Paris :
    • définition et suivi des plannings, gestion des budgets, suivi des sous-traitants, relations avec les clients,
    • expert dans le domaine de la gestion des mouvements de trains : suivi et coordination des développements (C++, Unix, Windows NT, Excel 97 / VBA),
    • formations des utilisateurs (dont une notable pour la définition des horaires du métro entre Lantau et Hong-Kong)
    • spécifications en R&D et support aux offres.
  • 2001 – 2007 : Chef de projets puis Directeur de projets à Roubaix :
    • interface entre les clients et les services commerciaux, techniques et administratifs,
    • mise en œuvre de logiciels de gestion commerciale en centrale et en magasin (Windows, SQL),
    • formations et opérations de maintenance complexes.
    • encadrement hiérarchique de 5 Chefs de Projets.

Et depuis 2008, Laurent Barme occupe  tous les postes (chacun à temps partiel) de la société qu’il a fondée à Lille :

  • en fait, ce serait trop long à détailler…

Tout ce qui précède c’est la partie informaticien ; il y a aussi la partie artiste. En effet, depuis 2018, Laurent Barme a pu accéder par un fablab à Lille à toute une panoplie de machines professionnelles dont certaines à commande numérique (comprendre pilotées par ordinateur). Ce qui lui a permis de rentabiliser enfin sa formation initiale en dessin industriel en classes préparatoires aux grandes écoles et surtout d’assouvir sa créativité exprimée dans des objets concrets et utiles dont on trouve un aperçu sur le blog dédié à cette partie de son activité.

Les deux activités d’informaticien et d’artiste de Laurent Barme ont en commun la conception et la réalisation de projets innovants et soigneusement adaptés à un usage sans équivalent avec un produit commun, couramment désigné  comme “disponible en magasin sur étagère”.

On retrouve aussi dans ces deux activités la même démarche : l’utilisation d’outils génériques ou de fonctions élémentaires qui pris séparément restent stériles mais savamment et méthodiquement combinés aboutissent à des réalisations exceptionnelles.

Les limites de l’open source

ATTENTION : cet article est destiné aux informaticiens ou, à la rigueur, aux personnes vraiment très curieuses à propos de la lutte contre les pirates.

Cette histoire commence par l’observation de messages inhabituels dans les journaux système :

Aug 31 08:43:31 host sshd[14231]: dispatch_protocol_error: type 90 seq 5 [preauth]
Aug 31 08:44:01 host sshd[14231]: dispatch_protocol_error: type 96 seq 6 [preauth]
Aug 31 08:44:01 host sshd[14231]: dispatch_protocol_error: type 97 seq 7 [preauth]

En première approche, l’instinct d’administrateur système suggère d’ignorer ces messages. Ce sera effectivement la conclusion de l’analyse qu’ils motivèrent. Si vous êtes là juste pour savoir ce qu’il faut en faire, la lecture de la suite est optionnelle.

Un 31 août c’est encore un peu les vacances. On a donc un peu plus de temps et on aimerait bien savoir à quoi correspondent ces mystérieux “type 90, 96 ou 97” pour lesquels il y a une “dispatch_protocol_error”.

A l’intention du profane, il est utile de préciser que ces messages d’erreur émanent du démon sshd. Pour faire simple, un démon est un processus système qui tourne en tâche de fond. Et le processus sshd est celui qui gère les connexions à distance. Dans le contexte de l’administration de serveur c’est à la fois un dispositif essentiel et incontournable et, en conséquence, la principale cible des pirates.

Une recherche méthodique sur Internet à propos de ces mystérieux messages d’erreur n’aboutit à aucun résultat probant. Il faut donc aller à la source de l’information : les sources d’OpenSSH.

On obtient ainsi plus de 740 fichiers qui totalisent plus de 200 000 lignes de code… la recherche de l’information convoitée est un véritable jeu de piste.

dispatch.c

L’instruction qui produit le message d’erreur “dispatch_protocol_error: type t seq n” est facile à trouver dans la fonction dispatch_protocol_error().

auth2.c

Cependant, cette fonction n’est appelée nulle part directement mais un pointeur sur cette fonction est utilisée dans l’instruction ssh_dispatch_init(ssh, &dispatch_protocol_error).

dispatch.c

En examinant de plus près ce que la fonction ssh_dispatch_init() fait de son paramètre dflt on découvre que le pointeur sur la fonction responsable des mystérieux messages est mémorisé dans la structure ssh->dispatch[i].

packet.c

En cherchant l’usage de cette information on apprend que l’appel de la fonction se fait dans ssh_dispatch_run() par l’instruction (*ssh->dispatch[type])(type, seqnr, ssh). A ce stade type est déjà défini auparavant dans la même fonction par l’une des instruction ssh_packet_read_seqnr(ssh, &type, &seqnr) ou ssh_packet_read_poll_seqnr(ssh, &type, &seqnr).

dispatch.c

En étudiant le code de ces deux fonctions on en déduit que le fameux type est défini dans la fonction ssh_packet_read_poll2(). Il y est d’abord initialisé à la valeur SSH_MSG_NONE puis renseigné par sshbuf_get_u8(state->incoming_packet, typep).

ssh2.h

Ah, là on tient un indice intéressant : SSH_MSG_NONE qui mène à la mine d’informations recherchée :

/* channel related messages */ 

#define SSH2_MSG_CHANNEL_OPEN              90
#define SSH2_MSG_CHANNEL_OPEN_CONFIRMATION 91
#define SSH2_MSG_CHANNEL_OPEN_FAILURE      92
#define SSH2_MSG_CHANNEL_WINDOW_ADJUST     93
#define SSH2_MSG_CHANNEL_DATA              94
#define SSH2_MSG_CHANNEL_EXTENDED_DATA     95
#define SSH2_MSG_CHANNEL_EOF               96
#define SSH2_MSG_CHANNEL_CLOSE             97
#define SSH2_MSG_CHANNEL_REQUEST           98
#define SSH2_MSG_CHANNEL_SUCCESS           99
#define SSH2_MSG_CHANNEL_FAILURE           100

Donc ces mystérieux “type 90, 96 ou 97” pour lesquels il y a une “dispatch_protocol_error” correspondent à :

SSH2_MSG_CHANNEL_OPEN
SSH2_MSG_CHANNEL_EOF
SSH2_MSG_CHANNEL_CLOSE

Et là c’est beaucoup plus clair !

Il s’agit vraisemblablement de tentatives de connexion faites avec des paquets incohérents. Une telle approche évoque une technique similaire à celle mise en œuvre pour exploiter la faille CVE-2018-15473 : on génère des erreurs volontairement pour glaner indirectement des informations sur la cible.

Pour ce qui concerne les dispositions à prendre pour contrer une nouvelle forme d’attaque, il n’y a rien de plus à faire pour consolider les défenses du serveur que ce qui est déjà fait.

Tout ce qui précède n’est en fait qu’un préambule au véritable sujet de cet article : une réflexion sur l’open source.

Tout d’abord cela illustre directement la réflexion de l’article “WHAT IS BETTER THAN OPEN SOURCE?” : une documentation concise serait bien plus utile en complément des fichiers sources ; elle permettrait d’éviter un reverse engineering laborieux pour décoder les sens cachés de message d’erreur.

Mais surtout, l’analyse faite à l’occasion de cette recherche sur un élément essentiel et crucial des serveurs exposés sur Internet donne le frisson.

On y découvre un style de programmation artificiellement compliqué. Par exemple : mais pourquoi diable passer par un pointeur sur une fonction laborieusement stocké en de multiples exemplaires plutôt que d’appeler tout simplement la fonction elle-même ? Le reste est à l’avenant, avec notamment un recours avide aux pointeurs, une fonctionnalité très puissante lorsqu’elle est bien employée mais une source redoutable d’erreurs.

Cela a sans doute peu d’impact sur les performances mais aboutit à un code difficile à comprendre et donc à la fois propice aux bugs et difficile à maintenir ;  un véritable terreau pour les failles de sécurité et un terrain très favorable aux portes dérobées.

On aboutit au résultat opposé à celui recherché par l’open source !

Visibilité inattendue de numerunique

Comme l’atteste la photo ci-dessus (où l’on aperçoit le logo de numerunique à la Fondation Serralves, à Porto), la visibilité de numerunique s’étend bien au delà de son périmètre originel.

Que numerunique soit visible à l’international est déjà remarquable mais qu’il le soit aussi dans le domaine de l’art contemporain est tout à fait inattendu.

En l’occurrence, c’est son logo qui lui a valu l’enthousiasme spontané d’amateurs d’art érudits qui ont eu l’idée bienvenue d’afficher numerunique dans un haut lieu de l’art contemporain.

L’idée serait-elle supérieure à sa réalisation ?

Le rangement des archives de numerunique a sorti de l’ombre un document qui invite à la réflexion. C’est ni plus ni moins que le manuel de référence du premier serveur web de l’histoire !

Il date de mai 1994 ; il a donc tout juste plus de 24 ans. A l’époque c’était simplement un document de travail, à la pointe de la technologie. Aujourd’hui, à l’échelle de temps de l’informatique, il tient davantage du fossile préhistorique que du manuel de référence. Il est numérisé et partagé ici : httpd1994.

Un détail attire l’attention : il a été écrit par Ari Luotonen et Tim Berners-Lee.

Une recherche rapide sur Internet révèle que ce serait Ari, alors étudiant au CERN, qui aurait réalisé cet élément crucial de l’idée de Tim à qui est pourtant universellement (et à juste titre) attribué l’invention du Word Wild Web.

Ari, comme la plupart de ceux qui ont contribué à la concrétisation de l’idée de Tim, a complètement disparu de l’histoire. Pour celle-ci c’est donc incontestablement l’idée qui prime sur sa réalisation.

Pourtant, avoir une idée c’est très facile mais la réaliser beaucoup moins ! Et une idée “en l’air” c’est juste rien. C’est sa réalisation qui lui donne tout son intérêt.

Chez numerunique, des idées il y en a plein et l’on sait pour le vivre les difficultés auxquelles on se heurte à vouloir les concrétiser. Mais là, peut importe si l’on retient l’inventeur ou les réalisateurs : c’est le même.

numerunique présente ses créations

A l’occasion du premier anniversaire du TechShop où numerunique a trouvé le biotope favorable à l’épanouissement de sa nouvelle branche d’activité, numerunique présentera ses créations d’objets uniques dont les plus récentes, telles que son mugcover et son doubledose :

Un couvercle à mug

Un doubleur de dose.

Pour en savoir plus sur ces objets, rendez-vous au marché des créateurs, de 10:00 à 18:00 les 19 et 20 mai prochains au TechShop , 30 rue Henri Régnault à Lille.