Selon les statistiques remontées concernant la mise à niveau régulière de la distribution Linux Mint, les développeurs s’interrogent sur le comportement des utilisateurs : faut-il ou non les forcer à appliquer les mises à jour ?
À titre de comparaison, sur d’autres distributions propriétaires (et plus rarement, sur les distributions Linux), les mises à niveau sont signalées aux utilisateurs par différents moyens : messages au démarrage, notifications en barre des tâches, popup réguliers. Ces moyens peuvent être considérés comme intrusifs, voire agacer selon la fréquence d’affichage et le paramétrage possible pour les effacer.
Selon les retours de certains utilisateurs, les développeurs LinuxMint ont noté une réponse assez étonnante : “many of them were sensitive to the importance of applying updates but didn’t do so simply because they were never really told to.”1 La raison ? Parce que l’on ne leur a jamais demandé de le faire.
En leur demandant pourquoi ce n’était pas le cas des mises à jour liées à leurs téléphones, les utilisateurs ont répondu aux développeurs que, même si les notifications étaient agaçantes, ils ont tout de même réalisé avec succès la mise à jour.
On peut aussi noter que l’autre raison qui les a poussés à appliquer la mise à jour, c’est parce qu’ils savaient que c’est une bonne attitude, et que les notifications n’apparaîtraient plus après cela.
Pour les développeurs, cela s’apparente clairement à un report des responsabilités : l’utilisateur est conscient de l’importance des mises à jour, mais aimerait que cela soit demandé par le système, via des notifications non intrusives dans la fréquence d’apparition, et avec le choix de la date de l’application (une notification avec consentement).
C’est à partir de ces constats que les développeurs ont décidé de proposer une solution qui consiste à conserver la liberté, et la flexibilité de l’utilisateur final, tout en alertant sur les mises à jour de la distribution.
À l’instar des notifications pour certaines applications, comme la réception de nouveaux courriels, celle-ci se veut être non intrusive, et laisse le libre choix à l’utilisateur de l’effacer, d’en savoir plus sur la mise à jour, voire de procéder à la configuration.
Pour éviter le côté intrusif, la notification n’apparaît plus pendant deux jours si elle est effacée par l’utilisateur. La configuration permet de modifier les conditions de notifications, tout en sachant qu’après une mise à jour, elle n’apparaît plus également pendant une certaine période, et de la limiter seulement pour ce qui a trait au kernel et à la sécurité.
La configuration du rafraîchissement de la liste des mises à jour se fait via le panneau comme illustré par la copie écran ci-dessous. On peut noter la période de grâce par défaut de trente jours, pendant laquelle aucune notification n’apparaît après l’application de la mise à jour (quel qu’en soit le moyen).
Une notification pour être averti des mises à jour, mais sans jamais les appliquer, est également possible en passant par la régénération de la clé gsettings, et l’utilisation du tracker spécifique « com.linuxmint.updates tracker-disable-notifications ».
Enfin, si dans le cas des VM de tests, ou d’autres situations, vous ne désirez pas vous embêter avec ce système de notification, vous pouvez le faire en désactivant les vérifications auto, ou l’Update Manager.
-
[NDM] : en français beaucoup d’entre eux étaient sensibilisés à l'importance de procéder à des mises à jour, mais ne le font pas, tout simplement parce qu’on ne le leur demande pas. ↩
Aller plus loin
- Depêche LinuxMint (57 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
# Debian
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Sur Debian Bullseye, il est proposé à l'arrêt de la machine de passer les correctifs sécurité. Si la case est laissée cochée, à chaque arrêt et si nécessaire, la machine commence par redémarrer (pour avoir moins de processus et de sessions en cours), passe les correctifs, puis s'arrête réellement.
[^] # Re: Debian
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Pour illustrer le propos :
[^] # Re: Debian
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 07 avril 2021 à 13:01.
Même comportement sur fedora depuis un certain nombre de versions.
C'est juste agaçant qu'il reboote avant quand tu as un disque chiffré car tu dois attendre d'être l'invite pour taper le mot de passe alors que tu voudrais le laisser faire son business et vaquer à tes occupations hors du laptop. Heureusement que les reboot sont rapides de nos jours.
Après ce message tu ne l'as pas si tu mets constemment en veille ton laptop donc une notif peut être sympa pour les étourdis ou alors mettre en place les updates autos.
[^] # Re: Debian
Posté par monseigneur . Évalué à 2.
Personnellement, je n'aime pas du tout ce comportement.
D'une part, il me fait trop penser à Windows. D'autre part, quand je veux éteindre l'ordinateur, je veux éteindre, pas attendre.
Je préfère largement qu'on me propose ces mises à jour en cours de session, en parallèle de mon activité, je ne trouve pas les notifications trop intrusives. Le plus souvent néanmoins je fais les mises à jour manuellement, de temps à autre. Comme je n'ai jamais eu de souci à faire ces mises à jour "à chaud", je ne vois pas pourquoi je devrais le faire "à froid"…
[^] # Re: Debian
Posté par Renault (site web personnel) . Évalué à 4.
Et donc ? Windows n'a pas que de mauvaises idées, il faut savoir s'abstraire de ce genres de considérations.
Car une mise à jour présente des risques de ne pas aboutir avec une session en cours. Ta session en cours peut planter (et donc corrompre la procédure en cours) et plus tu augmentes le nombre de processus qui tournent, plus le risque d'avoir un bogue qui pose soucis augmente. Des rapports de bogues ou des messages sur les forums suite à une MaJ ratée pour ce genre de problèmes il y en a, ce n'est pas un mythe.
La mise à jour est une étape critique, pour s'assurer de ton bon déroulement il vaut mieux le faire à froid.
Puis je passe outre qu'une mise à jour ça pompe des ressources, l'utilisateur n'a pas forcément envie d'avoir une machine au ralenti le temps que cela se termine.
Bref, que cela soit le comportement par défaut est sain, c'est techniquement le meilleur choix. Après si tu veux prendre des risques tu sais comment faire toi même.
[^] # Re: Debian
Posté par Julien Jorge (site web personnel) . Évalué à 5.
Cette popup m'agace aussi pour quasiment les mêmes raisons : quand je veux éteindre, c'est pour éteindre, souvent parce que je pars faire autre chose. Et j'ai aussi un disque chiffré qui m'oblige donc à attendre la demande de mot de passe au redémarrage, donc c'est hyper frustrant.
Si le but est de faire l'installation à froid, pourquoi ne pas la programmer pour le prochain démarrage plutôt que d'imposer un redémarrage sur le moment ?
[^] # Re: Debian
Posté par Renault (site web personnel) . Évalué à 6.
Car quand je veux allumer l'ordinateur, c'est pour m'en servir rapidement et pas regarder une machine faire une mise à jour.
Tu vois, le problème est miroir au tien, il faut bien faire un choix. Je vois un avantage avec cette méthode, avec l'extinction assez rapide des machines, tu perds peu de temps à rester devant la machine pour saisir éventuellement ton mot de passe de déchiffrement. Puis tu peux partir, la machine s'éteindra.
Au moins la machine peut faire des étapes en ton absence, assez idéal quand par exemple tu éteins l'ordinateur en quittant ton travail, il installera les mises à jour sans toi et tu pourras bénéficier le lendemain d'une machine opérationnelle dès ton arrivée. Si tu fais l'inverse, tu devras dans tous les cas assister passif à cette installation, pas très épanouissant ni un vrai gagne temps.
Si jamais tu veux faire un redémarrage rapidement ou que tu dois partir rapidement, tu décoches et tu le feras une autre fois.
[^] # Re: Debian
Posté par Dr BG . Évalué à 5.
Ça vous arrive sous Linux que le redémarrage après une mise-à-jour soit plus long ? Moi jamais. Sur le Windows du boulot ça m'est déjà arrivé d'attendre plus d'1h (1h20 je crois) le matin avec la première grosse mise-à-jour de Windows 10.
[^] # Re: Debian
Posté par Franck Routier (Mastodon) . Évalué à 2.
Pour ma part je partage le sentiment de @monseigneur… Ce comportement m'a piégé plus d'une fois, car la mise est jour est programmée au prochain démarrage, au moment où j'allume mon ordi, donc parce que j'en ai besoin.
Quant aux arguments sur les mises à jour à froid, à cause des risques d'une mise à jour à chaud… en 25 ans d'utilisation de Linux, ça ne m'est jamais arrivé qu'une mise à jour échoue pour cette raison. Pas une fois.
Bref, je pense aussi que cette case à cocher est un héritage du pire de Windows (j'ai connu des demi-journées entières de travail perdues en entreprise car Windows (7) avait décidé de se mettre à jour, pile à moment où il ne fallait pas.
[^] # Re: Debian
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Sur la même période de temps, j'ai planté des machines physiques, des machines virtuelles, des conteneurs, eu besoin de dépanner avec des CD puis des clés USB amorçables ou via le réseau ou même via un câble série. J'ai eu des machines qui ne redémarraient pas car les paramètres de cryptographie pour le déchiffrement du disque avaient changé par défaut, mais que les anciens n'étaient pas explicitement déclarés. J'ai eu des lilo et des grub qui étaient grognons, des X qui ne démarraient plus, etc., etc. Bref les soucis de mises à jour ça existe, si on lance dans les témoignages personnels. Surtout ceux qui sont du type ce qui ne m'arrive pas n'existe pas.
Sinon il est peu probable que la plupart des gens soient capables de savoir si la modification concernant systemd, dbus, le noyau, le microcode du noyau ou la libc nécessitent ou non un redémarrage, ou un signal bien envoyé ou une procédure spéciale ou une mise à jour de noyau à chaud est possible (et je me compte dans cette plupart en général, alors que je mets à jour des dizaines/centaines de machines chaque semaine).
Bref on a une solution qui est bien pour la plupart des utilisateurs d'environnement graphique, et ceux qui ne veulent pas peuvent décocher la caser (voire probablement la décocher par défaut par configuration), ceux qui veulent faire leur apt à la main peuvent toujours, ceux qui veulent de l'unattended-upgrade peuvent aussi.
[^] # Re: Debian
Posté par Renault (site web personnel) . Évalué à 5. Dernière modification le 08 avril 2021 à 16:21.
Chez Fedora, il y a même eu un bogue générique qui a entrainé une vague massive de problèmes de mises à jour à chaud.
J'avais rédigé à l'époque un petit topic chez fedora-fr pour le signaler. Et cela n'arrivait pas lors d'une mise à jour à froid.
Un bogue comme cela peut se reproduire à l'avenir, tout comme c'est arrivé à des tas de gens par le passé, dont toi et moi apparemment.
[^] # Re: Debian
Posté par seb95 (site web personnel) . Évalué à 1.
Bonsoir;
Je suis un peu surpris car c'est quand même l'inverse de ce qu'on a entendu depuis des lustres et ce qui est mit en avant dans les distributions vis-à-vis de windows, notamment debian met en avant les updates et les sauts de versions à chaud.
[^] # Re: Debian
Posté par Ambroise . Évalué à 1.
Alors sur Debian, je n'ai en effet jamais rencontré de soucis de mises à jour à chaud (tant que l'on reste dans des montés de version mineures).
Mais sur Archlinux, j'ai toujours préféré lancer mes mises à jour avant l'extinction ou un reboot car les mises à jour du noyau, ben elle ne sont pas transparentes du tout…
[^] # Re: Debian
Posté par flavien75 . Évalué à 1.
Sur Ubuntu, ça m'est arrivé (plusieurs fois) que la mise à jour de Firefox pendant qu'il tourne le rende instable. Après il n'y qu'à le relancer, donc rien de dramatique.
Les vrais naviguent en -42
[^] # Re: Debian
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Pas mal …mais cela suppose qu'on utilise une session graphique et qu'on est amené à redémarrer sa machine
^^“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# N'oublions pas nos racines
Posté par Marcel4567 . Évalué à 9.
Alors, forcer les utilisateurs, certainement pas. C'est contraire au valeurs du logiciel libre et extrêmement énervant. C'est ce que font les logiciels propriétaires et une des raison qui les rendent si détestables, le plus bel exemple étant les mises à jour de Windaube qui reboot la machine sans sommation pendant une présentation, ou Mac qui se met à télécharger 4Go de maj sans rien demander et qui tue le forfait 4G pendant un déplacement…
Les valeurs du logiciel libre, c'est de donner le contrôle à l'utilisateur : on lui propose une interface de configuration pour qu'il choisisse s'il veux une notification, a quelle intervalle, ou des mises à jour automatique, ou autre à sa guise.
Chez Opensuse, quand des mises à jours sont disponible, une icone apparaît dans la zone de notification. C'est simple, non intrusif, et suffisant pour signaler à l'utilisateur qu'il doit prendre une décision.
Chez Arch, il n'y a rien, c'est à l'utilisateur d'y penser: power user. Et c'est très bien comme ça pour ceux qui aime.
[^] # Re: N'oublions pas nos racines
Posté par Christophe B. (site web personnel) . Évalué à 5. Dernière modification le 07 avril 2021 à 12:36.
Tout a fait d'accord avec toi
Rien de pire que cette MAJ Windaube qui de plus peut planter d'autres logiciels.
Par contre dans certain cas, il serait judicieux de pouvoir paramètrer une MAJ automatique
Certaines personnes ne se posent jamais la question de savoir si il faut faire des MAJ
A tel point, que au bout de quelques années j'ai eu la désagréable surprise de voir que la version de Mint n'était plus maintenue …
bah oui, cela faisait plus de 5 ans (entre 7 et 8 ans je pense) que cette machine était utilisé quotidiennement sans aucun problème.
Pourquoi changer une équipe qui gagne ?
[^] # Re: N'oublions pas nos racines
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Mais là, c'est pas forcé hein
:-)C'est un outil qui est proposé pour répondre à un besoin d'utilisateurs et qui est configurable/désactivable (donc on reste raccord avec les racines tout en étant lambda-users friendly);-)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: N'oublions pas nos racines
Posté par aiolos . Évalué à 5.
Alors, autant je suis d'accord sur le fait de largement préférer qu'on ne me "force" pas à les appliquer (je le ferai quand je l'aurais décidé), autant ça n'a rien à voir avec un "esprit du logiciel libre".
L'esprit du logiciel libre, c'est plutôt au contraire de te laisser (la possibilité de) l'implémenter comme tu veux si ça te plait pas…
[^] # Re: N'oublions pas nos racines
Posté par Anonyme . Évalué à 2.
Je pense que la réponse ne doit pas être dogmatique et dépend du niveau de l'utilisateur. Car certains utilisateurs ne veulent pas se prendre la tête à comprendre pourquoi et comment marche la mise à jour.
Laisser le choix est le maitre mot, mais un choix maintenir mon ordinateur à jour en appliquant par défaut au moins les mises à jour de sécurité (à la windaube) est parfait pour certain. Il est entendu que ce choix est inadapté pour d'autres.
Je suis d'accord qu'il y a des bonnes pratiques à mettre en place sans que ce soit en lien avec un "esprit du logiciel libre". Parce que tous les utilisateurs d'open source ne sont pas forcément compétents, ont envie ou l'appétence nécessaire pour avoir l'esprit du logiciel libre à mon sens.
[^] # Re: N'oublions pas nos racines
Posté par Ant . Évalué à 3. Dernière modification le 08 avril 2021 à 12:45.
Tout à fait.
Mon fils de 17 ans est content de son linux (rapide et fiable). Il a bien compris ce qu'étaient les mises à jour, comment cela se faisait et pourquoi (sur la mageia installée sur son portable), mais il ne le fait jamais. Pourquoi ? parce que ce n'est pas obligatoire. La notion de "tu es libre de le faire mais il faudrait le faire quand même, alors fais le" lui est assez floue. Et il s'en moque un peu. Pour ce genre d'utilisateurs, un avertissement explicite ou une mise à jour automatique est mieux je pense.
Sur Mageia, il y a juste un petit icône qui apparait dans la barre des tâches quand des mises à jour sont disponibles, il faudrait quelque chose de plus automatisé. Surtout que les mises à jour sont rapides et généralement peu volumineuses à télécharger.
# choix dans la mise à jour
Posté par labgui . Évalué à 3. Dernière modification le 07 avril 2021 à 16:51.
Bonjour,
Sur mon poste debian perso, je fais mes mises-à-jour tout seul comme un grand (aptitude-update && aptitude full-upgrade) , je redémarre si il me demande. ça me permet d'avoir un œil sur ce qui change.
Sur le poste de mon fils tout se fait tout seul en mode silencieux grâce à unattented-upgrades, ça fait un bail que je ne m'en occupe pas en attendant l'arrivée de bullseye. L'ordinateur est systématiquement éteint en fin de journée donc pas de problème pour les redémarrages.
Les deux approches sont valables, ce qui est bien c'est qu'on peut faire comme on veut. Il suffit de pouvoir faire son choix de façon éclairée et responsable en fonction de ses compétences, à l'installation par exemple.
Guillaume
PS : super je suis arrivé à ne pas faire référence à qui vous savez :-)
Guillaume
[^] # unattended-upgrades
Posté par vv222 . Évalué à 6.
unattended-upgrades est aussi ce que je conseille de mettre en place sur les machines des personnes qui ne veulent pas perdre du temps à maintenir leur système, et sur les serveurs sensibles aux failles de sécurité potentielles.
[^] # Re: unattended-upgrades
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Je pense le mettre en place aussi dans ma mission actuelle.
Avant, j’utilisais plutôt cron-apt que j'aime beaucoup.
Dans tous les cas, j'aime que les mises de sécurité soient toujours faites, même sur une machine non-critique : je préfère le patch au fil de l'eau au lieu d'attendre une grosse campagne (dite de remédiation) tous les on ne sait combien de mois (en général plus de six dans les boîtes où j'ai vu ça.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.