Programmez

Le fil de programmez.com

  • Kira Linux : une vue d'ensemble

    Texte de Timothée Gauchez
    Le constat : posséder son système, vraiment
    La majorité des distributions Linux font un choix implicite à la place de l'utilisateur : abstraire, automatiser, masquer. Le résultat est un système qui fonctionne, jusqu'au moment où il ne fonctionne plus, et où personne ne sait pourquoi. Les développeurs qui veulent comprendre ce qui tourne sur leur machine se retrouvent à fouiller dans des couches d'abstraction accumulées sur des décennies.
    Kira Linux part d'un principe inverse : chaque composant doit avoir une raison d'être, être lisible, et pouvoir être modifié sans nécessiter de déconstruire l'ensemble du système. 
    > Ce n'est pas une distribution qu'on installe et qu'on oublie. C'est une distribution qu'on possède.
    L'architecture : construit depuis zéro, couche par couche
    Kira n'est pas une surcouche d'une distribution existante. Chaque composant a été sélectionné ou développé avec une intention précise.
    Shinigami : le noyau
    Shinigami est un fork du noyau Linux, recompilé avec Clang en ThinLTO, épuré de tout driver inutile, et patché avec le scheduler BORE (Burst-Oriented Response Enhancer) pour une meilleure réactivité sur les postes de travail interactifs. Le résultat est un noyau plus petit, plus rapide à compiler, et dont la configuration reste lisible et maîtrisable par une seule personne. Le versionnage suit le schéma `LINUX_VERSION-shinigami-YY.MM-N`, permettant de tracer précisément chaque build.
    musl libc : la bibliothèque C
    Kira utilise musl à la place de glibc. musl produit des binaires plus petits, facilite le linkage statique, et réduit l'empreinte mémoire globale du système. Les applications qui dépendent de glibc au runtime seront prises en charge par un contener debian créé et configuré sur mesure pour Kira.
    runit : l'init
    PID 1 sur Kira, c'est runit. Pas systemd. Les services sont de simples scripts shell dans `/etc/sv/`, lisibles et modifiables sans documentation extérieure. Le démarrage est rapide, l'architecture de supervision est transparente, et l'empreinte mémoire de l'init est négligeable.
    flux : le gestionnaire de paquets
    flux est le gestionnaire de paquets de Kira, écrit en C, sans dépendance runtime au-delà de libc. Son fonctionnement repose sur trois principes : compilation depuis les sources avec des flags d'optimisation par paquet ; cache de binaires signés (minisign) hébergé en propre pour éviter de tout recompiler à chaque installation ; résolution de dépendances strictement minimale, flux n'installe que ce qui est explicitement requis.
    Les recettes de paquets utilisent le format kotodama, un format déclaratif simple avec des hooks `%build`, `%install`, `%post-install`. flux est un binaire unique ; `flux install`, `flux update`, `flux search`, `flux info`, `flux self-update` couvrent l'ensemble du workflow sans configuration préalable.
    Le desktop : Wayland, intégré, fonctionnel
    Kira propose deux environnements de bureau officiellement supportés, tous deux sur Wayland :
    - Sleex est l'environnement principal. Développé par le projet AxOS, c'est un shell complet basé sur Quickshell et Qt/QML, offrant une expérience intégrée, fluide et modulaire. Sleex n'est pas une barre des tâches greffée sur un compositeur générique : c'est une interface pensée comme un tout cohérent.
    - SwayFX est le second environnement supporté. Fork de Sway enrichi d'effets visuels (flou, coins arrondis, animations), il s'adresse aux utilisateurs qui préfèrent une approche minimaliste et entièrement configurable via un fichier texte versionnable.
    Les deux environnements coexistent et sont sélectionnables à l'installation ou via un outil en ligne de commande dédié. XWayland est disponible en paquet optionnel pour les applications qui en ont besoin.
    Ce que Kira n'est pas
    Kira n'est pas une distribution pour débutants. L'installateur est guidé mais attend de l'utilisateur qu'il sache ce qu'est une partition. Il n'y a pas de telemetry, pas de compte à créer, pas d'assistant de bienvenue qui configure des choses à la place de l'utilisateur. Ce que le système fait au démarrage est documenté, et chaque service qui tourne a été installé explicitement.
    L'état du projet
    Kira Linux est développée depuis quelques mois par un seul développeur, étudiant en 3e année d'informatique à Sup de Vinci. Le projet est en début de phase 3 (sur 4) : le système de base s'installe et démarre sur du matériel réel (x86-64), l'environnement desktop fonctionne de bout en bout, le gestionnaire de paquets flux est pleinement opérationnel avec cache distant en production, et deux variants ISO sont disponibles (base et desktop). Le support de l'architecture RISC-V est prévu en phase suivante.
    Le projet est entièrement open source, sans financement externe, hébergé sur GitHub sous l'organisation `shinigami-os`.
    MàJ de dernière minute : la première version de l'OS est disponible en ligne sur le site de Kira Linux !
    Collaboration avec AxOS
    Kira Linux et AxOS sont deux projets indépendants qui partagent une philosophie commune autour de Wayland et du contrôle utilisateur. La collaboration concrète prend deux formes.
    - Sleex dans Kira : Sleex, le shell desktop développé par AxOS, est intégré comme environnement principal de Kira Linux. C'est un composant clé du projet, pas une option périphérique.
    - Un bootloader partagé : un bootloader custom est en cours de conception par Kira et sera mis à disposition des deux projets. Son objectif est de démarrer deux systèmes d'exploitation simultanément sur le même matériel, sans émulation de firmware ni hyperviseur de type 1. Là où les solutions existantes reposent sur de la virtualisation lourde, ce bootloader vise une approche légère opérant directement sur le matériel réel. C'est une fonctionnalité qui n'existe pas à ce jour dans l'écosystème open source grand public.
    Liens
    - Documentation : https://docs.kira-linux.com
    Catégorie actualité: 
    Systèmes, OS
    Linux
    Image actualité AMP: 

  • AWS met la main sur DuckLabs et la base DuckDB

    AWS a annoncé le 27 août dernier le rachat de DuckLabs. Ils travaillaient ensuite depuis 2 ans. DuckLabs développe la base de données analytique open source DuckDB. Cette base embarquée est écrite en C++. AWS va ainsi renforcer les capacités d'analyses tout en donnant aux équipes de DuckLabs une autre dimension pour développer les solutions. AWS a déjà annoncé que les projets open source actuels le resteront. DuckDB ne changera pas.

    AWS résume ainsi ce rachat :

    • Un outil conçu pour le quotidien et les agents IA : plébiscitée par les développeurs pour sa rapidité et sa simplicité, DuckDB a été pensée pour accélérer les requêtes du quotidien (moins d'un téraoctet). Cette architecture légère et ultra-rapide séduit aujourd'hui particulièrement les agents d'IA, qui fonctionnent grâce à une multitude de petites requêtes instantanées.Andy Warfield (VP & Distinguished Engineer chez Amazon) détaille d'ailleurs sur le blog All Things Distributed la façon dont cette approche redéfinit la physique de l'analyse de données. 

    • Garantie 100 % Open Source & Licence MIT : AWS n'acquiert pas le projet open source lui-même. DuckDB restera entièrement gratuite, sous licence libre MIT, gérée de manière indépendante par la DuckDB Foundation (organisme à but non lucratif). Rien ne change pour les utilisateurs.

    • Ancrage européen préservé : Basée à Amsterdam, l'équipe de DuckLabs rejoindra AWS. Ses créateurs et cofondateurs, Hannes Mühleisen et Mark Raasveldt, continueront de piloter la direction technique du projet.

    Catégorie actualité: 
    Outils
    AWS
    Image actualité AMP: 

  • Hugging Face : Nvidia veut bien dépenser 12,9 milliards pour racheter la plateforme

    Les rumeurs se sont accélérées ces derniers jours. Depuis quelques heures, les ultimes négociations sembleraient prêtes à aboutir à l'annonce du rachat par Nvidia d'Hugging Face pour 12,9 milliards $. The Information a rapporté l'information dès mercredi dernier. Pour le moment, aucune annonce officielle n'a été faite ni par le fondeur ni par la plateforme. 

    Hugging Face a été fondé en 2016 pour des Français et depuis la plateforme est devenue la référence pour la distribution et l'accès aux LLM open source. Pour Nvidia, ce rachat serait stratégique Cela permettrait de préserver les ventes de ces puces IA et d'avoir une plateforme LLM mondiale et d'accroître les modèles optimisées avec les technologies Nvidia. La collaboration entre les deux entitrés n'est pas nouvelle. 

    Avec le rachat de la plateforme référence, est-ce un moyen pour Nvidia de ralenter les puces concurrentes et élargir l'usage des SDK et de Cuda par les LLM ? Nvidia compléterait son écosystème IA du hardware à la distribution des LLM. 

    L'annonce officielle pourrait se faire dans les prochaines heures ou les prochains jours... 

    Catégorie actualité: 
    IA
    NVIDIA
    Image actualité AMP: 

  • GraalVM 25.3 : sécurité et performances

    GraalVM annonce la version 25.3. Cette mise à jour se focalise sur les performances et la sécurité. 

    1 / performances

    GraalVM 25.3 propose un nouveau "priority inliner". Il est disponible dans le JIT et Native Image. Il effectue une analyse du call graph pour optimiser les appels et donner la possibilité d'optimiser le code généré et permettre des optimisations supplémentaires dans le compilateur. La mise à jour vers la 25.3 peut améliorer de facto de nombreux apps. Native Image exécute plus rapidement les chemins et optimise les opérations synchronized. 

    2 / sécurité

    Cette version inaugure de nouvelles options d'intégrité des flux de contrôles H/CFI (Control-flow integrity). "CFI est un mécanisme de sécurité qui empêche les attaquants de rediriger l'exécution du programme vers des emplacements de code inattendus. Sur AMD64, des vérifications logicielles garantissent que les branches indirectes aboutissent à des cibles valides. Sur AArch64, des codes d'authentification des pointeurs protègent les adresses de retour stockées sur la pile. De plus, les emplacements de mappage de la mémoire anonyme exécutable sont désormais aléatoires par défaut."

    3 / divers

    Cette version propose aussi :

    - mise à jour des runtimes Node.js, Python

    - extension du support de WebAssembly

    Source : https://medium.com/graalvm/graalvm-25-3-is-here-41641acebfaf

    Catégorie actualité: 
    Langages
    GraalVM
    Image actualité AMP: 

  • Android : Google va imposer une optimisation de l'usage de la mémoire dans les apps

    Google veut accélérer l'optimisation de la consommation de la mémoire sur les smartphones Android par les apps et les jeux. Avec l'explosition des prix de la RAM, les smartphones embarquent moins de RAM. De nombreux modèles d'entrée de gamme se limitent à 4 Go de RAM. Ce qui n'est pas sans conséquences pour les apps. Google a publié le 26 août un post ayant pour titre : "amélioration de la qualité des applications : réduction de l'utilisation de la mémoire et amélioration de la migration des appareils".

    Google pose le problème ainsi : "Maintenir un écosystème Android sain est un engagement partagé où chaque application et chaque jeu a un rôle à jouer. Pour vous aider à offrir l'expérience utilisateur optimale attendue, Google Play introduit deux nouvelles exigences de qualité : l'une vise à réduire l'empreinte mémoire des applications, et l'autre à garantir une migration d'appareil sécurisée et fluide. Premièrement, afin d'aider les développeurs à gérer les contraintes matérielles du secteur et les limites de mémoire d'Android, Google Play établit de nouveaux seuils de performance. Deuxièmement, dans le cadre de notre engagement global à améliorer la qualité des applications, nous introduisons une nouvelle norme d'intégration pour simplifier et sécuriser la connexion lors des mises à niveau d'appareil."

    La réduction de l'usage mémoire pour les apps devient une priorité et derrière, il y a l'optimisation du code. Les éditeurs et développeurs vont devoir faire un travail de fond pour respecter ces nouvelles guidelines. La justification est donné immédiatement :
    "L'industrie mobile est confrontée à d'importantes contraintes d'approvisionnement en matériel, ce qui modifie la disponibilité de la mémoire des appareils et peut, à terme, impacter négativement l'expérience utilisateur. Android relève ce défi en imposant des limites de mémoire plus strictes afin de protéger l'expérience utilisateur globale contre les applications consommant trop de mémoire et provoquant des ralentissements du système.
    Dans cette optique, Google Play établit aujourd'hui des seuils de performance pour aider les développeurs à garantir que leurs applications continuent d'offrir l'expérience optimale attendue par les utilisateurs. Ces seuils concernent notamment l'utilisation de la mémoire dynamique, l'utilisation des bitmaps et l'optimisation du code afin d'éviter les ralentissements inattendus des performances sur l'appareil et les fermetures d'applications."
    Pour y arriver, Google préconise 3 éléments : 
    - usage dynamique de la mémoire (RSS anonyme et swap)
    - usage de la mémoire bitmap : ce paramètre évalue la mémoire utilisée par les bitmaps
    - optimisation du code DEX : un Android App Bundle optimisé utilise moins de mémoire et démarre plus rapidement...
    Pour réaliser cela, Google propose de nouveaux outils pour mesurer et trouver les problèmes. Mais surtout, Google ne vous laissera pas le choix. A partir de février 2027, les apps et les jeux devront utiliser et respecter ces paramètres d'optimisations. Google est très clair : "Les applications et les jeux qui ne respectent pas ces seuils pourraient voir leur visibilité et leurs possibilités de publication réduites sur Google Play. Des informations complémentaires seront communiquées ultérieurement.
    À l'avenir, à mesure que l'écosystème Android évolue et que nous comprenons mieux vos cas d'utilisation spécifiques, nous prévoyons que ces seuils s'adapteront. Lors de chaque mise à jour des exigences, nous veillerons à ce que vous disposiez du temps nécessaire pour vous y conformer."
    Catégorie actualité: 
    Technologies
    Android
    Image actualité AMP: 

  • OpenTelemetry arrive sur IntelliJ IDEA, GoLand, PyCharm et WebStorm

    Voilà une bonne nouvelle ! JetBrains annonce l'arrivée d'OpenTelemetry sur IntelliJ IDEA, GoLand, PyCharm et WebStorm. Depuis la version 2026.2 des outils, le plug-in OpenTelemetry est disponible sur les outils cités. Et il continuera à fonctionner sur Rider... 

    Le plug-in permet :

    - importer les logs

    - avoir les métriques

    - voir les traces et la cartographie

    Tout ça directement dans son IDE : "Vous pouvez les consulter sans avoir à configurer un backend d'observabilité local distinct."

    Ainsi depuis l'IDE et le plug-in installé, vous pourrez voir ce qu'il se passe avec une erreur, voir les dépendances et les services sollicités, déterminer le temps d'exécution d'une requête, vérifier si l'app génère les logs et métriques attendus, utiliser un agent IA pour automatiser l'usage d'OpenTelemetry. 

    Le plug-in est disponible sur la marketplace.

    Annonce : https://blog.jetbrains.com/platform/2026/08/opentelemetry-plugin-for-jetbrains-ides/

    Catégorie actualité: 
    Outils
    OpenTelemetry
    Image actualité AMP: 

  • Portable Computer : toute la stack Perplexity en local avec une DGX Spark

    Perplexity propose de faire tourner toute la stack IA sur votre machine avec... Nvidia. Il s'agit de Portable Computer. Cette approche locale évite d'utiliser des tokens cloud, des services distants, d'envoyer des données, etc. Il s'agit de mettre sur son PC, le Perplexity Computer. Il est construit sur Nvidia DGX Sparc (ou un équivalent chez HP, Lenovo, etc.). Il sera aussi disponible sur les GPU Nvidia, à une date précisée.

    Bref, pour installer et exécuter Portable Computer, il faut de la puissance, beaucoup de puissance et une bonne dose de mémoire vive : "Portable Computer permet aux utilisateurs d'exécuter Perplexity Computer entièrement sur leur appareil, pour analyser des données, synthétiser des fichiers et exécuter des flux de travail complexes. Les données privées restent locales et le travail effectué sur l'appareil ne consomme pas de crédits. Avec l'autorisation de l'utilisateur, le modèle local peut basculer vers le cloud pour des recherches et des raisonnements plus poussés, tout en conservant les informations sensibles sur l'appareil."

    Dans sa version actuelle, on peut faire tourner Qwen 3.8 27B, PPLx 27B. Côté Nvidia, on pourra utiliser Nemotron 3.5 Lightning. Portabel Computer peut exécuter la majorité des tâches demandés. Certaines demandes exigent tout de même un accès cloud. Portable Computer s'interface avec Google Drive, Gmail, Slack, GitHub. 

    Annonce : https://www.perplexity.ai/hub/blog/introducing-portable-computer-for-local-first-ai

    Catégorie actualité: 
    IA
    DGX Spark
    Image actualité AMP: 

  • Kotlin 2.4 : vidéo sur les nouveautés

    JetBrains nous propose une vidéo sur les principales nouveauté de Kotlin 2.4 incliant les paramètres contexte, les collections litérales, l'amélioration des constantes compile-time, la mise à jour de la lib standard, etc.

    Catégorie actualité: 
    Langages
    Kotlin
    Image actualité AMP: 

  • Compose Multiplatform 1.12.0 : MCP, évolution des API

    Jetbrains annonce Compose Multiplatform 1.12.0. Cette verison promet de nouveaux outils IA, des améliorations sur la gestion des ressources web et un meilleur contrôle sur les états des fenêtres desktop. 

    1 / Serveur MCP pour les agents IA dans Compose Hot Reload

    Compose Hot Reloard intègre, en expérimental, un serveur MCP pour connecter les agents de codage directement les apps qui s'exécutent. "Grâce au serveur MCP, un agent peut déclencher des rechargements, prendre des captures d'écran, inspecter l'arbre sémantique, simuler des clics et des saisies de texte, et consulter les journaux d'application. Concrètement, cela signifie que l'agent peut vérifier les résultats de ses propres modifications. Il peut confirmer que le rechargement a réussi, inspecter l'interface utilisateur rendue, intercepter une exception d'exécution et itérer, le tout sans que vous ayez à décrire ce qui s'affiche à l'écran."

    2 / gestion des caractères non gérés par la police en cours dans l'application

    Il est maintenant possible d'utiliser des caractères non supportés par les polices de son application. "Lorsqu'un caractère "inconnu" est rencontré lors du rendu, le logiciel télécharge à la demande le sous-ensemble de polices Noto correspondant et recompose le texte concerné. Ainsi, les caractères japonais, arabes, devanagari et les émojis s'affichent correctement sans que vous ayez à inclure de polices supplémentaires."

    3 / API v2 pour Window et dialog

    Les API pour Window et dialog arrivent en v2. Pour le moment, cette version est en préversion. Elle est utilisée par #WindowState et DialogState dans androidx.compose.ui.window.v2. Elle est par nature asynchrone des changements d'état de la fenêtre. Elle distingue l'état que vous demandez et l'état actuel de la fenêtre. 

    Cette version met à jour de nombreuses dépendances. 

    Annonce : https://blog.jetbrains.com/kotlin/2026/08/compose-multiplatform-1-12-0/

    Note de version complète : https://kotlinlang.org/docs/multiplatform/whats-new-compose-112.html

    Catégorie actualité: 
    Frameworks
    Compose Multiplatform
    Image actualité AMP: 

  • Prompt Engineer fait de la résistance : le baromètre des métiers IA de Silkhom

    Nous avions cru à la disparition, à juste titre, du prompt engineer. Ou comment transformer une compétence (faire des prompts IA) en profil métier... Sikhom publie un baromètre dédié aux métiers de l'IA. Le Prompt Engineer se situe autour de 50 k€, quand le LLMOps atteint 85 k€ et le Chief AI Officer approche les 116 k€. Ce qui nous frappe c'est l'extrême segmentation des profils et métiers IA. 

    "En 2026, les salaires des métiers de l’intelligence artificielle et du machine learning en France s’échelonnent de 32 000 EUR brut annuel pour un Prompt Engineer junior en régions jusqu’à 160 000 EUR pour un Chief AI Officer senior à Paris. Ce baromètre Silkhom, premier baromètre exclusivement dédié aux métiers IA publié par un cabinet de recrutement spécialisé, couvre 26 postes répartis en 4 familles : Intelligence Artificielle et ML, Vision Signal et Embarqué IA, Management et Stratégie IA, et Conseil et Intégration IA. Les données sont issues de placements CDI réels analysés sur plus de 25 000 profils entre 2019 et 2026, avec des fourchettes par niveau de séniorité et par zone géographique (Paris, Grandes Villes, Régions)." explique l'étude.

    En résumé, les salaires moyens selon le baromètre sont, en k€ :

    Ingénieur IA = 60,6
     
    Ingénieur Machine Learning = 67,1
     
    Ingénieur Deep Learning / IA = 60,3
     
    MLOps Engineer = 75,3
     
    Spécialiste IA Générative = 74,2
     
    Ingénieur en systèmes de recommandation = 67,1
     
    Chercheur en Intelligence Artificielle = 86,8
     
    LLMOps Engineer = 85,4
     
    Ingénieur RAG = 64,4
     
    Prompt Engineer = 49,7
     
    Analytics Engineer = 57,6
     
    AI Security Specialist = 81,5
    Nous voyons plutôt le prompt, le RAG ou encore l'IA générative comme des compétences que doivent posséder les développeurs, les experts de la données et les salariés. A force de segmenter les profits et les métiers IA, il y a un risque réel sur la gouvernance IA dans les entreprises avec des compétences IA mal maîtrisées par les salairés et une multitude d'intervenants qu'il faut ensuite coordonner et impliquer dans les projets. .
    Comme toujours, les écarts Paris, grandes villes et égions sont importants, moins sur les profils junior mais l'écart se creuse sur les profils senior. 
    Catégorie actualité: 
    Carrière
    IA
    Image actualité AMP: 

Menu principal

Connexion

Mes liens

Anciens articles