They have a Glfw build, it is a lot smaller and faster but they don’t want to support it.

Unfortunately they decided to use the slow bloated mess that is GTK4.

https://github.com/ghostty-org/ghostty/discussions/5592#discussioncomment-13186436

I bought an AMD gpu to use sway, I feel like the fuckers owe me 50 usd now which is what I payed for the gpu.

https://github.com/swaywm/sway/issues/8000

https://github.com/swaywm/sway/issues/8001

https://github.com/swaywm/sway/issues/8002

https://github.com/swaywm/sway/issues/8191

And it’s devs are not willing to fix the most basic issues like correctly handing a fucking environment variable lmao

https://github.com/swaywm/sway/pull/7380#issuecomment-2453356422

Not to mention I have a different issue that I haven’t even bothered to report because I already know won’t be implemented:

I have 3 displays that right now I use xrandr to merge the 3 displays into one, this is not possible in any wayland compositor today, the closest thing I found was someone suggesting to use gamescope to make a window with the resolution of the 3 displays but that’s a hack and doesn’t work for me because I need the displays to be merged, not just span a single window across them.

There is also no universal xdotool or similar in wayland to query info about windows, so you have to learn to use the CLI tool provided by each DE/WM and then handle the data, which in the case of sway it is json formatted.

So what used to be a simple xdotool <args> | grep became needlessly overcomplicated and different for each wayland DE/WM.

Unfortunately because PopOS is based on debian/ubuntu, they tend to split packages into a million pieces, so something that would have a simple pacman -Syu mesa vulkan-radeon on archlinux to get the video drivers is like 6 different packages on debian which I don’t know the names of.

Fedora is the testing ground of red hat, they are known for pushing a lot of breaking changes constantly, even more than Archlinux or other rolling release distros. A while back they pulled this nonsense that we had to deal with that not even upstream approves of.

So my only distro recommendation is archlinux or some archlinux fork, every time I have had to help people with distro issues they all eventually ended up in arch because all other distros have some weird issue that’s a deal breaker. Just don’t rely too much on the Aur.

My other suggestion is that you get most of your software as appimage thru AM: https://github.com/ivan-hc/AM

We ship Steam as an AppImage with a lot of common fixes that affect the flatpak version or native versions of steam (you can check them in the readme), and you don’t have to deal with the hassle of setting up the 32bit repo and installing Steam for example.

Processes are still isolated through nested seccomp filters.

You don’t have namespaces still…

For reference, chromium will not launch without that, you have to pass the --no-sandbox flag and brave iirc disabled that all together.

Not really an issue with chromium because you do have working namespaces sandbox thru zypack, although some disagree that this is safe

Would highly recommend against anything that “updates itself.”

Disable the self updates in that case… before you were saying that AppImages had no way to self update and now are saying that you don’t recommend it?

You want someone in the stream to do some sort of validation.

Also what validation are we talking about? the one that flathub does? The most you will get is recognizing that the application comes from upstream, you can even ship pre-compiled binaries thru flathub.

There is a reason we use centralized management.

Such as?

EDIT:

I also don’t want every app trying to check for updates.

With AppImage you have this outside the application thru the zsync delta updates, the info is embedded in the appimage and it is checked by appimageupdatetool, appimagelauncher, and similar and let you know when there is an update available without the application itself doing the check.

Thank you, it seems every way I go i make the wrong choice lol

Welcome to linux.

What you were told about appimage depending on legacy stuff is also not true, it is the libfuse2 dependency, which hasn’t been a dependency of AppImage for 3 years (though some projects haven’t updated yet).

It also isn’t a big deal if you run into an appimage that still depends on it, archlinux which is a rolling release distro, some of its packages like mtpfs and ntfs-3g still depend on libfuse2 as well. And you can still run the AppImage by setting the env variable APPIMAGE_EXTRACT_AND_RUN=1 to avoid having to install libfuse2 in those cases.

They are very dated and depend on legacy stuff that often was dropped by the distro

Is it libfuse2? This has no longer been a dependency with the static appimage runtime, which released in 2022!

Although most notable, electron apps still by default use the old runtime, because electron-builder hasn’t updated the appimage runtime.

Besides that AppImage do not depend on legacy stuff.

They are also terrible for security since there is no way of pushing out updates.

This was never true lmao.

Do not use flatpak for firefox based browsers because it breaks it namespaces sandbox.

Firefox releases a portable binary that self updates.

Xfce is on GTK3 and there are no plans to migrate to GTK4.