So I've been iso live testing Manjaro KDE Plasma lately and it looks very polished.

On the other hand, there is a negative vibe towards it.

Why the hate?

  • LeFantome@programming.dev
    ·
    9 months ago

    I used to be a huge Manjaro fan. There were many ways it let me down, some of which were just bad governance.

    The biggest problem though is the AUR. Manjaro uses packages that are older than Arch. The AUR assumes the Arch packages. This, if your use the AUR with Manjaro, your system will break.

    It is not a question of if Manjaro will break but when. Every ex-Manjaro user has the same story.

    For me, EndeavourOS is everything that Manjaro should be.

    • Raccoonn@lemmy.ml
      ·
      9 months ago

      Endeavour is basically Arch but with bling out of the box & an easier installer....

    • Samueru@lemmy.ml
      ·
      edit-2
      9 months ago

      The AUR doesn't assume arch packages, if the package your aur script wants isn't in your repo then the package simply fails to update/install.

      Edit: This is true even for Arch linux, as the Aur package might be out of date.

      • ShortN0te@lemmy.ml
        ·
        9 months ago

        The AUR doesn't assume arch packages, if the package your aur script wants isn't in your repo then the package simply fails to update/install.

        Edit: This is true even for Arch linux, as the Aur package might be out of date.

        The problem is not the package. It is the packages Version. If you have for example an application that depends on .net 7.0 and arch updates it to the latest 8.0 then the AUR usually gets updated soon as well. Now the AUR pqckage depends on the newer 8.0 Version while manjaro still has the 7.0 version. The programm now does no longer start on manjaro.

      • LeFantome@programming.dev
        ·
        9 months ago

        There are many cases where Manjaro causes problems. For example, a package mag already be in Arch but not yet in Manjaro. Or perhaps the Manjaro package is not a high enough version number. If another Arch package requires this first package, in Arch it would grab the Arch package. The Arch package will be maintained over time. In Manajaro, the package is not there and so the AUR grabs it from the AUR as well. Perhaps it is even the Git version with an unclear version number. Over time, the AUR dependency breaks or becomes unmaintained. Even once Manjaro has the package, it may not migrate it because of the version numbers. Now things are broken. This exact thing happened to me on Manjaro where my GIMP ended up using GEGL from the AUR. My system was broken for months.

        An even worse problem can happen when there are alternate dependencies. Sometimes in the AUR you will have multiple packages that fulfill a dependency. In Arch, you can see if one is from the actual repos and one is itself from the AUR. Again, if you choose the one in the repos, it will work and stay supports. In Manjaro, neither may be coming from the actual repos in which case it is easy to choose the wrong one. This sets you up to have package conflicts. In Manjaro, I would never know that the other option had now been added to the repos. More than once, I had the dependency that I had chosen break when the other would still have been fine.

        Ok, this is getting long and that was just a couple of scenarios.

        Suffice it to say, when I used Manjaro, I got the impression that the AUR broke all the time and that using the AUR broke my install from time to time. Now that I use Arch, I do not have those issues and I realize that it was Manjaro all along.

        • Samueru@lemmy.ml
          ·
          edit-2
          9 months ago

          the package is not there and so the AUR grabs it from the AUR as well. Perhaps it is even the Git version with an unclear version number

          You will see that the aur package will use a git version and you will also be asked to remove the conflicting package when you are installing a git version.

          And once again, this isn't unique to manjaro, on my arch install yuzu broke because they were using dynarmic from the aur instead of using the one provided by yuzu itself.

          Also gimp and gegl are already on both the arch and manjaro official repos, If you are using git packages and you don't update them lots of things will break regardless if you are on any arch distro.

          Now I wonder if pamac checks for updates of git packages by default, because your git packages will not be updated unless you explicitly tell yay to do so (yay --devel) I think paru every does it automatically with every update but then again most people will use yay instead.

          Suffice it to say, when I used Manjaro, I got the impression that the AUR broke all the time and that using the AUR broke my install from time to time. Now that I use Arch, I do not have those issues and I realize that it was Manjaro all along.

          My experience has been quite the opposite, a few months ago my install broke to the point that I could not update the system, turns out it was because of the arch migration and my system wasn't incorporating the new pacman.conf.new.

  • NoisyFlake@lemm.ee
    ·
    9 months ago

    There's not really any benefit of running Manjaro over Arch, it will only introduce problems over time. If you want a "pre-configured" Arch with a nice installer, go for EndeavourOS, it's great!

  • buckykat [none/use name]
    ·
    9 months ago

    My personal negative vibe toward Manjaro comes from my own experience with updates breaking things when I was running it

  • RubyWitch@lemmy.sdf.org
    ·
    9 months ago

    Real reason for the hate: The Linux community is overly focused on tribalism and has a console-wars mindset where what I'm using is obviously the best and everything else must be flawed and terrible. Manjaro is probably fine for most use cases.

    ...although I'd still suggest just using base Arch instead. :)

  • GreyFalcon@iusearchlinux.fyi
    ·
    9 months ago

    I have manjaro running on six machines. No problems that were not Just part of learning. Two of those computers were for testing different distros.... All ended up with Manjaro.

    Hate is for people that don't create, or improve their own world.

  • highduc@lemmy.ml
    ·
    edit-2
    9 months ago

    It's not all "purists" and "tribalism", Manjaro actually has issues. Besides the well known certificate issues and older packages, I have the following anecdote which made me really dislike it.

    A friend has Manjaro and one day his nvidia drivers stopped working after an update. I helped troubleshoot over the phone, while looking over the wiki. For nvidia drivers they have their own wrapper around pacman.

    Turns out there's a different nvidia driver for each kernel version. Already a stupid design. So unlike arch where there's 1 kernel package (the latest the distro offers) and 1 matching nvidia driver, Manjaro has dozens...

    The wiki never mentions how to install or update the drivers manually with pacman or anything like that. It pushes their own tool, a stupid wrapper around pacman, which is supposed to manage this for you.

    In my friend's case, the tool failed. It was trying to run pacman but there was a conflict issue. But the tool didn't show the pacman output, so we couldn't figure out what the tool is trying to do, and why it doesn't work. We tried removing the tool and re-installing, and all kinds of messing around with it. It failed to install the drivers, it failed to remove the drivers, it kept failing whatever we tried.

    Eventually we figured out the naming convention they used for the packages (again not mentioned in the wiki), and manage to install the correct kernel - driver pair manually, using pacman.

    Tl;dr: poor design, bad documentation, and they push their own crappy tools which hinder instead of helping

    • Atemu@lemmy.ml
      ·
      9 months ago

      there’s a different nvidia driver for each kernel version. Already a stupid design

      That's not a stupid design at all. A nvidia kernel module artifact is only compatible with exactly one kernel ABI. Thus you need one binary nvidia package for each kernel you ship.

      Arch also has one package for every kernel ABI they ship: nvidia and nvidia-lts.
      Though it should be noted that their design assumes that these two ABIs are the only possible ABIs which isn't strictly the case as the zen, hardened or RT variants may sometimes lag behind their regular counterpart. That's a stupid design if anything as it increases the friction of kernel ABI upgrades as a kernel package maintainer.

      We at NixOS also ship the nvidia module for each of our ~50 kernel variants; all major versions of the Nvidia module compatible with that kernel in fact.
      The only possible way to access these nvidia kernel modules is via a certain kernel's linuxPackages attribute set that contains all packages that rely on a kernel ABI such as kernel modules or packages like perf. That's good design if you ask me but I'm obviously biased ;)

      • highduc@lemmy.ml
        ·
        9 months ago

        I know you need a new nvidia driver every time the kernel updates, but why keep 50 kernel versions? My beef was them offering so many (outdated) versions instead of keeping the latest one which would make things very simple for users (imo).

        • Atemu@lemmy.ml
          ·
          9 months ago

          These aren't all versions per se but mostly variants, versions and versions of variants. For example, we have packaged the xanmod kernel which is a modified kernel optimised for desktop use but it has two variants: Main and LTS. We have packaged both.

          Here are the names of all of our kernels currently to give you an idea (as a JSON list):

          [
            "linuxPackages",
            "linuxPackages-libre",
            "linuxPackages-rt",
            "linuxPackages-rt_latest",
            "linuxPackages_4_14",
            "linuxPackages_4_19",
            "linuxPackages_4_19_hardened",
            "linuxPackages_4_9",
            "linuxPackages_5_10",
            "linuxPackages_5_10_hardened",
            "linuxPackages_5_15",
            "linuxPackages_5_15_hardened",
            "linuxPackages_5_18",
            "linuxPackages_5_19",
            "linuxPackages_5_4",
            "linuxPackages_5_4_hardened",
            "linuxPackages_6_0",
            "linuxPackages_6_1",
            "linuxPackages_6_1_hardened",
            "linuxPackages_6_2",
            "linuxPackages_6_3",
            "linuxPackages_6_4",
            "linuxPackages_6_5",
            "linuxPackages_6_5_hardened",
            "linuxPackages_6_6",
            "linuxPackages_custom",
            "linuxPackages_custom_tinyconfig_kernel",
            "linuxPackages_hardened",
            "linuxPackages_latest",
            "linuxPackages_latest-libre",
            "linuxPackages_latest_hardened",
            "linuxPackages_latest_xen_dom0",
            "linuxPackages_latest_xen_dom0_hardened",
            "linuxPackages_lqx",
            "linuxPackages_rpi0",
            "linuxPackages_rpi02w",
            "linuxPackages_rpi1",
            "linuxPackages_rpi2",
            "linuxPackages_rpi3",
            "linuxPackages_rpi4",
            "linuxPackages_rt_5_10",
            "linuxPackages_rt_5_15",
            "linuxPackages_rt_5_4",
            "linuxPackages_rt_6_1",
            "linuxPackages_testing",
            "linuxPackages_testing_bcachefs",
            "linuxPackages_xanmod",
            "linuxPackages_xanmod_latest",
            "linuxPackages_xanmod_stable",
            "linuxPackages_xen_dom0",
            "linuxPackages_xen_dom0_hardened",
            "linuxPackages_zen"
          ]
          

          (Note that some of these are aliases; linuxPackages_latest is currently linuxPackages_6_6 for example.)

          Each of these has the following nvidiaPackages (modulo incompatibilities):

          [
            "beta",
            "dc",
            "dc_520",
            "latest",
            "legacy_340",
            "legacy_390",
            "legacy_470",
            "production",
            "stable",
            "vulkan_beta"
          ]
          

          (Again, some of these are aliases.)

          This is useful to have because users might have hardware constraints. It's not hard to imagine a scenario where a user might have a WiFi chip that only works with kernel ABIs < 5.4 and require the 470 nvidia driver for their old GPU. Packaging just the latest kernel and just the latest Nvidia driver would make this user unable to use their system.

  • terminhell@lemmy.dbzer0.com
    ·
    9 months ago

    Just give it a go. I used it for years, and had relatively little issues tbh. Most of them I think are hardware related as I'll have similar issues in other distros and even windows.

    The devs have done some goofs yes. Things like letting certs expire, and as mentioned already, potential issues with aur. But, I remember having aur issues even with vanilla arch in the past.

    Using fedora currently though, and I don't think I'll switch anytime soon.

  • CrypticCoffee@lemmy.ml
    ·
    9 months ago

    I've had it break many times during update. Don't get me wrong, I liked it at first, but if you want a system that works after update, you're probably better checking elsewhere. Linux Mint, and Kubuntu are far better simplicity wise. Open Suse or Arch if you want rolling updates.

  • PureTryOut@lemmy.kde.social
    ·
    9 months ago

    The real question is, why are you considering Manjaro in the first place? What does it do that a different distro, without all the hate (which I personally think are 100% justified), doesn't do? Why "risk" it?

    • WeAreAllOne@lemm.ee
      hexagon
      ·
      9 months ago

      I'm an openSuse user for quite some time without any issues tbh. Just wanted to enter the Arch world and see if there is any significant difference.

      • PureTryOut@lemmy.kde.social
        ·
        9 months ago

        Then literally just use Arch. I don't understand why people want Arch but then install something different. If you don't want to go through the install process then it's honestly just not for you, but if you really want to try anyway give EndeavourOS a shot.

      • CrypticCoffee@lemmy.ml
        ·
        9 months ago

        I'm on OpenSuse and it's great. If you're tempted by Arch, go straight up Arch. Manjaro doesn't give any pluses here, only negatives.

      • Gaia [She/Her]@lemmygrad.ml
        ·
        9 months ago

        I would recommend reading through the first parts of the arch install tutorial, particularly the network connection through the terminal. If you're comfortable with that, the archinstall utility makes the rest of the process effortless. I've had Manjaro bork itself but not just plain arch.

  • yum13241@lemm.ee
    ·
    edit-2
    9 months ago

    https://manjarno.pages.dev

    Basically, the Manjaro team has no idea what they're doing.

    The ManjarNO sheep can fuck off to Reddit for all I care.

  • micnd90 [he/him,any]
    ·
    9 months ago

    I have been daily driving since 2018 on Manjaro + KDE. In the beginning, considering it is a rolling distro I just update the system every other week and it would break fairly often. But in reality most users really don't need to do sudo pacman -syyu unless they need certain and specific software update. That's the great thing about Linux, it is not forcing you to update like Windows update. You do update when you specifically need it and know what you want. There's barely any serious virus or security exploit for average Linux users. There are many top world supercomputers running on outdated kernels.

    If you are not chasing bleeding edge status, and update your Manjaro less regularly, say on par with Linux Mint update schedules of every 6 months or so, then it'll break less often unless you are really really unlucky.