Le blog de Seb

PassionGNU/Linux, la passion du Libre...

https://download.tuxfamily.org/passionlinux/site/banner.png

Mar 02, 2020

Upgrade Mageia 7, explication pour les rageux.

Je n'aurai pas imaginé encore une fois que de parler de Mageia allait déclencher une guerre de religion, vraiment, c'est bien la seule distribution avec qui, si je critique, j'ai autant de soucis, d'insultes, de gars sans vie qui viennent me menacer et j'en passe... Je passe car les menaces, les insultes, c'est mon quotidien de conducteur de bus allant dans des zones à risques ou reconnues comme telles. En gros pour que ça m'en touche une en bougeant l'autre, faudra vraiment monter de niveau. Comme d'habitude, je garde tous les mails pour justifier une action par la suite en cas où, du reste pas très intelligent de se faire passer pour Mageia dans vos mails d'insultes.

Pourtant j'ai critiqué tout un tas de distributions, notamment Manjaro, Archlinux, Gentoo, Debian (et oui), openSUSE, Mint, Sabayon, Ubuntu... Et c'est avec l'unique Mageia que j'ai droit aux cas sociaux sans vie, n'ayant comme défouloir que leurs écrans. La masturbation serait une bonne manière de vous vider bande de petits puceaux...

Donc je vais revenir au pourquoi un énième billet sur cet upgrade de Mageia 6 vers la 7, c'est simple, Frédéric en a fait un billet (Le talon d’Achille des distributions GNU/Linux fixed release, les montées en version ?) et a démontré que lui ça passait bien. Deux choses qui peuvent l'expliquer, Fred le fait dans une machine virtuelle (virtualisation), on le sait dans le monde matériel, il peut se passer tout un tas de truc qui ne se passera jamais dans une virtualisation car dans cette dernière on idéalise un monde matériel parfait et bien reconnue, donc pas de soucis matériels, pas de pilotes Nvidia et autres joyeusetés qui peuvent ternir une installation. La deuxième chose et pas la moindre, il sort d'une installation sans aucune personnalisation, c'est une installation par défaut out-of-the-box comme diraient les américains, ça a son importance comme la possible installation de paquets moins populaires et donc moins testés, qui pourront foutre la merde dans une mise-à-jour et plus en cas de saut de version.

Si je reprends mon installation de Debian, j'ai environ + de 4000 paquets, j'ai deux environnements (ma femme est GNOME et moi KDE), j'ai de nombreux serveurs dont encore un mail, un FTP, un Web pour tester, en plus d'autres services qu'on pourrait assimiler à des serveurs comme MiniDLNA ou bien MPD. Bref, le tout c'est qu'il y a plus de 4000 raisons pour que ça merde alors qu'une installation de base en a dans les 1000-1500 paquets. Chez moi et chez les particuliers de mon entourage qui me font confiance et qui mon malheureusement décrété comme étant l'informaticien de la famille ou bien informaticien tout court --ce rôle ingrat qui oblige toujours de passer plusieurs heures pour réparer les conneries de personnes qui de toute façon ne feront pas l’effort de comprendre puisque la réparation est gratuite--, ça passe les doigts dans le nez sans faire le moindre effort, honnêtement je ne prends pas autant de soin que Fred dans sa vidéo, je fais du apt update && apt dist-upgrade après avoir changé les sources. J'ai par exemple en Janvier, fait un saut de version de Jessie vers Stretch puis Buster pour un portable d'un normand que je ne vois que rarement quand il redescend dans ma région, qui s'est totalement bien passé comme prévu.

Juste en aparté, encore une fois, je comprends son idée qui dit que les rollings seraient bien plus adaptées que des fixeds, mais on sera toujours en accord sur nos désaccords, en l’occurrence, au regard des personnes que j'ai en face de moi, c'est même pas la peine de penser mettre une rolling. En gros dans un monde parfait, oui Fred aurait probablement raison, quoique vu les merdes que j'ai du faire face avec des Windows 10, mais dans mon monde réel, j'ai deux types d'utilisateurs qui sont incompatibles avec ce genre de système. Le premier type d'utilisateurs qui ne représente même pas 10% est celui de ceux qui sont assez débrouillards, ils ne sont pas capable d'installer une distribution linux ou un Windows mais vont mettre à jour en suivant scrupuleusement les recommandations si la méthode est graphique et seulement dans ce cas là, ils ne sont pas capable --et ne veulent pas le faire-- d'installer un programme par eux même et ce même si la méthode est graphique. L'autre type d'utilisateurs que j'ai surtout affaire est celui des j'en foutistes, ils ne feront rien, jamais rien, on aura beau leur expliquer, leur donner des raisons de faire au moins les updates, mais non... Je peux les comprendre, certains ont eu des comportements malsains de leurs anciens OS à la fenêtre et non plus envie de s'exposer à des emmerdes. Je pourrais citer un troisième genre, un mixte entre les deux, que j'ai puisque c'est quelqu'un de très proche, qui fait les mises-à-jour qu'une fois par an. Alors, non, je ne me vois pas mettre des rollings ou même des semi-rollings dans mon entourage, car il y a une grosse part de risque que je prends pour me faciliter la vie: j'automatise au max les upgrades sans aucune intervention humaine et ça se passe très bien du moins sous Debian.

Si je prends une rolling ou une semi-rolling, je ne pense pas pouvoir le faire, du moins, je ne serai pas aussi tranquille. Je parle vraiment d'une méthode de mise-à-jour totalement automatisée et indépendante d'une quelconque personne, aucun besoin d'intervention humaine, c'est de A à Z totalement géré en sous couche et totalement invisible pour la personne. Le seul truc que j'ai demandé et que la personne doit faire, c'est qu'au moins une fois par semaine de laisser la machine fonctionner dans la nuit. J'ai mis en place une heure à laquelle le tout doit se faire, normalement à partir de 2h. Il me semble en avoir déjà parlé dans le billet "Il faut sauver le soldat Asus".

Maintenant, une fois que j'ai ciblé un peu l'histoire, on va pouvoir passer vraiment à la procédure que j'ai appliqué sur la dite machine. Il n'y a pas 500 possibilités, 2-3 tout au plus, une première avec le DVD (que je ne compte pas mais j’expliquerai plus tard), une autre avec le MGA-applet qui est la seule graphique, une avec l'historique Urpmi, une autre avec le DNF ajouté vite fait dans Mageia...

Vu que la personne ayant pour propriété la machine avec la Mageia dessus, avait fait la méthode totalement automatique et graphique du mga-applet, pardon mgaonline, a eu pour résultat une distribution non utilisable car plus accessible graphiquement (ça restait sur une session tty et pas d’accès à GDM), j'ai dû improviser. J'ai bien sûr remarqué que c'était dû à un upgrade qui s'est mal passé car on était dans un entre les deux, avec des paquets un peu des deux (de la 6 et de la 7), par la suite il m'a parlé d'un message d'erreur qui avait mit fin au saut de version qu'il n'a pas eu l'idée de poser sur papier ni de comprendre. J'avais le choix ensuite de prendre une méthode qui me plaisait un peu mieux, donc on peut retirer la façon DVD car et je cite:

En outre, il est possible que Mageia 6 ait reçu une mise à jour d’une version de logiciel plus récente que celle disponible sur l’ISO. Lorsque cela se produit, la mise à jour peut échouer. Comme il est impossible, au moment où les ISOs sont testées, de prévoir quels paquets de Mageia 6 peuvent être mis à jour dans l’avenir, les mises à niveau hors ligne (c’est-à-dire mises à niveau tentées sans configurer les dépôts en ligne) ne sont pas pris en charge.

Ce qui veut dire en langue simpliste, que si un paquet de Mageia 6 recevait une mise-à-jour après la sortie de l'ISO de la 7, ça pourrait alors ne pas réussir... J'ai rigolé la première en lisant ça car je ne voyais pas le rapport de cause en effet. Si le gestionnaire est bon, il peut très bien faire l'upgrade sinon ça voudrait dire que sur une distribution et plus encore une rolling, dès qu'on a oublié de faire une mise-à-jour et au vu des changements rapides qu'il peut avoir en une semaine (parfois un programme dans une rolling a plusieurs version d'affilé en une semaine), raterait les mises-à-jour suivantes de ce même paquets... Que dire, j'ai des Debian que je ne peux mettre à jour qu'une fois par an ou tous les deux ans et ça se passe très bien avec un saut de version en prime...

Il ne m'en reste que deux, celle qui était la même que pour une Mandriva, donc Urpmi et la nouvelle mit comme ça pour faire plaisir à ceux qui pensent que Mageia devrait être une clone de Fedora, DNF.

Oui je vais faire un aparté, je suis en train d'insinuer que DNF sous Mageia est mit comme ça sans être totalement fonctionnel, car c'est le cas, j'ai eu plusieurs fois affaire à lui et effectivement il arrive fréquemment que le bonhomme sous Mageia n'arrive pas à faire ce qu'on lui demande (généralement une simple mise à jour de logiciel) alors que Urpmi ne bronche pas et le fait sans fioritures. J'en ai parlé en décembre 2018 et mars 2019. Je disais notamment en 2018 ceci:

... un autre gestionnaire de paquets du nom de DNF, celui de Fedora, en fait Mageia se tend à devenir une Fedora bis en moins qualitatif... Gestionnaire de paquets qui donne des comportements étranges sur cette Mageia, qui échoue à certaine mise-à-jour alors que URPMI lui y arrive...

En 2019, toujours la même chose:

En terme d'application on est dans le correcte, ni trop ni assez, juste la bonne limite pour permettre de couvrir tous les besoins d'une utilisation standard. On pourra en rajouter facilement avec au choix --et je pense que c'est une erreur de garder les deux-- URPMI et DNF. Comme je le dis, c'est pour moi une partie qui blesse, je pense que ce n'est pas une solution de garder les deux, il faut faire un choix, soit on garde l’ancêtre qui fait de la résistance et qui a le mérite de toujours savoir se sortir des mauvais coups; soit on prend le challenger, le petit nouveau, mais d'une part, il apporte peu d'amélioration en terme de vitesse si ce n'est pire, d'autre part ses sorties je les trouve autant si ce n'est plus, incompréhensibles ou peu pratiques, et en dernier lieu, j'ai réussi à le mettre mal dans une simple opération de mise à jour, alors que URPMI, lui a réussi. C'est pas la première fois que j'arrive simplement à mettre à mal DNF, sur une Mageia 6 et une Fedora 28 puis 29, j'avais facilement réussi à lui rendre la vie impossible. Pourquoi Mageia s’entête à toujours reprendre ce que Fedora/Redhat fait, alors qu'il y avait bien mieux? Zypp et Zypper de chez openSUSE sont de vraies perles que ce soit en terme de vitesse ou de réussite, je n'ai jamais eu une simple mise-à-jour qui part en sucette ou qui échoue ou encore comme je l'ai vu sur Fedora 28 et Mageia 6, impossible à faire...

Fin de l'aparté, J'ai donc tenté avec Urpmi:

Désactiver dnf makecache (cette étape peut être omise si dnf n'est pas installé)

systemctl mask dnf-makecache.service --runtime --now
systemctl stop dnf-makecache.timer && systemctl mask dnf-makecache.timer && systemctl daemon-reload

Supprimer toutes les sources existantes des médias sur votre système en exécutant cette commande :

urpmi.removemedia -a

Ajoutez les sources en ligne de Mageia 7 : En utilisant la méthode de LA LISTE DES MIROIRS (ce qui sélectionnera automatiquement un miroir en fonction de votre situation géographique):

urpmi.addmedia --distrib --mirrorlist 'http://mirrors.mageia.org/api/mageia.7.$ARCH.list'

(urpmi sait ce qu’il faut substituer à $ARCH) Utiliser un miroir de médias spécifique

urpmi.addmedia --distrib <mirror_url>

Vous pouvez récupérer la variable mirror_url en utilisant l’application web des miroirs Mageia [1]. Enfin, commencer la mise à niveau :

urpmi --auto-update --auto --force

Il est préférable d’exécuter la commande ci-dessus deux fois, parce que certains paquetages peuvent être téléchargés sans être installés le premier coup.

Sauf que ça rate, il demande une librairie qui ne peut être installé, ce que je force mais non rien à foutre. Je me dis que perdu pour perdu on va essayer DNF:

  1. Assurez-vous d'avoir toutes les mises à jour de Mageia 6 dnf upgrade

  2. Installez le greffon dnf system-upgrade : dnf install 'dnf-command(system-upgrade)'

  3. Exécuter la phase de téléchargement : dnf system-upgrade --releasever 7 download --allowerasing

  4. Si la simulation et les mises à niveau proposées se présentent correctement, déclencher la mise à niveau : dnf system-upgrade reboot

En résultat, j'ai eu pratiquement la même chose que quand je suis arrivé pour rattraper l'upgrade mais en pire, plus d'écran, plus de ligne, plus de clavier, plus rien...

En conclusion, pour ne pas faire croire que les fixeds ne sont pas capable de monter de versions et pour finir sur une note plus intelligente que "l'autre fait son neuneu en utilisant des commandes qui ne sont pas officielles", je dirais simplement que tout est sanguin, on l'a dans le sang ou pas, c'est acquis ou non depuis sa création, il y a les distributions pensées dès le début pour passer de version en version et les autres qui se sont mises à le faire plus tard, sans jamais vraiment être autre chose qu'un coup de chance quand ça réussit (Mandriva, Mageia)... Depuis la Ubuntu 6.06 jusqu'à la version 18.04, je n'ai eu que deux soucis qui m'ont forcé à réinstaller, une fois avec le passage de 10.04 vers 12.04 et l'autre de 12.04 vers 14.04 (problème de pilotes qui m'ont intégralement tout bloqué). Avec Debian, depuis la Etch (version 4) je dois noter qu'un seul soucis, quoique j'ai réinstallé pour faire un truc plus propre mais sinon ça marchait bien, qui était dû au passage de Upstart à Systemd lors du changement de la Debian Wheezy (7) à Jessie (8). Je ne dirai pas que les distributions fixeds sont de la merde dans ce genre de sauts, ni que ce soit leurs talons d’Achille mais que ça dépend du sérieux de la dite distribution et de son pedigree.

Feb 25, 2020

Upgrade vers Mageia 7 raté, j'en profite pour changer.

Comme je vous l'ai dit hier, le passage à la version 7 de Mageia a encore raté. je comprends le succès des rollings quand je vois que Mageia n'arrive pas à passer d'une version à une autre sans lacunes, entre elle et les Ubuntu avec le plein de PPA qui n'arrivent pas non plus, ça donne une pas si bonne image de ce qu'est la montée de version sur une fixed.

Un truc pouvant faire un semblant d'explication du ratage, est peut être dû à la personne ayant tenté avant moi. J'explique, il a vu dans sa barre des taches, l’icône des updates, au lieu qu'elle soit comme habituellement en rouge ou orange selon la gravité des updates, elle était bleu, il a cliqué, validé la demande et laissé faire, sauf qu'au milieu il y a eu un "message" qu'il n'a pas noté... D'où certainement la merde que j'ai eu avec URPMI et le passage en force avec DNF... Ce qui m'étonne c'est qu'il est sous GNOME et que je ne pensais pas que cette icône s'affichait dans cet environnement.

N'ayant pas plus d'affinité avec cette distribution et sa communauté francophone, j'ai proposé à la personne de changer. J'avais le choix entre openSUSE Leap, Debian 10, Ubuntu 18.04, j'ai aussitôt décliné l'openSUSE car la 15.2 va pas tarder à sortir --sa bêta est déjà -- et que j'ai pas envie de passer encore pour faire des sauts de versions, par contre j'ai vraiment hésité entre la Debian et la Ubuntu car chacune a ses plus et ses moins.

Le truc c'est que je suis sur Debian et donc si ça merde, je pourrais le savoir bien plus vite et colmater, donc va pour Debian. J'ai donc utilisé la deuxième machine (un portable) de la personne qui elle était resté sous Mageia 6 --ayant vu la merde lors de son passage sur son PC desktop, il n'a pas tenté le diable-- pour charger l'ISO netinstal de Debian 10 vu qu'il est fibré, ensuite j'ai lancé l'installation. Dans la foulée et à sa demande, j'ai fais de même avec le portable.

Feb 13, 2020

Apt-RPM n'est pas Apt de Debian/Ubuntu.

Billet qui fait suite à cette vidéo et ses commentaires.

Je sais pas ce que vous en pensez mais moi ça m'étonne toujours autant quand on parle de Apt-RPM comme d'un projet vivace, juste parce que les distributions qui ont l'ignorance de l'utiliser fassent encore des mises-à-jour. En l’occurrence, les updates actuels après vérification ne sont que des recompilions pour inclure des libs ou un Gcc plus récents. En tout cas juste en allant voir les sources du paquet APT sur Pclinuxos, je vois ça dans le changelog:

%changelog
* Mon Feb 10 2020 tex - 0.5.15lorg3.95-14pclos2020
- rebuild against glibc 2.31

* Wed Jan 29 2020 tex - 0.5.15lorg3.95-13pclos2020
- rebuild against updates

* Thu Jan 24 2019 tex - 0.5.15lorg3.96-12pclos2019
- redirect security patch

* Wed Dec 06 2017 Zen Subz <techars21 at gmail dot com> - 0.5.15lorg3.96-11pclos2017
- Rebuild with gcc7

* Wed Apr 27 2016 bb <bb> 0.5.15lorg3.96-10pclos2016
- drop cpu optimization

* Mon Apr 18 2016 bb <bb> 0.5.15lorg3.96-9pclos2016
- rebuild for updates

* Fri Apr 17 2015 bb <bb> 0.5.15lorg3.95-8pclos2015
- use revert patches 210 & 220 from vine

* Thu Apr 16 2015 bb <bb> 0.5.15lorg3.95-7pclos2015
- drop grub from rpmpriorities since we are moving to grub2
- update to git 522

* Wed Nov 13 2013 pinoc <vogtpet at gmail.com>  0.5.15lorg3.95-6pclos2013
- add gcc-4.7 patch

* Mon Sep 26 2011 Texstar <texstar at gmail.com> 0.5.15lorg3.95-5pclos2011
- Split out sources.list into separate rpm package

* Sun Aug 14 2011 Texstar <texstar at gmail.com> 0.5.15lorg3.95-4pclos2011
- sources list for 64 bit
- rebuild against libreadline6

* Fri Jun 10 2011 Texstar <texstar at gmail.com> 0.5.15lorg3.95-3pclos2011
- rework package so same name as old versions

Sans parler que le projet lui-même a comme dernière version stable une 0.5.15 datant de 2006, les distributions Altlinux et Pclinuxos se basent quand à elles sur la version testing de 2008... N'y a t'il pas eu de progrès et d'améliorations de RPM depuis? C'est un peu la même chose pour URPMI mais au moins lui est bien entretenue --du moins ils essayent--.

Dans ces deux distributions que sont PClinuxoc et Altlinux, il y a aussi le cas de Synaptic, c'est sûr que même sous Debian il n'évolue plus beaucoup, en même temps, on ne peut pas ajouter beaucoup plus à cette interface. Mais là où ça en devient drôle c'est sous les distributions RPM citées, on se retrouve avec une version 0.57.11 datant de 2005, oui vous ne rêvez pas, toutes les améliorations subies depuis 2005 jusqu'à nos jours ne sont pas inclues. Mais même pour RPM, il a eu de nombreuses améliorations et bien Synaptic sur ces distributions n'en profitera pas. Pour rappel, Synaptic sous Debian/Ubuntu en est à sa version 0.90.

%changelog
* Thu Feb 13 2020 tex - 0.57.11.1-4pclos2020
- add patch to 142 to try to fix crash

* Mon Feb 10 2020 tex - 0.57.11.1-3pclos2020
- rebuild against glibc 2.31
- add build req intltool

* Wed Jan 29 2020 tex - 0.57.11.1-2pclos2020
- rebuild against updates

* Sun Dec 17 2017 Zen Subz <techars21 at gmail dot com> - 0.57.11.1-1pclos2017
- Patch to fix the spelling error in rguserdialog.cc
- Updated build with source v0.57.11.1 from snapshot.debian.org

* Fri Dec 08 2017 Zen Subz <techars21 at gmail dot com> - 0.57.9-1pclos2017
- Updated build with source v0.57.9 from snapshot.debian.org
- Add -continue option to wget package download script
- Refresh patches with new ones

* Thu Dec 07 2017 Zen Subz <techars21 at gmail dot com> - 0.57.3-5pclos2017
- Replace gtk-go-up/gtk-info icons with more commonly available ones
- Use the original source from snapshot.debian.org

* Wed Dec 06 2017 Zen Subz <techars21 at gmail dot com> - 0.57.3-4pclos2017
- Add gcc-7 patch and fix FTBFS (#1424532) from Fedora
- Add patch from Alt Linux to fix null-history
- Add extra patches by Ratt Salad
- Add patch to fix icons on the main-window
- Updated build for PCLinuxOS with rebuilt libapt

* Thu Jan 19 2017 bb <bb> 0.57.3-3pclos2017
- revert gksu changes

Autant qu'en 2005/2006, je veux bien croire qu'on ne jouissait pas de gestionnaire de paquets --en ligne de commande ou pas du reste-- à la hauteur en RPM, face à un Apt, je pense notamment à URPMI, YUM; mais de nos jours, tout de même, il y a le pachyderme DNF, l'ancêtre toujours aussi hasbeen d'Urpmi, le rapide Zypper --et oui ça fait mal à beaucoup de monde, mais c'est bien openSUSE qui a le gestionnaire de paquets le plus rapide en RPM--, ... Bref, même si certains sont lents, au niveau des fonctionnalités, de la sécurité, ils sont bien au dessus de ce Apt-RPM.

Voila, si vous voulez exprimer votre point de vue, venez sur le forum.

Feb 02, 2020

Pourquoi vouloir avoir plus de monde sous linux?

C'est une question toute bête que je me pose, pour que vous comprenez bien, tout vient du billet de Fred, "N’ayons pas peur des mots : il faut une rationalisation des distributions GNU/Linux « bureautiques »." et de ses commentaires. Je partage une grosse partie du billet, dont notamment le fait qu'il y a trop de distributions ce qui en complexifie le choix mais je pense que j'en ai un peu marre de ça, ce truc où il faudrait que tout soit acquis, prêt à être servie, utilisé, sans aucuns besoin de comprendre ce qui s'y passe.

On va dire que je fais mon vieux con, peut être, je n'en sais rien, mais le truc de donner à bouffer à des pigeons idiots (merci Renaud), me répulse.

j'ai commencé dans un monde où le PC chez soi n'était pas chose fréquente, du reste mon tout premier PC sous Windows était une machine venant du boulot à mon père, une machine avec Windows 3.1... C'était bien différent du monde actuel qui veut qu'on donne tout sans compréhension, comme le permis à des gamins toujours plus jeunes et irresponsables, à mon époque, il fallait comprendre, casser, réinstaller, recommencer, jusqu'à assimilation... Je vais pas dire que c'était mieux avant mais disons le quand même, avant on faisait seul et on apprenait, on comprenait, maintenant les gens sont idiots et ne réfléchissent plus.

N'allez pas penser de suite que je ne veux pas que notre OS sorte de la case pour geek mais pas au détriments de la qualité et de la sécurité. En faite plus on va dans l'accessibilité et la facilité et plus on a des personnes qui ne comprennent rien et qui se retrouvent avec un truc qu'ils ne maîtrisent pas. Alors c'est sûr, ils vont pouvoir faire des serveurs, mais ne comprenant pas ce qui va avec, comme la sécurité, ils vont monter des serveurs avec pleins de failles et participeront à la masse de machines zombies.

Pour revenir à une quelconque liste de distributions à garder, je ne suis pas contre, effectivement la liste actuelle qui compte des centaines de distributions, peut faire peur, je me rappel dans les années 2005 que je fouillais sur le net pour voir ce qui se faisait dans le monde linuxien, j'avais été paumé et si je ne connaissais pas une personne sous linux pour me donner une direction à prendre, je n'aurais certainement pas eu le courage de me lancer ou du moins pas la même expérience (réussi pour le coup).

Je lis dans les commentaires du billet de Fred, un truc qui me fait toujours autant rire quand je le vois, c'est que linux est compliqué à installer et Windows est facile, d'où Windows est facile à installer? Non sérieusement, le gars avant de dire ça, a déjà installé un Windows? L'installation de Windows n'est pas bien différente de celle d'un linux, on passe par des étapes dont le partitionnement, donc en quoi Windows est plus simple à installer que la Ubuntu pour ne prendre qu'elle? Et c'est une personne (moi) qui installe des Windows depuis sa version 3.1 qui vous le dit...

Même la reconnaissance du matos est bien sous linux, je n'ai rien eu à faire avec une Ubuntu, une openSUSE ou une Debian si ce n'est pour cette dernière d'installer les drivers. C'est pas encore parfait pour tout, mais pour un OS qui n'a pas le support des drivers des constructeurs, je trouve qu'il s'en sort bien.

Personnellement, je ne vais que rarement sur des forums, car je vois en face des gens qui ne prennent pas le temps de comprendre, de chercher d'où vient leurs problèmes, pour tout dire, ils ne regardent même pas si il y a déjà une solution à leurs soucis... Ils balancent comme ça, attendent bêtement et ça c'est encore dans les meilleurs cas, car parfois on a des pressés qui s'emportent et harcèlent si pas de réponses, puis une fois leurs réponses obtenues, s'en vont sans un merci.

Tout ça pour dire que si c'est pour faciliter l'arrivée de casses couilles dans le monde de la banquise, ça sera sans moi car je pense qu'on souffre déjà assez avec des personnes qui n'ont plus cette petite chose qui s'appelle la curiosité.

Jan 23, 2020

La fausse bonne idée-des répertoires personnels d'openSUSE, un truc comme les PPA d'Ubuntu.

J'ai souvent entendu dire qu'Ubuntu n'était pas fiable, souvent ce genre de connerie venait suite à une mise-à-jour entre deux versions (exemple passage de la 14.04 vers la 16.04) et quand on y regarde de plus près, on voit les fameux répertoires personnels dits PPA d'Ubuntu. Je pense que les gars de Canonical doivent se mordre les doigts d'avoir permis de monter facilement des dépôts personnels sans gage de qualité. Combien de fois ai-je vu ces mêmes dépôts dans le source liste d'une Debian? Je ne m'en souviens plus mais malheureusement trop souvent et trop tardivement, ce qui résulte que les mecs se plaignaient d'avoir une Debian qui ne pouvait pas ou mal monter de version... L'humain n'a pas besoin d'aide et de qui que ce soit pour casser ce qu'il a, mais encore une fois Les pires choses en général sont faites des meilleures qui ont mal tourné (Victor Hugo) et les PPA sont les meilleurs exemples.

Quoique avec les nouveaux formats de paquets universels, ça sera peut être plus le cas encore longtemps...

Mais bon revenons à openSUSE, comme Ubuntu et même avant elle si mes souvenirs sont bons, celle-ci a voulu faciliter la vie de ses utilisateurs en mettant en place de quoi faire des dépôts personnels (les homes), ça partait d'un bon sentiment, du meilleur qu'on puisse avoir, du reste je m'en sers comme les PPA sous Ubuntu, mais on va dire que j'ai un petit quelque chose dans mon crane qu'on appel un cerveau. Je réfléchie donc avant de faire et surtout je n'ajoute que ceux dont je connais les personnes qui sont derrières.

J'aimerai rappeler un certain bon sens qui devrait être la base pour n'importe quel OS, mais en particulier je parlerai que de linux. Le bon sens est peu importe l'OS, on ne doit pas ajouter de programmes dont on ne sait rien. Maintenant si on retranscrit dans le monde linux, on ne rajoute des dépôts si seulement c'est nécessaire, que ce soit openSUSE, Ubuntu ou autre, si c'est seulement pour avoir une version plus récente autant resté sur la version donnée par sa distribution de manière officiel que ce soit la version des dépôts principaux ou des backports. Ne rajouter des sources que de ceux dont on connaît les personnes qui sont derrières, on ne rajoute pas les PPA ou les homes de personnes dont on ne connaît rien, c'est pas seulement une question de sécurité mais aussi de stabilité, qui vous dit que le gars qui en est la source, ait les capacités de faire un truc propre? Le packaging n'est pas facile et il serait faux de penser que ça risque rien.

Personnellement, je n'ajoute que les PPA et les homes de contributeurs officiels donc arrêtez de nous casser les couilles si vous ne savez pas réfléchir deux secondes et ajouter ce qui ne doit pas l'être! Et surtout ne rejetez pas la faute de votre incompétence sur les distributions alors que les seules fautifs sont bien les personnes qui sont entre la chaise et le clavier.

Next → Page 1 of 2