Why are so many people suddenly worried about down votes? They don't matter. You get nothing for a lot of upvotes, and you get nothing for a lot of downvotes. If you're so concerned about votes, I think that's a serious issue that you need to overcome, or you're going to have a very hard time in life.
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.
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.
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.
That’s not how source packages work. The only way they’d break is in case of major upstream changes. Which do happen, but the only inconvenience would be recompiling the package. Which you’re supposed to do anyway.
Do you reinstall your AUR packages after an update? If yes, you will never see them break on Manjaro or Arch. If you don’t, they will break on both Manjaro and Arch.
I am not theorizing. And I am not taking about source code not compiling. I am talking about dependencies which includes the reports version numbers and version number expectations of packages maintained by different parties. Those broke all the time for me on Manjaro and it was often because of the differences between what was in the Arch repos vs the Manjaro repos.
When Manjaro fell behind at one point, I ended up with a version of GEGL ( labeled - git ) being pulled from the AUR. Later releases of GIMP refused to upgrade over that version of GEGL. I just lived with it for a few months hoping it would clear itself up but it never did. I basically had to back everything my out and install again. Not that it was hard but these kinds of annoyances happened for me all the time on Mnajaro and basically never on EbdeavourOS or Arch.
What made me move away from Manjaro to begin with were all the problems it had with the dotnet packages at the time. I blamed dotnet and the AUR and was amazed that the problems went away when I used EndeavourOS instead.
If what you describe were true it would make AUR packages fail (on any Arch distro) if the user failed to upgrade their system each time, every time an update came out. The two week delay practiced by Manjaro is a completely arbitrary period of timen in the grand scheme of things. There are users who only upgrade once a month or even more seldom and nothing like this happens to them.
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.
I am not the most technically astute person, using Manjaro and the AUR for like five years and never had my system break. Yes, some package problems here and there, but where do you not have them ever? And so far nothing an internet search couldn’t fix. I found it very stable both in the XFCE and the KDE spin.
if your use the AUR with Manjaro, your system will break.
If your system breaks because of AUR it means you’re using AUR wrong… you’re not supposed to use AUR packages for critical system functions. It will break on Arch too if you do that.
For a total newbie, Linux Mint or PopOS are probably the best options. But EndeavourOS is getting there. There shouldn’t be any issues during the installation if one sticks to the defaults. Only thing is, it doesn’t come with a graphical package manager out of the box. But once that is installed (I think anyone will be happy to write a single terminal command, at least), I don’t see why it’s any harder to use than any other distro.
Mint, with any DE, does come with a graphical package manager. It’s as easy as any appstore. The only confusion is it suggests both it’s original and flatpack versions to install.
Reading it in a linear fashion, you drop one distro after another without much distinction. I believe it’d be better if you serve EndOS it’s own paragraph since it’s so different.
Plasma Panels have now gained a new visibility mode: “Dodge Windows” aka “intelligent auto-hide!” In essence, the Panel auto-hides when touched by a window, but is otherwise visible
Finally! With this, we can now have a panel behave like a proper dock.
I’ve tried running Plasma 5 on Wayland occasionally but due to having NVIDIA card there’s always been bigger or smaller annoying issues so I always reverted back to X11.
Looking forward to try out Plasma 6 as soon as it’s released!
i have a rtx3080ti and am using KDE plasma 5 wayland on Fedora 38(now 39) exclusively for gaming. i made the switch to wayland a month or so ago and i am having a considerably smoother experience than x11. especially with multiple monitors and flatpack apps like discord in the mix.(steam is running native though). no issues that i am aware of so far
Meanwhile Wayland absolutely hates my year old AMD laptop. It hangs itself on a regular basis, some applications go completely unresponsive every so often to the point they need to be kill -9’ed. Rock solid when running X11, completely unreliable in Wayland. It’s a shame, I want to like Wayland as I think there is no future for X11, but as it stands currently I simply cannot use it yet for my day to day business.
Just tried it yesterday. It is a LOT more smooth for me, but it can’t seem to handle 144hz. I turned it down to 60hz and it seems to be going well for now. I can live with this I think.
I’ve tried running Plasma 5 on Wayland occasionally but due to having NVIDIA card there’s always been bigger or smaller annoying issues so I always reverted back to X11.
Yeah, I tried it again this morning and got a black screen with mouse trails. I also have an Nvidia card and will give it another go when Plasma 6 comes out.
In the meantime please share that these issues exist on nvidia forums. Issues caused by nvidia drivrers shouldn’t come under the purview of the kde devs.
Exiting news! Can’t wait for final release to hit the repositories!
Yesterday I gave Wayland another try on Plasma 5 using the latest NVIDIA drivers, but unfortunately there were several visual glitches and the panel stopped updating itself :(
Same. Really wanted to give Wayland a chance, but having artifacts on blurry windows where the cursor was is just too annoying for me. Plasma team is already aware of the issue but said it’s too huge of a change for 5.x
To be honest, X11 is not terrible, even with multiple monitors with different refresh rates. I’m running 2x 60Hz and 1x 144Hz without any problems on X11.
Yeah I mean I get C-states for things that idle a lot, like homeservers, but i still don’t see the reasoning for outright replacing traditional suspend on computers. Now you have to worry if some random pcie device is going to up your consumption by 5 watts during suspension. Well, at least that’s only a big issue on laptops.
With a bit of modifying code to use the color picker and maybe rearranging the workflow to adapt to the new system, apps as advanced as DaVinci Resolve and LibreOffice can have permissions as restrictive as this (the network permission would of course may be needed but it would still be marked as Safe by Flathub).
You can use the file picker API to open the files or folders your app would need to access while having no filesystem permissions at all. You can access the camera, microphone, and GPS without the user devices portal, by simply using the respective portals where the user has the power to allow or deny access to such devices as they wish.
You can record the screen, take a screenshot, and pick a color in the screen by simply calling the proper portals, with the bonus that the user will be able to select if they want the entire screen, a specific window, or a specific area to be recorded/captured and whether the cursor should be shown or not.
Heck, even TeamViewer can be as this restricted without losing any functionality if they use the Screen Cast portal which allows apps to mirror input from a remote device! They would of course need the network permission, but that’s still safe.
Yes in the sense that the APIs were made because of flatpak, but not in the sense that devs would need to keep two separate code paths for flatpak vs non-flatpak - portals work everywhere.
This kind of thing could work for a few apps, say a color picker utility or a QR code generator etc.
Looking at the docs, it isn’t clear if apps can write to their own namespace (instead of writing to user folders directly), but if they can, we could expand the scope to games like supertuxkart, 2048 etc, which would then be able to save user milestones and progress in their own area - a bit like how Android apps do it
It’s a great start IMO, although admittedly there is still work to do. Flatpak atm bridges the gap with allowing new apps, requiring new libs, to run on older stable/LTS distros
Yes, they can. There are app-specific folders in .local that flatpaks can read and write to specifically for this purpose, and also the file picking dialog may give access to the one specific file you picked.
Android IMO has great usability in exposing a database to apps, which means they aren’t required to ship their own database engine.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.