Reprise du message précédent :
Un indice :  
 
https://imgur.com/a/UpLxt9m
 
   

KDE Neon + noyaux KRN

(cf topic uname -a)

J'ai voulu installer Xubuntu 24.04.1 sur PC portable Samsung et ça ne veut pas
Quand j'arrive sur la page de choix de la langue, ça reste figé
Ceci avec les versions Xubuntu desktop et Xubuntu Minimal
 
Je m'apprête à télécharger la version 22.04 ...

Prends la 23.10 plutôt, moins de mises à jour

 
Je ne trouve pas de version 23.10 pour Xubuntu

Ah oui c'est vrai, "end of life..."

Donc tu avais fait le bon choix avec la dernière lts

chuis bete, j'oubliai "old releases" https://old-releases.ubuntu.com/releases/
 
https://old-releases.ubuntu.com/releases/23.10/

Heu je vois pas l'intéret de prendre une version plus maintenue.
https://ubuntu.com/about/release-cycle

La 22.04 elle au moins reçoit des majs de secu jusqu'en 2027.

Donc si pb sur la 24.04 (et si tu une veux pas t'embêter à chercher l'origine) go 22.04.

éviter d'entrée une large mise à jour, surtout si la connexion est instable

Je ne vois pas ou tu veux en venir.
En installant la 23.10 plus maintenu l'objectif ça serait de passer sur quoi après? Puisque l'étape d'après c'est forcément la 24.10 qui ne passe pas?

Et passer de lts à lts+1 c'est normalement aussi risqué que de passer de version n à n+1 et le volume de donné à installer est proche.

Bon tu sais sans doute la majeure partie de ça, mais j'avais envie d'écrire

La pratique générale dans l'open source, c'est que les développeurs des applis mettent seulement à dispo un code source en .tar.gz avec des outils de build de base et de gestion configuration et de dépendance de build, comme Makefile etcetera

Ensuite le rôle de ces distribution est de fournir un système d'exploitation et une distribution d'applications executables compilées à partir des .tar.gz
Ces paquets sont compilés dynamiquement, c'est à dire que les librairies ne sont pas incluse dans le package, mais fournies par la distribution et chargées à la demande, et communes à beaucoup d'applications, ce qui permet de rationaliser l'espace disque et l'espace mémoire.

L'intérêt des .deb rpm etcetera était de gérer un système de dépendance et de version pour faciliter cette rationalisation, mais dans l'absolu, un .deb peut tout à fait fournir un paquet compilé de façon statique, c'est à dire avec les librairies nécéssaires inclues dans l'exécutable, ou bien ça peut être des librairies dynamiques fournies dans le .deb éventuellement.
C'est un peu ce qui se passait pour les jeux vendus dans le commerce pour Linux. Comme s'était trop compliqué de gérer plein de distrib, alors ils faisaient une sorte de gros executable avec tout ce dont il y a besoin et qui marchera sur tout.

Donc en parallèle de ce que font les mainteneurs des distributions, un dev d'application peut décider de fournir lui même des .deb statiques assez indépendants d'une version de distribution, ou bien par exemple faire par les ppas qui sont un système de build lié à Ubuntu qui permet de cibler des versions de distribution, et donc de s'inscrire dans la logique de rationalisation des librairies et diffusion de mise à jour centralisées.

L'intérêt des snap et flatpack c'est de s'affranchir de la distribution et d'avoir une sorte de binaire qui fonctionnera quelque soit la distribution linux, au prix de plus de conso mémoire et disque, mais de nos jours ça devient moins un probleme, et ça vaut le coup pour les applications difficiles à compiler et à maintenir, de n'avoir à le faire qu'une fois.

Après si quelqu'un peut m'expliquer la dimension containeur de snap, car ça monte plein de devices etcetera qu'on voit en tapant mount, c'est donc a priori plus compliqué qu'un simple binaire statique.

c'est sur que c'est bien plus complexe qu'une appimage qui inclus tout, mais elles sont énormes les appimage.
la au final snap a plein de lib, un vrai os a lui tout seul

Version après version, je constate que la barre d'avancement de copie d'un fichier depuis mon SSD (sur lequel tourne un Ubuntu 24.10) vers n'importe quel autre support (DD externe, clé USB, NAS) est complètement foireuse, tant au niveau de son avancée que du débit calculé. Je ne comprends pas qu'une fonction aussi basique d'un OS soit pétée à ce point, alors que n'importe quel OS (Windows, Android, OS Synology) y arrive très bien (oui bon sauf le dernier pourcent de Windows, parfois ).

Comment peut-on expliquer cela, et cela sert-il à quelque chose de faire remonter ce bug qui doit être largement connu et documenté ?

t'as déjà vu la barre de progression sous Windows afficher kkchose de pertinent ?
 
Tu passe de 1% à 2% en 5 mins de 2% à 20% en 30s et de 20 à 100% en 10min.. et une fois à 100%.. qui normalement indique que c'est terminé... bhaa rebelotte... on retourne à 1%.. et rezouuuu

C'est pas parfait ok, mais c'est moins nul que sous Ubuntu.

A l'instant encore, je fais une copie sur mon NAS via l'interface de son OS : aucun problème, la barre d'avancement est réaliste. Si Synology y arrive, Canonical devrait y arriver aussi

 
il y a plein de cache niveau kernel... donc difficile de savoir si le fichier est fini de copié ou pas.
 
donc perso je lance sync dans un terminal, la commande rend la main quand le fichier a fini d'etre copié

Exemple chez moi, sur Arch, avec Double Commander, quand je copie un gros fichier (1,3 Gio) :

• vers un disque dur externe NTFS : la barre de progression avance à vitesse constante et disparaît bien quand les 100% sont atteints.
• vers une clef USB FAT32 : la barre avance très vite jusqu’à environ 500 Mio, puis ralentit très fortement. Une fois à 100%, elle reste bloquée de longues minutes (en gros : la copie entière d’un tel fichier dure dans les 5 minutes).

Autre exemple, toujours avec DC et sur clef USB FAT32, mais sous Windows 11 : la barre avance normalement (elle ne ralentit pas) et disparaît à 100%.
 
Je mise sur la mise en cache des données avant leur copie effective, qui est désactivée par défaut sur Windows depuis XP, mais doit toujours être active sur Linux (et je sais pas comment désactiver ça, ne serait-ce que pour ne plus avoir l’impression trompeuse que la copie est immédiate alors qu’elle a à peine commencé en vrai).

Ce n'est pas comparable.

Il faut que tu comprennes que les distributions Linux c'est un assemblage de logiciels opensource développés par des centainnes de milliers de personnes qui n'ont jamais bossé ensembles dans la même boite

Ce que tu utilises pour faire la copie et qui affiche l'avancement c'est probablement le navigateur de fichier Nautilus.
Nautilus fait partie de la suite de logiciel de Gnome Shell, qui est une interface Desktop de la fondation Gnome.

Canonical customise les thèmes, et peut-être fait quelques patchs sur Gnome, mais c'est pas eux qui développent.
Et Gnome Shell ce n'est qu'un desktop parmis une dizaine qui ont tous des philosophie différentes, et que tu peux installer, mais il est par défaut et c'est un des plus complets avec KDE.
La philosophie de Gnome c'est la simplicité avec des options limitées, pour cette raison pas mal préfèrent KDE qui a un côté plus Windows.

Après concernant la barre d'avancement ça ne dépend donc que du navigateur, et par exemple Windows Explorer précalcule ce qu'il va devoir copier, là ou Nautilus par soucis de légerté et simplicité ne se fait pas chier avec ça.
Donc à toi de chercher un outil qui ferait ça mieux.

Moi ce qui me gène en général c'est qu'il n'y a pas de file d'attente de copie comme supercopier, mais j'avais trouvé un plugin qui le faisait une fois, mais évidement je pense qu'il ne fonctionnait plus par la suite

cherchez pas d'où ça vient : c'est la GLib lors de la copie qui ne surveille pas bien le transfert

Euh oui d'accord

: dans le doute, reboote

Ce genre de truc m'arrive quand un montage NFS ou un truc du genre s'est vautré, plus moyen d'accéder aux corbeilles (qu'il tente de lire sur certains montages qui ne sont plus accessibles) via Nautilus ou un autre explorateur de fichiers.

Ah oui ça doit être ça, entre temps mon NAS s'était éteint, ça n'a pas dû lui plaire

Normalement, il faudrait faire un umount -l /tonmontage
J'avais ça entre-autre quand je partais du travail et que je rouvrais mon portable dans le train, les montages étaient vautrés, et plus moyen d'avoir la corbeille dans Nautilus.
Même un umount -f ne fonctionnait pas ...
 
En fait, il cherche désespérément la corbeille dans /tonmontage/.Trash* et ne trouve rien évidemment, et comme il est con-con, il va continuer à la chercher.

C'est bon à savoir

Hello,

Je vais surement changer de config, d'un vieux I3-540 je vais passer à un Ryzen 8600G, pas de carte graphique.

Rien à signaler sur une potentielle incompatibilité du Ryzen 8600G et de son chipset graphique sur l'OS ubuntu?

Je pense partir sur une fresh install ubuntu lts 24.04 ou alors une Linux Mint Mate.

R.A.S.

très bon choix

Y a-t-il des experts DNS sur distro Ubuntu / Mint ?    
 
Lors de l'établissement d'un tunnel OpenVPN, l'OS ignore superbement le serveur DNS côté VPN, ce qui est embêtant pour atteindre les hôtes liés ....  

Arf, en fait, ça dépend de ce que le serveur VPN a envoyé comme config réseau (routes, DNS, etc ..)

S'il te manque des choses, soit tu corriges côté serveur, soit tu te tapes un script de mise à jour DNS et routes que tu lances une fois la connexion VPN établie.
Je sais, c'est pas fou fou

 
Mais en fait, tout à l'air en ordre...
 

 
... sauf que lorsque le système doit effectuer une requête DNS, il le fait via 192.168.1.1, pas le 10.1.1.1 ( et du coup les FQDN des hôtes côté VPN sont inconnus ...    )

cherches pas, systemd-resolved est le coupable... j'en ai fait les frais plusieurs fois.
en gros, cette bouse de resolved va envoyer la requete dns par toutes les interfaces et serveurs dns qu'il connait, et prendre celui qui repond le plus rapidement..  
du coup ca n'utilise pas forocémment le serveur dns via le vpn, et ca leak des informations internes à un autre DNS, et tu n'arrives pas à les résoudre  
 
solution: virer systemd-resolved (ou à minima, le desactiver et le masquer)
et n'utiliser que le bon vieux /etc/resolv.conf, qui dvrait alors etre géré proprement par NetworkManager.
pour ce faire:  
 
1/desactiver/masker systemd-resolved:

 
2/ supprimer /etc/resolv.conf:

 
3/ relancer le service NetworkManager. la t'auras tes dns normaux de ton lan dans le resolv.conf

 
4/ s'assurer que resolv.conf est bien un fichier (et nonu lien symbolique), et vérifier son contenu. tu devrais avoir le dns de ton lan

 
5/ et dans la config openvpn, il faut rajouter une ligne, je ne sais plus laquelle, appelant un script (possiblement deja présent dans /etc/openvpn) pour que lors de l'etablissement de la connexion openvpn et reception des infos (ip, netmask, dns etc..), le dns soit mis dans le resolv.conf (et enlevé lors de la deconnexion)

 
La solution violente  
 
Avant de tout dézinguer, sais-tu s'il n'y a pas une solution plus "soft" qui ferait comprendre à systemd-resolved d'interroger tel ou tel serveur DNS selon le suffixe du FQDN ?  
 
Je ne peux pas croire que les devs n'aient pas conscience du problème, on parle quand même d'un service qui est déployé sur des centaines de milliers de machines ....
 
 
 
 

bientot on va renomer linux en systemd tellement ça fait de merde ce machin...
 
j'ai vu qu'ils remplacent grub par systemd-boot...

Je pense avoir trouvé une solution satisfaisante    
 

• la directive dhcp-option DOMAIN ***** envoyée via le serveur OpenVPN ( ou définie en client-side ) permet de lier le tunnel VPN à un domaine particulier  

• le problème c'est que cette directive n'est pas prise en compte lors de la création du profil OpenVPN ( soit parce que systemd-resolved l'ignore ou alors la gestion des profils VPN est lacunaire )  

La solution alternative est de définir un script up dans le fichier de config *.openvpn , avec la commande suivante :
 

 
Et là, miracle :
 

C'est bien la le probleme. les devs de systemd. surtout le principal (un cerftain LP). qui bosse maintenant chez microsoft.
ce dernier est champion pour fermer les bugs reels de systemd en repondant "ca marche sur mon laptop, wontfix"  

Pour ma part, alors que j'etais sur mint, dans cette même situation, j'ai beaucoup cherché, et n'ai jamais trouvé de sollution fonctionnelle, me permettant d'utiliser le dns fourni par openvpn, autrement qu'en virant systemd-resolved..
Et avant cela, ya toujours lebug du meme systemd(resolved, ou aleatoirement, celui va te dire qu'il est bien configuré avec les dns filé par DHCP, sauf qu'en pratique, tes requetes dns sont envoyées à 8.8.8.8 (google).
je l'ai vu pour la 1e fois ya de nombreuses années, et je l'ai vu ya envore pas longtemps.

Donc serieusement, qu'on aime ou aime pas systemd est une chose, mais factuellement, systemd-resolved est une bouse, à laquelle on ne peut pas faire confiance.
Ta demande et constataion en est une preuve de plus

C'est assez veai, oui. progressivement systemd mange tout l'eco-systeme autour du noyau linux.
de fait, on ne devra plus dire gnu/linux mais systemd/linux.
merci redhat/ibm

ça fait deja un un bout de temps que ça existe. heureusement ce n'est pas enocore par défaut sur la plupart des distros.

Vous pensez que si j’installe ubuntu sur un Lenovo thinkpad compatible sim/4g ce sera automatiquement reconnu par ubuntu ?

Tu peux déjà tester en live avec une clé USB

GIMP 3.0 (rc1) cette chiasse  
la gestion des calques n'est plus la même

Krita ?