La nouvelle version de LinuxFr.org est en ligne depuis quelques jours. Vous nous remontez régulièrement des bugs et des propositions d'améliorations dans le suivi. Je vous encourage à continuer et à commenter / voter sur les entrées qui vous intéressent.

Voici quelques entrées sur lesquelles j'aimerais particulièrement avoir vos retours :

• Pour ou contre le respect de la syntaxe Markdown pour les retours à la ligne ?
• Quels services devrait-on prendre en charge pour les avatars ? Certains d'entre vous utilisent-ils pavatar ?
• Que pensez-vous des polices utilisées ?

Je pense que vous êtes également intéressés par l'architecture logicielle de cette nouvelle version. Vous pourrez donc trouver quelques explications à son sujet en seconde partie et n'hésitez pas à poser des questions dans les commentaires.

La première version de la distribution communautaire Mageia est sortie le 1er juin. Cette toute nouvelle distribution est issue d'une partie de la communauté Mandriva Linux.

8 mois après l'annonce du projet, la première mouture de Mageia est disponible depuis le premier Juin sur les miroirs comme prévu sur le planning. Fruit du travail d'une communauté issue des quatre coins de la planète, la distribution se décline pour le moment en :

• 2 DVD d'installation 32/64 bits,
• ainsi qu'un cd d'installation pour les 2 architectures,
• complété par 8 Live CD (KDE et GNOME et des variations sur les langues).

On y retrouve également un installeur réseau (fichier boot.iso) ainsi que la possibilité de placer les images ISO sur une clé USB pour une installation simplifiée sur les netbooks.

Pendant longtemps, les bases de données relationnelles ont été l'unique solution pour enregistrer des données, ou en tout cas, la solution adoptée par défaut par beaucoup de monde sans plus de réflexion sur le sujet. Pourtant, certaines personnes considèrent que le problème de stockage de données est en fait multiple et qu'il convient de se poser de nombreuses questions :

• Est-ce que les données sont fortement structurées ou non ?
• Quel est le ratio entre les lectures et les écritures ?
• Est-il acceptable de perdre un enregistrement sur un million ? Sur un milliard ?
• Est-ce que les données sont réparties sur plusieurs data-centres ?
• Est-ce que la taille des données peut être multipliée par 10 en l'espace d'un mois ?
• Quelle indisponibilité du service peut-on se permettre ?
• Etc.

Les bases de données relationnelles proposent leurs réponses à ces questions ; elles peuvent paraître raisonnables dans bien des cas, mais pas toujours. Par exemple, les bases de données relationnelles sont très mal adaptées quand on veut privilégier les performances plutôt que la garantie d'écriture des données.
Aussi, pour répondre à ces problématiques différentes, un mouvement, NoSQL, a proposé d'adopter des outils différents, spécialisés pour certains cas d'usage. Certaines bases de données NoSQL sont destinées à traiter d'énormes volumes de données, d'autres sont conçues pour maximiser le nombre de requêtes par seconde qu'un serveur pourra traiter, etc. Notons en particulier que la plupart des plus gros sites web ont quitté le monde relationnel (Google, Facebook, Twitter, Amazon), ce qui tend à valider le besoin d'avoir d'autres outils que les bases de données relationnelles.

NdA : Merci à Christophe Turbout, Thomas Douillard, Buf, olivierweb, Spack, baud123, Bruno Michel, mike.simonson et rakoo pour leur aide lors de la rédaction de cette dépêche

Le site LinuxFr.org utilise divers logiciels libres pour son fonctionnement et ses services : une large majorité provient de projets tiers (Debian, MariaDB, Redis - version d’avant le changement de licence, nginx, Postfix, conteneurs LXC et Docker, Ruby On Rails, Sympa, etc.) et d’autres composants sont développés pour nos propres besoins. Cette dernière catégorie comprend le code principal du site web en Ruby On Rails, et principalement 5 services autour : le cache d’images img, la tribune board, le convertisseur EPUB 3 epub, le partageur sur les réseaux sociaux share et le convertisseur LaTeX vers SVG svg. Cette dépêche va s’intéresser à img, un code sous AGPLv3.

Elle est née d’une envie personnelle d’expliquer, documenter et montrer ce qui a été fait sur le cache d’images de LinuxFr.org, complétée d’une demande d’un « article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter… ».

Sur les cinq dernières années, nous avons assisté un ballet impressionnant de changements de licences dans les « bases de données » (au sens large ici) libres (SQL ou NoSQL) : on parle ici de MariaDB (base relationnelle), Elasticsearch (moteur de recherche)/Kibana (visualisation de données), MongoDB (base orientée documents), Redis (base clé valeur), Confluent (gestion d’événements), CockroachDB (SQL distribué), Graylog (gestion de journaux système), et j’en oublie peut-être.

La trame

Les entreprises qui éditent ces bases se voient attaquées dans leur modèle (double licence libre et payante, open core, service, etc.). Selon ces entreprises, d’autres acteurs leur taillent des croupières, leur piquent leur chiffre d’affaires, se placent en intermédiaires captant la valeur, souvent avec une approche « base de données à la demande » de type opérateur d’infrastructure de cloud (mais ça pourrait aussi être un simple intégrateur de solution), et le tout sans contribuer.

Et souvent la solution retenue pour stopper ce qui est perçu comme une dérive est un changement de licence, vers une licence non-libre, respectant généralement les critères suivant :

• le code est visible / disponible (on part quand même d’une solution libre/open source, si le code n’était pas visible le changement serait brutal)
• « ça change rien pour toi utilisateur final » (soit tu ne payais pas et c’est encore le cas, soit tu payais déjà (pour le service, le support, etc.) et ça va continuer identiquement)
• il est interdit de faire du « à la demande » sans publier le code qui te permet de le faire.

Il est souvent évoqué les entreprises comme Facebook, Google, HP, Novell ou Red Hat qui contribuent au libre, avec plus ou moins de controverse ou de respect des pratiques communautaires. Mais on parle moins souvent des petites sociétés.

Dans cet article nous présenterons le retour d'expérience de trois jeunes start-ups françaises de moins de deux ans, comment elles utilisent des logiciels libres et quelles interactions elles ont avec la communauté.

Note : l'article est écrit collaborativement par trois membres des trois sociétés présentées.

Redis est une base de données de type clé-valeur, sous licence BSD. On peut voir Redis comme une sorte de Memcached boosté aux stéroïdes.

La version 2.2.0 est sortie la semaine dernière, très rapidement suivie de la version 2.2.1. Cette version apporte principalement des optimisations par rapport à Redis 2.0 :

• importante diminution de la consommation mémoire (à ce sujet, je vous conseille la lecture des astuces pour optimiser la mémoire) ;
• réplication non-bloquante ;
• la commande Watch pour faire du check and set ;
• l'Algorithme LRU pour l'éviction des données quand la mémoire consommée par Redis est limitée ;
• nouvelles commandes : SETBIT, GETBIT, SETRANGE et GETRANGE permettant d'accéder à des valeurs de type « chaînes de caractères », comme s'il s'agissait de tableaux.

Pour la suite, antirez (le principal développeur) souhaite se concentrer sur la prise en charge des grappes de serveurs (clusters) et sur diskstore (un stockage sur disque des données pour les instances où tout faire tenir en mémoire n'est pas une option).

Dans le cadre de mon activité professionnelle, je fais de la veille autour des technologies web. Suite à un récent journal sur CouchDb, je me suis dit que les lecteurs de LinuxFr.org pourrait être intéressé par le sujet. J'ai donc regroupé un paquet de liens récents dans la seconde partie de cette dépêche. La plupart viennent du compte delicious qui me sert pour la veille. Les autres liens sont de l'auto-promotion vers des billets que j'ai écrit.

Tout bon administrateur a un jour dû chercher une info à coup de grep, tail, awk dans les fichiers de logs des équipements qu'il gère.
Or la recherche est toujours un peu fastidieuse, avec les questions qui reviennent : "Où est-ce qu'ils sont ces logs ?", "Et c'est quoi le format déjà ?", "Tu connais le mot de passe pour se connecter sur le routeur ?".

Si on peut mettre en place une récupération des logs de façon centralisée avec des outils connus comme syslog, le trio Logstash, ElasticSearch et Kibana est un très bon candidat pour gérer et trouver efficacement des informations dans les milliers de lignes de traces que peuvent générer les divers services.

Bonjour tout le monde,

J’ai le plaisir, pour ce premier message sur LinuxFr.org, de vous annoncer un nouveau projet de stockage clé‑valeur en mémoire vive.

« Encore un » vous direz‑vous ? Certes. Voyons si j’arrive à vous convaincre.

N. D. M. : à ne pas confondre avec le protocole ROBERT (ROBust and privacy‐presERving proximity Tracing) qui vient d’être publié par l’INRIA et la Fraunhofer AISEC pour le suivi de contacts dans le cadre de la pandémie de Covid‑19.