Wayland is flawless for what it claims to do. The issue is you can't replace X Org with Wayland, you can only use Wayland combined with other software to replace X Org. This is the biggest issue with Wayland: "Wayland is a replacement for the X11 window system protocol,"[0] but you can't actually replace x11 with it. What they should have done is make sure all the features that x11 had were supported by Wayland. By this I mean user facing features like copy-paste and color management. (And if someone thinks copy paste is not secure or whatever, let there be a flag to disable it or something). But instead they wrote a specification that when implemented replaces 90% (lets say) of X11. And since there are multiple implementations of the Wayland server you cannot rely on the other 10% to be present on any given server. If they had not written a specification and just released x12, or if they sanctioned only one specification, or if they had added more features to the specification then the there would be no problem. They still have room to add more features to the specification which I hope they do.
When I was talking about switching to wayland with a colleague, who was already moved over at the time, he tried to convince me that having no copy paste is better for security.
And I, using a password manager that generates unspeakably complex passwords everywhere, was kinda stunned by that blindsightedness.
If you don't want copy and paste, use Qubes OS. That's the philosophy matching the rest of the architecture of the OS.
But as long as you have a binary named "[" on your system, don't try to convince people that you are doing it in the name of security. There is much more rotten fish to throw away before that.
The only thing that recently convinced me to give wayland another go is hyprland. Seeing all kinds of nice WM concepts being implemented in it, maybe hyprland is "the interoperability specification" we needed all along.
I'm confused, as every desktop environment and tiling window manager I've tried on Wayland has had copy-paste. There has never been a point in my Wayland experience where I had to even think about this.
You're speaking as though there is someone out there operating without that capability, when my experience has been the opposite. If that was the case you'd hear about it in every single "Wayland is bad" video, instead of the usual focus on nvidia (which I also have no issues with, even using Prime).
And here we are, those are my two cents and my experience.
I have used Linux for years, I liked the idea of defending something free and open.I absolutely love KDE and its personalization ability, it’s just exactly what I want.
Yet, I’m back on Windows, I like well defined screen, I have a 4K another one of lower resolution, to handle that well, I need Wayland, heck KDE just sometimes has less features or less solved bug on X11 now.
And at night I just want to watch one or two things before sleeping, I just need to turn my screen to my bed, and choose one the suggestions of plateforms like YouTube or Netflix with my mouse.
…Yet, sometimes I like to type something, it’s usually short so I just use and on screen keyboard program which I’ve still wait to find one that works for Wayland.
This is so dum, it’s crazy to me that we used to fly away from all the dysfunctions of Windows to go the sane Linux ecosystem to only find that is starting to look a bit absurd on that side too. And we look at the discourse of Wayland devs, they speak exactly like corporate would do.
So that and few package management breakage and I think this is also a weak point of the ecosystem, tends to break, to upgrade everything when you only need one thing, too complex too trouble shoot.We usually think we have superior technological paleform on with Linux kernel, but package management is one of the weak point IMO.
All of that pushed me outside of Linux for now.When I encounter something that looks infuriating on Windows, I just think I might see something like this on Linux.
I don't get why parts of the Linux community are so resistant to embrace AppImages and provide first class integration for them. Decent desktop integration isn't that hard.
As a user I want to download the thing and run it. AppImages provide that.
As an app developer I want to create one single package that works everywhere that users can just download. AppImages provide that.
Snap and Flatpacks are solving problems that don't need solving for most people. Shitty sandboxing that doesn't even work and makes my app slower? I don't want it.
Most software is best installed by the native package manager. For the few exception AppImages are perfects.
Personally I dislike AppImages, Snap, Flatpack, Docker, etc. for one main reason:
If an app is so hard to distribute in any other way, that to me is a red flag that the app is not up to my quality standards or otherwise violates my sensibilities in some way. On my Linux desktop, I am very much in the camp of "that which exists without my knowledge exists without my consent".
(I fully recognize that I am extreme outlier in general, and perhaps a slight outlier among Linux users. Just offering one perspective, I make no claims that this it the correct perspective for most Linux users.)
AppImage is a good distribution format, but IMO is not comparable to your system's package manager or Flatpak for that matter. For starters, when you downloads an AppImage, you are just getting the binary. Documentation, Desktop and Service files, and update tracking are all things that are missing from a vanilla AppImage deployment that your system package manager always provides (Flatpak and Snap only handle some of those sometimes).
The missing piece is perhaps some sort of AppImage installer which can be registered as the handler for the AppImage filetype. When ran it could read metadata (packaged as part of the AppImage?) and generate the support files. Ideally would also maintain a database of changes to be rolled back on uninstall and provide a PackageKit or AppStream provider to manage updates with your DE's store.
Now none of that addresses dependency duplication, but thats clearly not in scope for AppImage.
> I don't get why parts of the Linux community are so resistant to embrace AppImages and provide first class integration for them. Decent desktop integration isn't that hard.
> As a user I want to download the thing and run it. AppImages provide that.
Because Linux userspace libraries aren't designed to handle long term binary compatibility. There is no guarantee that a simple package upgrade or a simple distro version upgrade will not break things.
There is no guarantee that an Appimage will continue working 3 months later. If it relies on web communication, there is no guarantee that the application will stay secure since you have to bundle core system libraries like OpenSSL with your application (unlike Windows and MacOS).
I will even go and say especially GNU stuff is made specifically to make reasonable (imo at least 5 years) binary only i.e. closed-source software friendly distribution hard.
It is the culture adopted by all middle layer libraries and desktop environments too. The only supported form is source and every piece of software in Linux world assumes it is built as a part of an entire distro.
That's why Snap and Flatpak actually install a common standardized base distro on top of your distro or why Docker in its current form exists (basically packaging and running entire distro filesystems).
Only way to get around it is basically recreating and reengineering the entire Linux userspace as we know it. Nobody wants to do that.
Creating long term stable APIs that allow tweaking is very difficult, requires lots of experience in designing complex software. Even then you fail here and there and forced to support multiple legacy APIs. Nobody will do that unless they are both very intelligent and paid well (at the same level as an Apple, Microsoft or Android engineers). It is not fun and rewarding most of the time.
I likewise love AppImages and wish more projects used them, but I also love Flatpak. The downside of Flatpak is the overhead it takes to learn what it does, how it works, and how to manage them. If you already know container stuff like docker/podman then it isn't too bad, but it's a non-zero cost and friction.
I think most people don't like AppImages mostly because they don't provide any sandboxing. I think that's a silly reason myself, but I'm also an old, and us olds aren't terrified of using our computers like the youngs seem to be ;-). Though, other OSes are getting sandboxing for applications and Linux needs to not get left behind, so I'm glad it's being solved.
I also think fragmentation is a (valid) reason people dislike AppImage also. It's nothing wrong with AppImage specifically, but that its existence harms adoption of Flatpak by making it easy for people to not use Flatpak. Personally I see them occupying different niches. I use App Images for things like Kdenlive, Logseq, Upscayl, and UHK Agent. Those could all be Flatpaks, but developer effort matters. If devs provide an App Image build I think we should be praising them from the rooftops for caring about Linux!
Another reason is that it clashes with immutable OSes like Fedora Silverblue or SteamOS that are heavily container-based.
What I'd love to see is a tool that takes an App Image and automatically builds it into a Flatpak (possibly with predefined metadata). Flathub could easily be populated this way so that it's easy for developers/distributors to package and ship, but also Flatpak is the standard.
The Linux community is self-selected and highly opinionated on everything.
Concerning AppImages: I have no interest at all in them and although Flatpak still has its share of problems, basically all important communities adopted it (but Ubuntu).
Flatpak integrates in your system, has sandboxes, has automatic updates, shares dependencies etc.
Is Flatpak perfect or running w/o problems? Certainly not.
But IMHO AppImages add nothing over Flatpak, but lack the unified infrastructure and integration into packet managers etc.
We all would benefit from agreeing on one standard, and by now it looks like Flatpak is that one standard. So, I don't want to download random AppImages from the internet, I want a certified Flatpak which integrates with my system.
(Being a member of the Linux community for longer than most people using Linux are alive by now, of course and invetible, once Flatpak is working and established, it will be replaced by some broken other solution. :-P)
IMO AppImage fell short by not requiring upgrading support in all appimages. I don't want to have to monitor random sites for updates to my applications. So after trying to use them for a time I moved on. Currently experimenting with both flox and flatpaks as they both handle this aspect reasonably.
Loudly declaring your ignorance is not an opinion. If really cared, you would go look at the large volume of the well-thought-out complaints. But you don't.
> I don't get why parts of the Linux community are so resistant to embrace AppImages and provide first class integration for them. Decent desktop integration isn't that hard.
AppImages are good for certain use case. Recreational vehicles are also good for certain use cases. But just as a I don't live in RV parked in my garage when I'm at home, I don't use AppImages as my primary way of running locally-installed software on my main system.
> As an app developer I want to create one single package that works everywhere that users can just download.
You should just release source tarballs (or static binaries if you're not FOSS), and let the distros do their job of packaging and distributing the software. AppImages are fine to maintain in parallel for specific use cases, but I just want normal software binaries running in the OS environment I've already set up to my liking, not embedded in someone else's encapsulated runtime environment that's inconsistent in dozens of ways from my system config.
> Most software is best installed by the native package manager. For the few exception AppImages are perfects.
Exactly. But static builds are far superior to AppImage.
As a user I don't want to deal with updating all my software individually. AppImages also provide that. I would be perfectly fine with AppImage format packages being shipped through my package manager, but I don't want to download isolated software from the web when I can avoid it.
FWIW my package manager of choice is GNU Guix, which solves all of the same problems as snap and flatpak in a much more elegant way.
While I'd love to see good tooling for AppImages appear, it's just not made for it.
The fundamental problem is that AppImages are literally just an archive with a bunch of files in them, including libraries and other expected system files. These files have to be selected by the developer. It's really hard to tell which libraries can be expected to exist on every distribution, which libraries you can bundle and which ones you absolutely cannot due to dependence on some system component you can't bundle either, or things like mesa/graphics drivers. There's tools to help developers with this, "linuxdeploy" is one, but they're not perfect. Every single AppImage tutorial will tell you: Test the AppImage on every distribution you intend this to run on.
At the end of the day, this situation burdens both the developer (have I tested every distribution my users will use? both LTS and non-LTS?) as well as the user (what is this weird error? why isn't it working on my system?), and even if this all somehow works, newer versions of distributions are not guaranteed to work.
Flatpak, for all its bells and whistles, at least provides one universal guarantee: Whatever the developer tests, is exactly what the user will experience. I think this is a problem that needed solving for many people.
...it hurts a lot to say this as a longtime flatpak avoider, still always prefer distribution packaging, but I've come to accept that there's a genuine utility to flatpak, if only to cover for letting users test different versions of software easily, and similar situations that distributions just cannot facilitate no matter how fancy their package manager.
>> Snap and Flatpacks are solving problems that don't need solving for most people. Shitty sandboxing that doesn't even work and makes my app slower? I don't want it.
After using Ubuntu for years, this change made myself and many others I know switch. I've been on MX for the past two years and love it.
> As a user I want to download the thing and run it. AppImages provide that.
Yes. And no.
About 70-80% of AppImages I downloaded in the past didn't even start. 100% of my installed Flatpaks have been running fine on any distro I tried. I would love a world where Flatpak was redundant, but it very clearly isn't.
AppImages don't solve the discoverability or upgrade problem.
I'm on an immutable distribution (Fedora Kinoite) so installing native packages is discouraged. I have everything running in Flatpaks, even Steam and all games. I haven't experienced any performance impact. I think Snaps do something weird with squashfs, but Flatpaks just set up and manage symlinks to dependencies via ostree.
>>> Snap and Flatpacks are solving problems that don't need solving for most people. Shitty sandboxing that doesn't even work and makes my app slower? I don't want it.
To me that also raises the issue of Snap/Flatpacks and Wayland both handling part of sandboxing/capabilities.
Ultimately if you want to handle how your apps can be run and got resort back to lower primitive and you’re handling very different things like files acces(Snap/Flatpacks) and visual elements(Wayland) and maybe got back to the Linux kernel to handle that.
AppImages are nice as a user, but it seems the lead dev is intentionally not adding support for wayland (besides some other odd choices) so it feels like a dead end technology
Literally this. One thing both Apple and Windows have that Linux does not is, every software has an easy universal package for their respective platform. For Linux if its even in your main package manager its like whatever was "stable" in 2022 or whenever the last major version of Debian / Ubuntu came out, and that's all you get. It's annoying to no end. I now just download AppImage every chance I get.
Everything is outsourced to the compositor. It's insane. Same reason there's no xbindkeys for Wayland - every compositor needs to implement their own version of it. Every compositor needs their own screen reader and accessibility software as well. All in the name of preventing mythical attack surface (people write exploits to give themselves arbitrary code execution, not for the ability to read window contents or whatever Wayland is supposed to prevent).
Wayland also doesn't have a video capture interface as part of the standard. E.G. for Remote Desktop style applications (you might even use such if part of a video conference). Instead that's left up to the compositors, and therefore potentially not supported or possibly every compositor could have their own standard.
I had to switch back to X11 because both nVidia and nouveau would produce around 5 fps on my A2000 RTX on multiple distros. This is just for basic usage, not even painting-related.
Way-not-gonna-land as someone said some years ago. :-P
I'm using Wayland for my work now for two years now, and it has been amazing.
But then, I rarely do any graphics work.
I would like to move back to Linux (specifically NixOS), but I've held back because support on the T2 Macs is pretty bad still, and Apple is still providing updates to them for now.
When I tried installing Linux on there, I had a ton of trouble getting Wayland to work in any capacity (it was very glitchy when I tried), and I had to go back to X, before nuking the Linux install and going back to macOS.
A very lovely read. Well done to the author for taking the time to give such a thorough, generous description of their workflow and the whole process. I don't do any graphics stuff, so it was very interesting to imagine such a different world. Cool!
I work with Krita and digital tablets and made the switch to Arch-based distros in good part to address the problem of Krita being very much behind in official repositories or using the appimage with the problem he mentions.
With regards to update, this has been surprisingly smooth, the main problem has been with software development tools (the PostgreSQL and Python major updates for example require a few hours every time to fix everything, and occasionally things like Latex also break and require maintenance).
I did not try the switch to Wayland; I've actually tried installing the packages as recommended in the wiki, but despite that launching a session just fails and sends back to sddm, so I haven't tried much more. According to his guide, I won't try before a long time.
At this point I have only one app in XWayland (IntelliJ) and they are working on native Wayland support. I hope soon we cross the point where everyone is better off on Wayland.
I'm quite glad it works for me now, and I feel bad for everyone who's usecase is not yet catered for.
I just got a Framework 16, installed Ubuntu 24.04 on it, and have been going through this exact struggle after avoiding it for many years. The screen DPI is just high enough that it's uncomfortable for me to use at 100% scale, so I set it to 125%, but any non-Wayland application would get artificially resized and look blurry.
There's a pending Mutter MR[1] to allow XWayland applications to handle the scaling themselves (which IntelliJ IDEs can do) but it hasn't been merged yet, and I'm probably never gonna see it on 24.04 anyway. Apparently KDE already supports this, but the Gnome folks have been reluctant to adopt the same approach.
I ended up going back to 100% scaling, increasing the system font size, and then setting `GDK_DPI_SCALE=1.25` in `/etc/environment` to tell all GTK programs to increase their scale. It's not perfect, but most things are the right size. I definitely would not have wanted to switch to Wayland any sooner than this though. Transitional periods are such a pain.
Very nice cold shower for all the Wayland zealots.
I am generally pro-Wayland when it'll work, but against stucking Wayland into my throat and ordering me to abandon my routines, telling me they were no good. And this is what is happening right now with a lot of "enlightened" people.
Sounds like these desktop folks need to band together and re/implement/think the donut of missing functionality around wayland and get it standardized. Ship a lib metapackage called "wl-plus" perhaps. Then everyone could move on confidently.
What is the freedesktop group doing? I thought this was their area.
Do people just not realize that you are supposed to resize images? You don't just upload a 2560x1440 image, then have the client shrink it down to 930x523, unless you can take the server-side hit, and don't care about the time spent by the person waiting for the image to load.
I feel like the file size of an image that's the dimensions of a standard 1:1 pixel density desktop wallpaper on a site talking about digital painting is simply not the thing to be upset about.
Again -- I know I'm old, but it still boggles my mind how accepting LINUX people became of breaking backward compatibility in this situation. Like, the opposite of that was our whole thing.
>I've only been using this operating system for two weeks...I have already been productive with it and from my experience this is a really polished system.
If it works, it works. Artists have a different set of needs and the thread mentioned in the article showed stability > features
One of the things that Debian distros have over RPM based distros to me is installation. Even the worst one I've used (Debian stable) is better any RPM one. I've tried openSUSE and mandriva. Also, there's something about RPM distros, that I've tried, don't feel like they are mine to control.
[+] [-] fngjdflmdflg|1 year ago|reply
[0] https://wayland.freedesktop.org/
[+] [-] cookiengineer|1 year ago|reply
When I was talking about switching to wayland with a colleague, who was already moved over at the time, he tried to convince me that having no copy paste is better for security.
And I, using a password manager that generates unspeakably complex passwords everywhere, was kinda stunned by that blindsightedness.
If you don't want copy and paste, use Qubes OS. That's the philosophy matching the rest of the architecture of the OS.
But as long as you have a binary named "[" on your system, don't try to convince people that you are doing it in the name of security. There is much more rotten fish to throw away before that.
The only thing that recently convinced me to give wayland another go is hyprland. Seeing all kinds of nice WM concepts being implemented in it, maybe hyprland is "the interoperability specification" we needed all along.
[+] [-] Zetaphor|1 year ago|reply
You're speaking as though there is someone out there operating without that capability, when my experience has been the opposite. If that was the case you'd hear about it in every single "Wayland is bad" video, instead of the usual focus on nvidia (which I also have no issues with, even using Prime).
[+] [-] anton96|1 year ago|reply
Yet, I’m back on Windows, I like well defined screen, I have a 4K another one of lower resolution, to handle that well, I need Wayland, heck KDE just sometimes has less features or less solved bug on X11 now.
And at night I just want to watch one or two things before sleeping, I just need to turn my screen to my bed, and choose one the suggestions of plateforms like YouTube or Netflix with my mouse. …Yet, sometimes I like to type something, it’s usually short so I just use and on screen keyboard program which I’ve still wait to find one that works for Wayland.
This is so dum, it’s crazy to me that we used to fly away from all the dysfunctions of Windows to go the sane Linux ecosystem to only find that is starting to look a bit absurd on that side too. And we look at the discourse of Wayland devs, they speak exactly like corporate would do.
So that and few package management breakage and I think this is also a weak point of the ecosystem, tends to break, to upgrade everything when you only need one thing, too complex too trouble shoot.We usually think we have superior technological paleform on with Linux kernel, but package management is one of the weak point IMO.
All of that pushed me outside of Linux for now.When I encounter something that looks infuriating on Windows, I just think I might see something like this on Linux.
Edit: typos
[+] [-] cardanome|1 year ago|reply
As a user I want to download the thing and run it. AppImages provide that.
As an app developer I want to create one single package that works everywhere that users can just download. AppImages provide that.
Snap and Flatpacks are solving problems that don't need solving for most people. Shitty sandboxing that doesn't even work and makes my app slower? I don't want it.
Most software is best installed by the native package manager. For the few exception AppImages are perfects.
[+] [-] hamandcheese|1 year ago|reply
If an app is so hard to distribute in any other way, that to me is a red flag that the app is not up to my quality standards or otherwise violates my sensibilities in some way. On my Linux desktop, I am very much in the camp of "that which exists without my knowledge exists without my consent".
(I fully recognize that I am extreme outlier in general, and perhaps a slight outlier among Linux users. Just offering one perspective, I make no claims that this it the correct perspective for most Linux users.)
[+] [-] threePointFive|1 year ago|reply
The missing piece is perhaps some sort of AppImage installer which can be registered as the handler for the AppImage filetype. When ran it could read metadata (packaged as part of the AppImage?) and generate the support files. Ideally would also maintain a database of changes to be rolled back on uninstall and provide a PackageKit or AppStream provider to manage updates with your DE's store.
Now none of that addresses dependency duplication, but thats clearly not in scope for AppImage.
[+] [-] okanat|1 year ago|reply
> As a user I want to download the thing and run it. AppImages provide that.
Because Linux userspace libraries aren't designed to handle long term binary compatibility. There is no guarantee that a simple package upgrade or a simple distro version upgrade will not break things.
There is no guarantee that an Appimage will continue working 3 months later. If it relies on web communication, there is no guarantee that the application will stay secure since you have to bundle core system libraries like OpenSSL with your application (unlike Windows and MacOS).
I will even go and say especially GNU stuff is made specifically to make reasonable (imo at least 5 years) binary only i.e. closed-source software friendly distribution hard.
It is the culture adopted by all middle layer libraries and desktop environments too. The only supported form is source and every piece of software in Linux world assumes it is built as a part of an entire distro.
That's why Snap and Flatpak actually install a common standardized base distro on top of your distro or why Docker in its current form exists (basically packaging and running entire distro filesystems).
Only way to get around it is basically recreating and reengineering the entire Linux userspace as we know it. Nobody wants to do that.
Creating long term stable APIs that allow tweaking is very difficult, requires lots of experience in designing complex software. Even then you fail here and there and forced to support multiple legacy APIs. Nobody will do that unless they are both very intelligent and paid well (at the same level as an Apple, Microsoft or Android engineers). It is not fun and rewarding most of the time.
[+] [-] freedomben|1 year ago|reply
I think most people don't like AppImages mostly because they don't provide any sandboxing. I think that's a silly reason myself, but I'm also an old, and us olds aren't terrified of using our computers like the youngs seem to be ;-). Though, other OSes are getting sandboxing for applications and Linux needs to not get left behind, so I'm glad it's being solved.
I also think fragmentation is a (valid) reason people dislike AppImage also. It's nothing wrong with AppImage specifically, but that its existence harms adoption of Flatpak by making it easy for people to not use Flatpak. Personally I see them occupying different niches. I use App Images for things like Kdenlive, Logseq, Upscayl, and UHK Agent. Those could all be Flatpaks, but developer effort matters. If devs provide an App Image build I think we should be praising them from the rooftops for caring about Linux!
Another reason is that it clashes with immutable OSes like Fedora Silverblue or SteamOS that are heavily container-based.
What I'd love to see is a tool that takes an App Image and automatically builds it into a Flatpak (possibly with predefined metadata). Flathub could easily be populated this way so that it's easy for developers/distributors to package and ship, but also Flatpak is the standard.
[+] [-] throwaway38405|1 year ago|reply
Concerning AppImages: I have no interest at all in them and although Flatpak still has its share of problems, basically all important communities adopted it (but Ubuntu).
Flatpak integrates in your system, has sandboxes, has automatic updates, shares dependencies etc.
Is Flatpak perfect or running w/o problems? Certainly not.
But IMHO AppImages add nothing over Flatpak, but lack the unified infrastructure and integration into packet managers etc.
We all would benefit from agreeing on one standard, and by now it looks like Flatpak is that one standard. So, I don't want to download random AppImages from the internet, I want a certified Flatpak which integrates with my system.
(Being a member of the Linux community for longer than most people using Linux are alive by now, of course and invetible, once Flatpak is working and established, it will be replaced by some broken other solution. :-P)
[+] [-] eikenberry|1 year ago|reply
[+] [-] TwoNineFive|1 year ago|reply
Loudly declaring your ignorance is not an opinion. If really cared, you would go look at the large volume of the well-thought-out complaints. But you don't.
[+] [-] Gormo|1 year ago|reply
AppImages are good for certain use case. Recreational vehicles are also good for certain use cases. But just as a I don't live in RV parked in my garage when I'm at home, I don't use AppImages as my primary way of running locally-installed software on my main system.
> As an app developer I want to create one single package that works everywhere that users can just download.
You should just release source tarballs (or static binaries if you're not FOSS), and let the distros do their job of packaging and distributing the software. AppImages are fine to maintain in parallel for specific use cases, but I just want normal software binaries running in the OS environment I've already set up to my liking, not embedded in someone else's encapsulated runtime environment that's inconsistent in dozens of ways from my system config.
> Most software is best installed by the native package manager. For the few exception AppImages are perfects.
Exactly. But static builds are far superior to AppImage.
[+] [-] Zambyte|1 year ago|reply
FWIW my package manager of choice is GNU Guix, which solves all of the same problems as snap and flatpak in a much more elegant way.
[+] [-] mid-kid|1 year ago|reply
The fundamental problem is that AppImages are literally just an archive with a bunch of files in them, including libraries and other expected system files. These files have to be selected by the developer. It's really hard to tell which libraries can be expected to exist on every distribution, which libraries you can bundle and which ones you absolutely cannot due to dependence on some system component you can't bundle either, or things like mesa/graphics drivers. There's tools to help developers with this, "linuxdeploy" is one, but they're not perfect. Every single AppImage tutorial will tell you: Test the AppImage on every distribution you intend this to run on.
At the end of the day, this situation burdens both the developer (have I tested every distribution my users will use? both LTS and non-LTS?) as well as the user (what is this weird error? why isn't it working on my system?), and even if this all somehow works, newer versions of distributions are not guaranteed to work.
Flatpak, for all its bells and whistles, at least provides one universal guarantee: Whatever the developer tests, is exactly what the user will experience. I think this is a problem that needed solving for many people.
...it hurts a lot to say this as a longtime flatpak avoider, still always prefer distribution packaging, but I've come to accept that there's a genuine utility to flatpak, if only to cover for letting users test different versions of software easily, and similar situations that distributions just cannot facilitate no matter how fancy their package manager.
[+] [-] red_trumpet|1 year ago|reply
[+] [-] burningChrome|1 year ago|reply
After using Ubuntu for years, this change made myself and many others I know switch. I've been on MX for the past two years and love it.
[+] [-] alpaca128|1 year ago|reply
Yes. And no.
About 70-80% of AppImages I downloaded in the past didn't even start. 100% of my installed Flatpaks have been running fine on any distro I tried. I would love a world where Flatpak was redundant, but it very clearly isn't.
[+] [-] tapoxi|1 year ago|reply
I'm on an immutable distribution (Fedora Kinoite) so installing native packages is discouraged. I have everything running in Flatpaks, even Steam and all games. I haven't experienced any performance impact. I think Snaps do something weird with squashfs, but Flatpaks just set up and manage symlinks to dependencies via ostree.
[+] [-] triblemaster|1 year ago|reply
[+] [-] anton96|1 year ago|reply
To me that also raises the issue of Snap/Flatpacks and Wayland both handling part of sandboxing/capabilities. Ultimately if you want to handle how your apps can be run and got resort back to lower primitive and you’re handling very different things like files acces(Snap/Flatpacks) and visual elements(Wayland) and maybe got back to the Linux kernel to handle that.
[+] [-] bmicraft|1 year ago|reply
[+] [-] giancarlostoro|1 year ago|reply
[+] [-] guilhas|1 year ago|reply
I think they are all worse than the other packaging methods
With a NixOS configuration I can install almost all software I use in a single command
Even in window I mostly use scoop/chocolatey
[+] [-] toenail|1 year ago|reply
> It's now up to each desktop environment project (e.g. GNOME or KDE Plasma) to develop their own full featured GUI for tablet configuration.
That doesn't sound ideal.
[+] [-] costco|1 year ago|reply
[+] [-] mjevans|1 year ago|reply
https://wayland.freedesktop.org/faq.html#heading_toc_j_8
[+] [-] janosdebugs|1 year ago|reply
[+] [-] triblemaster|1 year ago|reply
[+] [-] tombert|1 year ago|reply
When I tried installing Linux on there, I had a ton of trouble getting Wayland to work in any capacity (it was very glitchy when I tried), and I had to go back to X, before nuking the Linux install and going back to macOS.
[+] [-] guilhas|1 year ago|reply
I think is more probable that anyone will have a problem in Wayland than X
[+] [-] sourcepluck|1 year ago|reply
[+] [-] woolion|1 year ago|reply
I did not try the switch to Wayland; I've actually tried installing the packages as recommended in the wiki, but despite that launching a session just fails and sends back to sddm, so I haven't tried much more. According to his guide, I won't try before a long time.
[+] [-] cies|1 year ago|reply
I'm quite glad it works for me now, and I feel bad for everyone who's usecase is not yet catered for.
[+] [-] iamjackg|1 year ago|reply
There's a pending Mutter MR[1] to allow XWayland applications to handle the scaling themselves (which IntelliJ IDEs can do) but it hasn't been merged yet, and I'm probably never gonna see it on 24.04 anyway. Apparently KDE already supports this, but the Gnome folks have been reluctant to adopt the same approach.
I ended up going back to 100% scaling, increasing the system font size, and then setting `GDK_DPI_SCALE=1.25` in `/etc/environment` to tell all GTK programs to increase their scale. It's not perfect, but most things are the right size. I definitely would not have wanted to switch to Wayland any sooner than this though. Transitional periods are such a pain.
[1]: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567
[+] [-] self_awareness|1 year ago|reply
I am generally pro-Wayland when it'll work, but against stucking Wayland into my throat and ordering me to abandon my routines, telling me they were no good. And this is what is happening right now with a lot of "enlightened" people.
[+] [-] kombine|1 year ago|reply
[+] [-] kaanyalova|1 year ago|reply
https://opentabletdriver.net/
[+] [-] OsrsNeedsf2P|1 year ago|reply
[+] [-] pm2222|1 year ago|reply
[+] [-] mixmastamyk|1 year ago|reply
What is the freedesktop group doing? I thought this was their area.
[+] [-] Dwedit|1 year ago|reply
[+] [-] bastawhiz|1 year ago|reply
[+] [-] moonlion_eth|1 year ago|reply
[+] [-] jrm4|1 year ago|reply
Us Wayland skeptics were always right.
Again -- I know I'm old, but it still boggles my mind how accepting LINUX people became of breaking backward compatibility in this situation. Like, the opposite of that was our whole thing.
[+] [-] resource_waste|1 year ago|reply
[deleted]
[+] [-] fefehern|1 year ago|reply
If it works, it works. Artists have a different set of needs and the thread mentioned in the article showed stability > features
https://discuss.kde.org/t/fedora-kde-40-plans-to-completely-...
[+] [-] bobajeff|1 year ago|reply
[+] [-] endofreach|1 year ago|reply
Curiosity: What would you recommend then, for someone who doesn't want to be ignorant or complacent?
[+] [-] rasengan|1 year ago|reply