Reprise du message précédent :
En vrai, j'utilise Debian sur mon serveur, mais je serais trop frustré de l'utiliser sur un ordinateur client.

Bha ça bouge pas. Mais ça marche

Quand Nginx était tout naissant et le package trop loin derrière, je compilais à partir des sources, ça marchait super bien (en même temps il y avait peu voire pas de dépendance )
 
Ça m'avait presque embêté de devoir délaisser la compilation (nostalgie Gentoo) pour le package debian quand celui-ci avait enfin atteint la v1.0
 
De mémoire je devais faire pareil avec Ruby (pour le passage de 1.8 à 2.0), mais c'était plus compliqué à maintenir, heureusement il y avait RVM pour les autres montées de version

Je ne sais pas quel a été le contenu de tes échanges sur les autres forums Debian.
Du coup je serai peut-être un peu hors sujet.
 
Mais je trouve cette façon de tout le temps tout changer assez malsaine.
Si c'est pour changer et apporter quelque chose de positif, de stable, de mieux conçu, en résumé quelque chose de positif : alors oui.
 
Si c'est comme je le vois trop souvent au taf, changer pour faire pire, pour avoir absolument la dernière version mal testée, truffée de bugs et tout casser : là non je ne vois pas l'intérêt.
 
Je suis informaticien et je le vois tous les jours hélas. Programme mal fait, bugé, pas ou mal testé, bugs récurrents, utilisation compliquée ou très lourde, utilisateurs qui se plaignent (et ils ont raison car quand ça ne marche pas c'est leur travail qui est compromis).
 
C'est pour cette raison que je suis passé sur debian sur mon ordinateur portable perso. C'est simple, stable, robuste, suivi, avec les maj de sécurité etc...
En gros je n'ai pas envie de m'embêter chez moi avec les mêmes conneries que je trouve au taf.  
 
Je ne dis pas que debian est exempte de bug (dans la vraie vie ça n'existe pas). Mais c'est quand même plutôt bien fait et je peux le configurer selon mes besoins et mes envies.
 
Et si je n'ai pas la dernière version à la mode et bien tant pis. Je veux que ça marche correctement et que ce soit stable.
 
 

Ouais et encore en testing ça va, on est pas non plus à des années lumières des dernières versions des apps.

pareil

Perso je l'utilise à la fois en serveur/vm et sur mes pcs perso.

J'ai plus assez de temps pour bricoler à côté, donc je veux pouvoir faire mes mises à jour sans me prendre la tête, et je sais que pour 99.9999% des cas ça se passera sans aucun problème avec debian stable.
Le seul moment ou je dois prévoir du temps c'est quand je fais mes tests de montée de version N+1 et du coup je sais quand c'est et je peux planifier.
Le reste du temps je peux utiliser ma config pour ce que je veux faire ce qui est le principal.

J'aimerais suivre les nouveautés plus rapidement, genre un compromis une maj par ans, mais ça n'existe plus vraiment. Donc faute de temps debian me convient même si la dernière année est assez frustrante en général en attendant la version N+1.

Moi ça me va parfaitement un linux qui bouge pas avec un noyau qui supporte bien mon matos (backports) et mesa récent (flatpak)
C'est plus les gens qui aiment pas le changement qui me dérangent. Enfin je sais pas comment décrire ça. Faudrai que je vous envoie le lien de ce qui s'est passé avec l'admin du forum debian facile et vous comprendriez

Purée c'est vrai que c'est cool Debian, mais ne pas avoir certaines version à jour parfois pénible.
 
Meilleurs méthode pour yt-dlp du style ajout de dépot? ça me force à prendre mon PC portable sur Arch...

ajout du dépôt unstable et le pinning qui va bien oui
 
pour yt-dlp les mises à jour sont bien suivies dans unstable, en plusieurs années j'ai très rarement été en rade suite à une MAJ de youtube, et ça n'a jamais duré longtemps.

mais non bordel, cette manie de vouloir faire des truc gorets de suite

yt-dlp est en backport https://packages.debian.org/search? [...] rds=yt-dlp

https://backports.debian.org/Instructions/#index3h2 (l'installation uniquement avec le -t la première version est moisie)

qu'est-ce que ça a de goret ?

 
Mixer du stable avec du unstable quand une solution moins risquée existe.

est quoi est-ce moins risqué ? Le résultat me semble fonctionnellement identique, à la fin dans les deux cas on a la dernière version de yt-dlp que les packageurs ont bien voulu packager pour Debian.

J'ai bien fait de demander, merci
 
Je vais tester ça.

 
 
D'un côté tu as un environnement avec uniquement des paquets stables et de l'autre tu te retrouves à mixer tes branches au risque d'avoir un jour ou l'autre un conflit de version.

et le fait de jouer avec le pinning qui n'est pas le truc le plus trivial qui soit et qui peut être catastrophique si tu te merdes et qu'il faudra éventuellement penser à remodifier avant de changer de version, etc.
 

backport est fait pour tourner en stable il est compilé avec les dépendances de stable quand c'est possible, testing ou unstable en ont rien a foutre du coup ils risquent d'installer tout leur écosystème...

sympa quand grub et initramsfs pètent en même temps.
J'essaye de réinstaller les versions de stable, mais lors d'un update-grub (ou même lors de la configuration de grub-pc), il me dit gentiment grub-mkconfig not found

[edit] et supprimer tous les paquets grub* et memtest86+ tentent de relancer grub-mkconfig non trouvé...

 
Bon pour virtualbox dans les repos de debian, je pense que je peux faire une croix dessus. Plus qu'à m'orienter sur autre chose, je vais finir par devoir partir sur libvirt + virtmanager mais ça me gêne quand même vu qu'on n'est pas sur un hyperviseur type 2, et donc sur un pc portable c'est un peut trop lourd (plus de 100 dépendances) pour juste virtualiser un truc pour tester de temps en temps  
 
 
Sinon, autre paquet qui n'est pas présent dans debian 13, c'est zulucrypt, plus qu'à trouver une alternative.

@thana54 comment t'as fait ton compte ?
et pour grub-mkconfig (installé dans /usr/sbin) il est normalement dans "grub-common"

@burn2 qemu-kvm est parfait pour cela. je l'utilise régulièrement pour me lancer une/des vms sur ma machine perso pour tester des distros ou des softs..
faut un script qui te lance la vm avec les bonnes options, ya pas de GUI, mais ya pas non plus trouze mille dépendances, qemu ne m'a jamais pété à la geule suite à une maj
edit: y'a aussi un autres soft (dont j'ai oublié le nom...) qui t'installe une petite interface web permettant de gérer simplement des vms, lancées avec qemu, qui marche relativememnt bien. faut que je te retrouve le nom, ça peut peut être te convenir..

C'est le pb, perso je cherche plus un gui qu'un truc pas pratique en cmd.  
y a bien aqemu mais ça semble pas suivi alors que dans le principe ça ferait le taf partaitement.

ha voila. il s'agit de cockpit.
essentiellement tu installes cockpit, et cockpit-machines (c'est le plugin qui permet de gerer les vms)
le paquet est dans les repos debian (mais il dépend de systemd.. au cas ou )
le site du projet: https://cockpit-project.org/

cockpit un gui web pour gérer des machines locales.  
Encore une fois vraiment pas un truc pour un poste utilisateur qui veut faire tourner des vm en local de temps en temps.  
 

Virt-manager ?

C'est ce que j'évoquais.
Le pb c'est que virtmanager ça ramène plus de 109 dépendances.
Et quand tu regardes c'est plein de daemon etc. On est plus dans l'optique d'une utilisation serveur que sur un poste utilisateur pour lancer un truc 2 ou 3 fois de temps en temps.  
En gros on n'est pas vraiment sur un équivalent virtualbox/vmware player.
 
Exemple aqemu (en incluant qemu) c'est 34 dépendances installées. ça ressemble bien plus à un équivalent ou t'as juste qemu et un gui. Je pense partir dessus mais ça ne semble plus du tout suivi donc j'ai peur que ça ne soit que temporaire.

quickemu
pas de gui, mais beaucoup plus simple et parfait pour de l'occasionnel.

Le but ce n'est pas de bricoler en CMD. (sinon à ce moment là je fais des alias etc et pas besoin de logiciel en plus)
Quickemu je l'avais vu, avec son gui "quickemu-gui".

Le suivi est assez ancien aussi de toute façon (vu que ça ne bouge plus de depuis 2024).

On en revient au final à aqemu est plus pertinent.

sinon pour quickemu (https://github.com/quickemu-project/quickemu), y'a aussi une GUI dans le meme projet github:
https://github.com/quickemu-project/quickgui
qui permettrait de créer/gerer des vms. à voir..

Oui c'est le gui que j'évoquais.
Mais pas présent dans les repos de base de debian.
Et en vrais pas vraiment convaincu par ce truc.
(choix techniques/ fonctionnement du truc et si je me base sur les screenshots je ne vois même pas comment on change les caractéristiques d'une vm existante ou comment on les définis...).

Bref, sauf à basculer sur aqemu, y a rien qui me bote vraiment dans ce qui est présent dans les repos. Soit c'est un truc bien trop complet (virt-manager), soit des trucs bricolés très moyen.
Sinon reste le choix de rajouter le repo d'oracle pour mettre virtualbox, mais tant que faire se peut je veux éviter les repos externes. (même si j'ai déjà mozilla)

Par contre, je vais creuser karton voir sur quoi il se base vu que ça l'équivalent de boxes pour kde, pour le coup, je ne comprends pas pourquoi ils ne sont pas partis de aqemu pour le moderniser mais il y a surement des raisons.
Il me semble avoir vu que ça se basait à nouveau sur libvirt à voir si on se retrouve avec la foule de dépendance évoquée avant.

t'as déjà le repo mozilla et tu veux pas rajouter de dépôt oracle

Oui pour l'instant.  
Mais vu l'évolution prévue de firefox, là aussi va falloir se retourner encore sur autre chose....  
 

Bon, aqemu c'est un non. C'est trop buggué.
La vm windows 10 marche mal (pas de curseur si je prends QML, si je mets le gpu de base le curseur est décalé).
Les réglages sautent genre je mets 4 vcpu, je quitte aqemu relance il est revenu à 1 etc.

Bon il ne va plus rester 36 000 choix, soit rajouter le dépôt de oracle soit tester virt-manager voir si ça se passe mieux qu'avec aqemu.
ET sinon oui karton c'est bien libvirt derrière, à voir ce que ça donne mais depuis aout ça n'a plus trop l'air de bouger le dev non plus. Donc loin d'être près cela dit ça sera peut-être près pour debian 14.

Franchement virt+manager ça fait le taf.
C'est léger , tu peux piloter des VM distantes et locales, c'est simple à prendre en main.

C'est c'est que j'ai installé au final virt-manager.
Par contre je ne dirais pas que c'est léger au vue des dépendances et daemon installés.  
 
Je commence à bidouiller la vm windows 11 à installer les guest agent et voir si tout se passe bien.

Vu dans la rue.
 
Qui du topic l'a fait?
 

Un apt dist-upgrade sur un mx-linux unstable. Ca faisait un moment que je ne mettais pas à jour grub et initramfs, et juste avant je me suis dit "vu la 'grosse' mise à jour de plus de 1Go, je vais faire un mx-snapshot...au cas où...".
Ca voulait pas me laisser réinstaller une version non buggée de grub, donc j'ai réinstallé à partir de l'iso de mx-snapshot.
Et j'ai mis grub en hold et initramfs aussi

Cherche plutôt du côté du topic Ubuntu

 
Ubuntu c'est un truc de state capitalists prétendument tiersmondistes, genre la Chine (et son OS Kylin)

Bon la bascule à virt-manager semble validée.
C'est peut-être un poil moins perf niveau graphique pour une vm windows, vais voir pour les vm linux mais normalement de ce côté là ce n'était pas un pb.

Petite fraicheur du matin, j'ai voulu faire une mise à jour progressive pour éviter d'avoir d'autres problèmes *tousse*
J'ai donc évité les grub, initramfs et autres composants vitaux de l'os (surtout du boot de l'os), et j'ai mis à jour plasma et ses brouettes de dépendances.
Pendant l'installation, mes écrans s'éteignent brusquement et je suis accueilli par l'écran de connexion sddm, pourtant la vidéo que j'avais tourne encore en tâche de fond (au moins l'audio), sur tty1 je pouvais voir les différents process de plasma/kwin/sddm listés, et kwin-wayland bouffer 29% de cpu alors que je n'avais rien. Redémarrage forcé de sddm, retour sur un bureau noir, rien d'autre. Après reboot, ca semble marcher "normalement" ...pour l'instant.