Windows has been a thorn in my side for years. But ever since I started moved to Linux on my Laptop and swapping my professional software to a cross platform alternative, I’ve been dreaming on removing it from my SSD.

And as soon as I finish my last few projects, I can transition. (I want to do it now).

Trouble is which I danced my way across multiple amazing distros, I can’t decide which one to land on since the one software I want to test, Davinci Resolve doesn’t work on my Intel Powered Laptop. (curse you intel implementation of OpenCL).

So the opinions of those of you who’ve used Davinci Resolve, Unity/Godot, and/or FreeCAD. I want it to be stable with minimal down time on hardware with a AMD Ryzen 5 1600x and a RTX 3050. Here’s the OS’s I am looking at.

CentOS (alt Fedora)

  • Pro: Recommended by Davinci Resolve for the OS, has good package manager GUI that separates Applications and System Software (DNF Dragon), Good support for multiple Desktop Environments I like. Game Support is excellent and about a few months behind arch.
  • Con: When I last installed Fedora my OS Drives BTFS file system died a horrific and brutal death, losing all of my data. Can’t have that. And I personally do not like DNF and how slow it makes updating and browsing packages.

Debain (alt Linux Mint DE)

  • Pro: The most stable OS I’ve used, with a wide range of software support both officially in the distros package manager, or from developers own website. I am most familiar with this OS and APT

  • Cons: Ancient packages which may cause issues with Davinci Resolve and Video Games. An over reliance on the terminal to fix simple problems (though this can be said for most linux distros). I personally don’t like APT and how it manages the software.

EndevourOS (alt Manjaro)

  • Pro: The most up to date OS, great for games with the AUR giving support for a lot of software which isn’t available on other distros.

  • Cons: Manjaro has died on me once, and is a hassle to setup right and keep up. EndevourOS has no Package Manager GUI, and is over reliant on the Terminal. Can’t use pacman in a terminal the commands are confusing.

OpenSUSE Tumbleweed

  • Pro: Like Fedora but doesn’t use DNF, good game support

  • Cons: Software isn’t as well supported.

  • JoshCodes@programming.dev
    0·
    8 months ago

    Not the above poster but Manjaro routinely pushes out broken packages, has had a number of issues with security (not renewing their tls certificates for their website) and is all around not stable. Arch is a predictable unstable, manjaro is an unpredictable unstable attempt at stable.

    • guywithoutaname@lemm.ee
      0·
      8 months ago

      Even if packages weren’t broken, the fact that they make it easy to use the AUR is problematic because the AUR expects the latest packages from the Arch Repos. Often, AUR packages will break on Manjaro for that reason.

      • JoshCodes@programming.dev
        0·
        8 months ago

        Personally, no, i havent used manjaro in years. However, it’s frequently spoken about problem in the community so im sure someone else can help you. Or you could look up people talking about it.

        • someonesmall@lemmy.ml
          0·
          8 months ago

          I’m asking because I’ve used Manjaro for the last 5 years without problems. I think a lot of arguements against Manjaro here are just based on “that’s what I’ve read somewhere”.

          • JoshCodes@programming.dev
            0·
            8 months ago

            Fair enough. I used to use Manjaro and it broke, cannot remember why. I moved to ubuntu sometime later and I’ve never left. Some would say that makes me a bad linux user, I would say I use an operating system that gets out of my way and let’s me use it. Use whatever tool gets the job done fastest!

    • elfin8er@lemmy.world
      0·
      8 months ago

      Found this file by user “arindas” on GitHub which seems to highlight a lot of the issues that I’ve been seeing. To summarize:

      Package Management

      Manjaro maintains a separate repository that is not in sync with Arch’s main repositories which means Manjaro is not just Arch. To add to that, even Manjaro wiki states that it is not Arch!

      Source: https://wiki.manjaro.org/index.php?title=Manjaro:_A_Different_Kind_of_Beast

      Manjaro claims to be stable just by delaying packages for a week. This is not an approach a stable distribution would take at all!

      Say that a package in the AUR depends on a library, say libxyz. And libxyz is in the main repos, not in the AUR. The package is updated so that it relies on the new features introduced in libxyz’s version 1.1 however Manjaro delays packages so libxyz is still on 1.0 in Manjaro. If you update the package in Manjaro, it will break because Manjaro holds back packages. So the only way Manjaro can be stable is by literally forking all the Arch related repositories including the AUR and keeping them in sync.

      However it is important to note that often these problems are isolated to single packages and not the system as a whole. Please read #25 (comment) for additional context.

      Security

      The Manjaro system updater used to have a serious security vulnerability [in 2018] which has fortunately been fixed.

      Source: https://lists.manjaro.org/pipermail/manjaro-security/2018-August/000785.html

      This is actually a core package, not an extra or community package. To quote the list,

      I have discovered an issue with one of your core Manjaro packages, manjaro-system 20180716-1 and earlier. The issue allows a local attacker to execute a Denial of Service, Arbitrary Code Execution, and Privilege Escalation attack.

      In an update, password less updates in pamac (Manjaro’s AUR helper) were sneaked in and from the look in the issue made concerning this, the change was made to look like a “feature”. This is a major security issue considering that packages in AUR are not checked by Arch Linux maintainers (and Manjaro does not maintain its own either). Some AUR packages were found to be malware in the past. So think about a casual user (Manjaro’s target demographic are not really power users) installing a harmless-looking AUR package that could potentially mess up their system!

      Source: https://gitlab.manjaro.org/applications/pamac/-/issues/719

      The post also mentioned an issue where the Manjaro updater used bad practices when updating packages such as using the no-confirm flag. This appears to have been fixed from what I can tell.

      Manjaro let their SSL certificates expire not once, not twice, not thrice, but four times! The first time [2015], they asked the users to use a private window and/or change the system time.

      Source: https://web.archive.org/web/20150409095421/https://manjaro.github.io/expired_SSL_certificate/

      Changing the system time could have unintended consequences such as with cron jobs not running at the intended time. It’s also not a best security practice to use an incognito window to bypass the SSL expiry alert. The correct solution is to not let the certificates expire in the first place, which is not difficult and is done by all secure websites.

      The second time when the SSL certificates expired [2016], they did the same.

      Source: https://web.archive.org/web/20160528135123/http://manjaro.github.io/SSL-Certificate-Expired/

      This time the Manjaro developers didn’t recommend changing the system time, but they still recommended creating an exception for the Manjaro website.

      The third SSL certificate expiration was handled a little more sanely [2021].

      Source? https://web.archive.org/web/20220102232338/https://forum.manjaro.org/t/expired-certificate-for-iso-download-on-download-manjaro-org/96441

      The fourth time, HSTS was set but the website was still down [2022].

      Source: https://web.archive.org/web/20221013234550/https://manjarno.snorlax.sh/expiry-2022-08-17.png

      Sending Unexpectedly Large Traffic volume to AUR

      I think some of the dates and sources in this section were wrong, but I did my best to correct them.

      On 2021-04-26, the AUR (Arch User Repository) faced a huge web traffic spike from pamac clients, caused by a bad version of pamac, which is the default Graphical Package Manager for Manjaro

      Source: https://gitlab.manjaro.org/applications/pamac/-/issues/1017

      Manjaro developers have developed thorough technical solutions to mitigate the huge traffic spike from pamac installations [2021-10-02]. They have outlined the steps taken here #25 (comment)

      Source: https://gitlab.manjaro.org/applications/pamac/-/issues/1161

      On 2021-10-14, Pamac was once again blocked by the AUR for shipping another version that flooded the AUR with requests. However the updated version itself was meant to mitigate problems.

      Source: https://gitlab.manjaro.org/applications/pamac/-/issues/1135

      Additional sources: https://www.reddit.com/r/linuxquestions/comments/wqzrpl/did_manjaro_just_forget_to_renew_the_ssl/ https://www.reddit.com/r/linux/comments/q85t8n/deleted_by_user/