Journal ManjaroARM se fait épingler par Asahi Linux

Posté par  . Licence CC By‑SA.
Étiquettes :
2
3
oct.
2022

https://nitter.it/AsahiLinux/status/1576356115746459648

@ManjaroLinux livre une version instable du noyau, plus récente que celle que nous livrons aux utilisateurs finaux, et qui ne fonctionne pas sur certaines plateformes.
Nous n'avons pas été contactés par eux concernant cette version d'Apple Silicon.

Sachant que Asahi c'est l'équipe qui travaille sur le port du noyau sur les nouvelles puces d'Apple. Leur travail a récemment été encensé par Linus. En lisant les commentaires sous ce post Twitter, je continue à me demander ce que fais Manjaro exactement. Il y a eu une période où j'ai envisagé cette distro pour l'installation d'un nouveau PC, histoire de gagner du temps. Puis j'ai lu quelques fils et notamment les histoires de repos incompatibles donc finalement non j'ai repris mon Archwiki qui m'a permis d'obtenir un OS tout beau tout propre très rapidement. Sous le post ci-dessus plusieurs personnes se plaignent de la version Pinephone de la distribution et maintenant cette critique de l'équipe ARM.
Vous avez un avis éclairé sur cette distribution et l'objectif de l'équipe ?

  • # Avis pour pinephone

    Posté par  . Évalué à 5.

    Sous le post ci-dessus plusieurs personnes se plaignent de la version Pinephone de la distribution et maintenant cette critique de l'équipe ARM.
    Vous avez un avis éclairé sur cette distribution et l'objectif de l'équipe ?

    Les avis, c'est comme les trous du cul : chacun le sien.

    Mais sur mon pinephone, j'ai eu plusieurs problèmes directement liés à des choix côté manjaro. Le plus récent date de ce matin : contraintes incorrectes sur les versions des paquets, du coup mon système a cessé de fonctionner suite à une désynchro partielle des miroirs (le miroir FR/EU n'avait pas la bonne version de qt5-wayland-client).
    Dans le lot des soucis liés à la distrib, le principal autre a été des fichiers de conf incorrects pour l'audio (alors que les confs correctes tournaient depuis des mois). Ça donne vraiment pas l'impression d'une distribution sérieuse, j'envisage de changer (mais y'a un port de Sculpt OS qui a été annoncé, ça m'intéresse bien donc j'hésite)

    • [^] # Re: Avis pour pinephone

      Posté par  (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 03 octobre 2022 à 22:43.

      Les avis, c'est comme les trous du cul : chacun le sien.

      Non, les avis sont à partager pour éclairer chacun. Après évidemment, chacun se fera son propre avis. Si tu ne précise pas qu'Arch est pour une utilisateur éclairé et qu'Ubuntu est plus simple (avec notamment des drivers non libre) tes amis vont avoir des surprises. Les avis ça sert à prendre la décision avant d'avoir son avis ;)

      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

      • [^] # Re: Avis pour pinephone

        Posté par  . Évalué à 5.

        Mon avis, c'est que cette phrase était là juste parce qu'elle était rigolote, et qu'il ne fallait pas la prendre au premier degré. Mais je te laisse te faire ton avis sur la question.

        • [^] # Re: Avis pour pinephone

          Posté par  . Évalué à 7.

          Mon avis, c'est que sa réponse améliore la blague…

          Les avis, c'est comme les trous du cul : chacun le sien.

          Non, les avis sont à partager pour éclairer chacun.

          Je te laisse donc imaginer l'éclairage…

          • [^] # Re: Avis pour pinephone

            Posté par  (site web personnel, Mastodon) . Évalué à 5.

            (lumière noire)

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Avis pour pinephone

            Posté par  . Évalué à 3. Dernière modification le 07 octobre 2022 à 08:07.

            Non d'un p'tit bonhomme, c'est que tu as raison. Par contre, est-ce que c'était vraiment volontaire ?

    • [^] # Re: Avis pour pinephone

      Posté par  . Évalué à 4.

      Pour le Pinephone, ici, le véritable problème c'est que Pinephone à un contrat exclusif avec Manjaro. Et puisque manjaro n'est pas le plus gros contributeur à ce projet, il y a de la jalousie des autres distributions et contributeurs à ce projet (pas tous et pas tout le monde !). Donc, plus de critiques négatives mais pas forcément objectives au départ.

    • [^] # Re: Avis pour pinephone

      Posté par  . Évalué à 8.

      Mon expérience récente avec PinePhone : je le déballe sous Manjaro ARM, il chauffe et se décharge très vite, je ne m'en sers pas beaucoup tout de suite.

      Je retente, l'updater apparaît et me propose une mise à jour… Ça se coince et je ne peux plus rien installer. La console me fait comprendre que pacman est planté sur un conflit de dépendances je crois, mais si je supprime le paquet incriminé une bonne partie du système serait désinstallée. J'attends quelques jours et je fais la manip quand même, réinstalle tout, enfin je peux mettre des apps. Update suivante, plein de composants plasma changent… et ça se met à bugguer dans tous les sens, fenêtres à moitié hors écran, impossible de lire et d'atteindre les boutons, bravo. Et les appels ne marchent plus.

      Je me fais une carte SD avec Mobian (plasma toujours), l'interface marche mieux. Par contre ça chauffe toujours, et le modem est pas bien stable (mon vieux tel est vraiment mort, j'ai mis ma carte SIM et je rate des appels).

      J'apprends qu'une mise à jour du firmware modem règle le problème de conso/chauffe, c'est documenté sous PostMarketOS => allez hop je l'installe, avec Phosh, sur l'eMMC cette fois.

      L'étape fwupd se passe très bien, et au lieu de tenir 4h la batterie tient maintenant presque 2 jours ! (je n'active que le cellulaire et communique peu). Les fonctions de base marchent, stables : j'ai retrouvé un téléphone ! Bon, pas très smart quand même, à part tel et SMS pas grand chose (appareil photo pourri, synchro calendrier/agenda limitée à quelques fournisseurs mais pas mon système *DAV, GPS ? pas d'appli, pas Signal…)

      Moralité : Manjaro c'était tout cassé de base, PMOS ça me semble mieux ; j'aimerais avoir plus de temps pour aider plasma-mobile mais c'est encore un peu loin du compte…

  • # sans doute pas un avis "éclairé"

    Posté par  . Évalué à 5.

    Je ne suis qu'un utilisateur de Manjaro et je ne connais que les objectifs affichés sur leur site (et pas ceux qu'ils nous cacheraient…). Tout ce que je peux dire c'est que je l'utilise depuis deux ans et que j'en suis très satisfait. Je respecte (et comprends) le choix de ceux qui préfèrent utiliser Arch mais ce n'est pas le mien.

    Il y a bien cette histoire de pousser Only Office mais ça n'a rien d'obligatoire alors ça ne me gêne pas. J'imagine que c'est comme pour Firefox et Google, une histoire de sous.

    Si ton histoire de repos incompatibles, c'est le fait qu'ils utilisent leurs propres repos plutôt que ceux de Arch directement, je ne vois pas en quoi c'est un problème, c'est le cas pour la plupart des distributions et c'est clairement affiché.

    Et je ne comprends pas la critique sur les noyaux livrés : sur mon installation, j'ai un noyau standard (actuellement le 5.19.7) et je peux, si le souhaite, installer un noyau marqué "expérimental" ou un noyau marqué "temps réel". Quel est le problème ?

    En l'état, ton journal ressemble un peu à du FUD sur Manjaro mais je peux me tromper sur tes intentions. Alors à moi de te retourner la question : quel est ton (vrai) objectif avec ce journal ?

    • [^] # Re: sans doute pas un avis "éclairé"

      Posté par  . Évalué à 5.

      Et je ne comprends pas la critique sur les noyaux livrés : sur mon installation, j'ai un noyau standard (actuellement le 5.19.7) et je peux, si le souhaite, installer un noyau marqué "expérimental" ou un noyau marqué "temps réel". Quel est le problème ?

      Pour ce qui est du noyau, tu parles du noyau proposé dans la version ARM alors que moi je te réponds (à coté de la plaque) sur la version x86. Ceci dit, je viens de regarder sur le site de Manjaro et il semble y avoir, comme pour Manjaro x86, une version dite "stable" et une version "instable". La critique serait qu'ils utilisent un noyau instable dans leur version dite stable, c'est ça ?

      • [^] # Re: sans doute pas un avis "éclairé"

        Posté par  . Évalué à 7.

        La critique serait qu'ils utilisent un noyau instable dans leur version dite stable, c'est ça ?

        La critique, c'est qu'ils utilisent un noyau hautement expérimental, dont le développement est incessant, et envoient ça aux utilisateurs sans avoir demandé aux développeurs de la série de patchs du noyau ce qu'ils en pensaient ou l'état général de la chose. En l'occurence, les patchs pour les SoC Apple M1 et M2. C'est ultra expérimental, j'ai cru lire que ça pouvait détruire les hauts-parleurs selon les réglages… on est bien bien bien au delà de "instable".
        Du coup les développeurs des patchs ne sont pas contents parce qu'on ne leur a pas demandé leur avis, aucun canal n'a été mis en place.
        Une distribution ne devrait pas venir prendre du code en développement (surtout à ce niveau là) sans discuter, c'est la moindre des politesses.

        • [^] # Re: sans doute pas un avis "éclairé"

          Posté par  (Mastodon) . Évalué à 3.

          Une distro fait ce qu'elle veut hein. Elle n'a rien à demander à upstream. Et si ça pète le matos de ses utilisateurs, le problème et le litige se situera entre manjaro et ses utilisateurs.

          • [^] # Re: sans doute pas un avis "éclairé"

            Posté par  . Évalué à 10.

            Je comprends plutôt ça comme "ils feraient mieux de", pas "ils doivent".
            C'est ce que dit Asahi : "please talk to us so we can help you do it right!

          • [^] # Re: sans doute pas un avis "éclairé"

            Posté par  . Évalué à 9.

            Là, ce que fait la distro, c'est juste tenter de tirer la couverture à soi tout en prenant le risque de discréditer le travail des développeurs en mettant dans les mains de personnes pas du tout prêtes du code complètement expérimental.
            Donc non, le problème ne sera pas seulement entre manjaro et ses utilisateurs.

            • [^] # Re: sans doute pas un avis "éclairé"

              Posté par  (Mastodon) . Évalué à 2. Dernière modification le 03 octobre 2022 à 22:24.

              Ils utilisent du logiciel libre expérimental à leurs risques et périls et à ceux de leur utilisateurs. Point barre.

              La distro ne s'appelle pas ManjaroAsahi.

              On peut critiquer leur choix à chier mais ils ne doicent rien à Asahi et ne leur causent pas du tort.

              • [^] # Re: sans doute pas un avis "éclairé"

                Posté par  . Évalué à 4.

                (vraie question)

                Manjaro avertit-elle ses utilisateurs que le noyau fourni pour les puces M1/M2 d'Apple est experimental et que ça peut carrément casser du matériel ?
                Si oui, ça va. Mais vu la discussion ci-dessus, j'ai l'impression que ça n'est pas le cas…

                • [^] # Re: sans doute pas un avis "éclairé"

                  Posté par  (Mastodon) . Évalué à 5. Dernière modification le 04 octobre 2022 à 09:28.

                  Ils ont répondu au tweet. Ouais leur anglais n'est pas très bon mais au final on comprend:

                  We are currently only tested our version on a MacBook Air M1 and stated that also on the #README file on the development project at #SOURCEforge. We will contact @AsahiLinux team soon to establish a good development relationship.

                  Accessoirement Asahi a réagit à un message de commit qui parle de branche unstable:

                  https://lists.manjaro.org/pipermail/manjaro-packages/Week-of-Mon-20220926/052354.html

                  _### BoxIt memo ###

                  User philip committed following changes:

                  • arm-unstable core aarch64: 4 new and 0 removed package(s)
                  • arm-unstable community aarch64: 1 new and 0 removed package(s)

                  -------------- next part --------------
                  [New Packages]
                  linux-apple-silicon-6.0rc7-1-aarch64.pkg.tar.zst
                  linux-apple-silicon-headers-6.0rc7-1-aarch64.pkg.tar.zst
                  m1n1-1.1.5-1-aarch64.pkg.tar.zst
                  uboot-apple-silicon-2022.07-1-aarch64.pkg.tar.zst
                  -------------- next part --------------
                  [New Packages]
                  lzfse-1.0-1-aarch64.pkg.tar.zst_

                  Je ne suis pas spécialement fan de manjaro, bien au contraire, mais c'est beaucoup de bruit pour rien. Et le logiciel libre, c'est aussi la liberté de faire de la merde si on en a envie.

                  • [^] # Re: sans doute pas un avis "éclairé"

                    Posté par  . Évalué à 5.

                    le logiciel libre, c'est aussi la liberté de faire de la merde si on en a envie.

                    Encore une fois personne n'a dit qu'ils n'avaient pas le droit. Mais si tu fais de la merde bin faut s'attendre à ce que qqun vienne te dire que tu fais de la merde. Et tu auras toujours le droit de continuer ta merde hein… Et d'autres viendront te le répéter.

                    • [^] # Re: sans doute pas un avis "éclairé"

                      Posté par  . Évalué à 7.

                      (pardon, trop tard pour l'EDIT)

                      Là ils disent carrément qu'ils se sont trompés (Manjaro)
                      https://twitter.com/ManjaroLinux/status/1576568126992707585

                      Et ce mainteneur de Arch qui enfonce le clou
                      https://twitter.com/Sh1bumi/status/1576583348604239872

                      Bref, oui ils font bien ce qu'ils veulent mais si ils font des trucs pas safe, pas étonnant que ça soit relevé.

                      • [^] # Re: sans doute pas un avis "éclairé"

                        Posté par  . Évalué à 4.

                        Super le second lien

                        mainteneur Arch Linux et ils arnaquent constamment nos PKGBUILD

                        Mais, quand on lui demande un exemple … le "constamment" deviens "j'ai oublié".
                        manjaro fait à 99,9% une simple copie binaire des paquets arch qu'il récupère (donc sans les modifier), et pour une poignée d'autres comme grub et pacman (venant de arch mais modifié), ils sont sur le dépôt git donc il lui est facile de nous faire un lien vers l'historique incriminant.
                        A moins que ce qu'il a oublié : c'est qu'il avait lu cela sur un réseau social ?

                        Note: ne pas trouver de trace de arch pour le système (kernels, systemd, drivers vidéo) est normal puisqu'ils ne viennent pas de arch, peut-être que ce Archer ne le sait pas ?

                • [^] # Re: sans doute pas un avis "éclairé"

                  Posté par  . Évalué à 1.

                  Tous les utilisateurs de Mac m1 savent qu'un portage de Linux est hautement expérimental sur cette plateforme !

                  • [^] # Re: sans doute pas un avis "éclairé"

                    Posté par  . Évalué à 5.

                    Oui, enfin…
                    Si ma distro décide du jour au lendemain d'intégrer un kernel avec du travail experimental susceptible de casser du matos, je m'attends à ce que ce soit écrit en CAPITALES ROUGES ET GRASSES partout ! Pas que ça passe comme une simple mise à jour…

                    • [^] # Re: sans doute pas un avis "éclairé"

                      Posté par  . Évalué à 3.

                      Une mise à jour de Manjaro n'applique JAMAIS un noyau expérimental. Il y a juste un outil qui permet de changer de noyau si on le souhaite parmi une liste comportant des noyaux "normaux", des noyaux temps réel et des noyaux expérimentaux ; chacun étiqueté comme tel.

                      Alors, certes, l'étiquette "expérimental" n'est pas en lettres rouges et grasses mais ça ne passe en aucun cas comme une simple mise à jour.

                      NB. Distinguer "expérimental" et "expérimental risqué" me paraît difficile… et risqué (comment être sûr que le "expérimental" n'était pas en fait un "expérimental risqué" ?). De mon point de vue, un noyau expérimental ne s'adresse qu'à des développeurs/testeurs qui savent ce qu'ils font et vont certainement consulter les notes de publication associées.

                    • [^] # Re: sans doute pas un avis "éclairé"

                      Posté par  (Mastodon) . Évalué à 2. Dernière modification le 05 octobre 2022 à 14:15.

                      HA HA HA

                      Chaque version du kernel, même dans sa version LTS maintenue par GKH est par définition expérimentale.

                      Tiens cadeau pas plus tard qu'il y a deux jours:
                      https://lore.kernel.org/all/YzwooNdMECzuI5+h@intel.com/

                      Et des utilisateurs de distros majeures ont été affectés. J'étais sur le 5.19.12 pendant au moins 24H sur mon laptop pro.

                      • [^] # Re: sans doute pas un avis "éclairé"

                        Posté par  . Évalué à 3. Dernière modification le 05 octobre 2022 à 14:38.

                        C'est un point de vue radical sur lequel je ne me prononcerai pas (surtout qu'il est étayé par un seul exemple) mais quel est le rapport avec le sujet du journal ?

                        Ceci dit, je constate que la dernière version "normale" qui m'est proposée par Manjaro est la 5.19.7, pas la 5.19.12. Du coup, le décalage de 3 ou 4 semaines par rapport à upstream n'est pas si mal.

                      • [^] # Re: sans doute pas un avis "éclairé"

                        Posté par  . Évalué à 4.

                        Oui bon, vu comme ça c'est toute l'industrie qui est expérimentale à part éventuellement dans l'aéronautique. Oui les logiciels sont toujours « "AS IS" WITHOUT WARRANTY OF ANY KIND » et les bugs ça existe. Tu enfonces une porte ouverte là, mais on peut s'attendre à un minimum de précautions de la part d'une distribution grand public. ManjaroARM n'est pas encore grand public mais c'est leur objectif.

        • [^] # Re: sans doute pas un avis "éclairé"

          Posté par  (Mastodon) . Évalué à 6. Dernière modification le 04 octobre 2022 à 08:00.

          ça pouvait détruire les hauts-parleurs selon les réglages… on est bien bien bien au delà de "instable".

          Cela me semble normal que l'on puisse détruire les hauts-parleurs avec un mauvais hifi.conf (et/ou une table quirk) : c'est le matériel qui fait ce choix d'absence de gardes-fous et en même temps d'absence de documentation. (proche d'une électronique de ce qui se fait en embarqué avec par exemple une carte "planquée" derrière un gpio ou un bus d'une puce en version différente de celle pourtant taguée (cas des baytrail intel) ou encore d'une absence d'harmonisation électronique (cas des cartes sons rt5648 planquées derrière des cochoncetés intel sst nécessitant des tables dsdt pas documentées) ou encore de puces strictement identiques mais aux déclaratifs différents. Bref, un "bordel" dont nous n'avons pas l'habitude avec les pc bios et l'acpi, mais tout à fait courant lorsque tu tâtonnes sans fiche descriptive)

          Cela peut apparaître surprenant, certes, de pouvoir "détruire son matériel depuis le logiciel" aujourd'hui, mais logiquement ce n'est pas déconnant. Les cartes sons en sont un exemple qui saute aux oreilles mais il y a d'autres. Ce qui surprends peut être c'est qu'on peut le détruire avec une mauvaise conf sans avoir besoin d'un mauvais code. Mais je ne sais pas si c'est suffisant pour passer le qualificatif de "instable" à "expérimental"

          • [^] # Re: sans doute pas un avis "éclairé"

            Posté par  (Mastodon) . Évalué à 5.

            Accessoirement il y a quelque chose qui est fait quelque part soit au niveau kernel, soit au niveau pulseaudio/pipewire mais avec le même laptop sous linux il est souvent impossible d'avoir le volume aussi fort que sous windows avec les hauts-parleurs embarqués à moins de passer au dessus de 100% dans les réglages de volumes (et avoir de la saturation).

            Il y a donc des developpeurs ou des mainteneurs de distros qui mettent des garde-fous arbitraires pour éviter qu'on ruine le matos.

            • [^] # Re: sans doute pas un avis "éclairé"

              Posté par  (site web personnel) . Évalué à 3.

              Ça m'est déjà arrivé de devoir passer par alsamixer pour avoir accès à des contrôles supplementaires, pour activer des sorties ou augmenter des volumes (genre un canal PCM qui n'apparaissait pas dans l'interface graphique). Si ça peut être ça…

              Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: sans doute pas un avis "éclairé"

      Posté par  . Évalué à 5.

      pas ceux qu'ils nous cacheraient…

      Oulà je n'ai jamais dit, ni même sous-entendu, qu'ils nous cachaient quoique ce soit hein…

      Si ton histoire de repos incompatibles, c'est le fait qu'ils utilisent leurs propres repos plutôt que ceux de Arch directement, je ne vois pas en quoi c'est un problème, c'est le cas pour la plupart des distributions et c'est clairement affiché.

      Vu que l'objectif de Arch, tout comme Manjaro, c'est une rolling-release, avec "Access to the very latest cutting and bleeding edge software", et le même gestionnaire de paquets… je considérais (à tort visiblement) Manjaro comme un moyen pratique d'installer un desktop Arch léger & fonctionnel. C'est une distribution parce qu'ils font des choix (le bureau, les logiciels installés par défaut) et je n'ai aucun soucis avec ça. Mais du coup à quoi servent les repos séparés ? Est-ce qu'on ne pouvait pas parvenir au même résultat avec les repos Arch ? Je n'ai pas utilisé Manjaro (justement à cause de cette affaire de repos) donc ce sont de vraies questions.

      Et je ne comprends pas la critique sur les noyaux livrés

      Ici ce n'est pas ma critique mais celle de Asahi. Visiblement ce sont eux qui fournissent les noyaux pour les puces Apple et Manjaro a déployé une version "pas prête". Ils confirment ici : https://twitter.com/AsahiLinux/status/1576536552515461121.

      Quel est ton (vrai) objectif avec ce journal ?

      Me faire une idée parce que l'idée de départ m'intéresse (un desktop Arch rapidement). Je sais que beaucoup de gens l'utilisent et d'un autre côté je lis beaucoup de critiques. Avec la notoriété, forcément les critiques se multiplient, ça c'est normal. Mais ici la critique vient d'une équipe de "pros" et avec les soucis remontés sur le Pinephone ça renforce mon sentiment qu'ils gèrent le projet un peu par-dessus la jambe. Je dis bien "mon sentiment"… je n'ai pas grand chose de concret justement, à part des tweets trouvés sous celui que Asahi :

      "as per usual, they somehow make every aspect unstable as possible"

      "sounds about right for manjaro, never shipping stable or working things while claiming to be a "user friendly distro"

      "Manjaro doing what they do best 😩"

      Alors pourquoi tant de haine ?

      • [^] # Re: sans doute pas un avis "éclairé"

        Posté par  . Évalué à 3. Dernière modification le 03 octobre 2022 à 18:43.

        Alors pourquoi tant de haine ?

        Après ta réponse (mais c'était déjà le cas avant) je n'en éprouve aucune. Mais j'ai sans doute été un peu "agressif", sincèrement désolé.

        Je ne peux parler que du Manjaro "classique", j'ignore tout des versions ARM ou Pinephone et les critiques que tu cites par rapport à ces dernières sont peut-être justifiées.

        C'est une distribution parce qu'ils font des choix (le bureau, les logiciels installés par défaut) et je n'ai aucun soucis avec ça. Mais du coup à quoi servent les repos séparés ?

        C'est un peu plus que ça. Si installer une Arch consistait seulement à faire un pacman -S package_name1 package_name2 … ça se saurait et personne ou presque ne choisirait Manjaro.

        Par ailleurs, les repos de Manjaro jouent aussi le rôle de tampon temporel : c'est une rolling release avec un décalage temporel sur Arch censé éviter les éventuels problèmes d'une rolling release pure et dure avec en plus une factorisation des mises à jour (une seule mise à jour par mois en moyenne, sauf maj de sécurité).

        Ce dernier point ne compte pas vraiment pour moi car j'utilise btrfs et je peux donc revenir en arrière facilement si une mise à jour se passe mal.

        Donc non, mon ressenti en ce qui concerne la version x86, c'est qu'ils ne gèrent pas ce projet par dessus la jambe.

        • [^] # Re: sans doute pas un avis "éclairé"

          Posté par  . Évalué à 3.

          Après ta réponse (mais c'était déjà le cas avant) je n'en éprouve aucune. Mais j'ai sans doute été un peu "agressif", sincèrement désolé.

          Le "pourquoi tant de haine" faisait référence aux divers commentaires sur le web, pas aux tiens ;-)

          Autre exemple des nombreuses critiques, en fouillant cette affaire de tampon temporel j'ai trouvé un dépôt Github carrément dédié à décourager l'utilisation de Manjaro : Manjarno L'histoire des certificats SSL et les soucis de Pamac sont un peu flippants aussi. Peut-être juste des erreurs de jeunesse… Je garderai un oeil dessus car je connais assez bien Arch et j'avais envie de tester Manjaro ARM sur le M1 qu'on a offert à ma femme.

      • [^] # Re: sans doute pas un avis "éclairé"

        Posté par  . Évalué à 3.

        Alors pourquoi tant de haine ?

        Distro drama, rien de plus ni de moins. Une bonne vieille guerre clochers. Les comptes que tu citent ne contribuent pas franchement grand chose a part gueuler.

        Juste ignore les, le tweet officiel et la (potentielle) réponse de Manjaroo me paraissent être les seules choses pertinentes dans cette histoire.

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: sans doute pas un avis "éclairé"

        Posté par  (site web personnel) . Évalué à 3.

        J'utilise Manjaro depuis pas mal d'années avec beaucoup de bonheur :) J'essaye toujours de comprendre d'où viennent les critiques récurentes.
        D'après les réponses que j'ai eut, beaucoup d'utilisateurs Arch n'aiment pas Manjaro car c'est une société qui court un peu après l'argent en se basant principalement sur le travail bénévole de Arch. Un peu comme Ubuntu et Debian à une époque.

        Mais du coup à quoi servent les repos séparés ?

        Là, je peux essayer de répondre. En fait, Manjaro essaye d'être la plus stable possible. C'est une rolling release, mais elle a des mises à jours par paquets (tous les 15j / 3 semaines). Donc, ils essayent de tester les mises à jours Arch avant de les proposer aux utilisateurs de Manjaro. De plus, beaucoup de paquets sont personnalisés pour avoir un look homogène et sympa.
        Le problème, c'est que les repos AUR sont synchronizés en direct (ou presque) avec Arch, ce qui fait que les mises à jour des paquets AUR peuvent parfois poser des problèmes de comptatibilités.

        je considérais (à tort visiblement) Manjaro comme un moyen pratique d'installer un desktop Arch léger & fonctionnel.

        Tu peux essayer https://endeavouros.com/ et https://garudalinux.org/

        • [^] # Re: sans doute pas un avis "éclairé"

          Posté par  (Mastodon) . Évalué à 4.

          Il y a aussi :

          archinstall --script guided

          Qui suffit amplement. De toute façon l'installeur calamares utilisé par endeavour et garuda a toujours été un peu buggé.

  • # Petit retour d'expérience de Manjaro sur Pinephone

    Posté par  (site web personnel) . Évalué à 5.

    Je n'ai testé Manjaro que sur Pinephone. Au début avec le bureau Plasma (KDE) préinstallé, mais il était trop lent, instable, et causait une surchauffe permanente.

    Après avoir testé Postmarket OS avec SXMO (trop galère et plante tout le temps), j'ai réinstallé Manjaro avec Phosh (GNOME), parce que je suis habitué à Arch et que j'aime beaucoup pacman. C'est suffisamment fluide si on ne lui en demande pas trop, ça plante encore de temps en temps, ce qui semble encore inévitable sur Pinephone (donc ce n'est probablement pas la faute de l'équipe Manjaro ARM, seulement que l'écosystème de pilotes est encore trop jeune, que les fabricants ne doivent pas être coopératifs, et que les environnements de bureau et les interfaces graphiques n'étaient pas conçus pour téléphone au départ).

    Par contre les dépôts sont très peu souvent mis à jour, et certaines mises à jour créent de nouveaux plantages qui ne sont pas corrigés. (par exemple je ne peux plus fermer ni changer de fenêtre, sinon ça plante) Et si par ignorance on utilise pacman au lieu de pamac, ça casse tout. Il manque aussi quelques paquets qui sont disponibles dans d'autres distros.

  • # pourquoi tant de haine

    Posté par  . Évalué à 4.

    Je viens seulement de lire le fil pointé par le journal. C'est effectivement un flot de haine envers Manjaro (il y en a même un qui suggère un patch dans le noyau pour que celui-ci s'arrête s'il est en train de s’exécuter dans Manjaro !).

    Le problème que j'ai avec ça (au delà de la forme), c'est que ça ne correspond pas du tout à mon expérience personnelle de deux ans avec une seule fois un problème de mise à jour que j'ai trouvé plus simple de contourner en revenant au snapshot BTRFS précédent jusqu'à ce que ce que ce soit résolu.

    Je suis bien conscient que mon expérience personnelle ne reflète pas nécessairement l'expérience de la majorité, mais je suis quand même dubitatif. J'ai en effet déjà eu écho d'autres réactions virulentes provenant d'utilisateurs d'Arch vis à vis de Manjaro, au motif que le succès de Manjaro serait bâti au détriment de Arch à qui il doit pourtant (presque) tout, y compris son wiki.

    Du coup, j'ai l'impression que le moindre problème est pris comme prétexte à réactiver cette vindicte alors que seuls les utilisateurs de Manjaro seraient fondés à éventuellement se plaindre.

    Je trouve plus pondérée et argumentée la position du site manjarno cité plus haut :
    Disclaimer: I don't hate Manjaro. These are some reasons which made me consider shifting to a different distro. However, I still believe that Manjaro is a good starting point for beginners who want to explore an Arch based like distro.

    • [^] # Re: pourquoi tant de haine

      Posté par  (site web personnel) . Évalué à 5.

      Le hic c'est plus le support

      -> vous ne trouvez pas de wiki ou d'info riche comme pour Arch
      -> les dépôts core ne sont pas ceux de Arch ( comme Ubuntu/Debian ) , mais vous installez les AUR de Arch
      -> il peut y avoir des choses moins flexibles dans Manjaro comme sur les kernel
      -> il y a des éléments "ajoutés" par rapport à Arch ; par exemple la version GNOME ils foutent le bordel dans GNOME

      Donc si un truc marche pas, le user de Manjaro il va chercher un peu, ne pas trouver, puis demander de l'aide aux Arch-iens. Et du coup les Arch-iens ben ça les emmerde de faire le support d'une distrib basée sur la leur mais qui fournit des kernels différents ou rajoute des surcouches.

      De nos jours il y a de meilleures solutions pour les flemmards comme moi, où l'ont peut avoir un installeur mais rester sur une vraie Arch - c'est à dire sur les dépôts Arch. Du coup Manjaro n'a absolument plus aucun intérêt aujourd'hui - au contraire cette distrib ne fait qu'apporter de potentiels problèmes. Même s'il oui la plupart du temps ça marche tranquillou.

      • [^] # Re: pourquoi tant de haine

        Posté par  . Évalué à 6.

        De nos jours il y a de meilleures solutions pour les flemmards comme moi, où l'ont peut avoir un installeur mais rester sur une vraie Arch - c'est à dire sur les dépôts Arch. Du coup Manjaro n'a absolument plus aucun intérêt aujourd'hui.

        Vraie question : installer Arch via un installeur aboutit au même résultat qu'installer Manjaro (aux différences cosmétiques près) ?

        Je vais me retrouver avec tout ce qu'il faut pour BTRFS (les sous-volumes par défaut, etc…), la prise automatique d'un snapshot en cas de mise à jour, de quoi installer une imprimante sans passer par la ligne de commande, idem pour un logiciel, un noyau, etc… ?

        Parce que moi, ce que je veux, c'est une rolling release (sous KDE) mais je n'ai pas envie d'apprendre tout ce qu'il y a à apprendre via l'installation, certes très bien documentée, d'une Arch (tout comme je n'ai pas envie d'apprendre la couture ou comment faire moi-même la vidange de ma voiture, ce sont des choix). De plus, cette connaissance aurait peu de chance de m'être nécessaire car en cas de problème je reviens sur un snapshot précédent.

        J'ai la fibre mais si j'étais en ADSL, peut-être que je n'aurais pas envie non plus de faire des mises à jour quotidiennes.

        N'es-tu donc pas un peu péremptoire en disant que "Manjaro n'a absolument plus aucun intérêt aujourd'hui" ? Tu es sûr que le flemmard que tu invoques est bien représentatif de tout le monde ?

        Ceci dit, j'attends ta réponse avec intérêt car si passer par un installateur m'amène très près de l'état d'installation d'une Manjaro, je pourrais effectivement choisir Arch.

        • [^] # Re: pourquoi tant de haine

          Posté par  (site web personnel) . Évalué à 4.

          Vraie question : installer Arch via un installeur aboutit au même résultat qu'installer Manjaro

          Non - Manjaro ce ne sont pas les dépôts Arch. C'est pour cela que je comparais à la relation Ubuntu/Debian.

          Alors qu'il existe des installeurs qui ne font que installer Arch. Arch en développe un officiel (si si!!), mais que je n'ai pas testé. Bon ça a l'air de laisser un peu la main quand même.

          https://wiki.archlinux.org/title/archinstall

          Ce que j'ai testé c'est un truc non officiel et graphique. Ce n'est pas que pour les boulets les trucs graphiques - ça a l'avantage de permettre de vérifier que tout le matos est pris en charge correctement!

          https://archlinuxgui.in/

          N'es-tu donc pas un peu péremptoire en disant que "Manjaro n'a absolument plus aucun intérêt aujourd'hui" ?

          Hmmm oui je suis un peu péremptoire c'est vrai.

          • [^] # Re: pourquoi tant de haine

            Posté par  . Évalué à 2.

            Non - Manjaro ce ne sont pas les dépôts Arch.

            Je sais mais ce n'était pas ma question. En tant qu'utilisateur lambda, je voulais juste savoir quelles sont les différences "fonctionnelles" une fois l'installation finie.

            • [^] # Re: pourquoi tant de haine

              Posté par  . Évalué à 4. Dernière modification le 05 octobre 2022 à 12:38.

              manjaro reprend 99% des paquets arch tel quels, mais les dépots ne sont pas synchro avec arch : décalage de 15 jours environ
              Donc, avec manjaro, une seule mise à jour (environ tous les 15 jours) mais très importante contrairement à arch qui a 1 à une poignée de paquets chaque heure.
              manjaro fournit ces propres kernels et propose plus de choix de versions et changement par un clic.

              En fait le gros changement (en plus du décalage) est que archlinux est par son adn KISS (utilisateur fait tout par lui même) alors que manjaro fait tout pour que l'utilisateur en fasse le moins en proposant quelques petits outils
              Voir par exemple manjaro-system qui peut installer/supprimer des paquets lors des mises à jour (une aberration pour un archer)
              https://gitlab.manjaro.org/packages/core/manjaro-system/-/blob/master/manjaro-update-system.sh

              Puisque les utilisateurs choisissent arch pour son coté KISS, il est donc normal que ces mêmes utilisateurs "méprisent" manjaro qui se positionne clairement comme son opposé.

      • [^] # Re: pourquoi tant de haine

        Posté par  (site web personnel) . Évalué à 2.

        Donc si un truc marche pas, le user de Manjaro il va chercher un peu, ne pas trouver, puis demander de l'aide aux Arch-iens.

        Il y a des forums très actifs, autant en anglais qu'en français spécifiques à Manjaro.
        Et il y a un wiki également (sans doute pas aussi bon que celui de Arch), mais je ne me souvient pas avoir rencontré le cas d'un truc venant du wiki de Arch qui ne fonctionnait pas sur Manjaro…

        • [^] # Re: pourquoi tant de haine

          Posté par  (site web personnel) . Évalué à 5.

          J'ai du manquer de chance. Je suis tombé sur un AUR ou deux qui ne passaient pas avec Manjaro. Puis j'ai voulu install les zen kernel et je me suis rendu compte que Manjaro ne le permettait pas. Je suis tombé sur des cas où le wiki de Manjaro ne documentait pas, et je ne savais pas si le wiki de Arch s'appliquait vraiment où pas.

          J'aurai très bien pu ne pas remarquer tout cela. Je suis sûr que plein d'utilisateurs de Manjaro sont contents. Mais je suis aussi convaincu qu'ils seraient contents sous Arch…

          • [^] # Re: pourquoi tant de haine

            Posté par  . Évalué à 2.

            Mais je suis aussi convaincu qu'ils seraient contents sous Arch.

            Je ne pense pas : il est notoirement admis qu'il ne faut pas conseiller Arch à un utilisateur lambda (ce qui ne veut évidemment pas dire que Arch est moins bien "techniquement", c'est même sans doute le contraire).

          • [^] # Re: pourquoi tant de haine

            Posté par  . Évalué à 0.

            J'ai du manquer de chance. Je suis tombé sur un AUR ou deux qui ne passaient pas avec Manjaro.

            Puisque manjaro a un retard sur arch, il est normal que parfois certains paquets aur ne peuvent s'installer alors que c'est ok avec arch.
            Chose rare, mais claire pour tout utilisateur manjaro

            Puis j'ai voulu install les zen kernel et je me suis rendu compte que Manjaro ne le permettait pas.

            Encore heureux ! manjaro fait ces propres kernel. Installer un kernel fait pour une autre distribution est une chose étrange.
            ps: c'est pourtant techniquement possible d'installer il me semble mais durable je ne pense pas

            Je suis tombé sur des cas où le wiki de Manjaro ne documentait pas

            L'idée de départ avec le wiki manjaro était de ne pas (mal) dupliquer les excellentes pages du wiki arch si il n'y avait pas de différence. Après des années, on a maintenant quelques duplications mais, le wiki arch est beaucoup trop complet/actif pour bien être reporté sur le wiki manjaro.

            Je suis sûr que plein d'utilisateurs de Manjaro sont contents. Mais je suis aussi convaincu qu'ils seraient contents sous Arch…

            Pas totalement faux. A mon avis beaucoup se font les dents sur manjaro pour ensuite passer à arch.
            Existe même des (rares) utilisateurs arch qui passent à manjaro ;)
            ps: on peut aussi écrire "je suis aussi convaincu qu'ils seraient contents sous Ubuntu…" ;)

  • # twit ?

    Posté par  . Évalué à 3. Dernière modification le 03 octobre 2022 à 23:00.

    bonjour

    1) twitter ?
    Je trouve particulier que Asahi communique via twitter, pourquoi ne pas contacter avant manjaro ?
    le gitlab manjaro existe et pas une seule issue ? le repo existe depuis 4 jours
    https://gitlab.manjaro.org/manjaro-arm/packages/apple-silicon

    2) disponibilité
    https://packages.manjaro.org/?query=silicon&arm=on
    Pour l'instant ce n'est disponible que dans la branche instable : branche réservée aux développeurs manjaro arm. Donc nous ne sommes pas encore dans un véritablement déploiement.
    Si Asahi communiquait directement avec manjaro, je ne vois pas pourquoi, manjaro pourrait mettre ce projet en attente, ils n'ont certainement pas un besoin urgent de ce support matériel.

    3) demander autorisation à Asahi ?
    A titre personnel, cela me semble plus que normal. Mais, dans les faits, si on regarde les kernels, quelle distribution va demander l'autorisation à kernel.org…
    Manjaro a quand même l'habitude de distribuer des kernels en RC pour les x86 (oui, pas top) et ici, il me semble que l'on est dans le même cas

    • [^] # Re: twit ?

      Posté par  . Évalué à 3.

      Manjaro a quand même l'habitude de distribuer des kernels en RC pour les x86 (oui, pas top) et ici, il me semble que l'on est dans le même cas.

      Pourquoi "pas top" ?

      Le noyau installé par défaut n'est jamais un noyau RC. On peut, si on veut, installer un noyau RC mais celui-ci étant marqué "expérimental", personne n'est pris en traître. Il est interdit de tester un noyau RC via une Manjaro ? Il y a des distributions réservées à cet usage ?

    • [^] # Re: twit ?

      Posté par  (site web personnel) . Évalué à 10.

      Je trouve particulier que Asahi communique via twitter, pourquoi ne pas contacter avant manjaro ?
      le gitlab manjaro existe et pas une seule issue ? le repo existe depuis 4 jours
      https://gitlab.manjaro.org/manjaro-arm/packages/apple-silicon

      La communication par Twitter est un problème en soi. Mais par contre c’est Asahi l’upstream ici, donc si quelqu’un a un intérêt dans ce que produit Asahi, c’est à lui de contacter Asahi, pas l’inverse. C’est ça l’essentiel du message à la base malgré la forme du tweet/

      Pour se faire une idée d’à quel point “expérimental” veut dire dans ce contexte, on peut donner cet exemple : récemment une personne contribuant à Asahi a publié une vidéo titrée « ÇA MARCHE! GNOME, Firefox, applications KDE, tout !!!! ». Et effectivement à première vue ça marche… SAUF QUE de ce que j’ai lu à droite et à gauche, il y a un énorme HACK qui est utilisé pour contourner un gros bug, et ce hack ce serait d’éteindre et rallumer le GPU à chaque frame. Quelqu’un qui livrerait ça ce serait un peu comme livrer une voiture qui, pour pouvoir être conduite par des tiers et rouler y compris à 120 sur l’autoroute, le démarreur doit être maintenu continuellement en marche et le frein jamais touché. Si Manjaro livre des choses expérimentales d’Asahi sans concertation avec Asahi, les utilisateurs sont à risque de recevoir ce genre de choses, et peut-être pire.

      Quand on développe, on peut avoir des situations où les choses commencent à prendre vraiment forme, suffisamment pour en faire des démos, mais en sachant qu’il y a des trucs bien sales voire des choses super risquées qu’il ne faut pas du tout faire. Le développeur qui fait la démo peut faire exprès de ne PAS faire ci ou ça, ne PAS cliquer là, etc. Mais dans une démo contrôlée pour communiquer sur l’avancement (ce sont déjà des succès énorme, chaque bug après l’autre) on ne peut pas tout dire, et parfois le développeur n’a que des intuitions sur ce qui serait super risqué de faire sur la base de ce qu’il sait avoir grossièrement dégrossi à l’arrache.

      Ça peut donc être très préoccupant pour un développeur de voir son patch se retrouver en prod alors qu’il n’est public que par amour de l’open source, méthode de travail, transparence, communication, toussa, ou même rien que pour se faire mousser, et se dire « merde ça peut flinguer le matos des gens il y a que moi qui le sait et ce gus il a pris mon code et il leur a donné sans même me demander s’il y avait un risque 😱️ ».

      C’est un variante de « si c’est sur Internet c’est pour être utilisé » : « si c’est sur Internet c’est que c’est prêt pour la production ».

      Là récemment je suis de près le travail sur rusticl, un nouveau pilote OpenCL pour Mesa. Le développeur a publié une copie d’écran de LuxMark fonctionnant avec une carte Radeon, puis que le pilote “passait la conformité OpenCL 3.0 CTS”, j’ai démontré la capacité à utiliser plusieurs GPUs en même temps et la couverture large des générations de matériel, puis j’ai montré que Darktable fonctionnait. Vu comme ça c’est super excitant. Ça a l’air de marcher et tout. Certains pourraient être tentés de livrer ça sur la base de ces images et autres témoignages. En fait il y a d’énormes limitations, par exemple le compilateur ne sait pas encore gérer les appels de fonctions donc toutes les fonctions sont “inlinées”. Le premier benchmark de LuxMark marche parce que le code est simple, mais prend le deuxième et 20h après le compilateur OpenCL compile encore sur ton Ryzen de compétition et le process te bouffe 70Go de mémoire. Alors ici ça va peut-être pas flinguer ton matos (mais qui sait?), mais tu vas possiblement paniquer ton kernel ou juste voir ton PC planter par manque de ressource. Mais qui sait tout ça ? Le développeur qui sait précisément là où il en est dans son code, et là où il n’est pas. Comment moi je sais ça ? Parce que je discute avec le développeur, je teste ce qu’il produit, lui fait des rapports sur mes tests, il corrige en fonction de mes rapports, etc.

      J’imagine que les gens d’Asahi ont aussi plein de trucs qu’on ne peut pas savoir si on n’est pas avec eux à chaque étape. Ils font des jolies démos, ils montrent le travail accompli, et PAF ils voient leur code hautement expérimental qui n’est pas beaucoup plus qu’une preuve de concept être distribué par un tiers comme un produit “releasé”, et sans même s’être enquit d e quoi que ce soit avant… Et ce tiers est genre un inconnu qu’ils ne voient jamais ? Comment pourrait-il savoir ce qu’il fait ? Il ne peut pas savoir ce qu’il fait, c’est impossible.

      Récemment j’ai découvert cette page : https://dont-ship.it/

      Il y a des arguments intéressant. Ils précisent bien qu’il n’y a pas de problème à ce que les gens aient envie d’essayer des trucs.

      Mais là on a des gens qui font essayer à d’autre ce qu’ils n’ont pas développés et les autres (ceux qui essaient) n’ont pas l’initiative de l’essai. Les testeurs n’ont ni l’initiative du développement ni l’initiative du test. Et celui qui livre le travail du développeur au testeur ne communique pas avec le développeur sur les risques et les manières de livrer ça au testeur, et il n’est pas clair dans sa communication auprès du testeur non-plus (à part dire que c’est tout neuf tout beau).

      Un des arguments avancés c’est notamment que les projets amonts qui souffrent de la mauvaise réputation que font les utilisateurs trahis par les intermédiaires. Ceci peut pousser les développeurs à cessent de travailler de manière ouverte et transparente.

      Et au delà de ça il y a un vrai problème concernant le fait que, non, s’il y a une vidéo, une copie d’écran, un tweet d’émerveillement concernant une étape atteinte dans un produit en cours de développement, non ce n’est pas livrable.

      Je donne un autre exemple : Le moteur Dæmon qui propulse le jeu Unvanquished est un descendant du moteur XreaL. Il y a dix ans, les développeurs d’XreaL avaient montré des vidéos excitantes de fonctions en cours de développement. Depuis, il y a quelqu’un qui passe de temps en temps pour nous cracher à la gueule en disant que les développeurs ne savent pas ce qu’ils font, qu’ils gâchent tout, etc. Qu’ils retirent des fonctionnalités, et que c’est bien la preuve de leur incompétence car ça montrent qu’ils ne savent pas comment ça marche ni le maintenir, etc. La réalité, c’est qu’XreaL était une preuve de concept. Un tas de preuve de concepts posées à côté les unes des autres (parfois même pas empilées les unes sur les autres). Chaque fonctionnalité que l’on voit dans les vieilles vidéos, en gros elle marchent mais une à la fois. T’en active deux ça pète. Aucun produit fini n’a jamais existé avec ces fonctionnalités. J’ai moi-même terminé l’implémentation d’un code qui avait été incorporé à l’état de brouillon il y a dix ans et jamais touché depuis : le code des “heightmaps”. Un point qui montre que c’était une preuve de concept c’est que la carte codait la hauteur si la donnée était stockée dans un fichier à part et codait la profondeur si la même donnée était stockée dans un fichier stockant d’autres données. Et si on activait la fonctionnalité, toute absence de canal alpha dans une image était interprétée comme une profondeur maximum (!!!), ce qui avait poussé le développeur de la preuve de concept à implémenter un mot-clé (à écrire pour chaque image !!!) pour « empêcher de lire l’absence de canal alpha » (lol) pour contourner le bug du bug du bug. Bref. Les copies d’écrans et vidéos étaient séduisantes. Mais entre le jour où les vidéos ont été faites (ou même des démos jouables distribuées) et le jour 10 ans plus tard où j’ai transformé le code depuis l’état « preuve de concept qui pour marcher demande d’enregistrer les données de manière incorrectes et de configurer chaque données pour dire au moteur de faire une autre erreur qui annule la première » en implémentation correcte, j’ai pourtant été témoin années après années des plaintes disant que les développeurs étaient incompétents et qu’ils supprimaient des fonctionnalités qui marchaient avant, que tout marchait avant, etc.

      Et d’ailleurs pendant dix ans j’ai vu quelqu’un promettre ce genre de tas de preuve de concept à des gens en leur vantant monts et merveilles, pour les laisser dans la désillusion amère quelques années plus tard, recommençant la montagne russe émotionnelle avec des nouvelles victimes toutes les X années. Il y a des gens comme ça, qui se placent entre les développeurs amonts et les utilisateurs, qui ont d’ailleurs assez de compétence pour être un développeur amont s’ils voulaient travailler en équipe (mais ce serait inconcevable), et qui utilisent surtout ces compétences pour vendre du rêve à des victimes toujours renouvelées. Parfois ils arrivent quand même à livrer des choses vraiment intéressantes avec des gens satisfaits quand même, parfois ils ne laissent que de la souffrance, et dans tous les cas les développeurs amonts sont dénigrés, ignorés, voire calomniés avec des ribambelles d’utilisateurs indirects biberonnés à du dénigrement, si ce n’est de la haine ou du mensonge envers les développeurs amont.

      Je ne connais pas Manjaro, je ne sais rien de plus que le fait qu’ils auraient distribués une preuve du concept sans concertation avec le projet amont, je ne dis pas qu’il y a plus grave comme ce que j’ai dit avoir vu dans d’autres projets. Mais je comprends tout à fait que cet évènement cristallise les souffrances de plein de gens, et pas forcément à cause de leur implication dans les projets en question, mais aussi à cause de leur propre expérience dans d’autres projets. Et ça ressemble quand même au schéma de l’équipe qui vend du rêve sur le travail des autres en se plaçant comme intermédiaire opaque et mettant ses utilisateurs à risque (ne serait-ce qu’au risque de la déception, du découragement et autres poisons émotionnels).

      En général quand il y a quelqu’un qui livre à des utilisateurs le travail d’un autre sans concertation avec un autre et que ça devient constitutif de la méthode de travail, il y a rapidement d’autres trucs bien toxiques qui couvent et font surface de façon pas très honnêtes. Par exemple, l’absence de communication avec l’amont, si elle s’installe, devient du passif-agressif, passif-agressif qui devra être rationalisé pour être supportable par son acteur, et donc rationalisé en calomnies ou en haine ou autres choses justifiant a postériori l’absence de communication. Quand bien même à la base l’absence de communication n’était motivée que pour se présenter comme un sauveur et satisfaire un besoin narcissique par exemple, sans aucune haine ni calomnie ni malveillance initiale envers les autres.

      Des gens qui vivent ce genre d’expérience, il y en a beaucoup en fait. Peut-être que Manjaro paie pour les autres, à cause du motif, du “pattern”. Mais ça ne m’étonne pas que ce petit fait divers soit en train de popper dans plusieurs de mes flux d’informations à la fois. Marmite, vapeur, pression, toussa. Ça aurait pu être un autre déclencheur.

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: twit ?

        Posté par  (Mastodon) . Évalué à -4.

        Personne n'oblige les developpeurs d'Asahi de publier leurs branches les plus expérimentales sur internet non plus hein. Git c'est décentralisé. Ce n'est pas comme si ils ne peuvent pas avoir une QA avec un passage en branche publique uniquement quand le code a été sujet à des tests sur les plateformes hardware supportées.

        Tu crois que toutes les distros envoient un mail au développeur de chaque bout de code, librairie, petit utilitaire avant de fournir un paquet? Tu crois que c'est une méthode de fonctionnement valable? Moi je serais le dev de la lib trucumuche, ça me gaverait de recevoir 50 emails de ce genre.

        • [^] # Re: twit ?

          Posté par  . Évalué à 5.

          Tu crois que toutes les distros envoient un mail au développeur de chaque bout de code, librairie, petit utilitaire avant de fournir un paquet? Tu crois que c'est une méthode de fonctionnement valable? Moi je serais le dev de la lib trucumuche, ça me gaverait de recevoir 50 emails de ce genre.

          Bonjour sophisme.
          Comparer une lib ou un petit utilitaire à un chantier de reverse engineering produisant un ensemble de patchs au noyau, y compris un nouveau pilote DRM en Rust, et une autre pelletée de code dans Mesa et ailleurs…

          • [^] # Re: twit ?

            Posté par  (Mastodon) . Évalué à 0. Dernière modification le 04 octobre 2022 à 10:39.

            Ça ne change rien. De toute manière si tu achètes un Mac pour y installer linux dessus, c'est que t'aimes faire des trucs expérimentaux et que t'acceptes un certains nombre de risques.

            Tout ça c'est juste un problème d'ego, à chaque fois l'emphase est sur la réputation du developpeur.

        • [^] # Re: twit ?

          Posté par  . Évalué à 3.

          Donc, tu es pour que les gens ne publient leur code pour les autres puissent le commenter avant qu'il ne soit complètement fini ? Perso, je préfère largement qu'ils publient du code instable avant qu'il ne soit utilisable.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: twit ?

            Posté par  (Mastodon) . Évalué à 1.

            Donc, tu es pour que les gens ne publient leur code pour les autres puissent le commenter avant qu'il ne soit complètement fini ? Perso, je préfère largement qu'ils publient du code instable avant qu'il ne soit utilisable.

            Moi aussi, mais je préfère qu'ils ne pleurnichent pas si leur ego est blessé parce que quelqu'un a l'audace de l'utiliser et qu'ils ravalent leur fierté. Et s'ils n'en sont pas capables ils savent quoi faire.

        • [^] # Re: twit ?

          Posté par  (site web personnel) . Évalué à 10. Dernière modification le 04 octobre 2022 à 13:12.

          J’ai lié ça, je vais en citer des bouts : https://dont-ship.it/

          Personne n'oblige les developpeurs d'Asahi de publier leurs branches les plus expérimentales sur internet non plus hein. Git c'est décentralisé. Ce n'est pas comme si ils ne peuvent pas avoir une QA avec un passage en branche publique uniquement quand le code a été sujet à des tests sur les plateformes hardware supportées.

          Réponse pré-existante :

          “It discourages developers from working on new features publicly, something we care about a lot in the Free and Open Source Software community. It also frustrates developers, and in some cases, causes developers to stop supporting a distribution altogether. In this scenario, the end user gets the worst of both worlds: a broken distribution and developers who are unwilling to help.”

          « Cela décourage les développeurs de travailler publiquement sur de nouvelles fonctionnalités, ce qui nous tiens à cœur dans la communauté des logiciels libres et open source. Cela frustre également les développeurs et, dans certains cas, les amène à cesser complètement de soutenir une distribution. Dans ce scénario, l'utilisateur final subit le pire des deux mondes : une distribution cassée et des développeurs qui ne sont pas disposés à aider.

          Là tu prends la posture du saboteur pour le seul bénéfice de gagner un débat sur un forum Internet.

          Tu crois que toutes les distros envoient un mail au développeur de chaque bout de code, librairie, petit utilitaire avant de fournir un paquet? Tu crois que c'est une méthode de fonctionnement valable? Moi je serais le dev de la lib trucumuche, ça me gaverait de recevoir 50 emails de ce genre.

          Réponse pré-existante :

          “In short: when a project is being actively developed, tagged releases are the only safe option to ship to users.”

          « En bref, lorsqu'un projet est en cours de développement actif, les versions taggées sont la seule option sûre pour la distribution aux utilisateurs. »

          Bienvenue à l’homme de paille. C’est toi qui prétends qu’il n’y a pas de graduation dans le traitement du code des autres.

          Pas besoin de contacter un développeur si c’est clairement marqué comme prêt pour la publication. On parle ici de code en cours de développement dont une bonne partie relève probablement de l’essai & erreur.

          Tu remarqueras qu’ils ne disent pas « la seule option », mais « la seule option sûre », c’est à dire l’option qui peut-être choisie les yeux fermé et donc sans interaction. Si tu sors des pistes, bien sûr t’es libre, mais tu peux te mettre à risque ou mettre les autres à risque, c’est mieux de s’y initier avec quelqu’un d’expérimenté dans le hors piste et dans ce terrain en particulier. Surtout qu’ils sont probablement disposés à aider, et peut-être même enthousiastes à cette idée.

          Mais au final tu démontres précisément ce que je relevais : tu ne fais aucune différence entre un code en cours de rédaction et un code vérifié, relu, revu, validé, committé, releasé.

          Sachant que même un code en cours de rédaction a plusieurs niveau, ça peut-être un code qui suit une documentation adaptée, qui réécrit un code existant et éprouvé, ou qui, comme ici, explore un terrain qu’aucune personne ne peut témoigner avoir exploré avant.

          Comme je disais : C’est un variante de « si c’est sur Internet c’est pour être utilisé » : « si c’est sur Internet c’est que c’est prêt pour la production ».

          Si tu supposes qu’il n’y a pas de différence et que tout code publié est distribuable, cela dit que tout code publié est prêt pour la production, et donc que tout code publié doit être prêt pour la production, cela interdit toute collaboration sur une forge publique, et on en revient au sabotage car il s’agit ici de poser des exigences qui font obstacle à l’effort de production.

          Moi aussi, mais je préfère qu'ils ne pleurnichent pas si leur ego est blessé parce que quelqu'un a l'audace de l'utiliser et qu'ils ravalent leur fierté. Et s'ils n'en sont pas capables ils savent quoi faire.

          Bienvenue à l’homme de paille. C’est toi qui supposes que c’est une affaire d’égo.

          Ça s’appelle rationaliser une posture pré-éxistante, c’est précisément ce dont je parle dans mon commentaire précédent. Celui qui ne fait pas l’effort de communiquer avec l’amont quand c’est nécessaire ou qui défend ce genre de déséquilibre doit appaiser sa tension interne et pour se faire il doit se persuader qu’il y a une bonne raison qui empêche de le faire ou qui justifie de ne pas le faire.

          Le plus simple pour cela est de calomnier comme tu viens précisément de le faire. Tu prétends que ce sont des pleurnichards égoïstes imbus de fierté, ce faisant tu persuades les autres et te persuades que toute communication avec eux sera difficile et douloureuse et qu’ils rendent les relation sociale difficile si ce n’est qu’ils s’y opposent, et donc cela justifie de ne pas communiquer avec eux ou même qu’au final, ils sont la cause de toute absence de communication car il faut bien se protéger des gens toxiques. Distribuer leur code dans ces conditions et selon ces manières serait même un acte héroïque qui permettrait de sauver cette production de la main de ces gens problématiques, c’est être une forme de robin des bois des temps modernes qui prend aux méchants pour donner aux gentils.

          Quod erat demonstrandum.

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: twit ?

            Posté par  (Mastodon) . Évalué à -2. Dernière modification le 04 octobre 2022 à 13:49.

            De toute manière ce n'est pas parce que quelqu'un enregistre un domaine, écrit un pavé et qu'il soit signé par une dizaine de personnes que des milliards d'autres ont l'obligation d'être d'accord.

            Ça ne marche qu'à coups d'éclairs envoyé depuis les cieux sur des tablettes de pierre. Et encore.

        • [^] # Re: twit ?

          Posté par  . Évalué à 3.

          Tu crois que toutes les distros envoient un mail au développeur de chaque bout de code, librairie, petit utilitaire avant de fournir un paquet? Tu crois que c'est une méthode de fonctionnement valable? Moi je serais le dev de la lib trucumuche, ça me gaverait de recevoir 50 emails de ce genre.

          Avant chaque version de chaque paquet, non. Mais quand tu veux tester un cas un peu particulier que le dev n'a pas spécifié ? Un petit message fait pas de mal. Du genre "hey, on pensait utiliser la version de dev xyz pour notre distro, à quoi on peut s'attendre ?".

          Les devs seront les premiers à savoir à quel point c'est viable, les problèmes connus, les conflits possibles avec d'autres packages, etc.

      • [^] # Re: twit ?

        Posté par  . Évalué à 2.

        Dans le tweet, est-il dit que le code s'est effectivement retrouve en prod voire empaquete (dans une version affichee stablec hein)?
        Si ce n'est pas le cas, et compte tenu de l'age du repo (quelqu'un a dit 4 jours) alors je trouve en effet la reaction exageree.

        Quant a la "commication" j'ai fait l'effort d'aller voir le message: aucune preuve que ca ait ete release. Un lien qui indique de quoi on parle serait pourtant un minimum de respect envers les developpeurs de manjaro et les utilisateurs de twitter.

        Upstream ici ne fait qu'affirmer sans prouver, et se font passer pour les gentils dans la 2nde partie du tweet.
        Si ca se trouve, les gens de manjaro ont juste clone pour experimenter ensemble, sur une forge publique, qui comme tu le dis est faite pour developper de maniere publique mais n'est pas une prod. De la meme facon qu'il existe plus de clone de daemon que de serveurs daemon, en fait.

        • [^] # Re: twit ?

          Posté par  . Évalué à 3.

          Ils disent que ça a bien été release mais qu'ils ont supprimé par la suite
          https://twitter.com/AsahiLinux/status/1576536552515461121

          • [^] # Re: twit ?

            Posté par  (site web personnel) . Évalué à 4.

            Après, c’est Asahi qui le dit… Et ils disent « The release is still up. » mais ne mettent pas de lien.

            J’aurai à gérer ça je ferai une copie dans la web archive et je mettrais le(s) lien(s) pour sourcer.

            ce commentaire est sous licence cc by 4 et précédentes

            • [^] # Re: twit ?

              Posté par  . Évalué à 5.

              Un autre dit:

              As I see it, it got uploaded to the sourceforge manjaro-dev directory. Wouldn't call that a release…

              Donc, tous les éléments tendent à montrer que non, les devs de manjaro n'ont pas fait de release proprement dite, et perso je me dis qu'il n'y a vraiment rien de mal a tester des modules kernels pas fiables avant que tout ne soit prêt, pour des gens qui font une distro, loin de la, je dirais que c'est leur job. Par contre, faire taper l'affiche sur twitter, ça, c'est mesquin, et ça encourage les réponses hâtives, surtout quand on ne mets pas tous les éléments dans le message d'ouverture.
              D'un autre côté, si twitter était fait pour communiquer, au sens de l'échange, et non pas pour faire du sensationnel, ils n'auraient jamais eu de limite à 140 caractères.
              Un mail, ou article de blog, possiblement un tweet qui réference ledit article de blog, aurait été bien plus respectueux en permettant d'avoir bien plus d'éléments pour les lecteurs. Mais était-ce le but, d'informer? Encore une fois: twitter.

              Les autres discussions de ce journal montrent également que, non, les trucs pas stables ne sont pas jetés aux utilisateurs sans prévenir (au tout cas il est dit qu'ils ont un noyau marqué expérimental, pour ce qui a trait au noyau).

              • [^] # Re: twit ?

                Posté par  . Évalué à 3.

                Mais du coup pourquoi
                - Manjaro qu'ils se sont gourrés (j'ai pas tout compris à leur explication)
                - Manjaro dit qu'ils ont viré le kernel en question et rajouté une note pour dire de faire attention

                Bon pour les échanges sur Twitter par contre… Je suis d'accord mais c'est malheureusement devenu la norme.

                • [^] # Re: twit ?

                  Posté par  . Évalué à 6.

                  Je ne m'amuse pas a suivre twitruc, je n'avais lu que le message de début d'asahi. Mais du coup, s'ils se sont trompés (j'ai jeté un oeil rapide a ton 1er lien, mais "c'est pas super clair" pour moi non plus, pour ne pas dire que je comprend pas grand chose au laïus) était-ce utile d'afficher le problème sur la voie publique?

                  Je suis d'accord mais c'est malheureusement devenu la norme.

                  Le logiciel propriétaire est aussi une norme, ne faisons rien contre. Pareil pour le sensationnalisme.
                  J'entend bien que ce n'est pas ton propos, et que je suis un vieux con, mais bon, j'ai vraiment du mal avec ces trucs… twitter en particulier, c'est vraiment pour la com' à 2 balles "3 mots 0 pensée" qui est pour moi un vrai fléau. Même le poivrot qui maintiens le zinc du PMU d'en face utilise plus de 120 caractères quand il exprime une idée, pour dire! (on me souffle que cette règle à changé, mais l'idée reste la)

  • # Mais au fait, c'est qui Manjaro ?

    Posté par  (site web personnel) . Évalué à 2.

    Je me suis posé cette question, qui est derrière Manjaro ? J'ai cherché sur leur site, mais je n'ai pas trouvé grand chose…
    Quelqu'un a la réponse ?

    • [^] # Re: Mais au fait, c'est qui Manjaro ?

      Posté par  (Mastodon) . Évalué à 4.

      C'est marqué en bas de page: Manjaro GmbH & Co KG. En gros une SARL.

      Et tu as plus de détails sur celle-ci ici. Elle est enregistrée en Bavière et dirigée par Philip Mueller et Bernhard Landauer. De là tu peux aller sur linkedin pour plus de détails sur ces personnes.

    • [^] # Re: Mais au fait, c'est qui Manjaro ?

      Posté par  . Évalué à 7. Dernière modification le 04 octobre 2022 à 13:42.

      Philip Müller a créé une distribution communautaire manjaro il y a 10 ans
      Il y a 2..3 ans, Philip à quitté sont travail pour se consacrer à manjaro.
      Pas assez de dons, donc création d'une société qui tire ces profils de la boutique (mugs,…) et de quelques $ pour chaque machine vendue avec manjaro intégré.

      Donc ici, cette "affaire" n'a pas de lien avec la société (distincte de l'association) c'est la communauté/équipe manjaro arm qui essaye de porter son os sur le plus de machines possibles.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.