Cette espace vous permet de voir toutes les Messages réalisées par ce membre. Vous ne pouvez voir que les Messages réalisées dans les espaces auxquels vous avez accès.
Sur trois installations de TW, sur une seule j'ai eu la question au sujet du conflit grub2 / dracut-pcr-signature. Je me suis dit qu'il était impossible de virer grub2 sans connaître de graves problèmes ultérieurement. Je suis allé voir les deux autres installations et sur celles-ci dracut-pcr-signature n'était pas installé (pas plus que sdbootutil). J'ai donc choisi l'option 2 (dracut tout seul n'en demeure pas moins installé).
Je n'ai aucune idée de la raison pour laquelle ces paquets conflictuels avec grub2 étaient installés sur ce PC.
Jette un œil sur cette page pour réparer une base de donnée RPM corrompue :
C'est de la documentation SUSE plutôt complète sur le sujet. Elle indique aussi où le système fait des sauvegardes de la base de données RPM et comment au besoin récupérer l'une d'elles.
Tout ça me dépasse mais, rapport au dernier incident majeur, la réactivité est notable et les moyens mis en œuvre me paraissent considérables. Chapeau!
La quantité de RAM est trop juste. Je crois qu'on peut monter à 4 Go avec cette machine, peut-être 8.
Un SSD SATA comme dit Mister-Magoo mettrait un sacré coup de fouet à ton ordi. Faut pas viser trop haut, 240 Go ou 500 Go max des fois que la machine n'encaisse pas (c'est possible).
Sinon, en l'état, sans rien toucher, il faut viser des distributions Linux bien plus frugales. Faut un peu chercher bien sûr. Mais c'est jouable.
Windows 10, à moins de 4 Go... et encore! avec un disque dur mécanique, faut pas y compter. Leap pareil en gros (ce doit être possible mais à quel prix en termes d'optimisation).
Ne jette pas surtout, si tu ne sais pas quoi en faire, d'autres sauront.
Changement effectif du format du fond d'écran officiel avec la mise à jour d'aujourd'hui sur TW (20240409).
Bon d'accord, aucune objection à l'utilisation d'un format sans perte. D'ailleurs le fond d'écran officiel de la nouvelle mouture de KDE est aussi en png (depuis plus longtemps peut-être, je n'ai pas fait attention).
openSUSE cherche à optimiser l'utilisation de ce format pour en réduire le poids si j'ai bien compris. Très bien... enfin cela montre une intention très louable.
Chouette! de nouveaux fonds d'écran. J'aime beaucoup l'actuel ceci-dit même si je l'utilise peu (j'y reviens quand même parfois).
J'ai un peu regardé comment fonctionnait la méthode interactive, c'est simple à priori. Par défaut nous avons déjà xdm qui est installé en plus de sddm, mais je ne sais pas à quoi il ressemble. Tu peux installer lightdm qui est probablement plus chouette qu'xdm. Tout ça sur X11 par contre (mais comme solution provisoire...)
@burn2 : Là on rétropédale encore une fois (-2), d'où l'inquiétude. Je n'ai pas non plus les moyens intellectuels de vérifier la pertinence de tout ça.
@chumi : en même temps, le sous-système Linux développé par (et pour) Microsoft est sans doute également impacté par cette backdoor.
Oui certainement mais dire que ces failles sont indétectables par ou dans des systèmes propriétaires m'a semblé caricatural. Le logiciel propriétaire a de bons ingénieurs, la preuve. Par contre, c'est vrai, l'ouverture du code, à l'avantage du logiciel libre, a permis à l'un de ces ingénieurs "propriétaires" de mettre le nez dedans.
C'est comme un écho de ce qu'il s'est passé avec le paquet xz.
Peut-être ou pas, mais cela manifeste encore une faiblesse en termes de contrôle (là, au niveau du magasin de KDE).
Et dire que je voyais d'un mauvais œil les extensions de Gnome pour des raisons similaires supposées par moi, ce n'est pas pire finalement.
De mon côté je me satisfais depuis un bon moment du thème Breeze par défaut même si j'ai un peu joué au début quand j'ai redécouvert KDE. Bon, c'est quand même gênant cette histoire pour un environnement qui offre tant de possibilités de personnalisation et dont c'est un peu l'image de marque.
J'imagine l'angoisse de nos amis sous système propriétaire dans lesquels ces failles sont indétectables.
Bonjour,
Andres Freund qui a découvert la faille est un ingénieur de chez Microsoft (on peut trouver sa fiche sur Linkedin). Ce n'est pas rapporté dans tous les articles ou toutes les nouvelles mais ici oui par exemple :
Il faut reconnaître que le déroulé de l'affaire fait surtout apparaître une faiblesse humaine dans le modèle de développement du logiciel libre. Cela n'invalide pas le modèle social de ce dernier mais le monde est ce qu'il est aujourd'hui, pourri de tensions géopolitiques et économiques auxquelles rien n'échappe.
Tiens! j'ai mis à jour (20240328) et redémarrer immédiatement sans connaissance de tout ça (qui ne m'éclaire pas trop sur le risque que j'encoure personnellement). Bon, prosaïquement j'attendais autre chose de cette maj KDE 6.0.3, quoi de neuf? ou plutôt, quoi de mieux? qu'est-ce que j'observe de mieux?
La consigne est donc de mettre à jour et de redémarrer.
Merci pour l'info (ça le fait, une citation et un lien vers ton blog).
Tu as essayé le paquet communautaire? ou une une installation manuelle... pip-je-ne-sais-quoi ?
Je crois qu'il va falloir être patient mais il y a un espoir. À titre personnel je ne le sens pas d'expérimenter à tout-va pour retourner des bugs ou un fonctionnement inattendu (en anglais déjà?). Je m'éloigne peu à peu d'une pratique photographique exigeante et précise sous certains aspects.
Il y a de très bons photographes qui utilisent Linux, dont certains qui vivent de leur passion, j'ai bon espoir.
(comme l'un des intervenants dans cette discussion, lors de mon essai avec Wayland, "DisplayCal fonctionne, mais n'affiche pas le patch de couleur")
Le projet du fork est actif. On peut se permettre d'espérer une issue. La question est de savoir à quelle vitesse Wayland viendra à supplanter complètement X11.
On verra bien... que dire de plus? En ce qui me concerne je n'ai pas le temps ni les moyens de creuser davantage la question, ce qui n'empêche pas d'essayer d'entrevoir vaguement l'avenir.
Cette page continue d'être mise à jour et j'y apprends qu'il y a un paquet communautaire pour TW. Visiblement il y aurait aussi en plus un paquet expérimental pour TW et un communautaire pour Leap 15.5 :
Pour les photographes passionnés (dont je fais de moins en moins partie même si le sujet m'intéresse quand même), la prise en compte par les environnements graphiques du ou des profils (icc) résultant du calibrage d'un moniteur, est importante.
Je ne refais pas toute l'histoire mais nous avons un logiciel bien connu pour calibrer nos écrans, DisplayCAL, qui n'est plus disponible dans les dépôts (flatpak donc car je doute que sa compilation soit possible ou simple en raison de la version de python dont nous disposons).
Du fait que KDE Plasma 6 pousse en quelque sorte à l'utilisation de Wayland, je me suis posé la question de l'utilisation de DisplayCAL avec ce serveur graphique, ce que je n'avais jamais essayé de faire jusque là.
J'ai donc tenté de calibrer mon écran avec DisplayCAL sous Wayland.
Le logiciel se lance mais un message d'erreur a bloqué ma tentative de calibrage. À confirmer par d'autres utilisateurs du logiciel en question.
Qu'à cela ne tienne je suis donc allé calibrer sous X11 et j'ai obtenu un profil icc.
Avec X11 sur KDE, la prise en compte de ce profil par l'environnement graphique se fait grâce au Gestionnaire de couleurs dans la Configuration du système, à condition d'avoir installé le paquet colord-KDE.
Avec Wayland, ce n'est pas là que ça se passe. Il faut se rendre dans la Configuration de l'affichage.
Cela pose un petit problème. Avec X11, dans le Gestionnaire de couleurs, il est possible d'enregistrer plusieurs profils à ce niveau (un destiné à l'affichage sur le Web et un autre pour l'impression par exemple) et de basculer rapidement de l'un à l'autre.
C'est beaucoup moins simple avec Wayland comme vous pouvez le voir sur la capture d'écran ci-dessus.
Je m'interroge à présent sur DisplayCAL dont le développement est l'arrêt depuis un moment. S'il se confirme qu'il ne fonctionne pas avec Wayland, les photographes, les vidéastes et les graphistes auront des soucis à l'avenir. Argyll CMS en lignes de commande, sur lequel repose d'ailleurs DisplayCAL, ce n'est pas la joie
Ça pour KDE car Gnome dispose d'une solution rudimentaire, mais d'une solution quand même (gnome-color-manager) pour faciliter le calibrage.