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.
Le gros point noir je trouve c'est qu'il n'y a pas assez d'explication sur quelles sont les différences entre une micro os avec son bureau et leap 16. Je ne sais pas si c'est moi qui ne suit pas mais pour l'instant je n'arrive pas à comprendre (ou ça n'a jamais été précisé) quelles seraient principalement les différences entre les deux.
Par curiosité j'attends de voir ce que va donner leap 16, mais je doute que ça ne soit mon futur. Restera à voir entre slowroll ou partir ailleurs.
Je reviens sur le sujet suite à la réponse de @burn2
Je suis donc allé voir sur mon Lenovo ThinkPad X240 (plus haut j'étais sur ma tour principale).
Un petit tour du côté des mises à jour sur Discover pour commencer : il y a une candidate nommée UEFI dbx que ne me mentionne pas zypper dup.
Si je lance les commandes de vérification de fuwpd, j'ai toujours l'avertissement signalé plus haut mais au bout du bout j'ai bien la possibilité d'installer une maj. J'installe, il s'agit bien d'UEFI dbx... et de rien d'autre.
dbx - Forbidden Signature Database - Le contraire de la base de données des signatures, des clés publiques, des signatures et des hachages qui ne devraient jamais être autorisés à démarrer.
Bon, sauf que Secure Boot est désactivé sur tous mes ordis. Ce n'est peut-être pas très malin mais le temps n'est pas si vieux où il fallait le désactiver pour pouvoir installer Debian par exemple (un Secure Boot fonctionnel est apparu avec Debian 10). D'un autre côté je lis que Secure Boot peut limiter certaines actions des utilisateurs (wiki Debian, rubrique Secure Boot). Le passage sur les pilotes gérés par DKMS ne me plaît pas beaucoup.
Bref, je reste comme ça... et cette maj UEFI dbx ne me sert à rien dans l'état actuel des choses
Bonjour,
Cette mise à jour est souvent disponible sur les pcs lenovo/dell, il s'agit d'un update de la liste des clefs de confiance secureboot.
Vu que tu n'utilises pas secureboot aucun intérêt à la faire. (il ne s'agit donc pas ici d'une mise à jour d'un firmware ou du bios/uefi, même si ça concerne l'uefi)
Je connais, mais personnellement je n'ai aucune machine compatible. Il faut avoir une machine du tyle dell ou parfois lenovo ou une machine compatible full linux genre slimbook pour pouvoir avoir un bios de ce style.
Apparemment ça sent le sapin pour ce pilote. Pour Tumbleweed on peut encoretrouver un pilote à jour pour le kernel actuel dans un dépôt communautaire : https://build.opensuse.org/package/show/home%3Awkazubski%3AG03/nvidia-gfxG04 Pour Leap 15.6 c'est cuit, il est supprimé. En attendant la sortie de 15.6, je n'ai plus qu'à mettre des brouzoufs de côté pour remplacer ma carte Gtx 550 Ti (vieille de 10 ans quand-même)
Nouvelle version installée ce lundi: Version 119.0.6045.199 (openSUSE Build) stable (64 bits)
Et à nouveau le bug est revenu. Comme la dernière fois solution de contournement désactiver l'accélération graphique dans chromium. Toujours sur l'igp vega, sous leap 15.5 kde X11.
Je pense que pour l'instant slowroll ne doit pas être très loin d'être tumbleweed tant que l'équipe pour contrôler ou le rythme n'est pas défini.
Donc pas si déconnant que ça.
D'ailleurs ne pas oublier que même si les mises à jour doivent être moins courantes, on parle des mises à jour de montée de version, quand il s'agit de sécurité, la descente sera toujours aussi rapide (et doit le rester) donc voir des mises à jour comme sous leap n'est pas un problème.
Bizarre effectivement, et tu n'aurais pas d'autre os à côté qui aurait pu jouer sur les partitions? Ou qui pourrait utiliser cette partition de swap et la verrouiller?
La présence de swap ou pas n'est pas lié à la présence de ssd ou pas. C'est une sécurité en cas de débordement de l'espace mémoire, ou c'est nécessaire en cas de mise en place de l'hibernation profonde puisque le contenu de la mémoire vive est copié vers le swap avant l'arret du pc. (mais il faut donc que la taille du swap soit > à la quantité de mémoire vive).
Perso j'ai beau avoir 32go de ram, je garde quand même un swap de plusieurs go ( 16go en général ), ça reste négligeable sur plusieurs to, ça évite en plus de pouvoir remplir à 100% le ssd et peut éviter certains plantages. Au final le swap n'est jamais utilisé (avec la conf qui va bien) mais ça reste une sécurité.
Pas encore testé (il faudrait que je vois en vm). Pour l'instant ça reste plus que de l'alpha et il n'est pas sûr que ça soit mis à jour régulièrement, donc si install il doit y avoir c'est "pour tester" et non pas en production.