Bon, si vous êtes un vieux de la vieille sous Linux, j'ai une nouvelle qui va vous faire verser une petite larme ! GNOME et Firefox envisagent tous les deux de désactiver la possibilité de coller avec le clic milieu par défaut. Vous savez, ce truc où vous sélectionnez du texte, puis un coup de clic molette et hop, c'est collé ailleurs sans passer par Ctrl+C/Ctrl+V.

Jordan Petridis, développeur chez GNOME, vient de soumettre une merge request pour désactiver cette fonctionnalité dans les paramètres par défaut. D'après lui ce serait un véritable désastre... Des mots forts pour une fonctionnalité que beaucoup adorent mais faut dire que le mec n'a pas tort car avec les trackpads modernes et les souris à molette cliquable un peu sensibles, on finit souvent par coller des trucs sans faire exprès.

Du coup, c'est quoi exactement ce "primary paste" ? Hé bien c'est une spécificité historique de X11, le système de fenêtrage qui fait tourner les bureaux Linux depuis des lustres. Quand vous sélectionnez du texte, il est automatiquement copié dans un buffer séparé (le "PRIMARY selection"), différent du presse-papier classique . Et le clic du milieu colle ce buffer directement. C'est comme avoir deux presse-papiers en parallèle, c'est pratique mais ça peut foutre le bordel si vous cliquez au mauvais moment.

Et Firefox n'est pas en reste puisqu'une révision chez Mozilla propose exactement la même chose à savoir désactiver le collage au clic molette par défaut. Les arguments sont similaires... surtout que les utilisateurs qui découvrent cette fonctionnalité par accident (coucou les Windowsiens) ne comprennent pas d'où sort le texte qui vient de s'afficher dans leur barre de recherche. Perso, j'avoue que ça m'est arrivé de coller des trucs gênants dans un chat parce que j'avais cliqué sur la molette sans faire gaffe ^^.

La bonne nouvelle, c'est que ça reste réactivable pour ceux qui y tiennent. Sous GNOME, il suffira de taper :

gsettings set org.gnome.desktop.interface gtk-enable-primary-paste true

Lire plus

Microsoft continue de durcir les conditions d’utilisation de Windows et d’Office sans connexion internet en désactivant son service historique d’activation par téléphone. Le groupe remplace cette méthode par une redirection automatisée vers ses services sur Internet. La fin de l’activation par téléphone pour Windows et Office Comme l’a …

Lire la suite

Aimez KultureGeek sur Facebook, et suivez-nous sur Twitter

N'oubliez pas de télécharger notre Application gratuite iAddict pour iPhone et iPad (lien App Store)

L’article Microsoft ne permet plus l’activation par téléphone de Windows et Office est apparu en premier sur KultureGeek.

Lire plus

Vous avez déjà rêvé de virer le petit Tux qui s'affiche au démarrage de votre machine Linux pour le remplacer par un truc plus perso ?

Bon OK, sur les distros modernes avec Plymouth ou un bootsplash, on ne le voit plus trop ce logo du kernel... mais si vous bootez en mode console framebuffer, il est bien là ! Petite précision quand même, le logo du kernel ne s’affiche pas magiquement dès qu’on est en "console framebuffer". En fait, pour que ça marche, il faut à la fois que le support de la console framebuffer soit activé dans le kernel (CONFIG_FB_CONSOLE=y) et qu’un framebuffer soit réellement disponible au moment du boot.

Sur les machines modernes, ça passe souvent par simpledrm + KMS, ce qui fonctionne très bien dans la majorité des cas. Mais selon le GPU et le firmware, il arrive encore que l’écran reste noir jusqu’au passage en userspace, même sans Plymouth. Le** logo peut s’afficher**, mais ce n’est pas garanti à 100 % sur toutes les configs.

Bref, c'était possible avant mais fallait se farcir pas mal de bidouille dans les sources du kernel, et c'était pas franchement user-friendly.

Hé bien bonne nouvelle, Vincent Mailhol vient de proposer un patch qui simplifie tout ça !

Du coup, avec ce nouveau patch pour un prochain kernel, vous pouvez spécifier directement le chemin de votre logo personnalisé dans la configuration Kconfig. Fini les bidouilles dans les Makefiles et les sources, y'a maintenant trois options toutes propres : une pour le logo monochrome (format PBM), une pour la version 16 couleurs (PPM), et une pour la version 224 couleurs (PPM aussi). Et c'est à la compilation, que l'outil pnmtologo convertit votre image en code C qui est ensuite directement intégré au kernel. Et ensuite, c'est le framebuffer qui l'affiche au boot comme d'hab.

Et là je me suis dit que ça serait cool de vous proposer mon logo Korben tout prêt, histoire que vous puissiez tester direct. Du coup je vous ai préparé le fichier logo_linux_clut224.ppm au bon format (PPM ASCII 224 couleurs), vous n'avez plus qu'à le télécharger et suivre le tuto ci-dessous.

Ce qu'il vous faut !

Bon alors avant de vous lancer, vérifiez que vous avez les sources du dernier kernel Linux, les outils netpbm pour la conversion d'image, et les trucs de compilation habituels (gcc, make...etc.). Hop, une fois que c'est bon, on peut attaquer.

L'installation rapide (une fois le patch intégré)

Avec le nouveau patch (une fois qu'il sera mergé dans le kernel), c'est devenu hyper simple. Dans menuconfig ou xconfig, allez dans :

Device Drivers -> Graphics Support -> Bootup logo
 -> Standard 224-color Linux logo file: /chemin/vers/logo_linux_clut224.ppm

Voilà, vous spécifiez le chemin et c'est réglé. Mais si vous êtes sur un kernel plus ancien, faudra passer par la méthode classique.

La méthode classique (testée sur les kernels 5.x/6.x)

Commencez par installer les dépendances. Sous Debian/Ubuntu :

sudo apt install netpbm build-essential libncurses-dev bison flex libssl-dev libelf-dev

Sous Fedora/RHEL (téléchargez les vraies sources kernel depuis kernel.org) :

sudo dnf install netpbm-progs ncurses-devel elfutils-libelf-devel openssl-devel bc bison flex

Et sous Arch :

sudo pacman -S netpbm base-devel

Ensuite, récupérez les sources du kernel. Soit vous chopez celles de votre version actuelle avec apt source linux-image-$(uname -r), soit vous téléchargez la dernière sur kernel.org. Une fois décompressées, copiez le logo Korben à la place du logo par défaut. Sachez quand même que remplacer directement les fichiers dans drivers/video/logo/ fonctionne très bien pour un test perso, mais ce n’est clairement pas une méthode propre sur le long terme.

Ça complique les mises à jour, ça casse la reproductibilité du build, et c’est totalement inacceptable dans un contexte de packaging distro.

Mais bon, pour bidouiller chez soi, comme on est en train de le faire là, aucun souci. Mais pour un usage propre ou maintenable, mieux vaut éviter… et justement, le fameux patch dont je parlais plus haut va dans ce sens !!

cp /chemin/vers/logo_linux_clut224.ppm drivers/video/logo/logo_linux_clut224.ppm

Maintenant on configure le kernel. Copiez d'abord votre config actuelle avec cp /boot/config-$(uname -r) .config puis lancez make menuconfig. Naviguez vers :

Device Drivers --->
 Graphics support --->
 [*] Bootup logo --->
 [*] Standard 224-color Linux logo
 Console display driver support --->
 [*] Framebuffer Console support

Assurez-vous que ces options sont cochées avec * (ce sont des booléens, pas des modules).

Ensuite, y'a plus qu'à compiler. Adaptez le -j selon votre nombre de coeurs :

make -j$(nproc)
sudo make modules_install
sudo make install

Sur Debian/Ubuntu, lancez

sudo update-grub

Sur Fedora, c'est

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Et si votre distro utilise un initramfs, pensez à le régénérer aussi (sudo update-initramfs -u ou équivalent).

Et hop, redémarrez et admirez votre nouveau logo au boot !

Créez votre propre logo

Si vous voulez utiliser une autre image que mon logo Korben, voici comment la convertir au bon format :

sudo apt install imagemagick netpbm
convert mon_logo.png -background white -flatten -colors 224 temp.png
pngtopnm temp.png | ppmquant 224 | pnmtoplainpnm > logo_linux_clut224.ppm
rm temp.png

Le kernel attend un format PPM ASCII (P3) avec maximum 224 couleurs. Pour la taille, pas de contrainte stricte mais entre 80x80 et 200x200 pixels c'est l'idéal. À noter aussi que cette histoire de taille "idéale" reste surtout une recommandation et pas une règle imposée par le kernel car techniquement, Linux ne fixe aucune dimension maximale ou minimale pour le logo. L’image est simplement centrée à l’écran, sans mise à l’échelle.

Là je me suis loupé !

Du coup, un logo trop grand ne sera pas redimensionné mais sera juste rogné ou visuellement dégueu selon la résolution du framebuffer.

Les tailles autour de 80×80 à 200×200 pixels donnent en général le meilleur rendu, mais c’est avant tout du bon sens. Et évitez les dégradés trop complexes vu la limite de couleurs.

Et si ça marche pas ?

Sur les kernels récents (6.x et plus), sachez que simpledrm joue un rôle clé dans l’affichage du logo. En effet, sur beaucoup de machines modernes, il a pris le relais des anciens framebuffer comme efifb et permet d’avoir un affichage très tôt au boot, avant même le lancement de l’userspace.

Donc si le logo ne s’affiche pas alors que tout semble correctement configuré, le problème vient parfois simplement du fait que le framebuffer n’est pas encore actif à ce stade du démarrage, selon le GPU, le firmware ou la façon dont le driver est initialisé.

Autre cause fréquente, Plymouth (ou un autre bootsplash) qui masque tout simplement le logo du kernel. Pour vérifier, vous pouvez désactiver Plymouth temporairement en ajoutant plymouth.enable=0 aux paramètres kernel dans GRUB.

Rnfin, si vous utilisez un driver graphique KMS moderne (ce qui est le cas de la majorité des systèmes actuels), le logo devrait alors s’afficher pendant les toutes premières secondes du boot. En cas d’écran noir persistant, un test ponctuel avec nomodeset peut aider à diagnostiquer le problème, mais ce n’est pas une solution à utiliser systématiquement sur les machines récentes.

Et, pour les problèmes de couleurs bizarres, assurez-vous que votre fichier est bien en format P3 (ASCII) et pas P6 (binaire), quitte à relancer la conversion avec pnmtoplainpnm.

Dernière précision qui évite pas mal de confusions et après j'arrête de vous en faire des tartines, ce logo de boot est directement intégré au kernel, et pas à l’initramfs. Autrement dit, régénérer l’initramfs avec update-initramfs ou équivalent n’a aucun impact sur le logo du kernel. Donc si vous changez le logo, c’est bien le kernel lui-même qu’il faut recompiler et réinstaller.

Bref, perso, je trouve ça super cool qu'on puisse enfin personnaliser ce logo sans se prendre la tête. Ça fait un peu geek old-school c'est vrai, mais y'a un petit côté frime à avoir son propre logo au démarrage de sa bécane, que j'aime bien ^^.

Source

Lire plus

Lire plus

Lire plus

Lire plus

Si vous avez un PC Intel sous Linux et que vous avez toujours eu l'impression que Windows tirait mieux parti de votre processeur, vous n'étiez pas forcément paranoïaque. Sur certains processeurs récents, le noyau Linux gérait les fréquences CPU de manière conservatrice, ce qui pouvait limiter les performances dans certains cas. Bonne nouvelle : ça vient de changer.

En effet, le kernel 6.18, annoncé par Linus Torvalds le 30 novembre 2025, embarque un patch qui lève une restriction du pilote intel_pstate. Concrètement, le driver peut maintenant activer les états de performance matériels (HWP) dans des cas où il refusait de le faire auparavant.

Le truc technique, c'est que jusqu'ici, le pilote intel_pstate refusait d'activer HWP (Hardware P-States) si le processeur ne supportait pas EPP (Energy Performance Preference). Rafael J. Wysocki, mainteneur du sous-système power management, a modifié cette logique : désormais, si le bit DEC (Dynamic Efficiency Control) est activé dans le registre MSR_IA32_POWER_CTL, HWP peut fonctionner même sans EPP.

C'est important, parce que certains processeurs Intel récents intègrent cette fonctionnalité DEC mais pas forcément un support EPP complet. Du coup, avant ce patch, le driver désactivait HWP par prudence sur ces plateformes. Le patch cible notamment les processeurs Panther Lake.

Je sais, c'est beaucoup de jargon technique et je pense que j'en ai perdu pas mal d'entre vous, mais c'est chouette pour les gamers et les utilisateurs de distributions Linux orientées gaming comme Bazzite .

Sur les plateformes concernées, les applications mono-thread et les jeux qui dépendent des fréquences CPU élevées pourraient en bénéficier, même si l'impact réel dépendra de votre configuration matérielle et des réglages de votre distribution.

Bref, Linux rattrape enfin son retard sur Windows en matière de gestion des fréquences Intel. C'était pas trop tôt.

Source

Ceux qui ont déjà essayé de faire de la musique sous Linux savent de quoi je parle. Configurer JACK, gérer les latences ALSA, prier pour que le plugin VST fonctionne... C'était un peu l'enfer, non ? Perso, j'ai abandonné plusieurs fois avant que PipeWire vienne tout simplifier.

Du coup, quand je suis tombé sur LinuxDAW.org , j'ai eu un petit moment d'émotion. C'est un catalogue visuel et bien foutu qui répertorie plein de plugins audio disponibles sous Linux : VST2, VST3, CLAP, LV2, standalone, et même des modules VCV Rack. Le site a été créé par fractalf (le code est sur Codeberg ) qui explique l'avoir créé simplement parce qu'aucun des sites existants ne répondait vraiment à ses besoins quand il a switché vers Linux.

Et ce qui me plaît ici, c'est que ce n'est pas un site puriste open source. Y'a du FOSS bien sûr (et un filtre dédié pour les trouver), mais aussi les plugins commerciaux de u-he, Toneboosters, Kazrog et compagnie. Parce que oui, de plus en plus d'éditeurs supportent Linux nativement maintenant.

Après c'est vrai qu'en cochant le filtre FOSS, on voit nettement la différence de qualité d'interface avec les plugins payants. Vous le savez car je m'en plains souvent, mais niveau design, les projets libres ont encore du chemin à faire... Mais bon, ça reste fonctionnel et gratuit, donc on va pas cracher dessus.

Bref, si vous êtes musicien et que vous envisagez de passer sous Linux (ou si vous y êtes déjà et que vous cherchez des outils), LinuxDAW.org c'est exactement ce qu'il vous faut. Y'a plus qu'à digger tout ça ! Et si ça vous amuse, vous pouvez même contribuer en ajoutant des plugins qui manqueraient au catalogue.

Vous avez déjà essayé de faire tourner un vieux logiciel Linux sur une distrib récente, du genre un truc compilé il y a 5 ans ? Bah bon courage, parce que y'a de grandes chances que ça plante lamentablement à cause d'une dépendance qui aura changé entre-temps.

Maintenant, prenez un .exe Windows de 1998, genre un vieux jeu ou une appli Win32 classique. Lancez-le sous Wine et là, ô surprise... y'a de bonnes chances que ça tourne ! Bon, ça dépend des applis évidemment, mais le taux de réussite est souvent meilleur qu'avec les vieux binaires Linux...

C'est précisément ce paradoxe que pointe le projet loss32 , une distro Linux expérimentale dont l'idée complètement dingue serait de faire tourner TOUT l'environnement de bureau en Win32 via Wine. Leur slogan c'est "Win32 is the stable Linux ABI!" ce qui veut dire en gros que l'interface binaire la plus fiable pour faire tourner des applications sur Linux à long terme, c'est celle de Windows. Ahaha, je suis mort de rire en écrivant ça car j'imagine votre tête énervée de barbu ! Pourtant, vous allez voir, c'est difficile de leur donner tort...

Alors c'est quoi le problème avec Linux exactement ?

Hé bien en août 2022, un changement dans la toolchain a fait des dégâts. Beaucoup de distributions ont basculé vers l'option --hash-style=gnu au lieu de --hash-style=both, ce qui génère des binaires sans la section DT_HASH classique. L'idée c'était de gagner quelques kilobytes par binaire avec DT_GNU_HASH, qui est plus moderne et plus performant.

Ça n'a l'air de rien comme ça... sauf que ça a cassé pas mal de trucs. Des jeux utilisant Easy Anti-Cheat d'Epic se sont retrouvés en vrac, par exemple Shovel Knight a eu des soucis, ou encore le limiteur de framerate libstrangle . Bref, des logiciels qui marchaient très bien la veille se sont retrouvés dans les choux du jour au lendemain.

Et c'est là qu'on touche au cœur du problème car sous Windows, Microsoft maintient une compatibilité binaire quasi-religieuse pour les applis Win32 classiques. Un programme compilé pour Windows 95, s'il n'utilise pas de drivers ou d'APIs obsolètes, a de bonnes chances de tourner sur Windows 11. C'est un contrat tacite entre Microsoft et les développeurs qui a tenu pendant trois décennies.

Et même si sous Linux, le kernel et glibc sont plutôt stables, c'est vrai, dès qu'on parle de binaires tiers liés à des bibliothèques user, c'est une autre histoire. Et comme c'est le bordel et que chaque distribution fait un peu ce qu'elle veut, et les dépendances évoluent forcément. Du coup, si votre binaire précompilé casse, c'est votre problème. La philosophie c'est donc plutôt "recompile ton truc et arrête de te chialer 'spèce de fragile".

Et c'est pour ça que Valve a misé gros sur Proton. Officiellement, ils n'ont pas de préférence entre ports natifs et Windows via Proton, mais dans les faits, Proton fonctionne tellement bien que pas mal de studios ne se cassent plus la tête à faire des ports Linux natifs. Et parfois, les jeux Windows via Proton tournent même mieux que les ports natifs ... c'est dire.

Et le projet loss32 pousse cette logique jusqu'au bout car pourquoi se battre contre les moulins à vent de la fragmentation Linux quand on peut simplement tout faire tourner en Win32 ?

Alors perso, j'ai hâte de voir ça et visiblement un PoC devrait sortir en janvier 2026 avec un paquet APT pour qu'on puisse tous tester ça chez nous. Et si ça fonctionne bien, ça veut dire que si vous créez une application desktop simple et que vous voulez qu'elle tourne sur Linux encore dans 10 ans, cibler Win32 et distribuer un .exe via Wine/Proton est une option à considérer sérieusement.

Ça semble contre-intuitif, mais pour certains cas d'usage, c'est une stratégie pragmatique...

Pour les utilisateurs, ça veut dire aussi que Wine et Proton ne sont pas des rustines en attendant mieux mais des solutions de première classe pour faire tourner des logiciels de manière stable sur Linux. Le Steam Deck l'a prouvé avec des milliers de jeux Windows qui tournent nickel.

Bref, on en est là... Win32, l'API de Microsoft, est devenue paradoxalement une des couches de compatibilité les plus stables pour faire tourner des logiciels sur Linux. C'est fou non ? Ça va faire grincer des dents de barbus c'est sûr mais c'est aussi la preuve que parfois, les solutions terre à terre l'emportent sur l'idéologie.

Source

Lire plus