Quitter le forum et retourner au site

Les problèmes de GNU/Linux

Lieu "à la mode" pour discuter et débattre sur les logiciels libres, les distributions linux, etc...
Avatar de l’utilisateur
le Manchot Masqué
Administrateur du site
Messages : 719
Inscription : lun. 26 mai 2008, 21:05
Distribution : Debian, Ubuntu
Niveau : Moitié plein !
Localisation : Guebwiller

Les problèmes de GNU/Linux

Message par le Manchot Masqué »

On a beau dire que notre OS est le meilleur - ce qui est vrai dans quasiment tous les domaines aujourd'hui - il n'en reste pas moins qu'il n'est pas parfait non plus, et qu'il reste toujours des petites choses à améliorer.
Le but de ce post est de faire un peu le point et de voir ce que nous pouvons faire à notre niveau pour essayer de pallier ces problèmes, et de faciliter la vie de nos usagers.

Les mises à jour
-------------------

La plupart des particuliers commettent tôt ou tard l'erreur d'éteindre leur machine brutalement, alors qu'elle est en train de faire ses mises à jour. C'est peut être un détail pour vous, mais pour eux, ça veut dire beaucoup (= machine plantée)...
Un libriste aura vite fait un

Code : Tout sélectionner

dpkg --configure -a
puis un

Code : Tout sélectionner

apt-get -f install
pour une distribution à base de paquets deb, il n'en reste pas moins que cette procédure devrait faire partie du démarrage, et non d'une action utilisateur à posteriori. Peut-être quelque chose à rajouter dans /etc/rc.local, avant la ligne exit ?

Autre solution possible : mettre les mises à jour en manuel d'office, avec le risque d'une machine moins à jour pendant un certain temps.

La reprise de contrôle
--------------------------

Là encore, nous avons l'habitude d'utiliser des clés USB bootables, et de faire des manipulations en console pour reprendre le contrôle d'un OS planté (libre ou non...). Côté GNU/Linux, il serait bien plus simple d'avoir un programme qui effectue la vérification du système installé sans aucune intervention, et effectue par exemple les commandes de mises à jour déjà vues plus haut.

Je parle évidemment de cas "simples", où l'OS est installé sur une partition standard sans RAID, LVM, cryptage et autres joyeusetés.

Le gestionnaire de mot de passe
--------------------------------------

Actuellement, c'est le paquet gcr qui joue rôle de gestionnaire de certificats sous Mate, en remplacement de gnome-keyrings. Problème : si vous mettez un mot de passe principal la première fois, en théorie, gcr-viewer devrait vous permettre de le modifier en mode graphique. Mais voilà : gcr ne semble pas vouloir afficher le contenu du portefeuille, et c'est très vite barbant, pour le grand public, de devoir se retaper à chaque fois un mot de passe dès qu'une application à besoin d'un mot de passe enregistré dans le portefeuille... Là encore, un habitué aura vite de renommer le ~/.local/share/keyrings en ~/.local/share/keyrings.bak et de relancer la session, mais on est de nouveau dans une manipulation de console pure, ce qui n'est pas normal. Espérons que gcr-viewer sera bientôt corrigé, et permettra fera enfin son boulot correctement !

Les drivers graphiques
--------------------------

On connaît tous le problème : des fabricants qui ne veulent toujours pas ouvrir complètement les sources de leurs drivers, et traînent des pieds avec le matériel récent. Entre le pilote libre "nouveau" pour les cartes nvidia, et "amdcccle" pour les cartes ati, il est clair que cette grosse partie se joue clairement au dessus de nos têtes, et est vraiment le dernier point faible de nos distributions. Le problème ne serait pas si grave si les fabricants fournissaient enfin des scripts qui remettent automatiquement l'ancienne configuration en place dans le cas où le pilote propriétaire échoue à l'installation. Malheureusement, il est souvent arrivé, y compris en réunion, qu'on ait à mettre les mains dans le cambouis pour reprendre la main.

Le BIOS UEFI
---------------

Pour les machines en dual boot, les constructeurs arnaquent les usagers en favorisant bien évidemment le boot windows, c'est à dire en court-circuitant GRUB, ce qui est inadmissible. Seule solution : mettre dans /etc/rc.local le lancement d'efibootmgr en "forçant" la partition GNU/Linux comme seul et unique OS installé.

En clair, ça donne dans /etc/rc.local (ligne de commande à adapter suivant la sortie de efibootmgr sans arguments), avec la ligne exit, quelque chose du genre :
/bin/efibootmgr -o 0003




Voilà en tout cas pour ce petit tour d'horizon. Comme toujours, il y a des choses sur lesquelles on peut facilement agir, et d'autres pas. Si vous avez d'autres idées pour améliorer la vie des usagers, c'est le moment de poster !
Répondre