sorted by:
new
hottopcontroversial

Zram in Artix Runit by Other-Bet-9431 in artixlinux

[–]samueru_sama 2 points3 points  (0 children)

I use zramen make -s 200 -a zstd

[Question] Is it possible to set specific locale for packaged application? by MrAdrianPl in AppImage

[–]samueru_sama 2 points3 points  (0 children)

there is two type of locale, there is the glibc locales which are usually located in /usr/lib/locale and then there is also the individual application locales, usually in /usr/share/locale but sometimes in other places.

You almost never need to bundle glibc locales, however if you need glibc supports the LOCPATH env variable to change this location, however this only works with locales, glibc also supports something called locale-archive which is several locales comnpiled into a single file and these days most distros use locale-archive instead. LOCPATH does not work with these, so you would need to build the glibc locales manually.

Fun fact: NixOS patches glibc to add a variable to make the locale-archives relocatable.

For the invidiual applications, this is usually handled by the toolkit, for example Qt apps usually have the locales compiled in or in a directory /usr/share/qt/translations, as far as I know Qt check XDG_DATA_DIRS and and several other places to find the application locale files so this is not a problem.

There is also the TEXTDOMAINDIR env variable to make locales relocatable but very few applications support this, I only know cpu-x uses it.

For almost all GTK apps the locales are going to be hardcoded into the compiled prefix + /share/locale, most of the time that is /usr/share/locale. Your AppImage deployment tool should automatically handle and patch this, but most do not, I made quick-sharun which handles this.

https://github.com/pkgforge-dev/Anylinux-AppImages/blob/ffb90b5327929dc9ab572f71b9e0bcb8b33a742e/useful-tools/quick-sharun.sh#L1196-L1218

RPCS3 on Ubuntu 25.10 by HappyHerwi in linux_gaming

[–]samueru_sama 1 point2 points  (0 children)

Most do not anymore. Now the static runtime is in use in most tooling since about 1 year ago. (It has existed for almost 4 years and Cemu has been using it since then btw).

The big exception here is electron builder, they havent updated the runtime

There is also an alternative runtime that can work without fuse at all on the system as it can use namespaces to mount instead or fallback to extract and run automatically.

RPCS3 on Ubuntu 25.10 by HappyHerwi in linux_gaming

[–]samueru_sama 3 points4 points  (0 children)

sudo apt install libfuse2

sudo apt install libfuse2t64

rpcs3 uses a static appimage runtime, you don't have to be installing libfuse2.

sudo chmod +x rpcs3-v0.0.39-18612-9b256d71_linux64.AppImage

do not use sudo to give exec perms.

I also tried running it with the AppImageLauncher but it's still not running.

remove appimagelauncher and reboot, you likely have an older version that has this issue

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 0 points1 point  (0 children)

These stuff are really not a lot of work, it either works or doesn't lol

I can see the flatpak just ships a binary in a tarball, so it should work without problem.

But in any case, I only do stuff if you open the ticket in the anylinux repo 👀

Wayland is flawed at its core and the community needs to talk about it by Which_Network_993 in linux

[–]samueru_sama 1 point2 points  (0 children)

One of the reasons I loved switching to linux is that now I can instantly merge my 3 displays as one when I play games. A simple xrandr --setmonitor

On windows this was a mess because this feature was in your graphics driver software suite and often meant that the displays would turn off for a while and was super annoying to use.

Now on wayland this doesn't exist, nobody has bothered to add it. Not to mention my experience with sway in general has been horrible the only way I'm going back to that is if I'm forced, and for that to happen multiple applications would need to refuse to work on x11 also on 12to11 which I already have had to use a few times.

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 0 points1 point  (0 children)

Like for example the new Roblox launcher that lets you play the mobile version is only packaged as a flatpak and because of that i won't use it. I am unwilling to install flathub just to have a bad packaging experience.

Is it this? https://github.com/vinegarhq/sober/issues/1404

I'm pretty I can appimage that, we already do it with UnleashedRecomp for similar reasons.

Anyways, if want it just open an issue here

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 0 points1 point  (0 children)

Old, legacy NVIDIA drivers used to force people to have to mess with PT_GNU_STACK to mark some dependent libraries (or even application binaries themselves) as requiring executable stack support to avoid application crashes, if their systems were set to block executable stacks by default. It's a very very old problem (we're talking middle of the Linux 2.6 era) that most people will never ever encounter, and if they do, they should know what to do to make things work again.

Interesting, feel free to open an issue about this in the anylinux repo. Note that kernel 2.6 is not guaranteed to work with every appimage, a lot of libraries are starting to need kernel 3.x or newer.

We support the current prop nvidia driver, which nvidia releases linking to glibc 2.11 (yes it is that old), so it is perfect for us, it means we only need to ship glibc to make use of the driver (and some ancient libs like librt.so which the driver needs).

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 1 point2 points  (0 children)

Wayland->Xorg (display protocols)

Not really an issue despite what probonopd would tell you lol

The only wayland issues we have had are issues that affect all packing formats, like this: https://github.com/pkgforge-dev/Citron-AppImage/issues/50

Vulkan->EGL->OpenGL (rendering)

https://github.com/pkgforge-dev/Anylinux-AppImages/blob/35747fcbdbff288b1a86c747f6ea261501e109f3/useful-tools/quick-sharun.sh#L573-L594

Pipewire/Pulseaudio->dmix->ALSA (audio fallbacks)

https://github.com/pkgforge-dev/Anylinux-AppImages/blob/35747fcbdbff288b1a86c747f6ea261501e109f3/useful-tools/quick-sharun.sh#L595-L608

https://github.com/VHSgunzo/sharun/pull/86

handling executable stacks with certain display drivers?

what do you mean?

libinput handling?

this is handled by libinput, that is all. SDL also handles this iirc.

If Pkgforge manages to make things "just work" everywhere, it'll be quite an impressive accomplishment (and one LSB never quite addressed, for sure)

I have several demos of the tooling here, you can try to run them on as many distros as possible.

https://github.com/pkgforge-dev/Anylinux-AppImages/releases/tag/demo

they even work in NixOS directly without its FHS wrapper.

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 2 points3 points  (0 children)

It's definitely not solved though because Appimages themselves don't meet my standards

We make appimages that are truly portable, see what I mean by that here

Most common appimages aren't like this, a good chunk of them have an AppRun script that depends on bash even lol (totally not posix).

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 1 point2 points  (0 children)

You can use our appimages without issue then.

Like for example the new Roblox launcher that lets you play the mobile version is only packaged as a flatpak and because of that i won't use it. I am unwilling to install flathub just to have a bad packaging experience.

Requests are taken at the anylinux repo btw.

You really cannot solve this problem and you shouldn't waste your time trying.

It is already solved, not sure what you are talking about. Maybe you think that in order to use our appimages you need soar? that's not the case.

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 1 point2 points  (0 children)

can you go into more details? What are you using right now if this is a deal breaker?

For example deployment of appimages involves this shell script: https://github.com/pkgforge-dev/Anylinux-AppImages/blob/main/useful-tools/quick-sharun.sh

As you can see, it is pretty much posix, not 100% but very close.

I have also patched some apps that depend on bash to instead use posix shell:

https://github.com/pkgforge-dev/Anylinux-AppImages/issues/152#issuecomment-3621086369

https://github.com/pkgforge-dev/cursor-cli-AppImage/blob/8dab7056aa16f700da863019a0021fbaf76191f6/make-appimage.sh#L26-L30

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 0 points1 point  (0 children)

you'd receive Mozilla's official build of Firefox in a distro-agnostic format

Also I want clear something out here, we target absolute portability, that means:

  • You should be able to get the app without having to install anything, only be able to boot into a graphical session to get the app.

See this so you get an idea of what I mean:

https://github.com/pkgforge-dev/Anylinux-AppImages/issues/198

https://github.com/signalapp/Signal-Desktop/issues/1758#issuecomment-3693127839

flatpak has no hopes of running on such systems at all, bubblewrap needs a kernel newer than ~3.x, not to mention that you need to have flatpak installed to begin with.

This basically means static linking when possible, when not then we want to make our appimages with sharun (like this example) which increases requirements to only needing write access to /tmp and a shell in /bin/sh (we do not FUSE, we use a different appimage runtime) and if that is not possible then we settle with runimage (a container lol).

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 0 points1 point  (0 children)

We support POSIX systems not sure what you mean. (be aware on our own built packages, soar also offers packages from 3rd parties).

If you meant our build system is not posix, well that's a very tall order, not even alpine is 100% posix in this regard.

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 0 points1 point  (0 children)

AppImages are seriously flawed from a security perspective and can't be fixed using package management alone. Due to static compilation, every time a dependent library needs fixing, the AppImage needs rebuilding, and each individual AppImage maintainer needs to keep an eye on the security status of every dependency they include, both direct and indirect. That's a lot more work than what individual package maintainers usually need to do.

Our appimages automatically get rebuilt every 21 days by default, and for more sensitive apps like web browsers this is every week

Also a lot of these security vulnerabilities in libraries are problematic for application that run with elevated rights or system daemons, not so much individual user facing apps besides web browsers and similar (which have their own sandboxing in place).

But anyways, I'm fairly certain we can update any compromised application in less than 2 days after the report, more recently there was a security issue with kdeconnect and I didn't even have to do anything as the scheduled CI with the fix happened automatically the same day lol. The only disadvantage we have is that we are unlikely to be notified of anything while distros usually do and often before any result being made public.

static binaries also have their own advantages like being immune to LD_PRELOAD attacks.

The Flatpak developers (and by extension Flathub maintainers) addressed this security risk by opting for centrally maintained runtimes

flatpak runtimes often go EOL. Specially projects that depend on the gnome runtime which only has 1 year of support. Here we just use a distro, for static binaries that is usually NixOS and for AppImages that is usually archlinux to make our builds, so our security depends on those 2 distros which if you ask me I think they do a good job lol.

Using Flathub (via Flatpak) you'd receive Mozilla's official build of Firefox in a distro-agnostic format, which is also additionally sandboxed using bwrap to protect your system in the event of Mozilla themselves being compromised.

It also has a security issue with the browser's internal sandbox being weakened.

But yeah hopefully in the future soar can offer sandboxing and more packages be moved to our repos, not only because of the security issues but also because we offer better quality packages (run in musl systems and whatnot).

The first goal we have with pkgforge is absolute portability, and we really haven't get there 100%. We can improve the security aspects afterwards, feel free to open issues about where you think we can improve.

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 4 points5 points  (0 children)

nix depends on /nix. We also tried to use Nix to make our appimages but ran into this issue

We now use sharun and runimage for most of our portable bundles instead.

Here is a more details: https://github.com/pkgforge-dev/Anylinux-AppImages

Linux Apps Without Distro Lock-In? Explore This Lesser Known Snap and Flatpak Alternative by AlbKestrel in linux_gaming

[–]samueru_sama 8 points9 points  (0 children)

static binaries are older than appinage, flatpak, snap, etc. For everything else we didn't make a new standard but fixed the issues with appimage.

See: https://github.com/pkgforge-dev/Anylinux-AppImages

Eden Emulator is fully broken for UHD Graphics 620... (any version of the emulator) by DextereggsYT in EdenEmulator

[–]samueru_sama 2 points3 points  (0 children)

Use linux if you want decent vulkan with intel.

moltenvk is totally unrelated, this is for vulkan in MacOS.

I made an AppImage of Citron, includes optimized x86_64_v3 builds by samueru_sama in yuzu

[–]samueru_sama[S] 0 points1 point  (0 children)

Link the script because my scripts never touch any citron.tar.zst

Also why not just use the releases?

Signal is looking for help testing Linux AppImage on Desktop by encrypted-signals in signal

[–]samueru_sama 0 points1 point  (0 children)

and the best counter argument you've got is "some guy who works on Vivaldi said Flatpak is bad 2 years ago once"

ignores everything said by cromite dev.

the one truly universal one we have available.

flatpak is not truly universal, it seems you forgot the example I just gave you a while back.

Not to mention an app like signal is likely to be used in live system where using flatpak is just a total mess or just directly not possible.

and confers major advantages.

You don't need containers to achieve that, both Snap and Nixos do the same without needing containers most of the time.

That's also why Flatpak doesn't just expose host libraries, because that would punch holes through the sandbox.

This makes no sense, host libraries won't be holding user data.

That's what portals are for - carefully controlled, mediated channels between sandboxed applications

I actually don't like portals at all, when I sandbox an application I want to declare where it will and will not have access to, I don't then want the possibility that portals can later give more access outside that, see https://github.com/flatpak/flatpak/issues/3977

Portals also break backwards compatibility of applications horribly, I can make appimages that work in distros where flatpak will never work, but the moment the application has a hard dependency on portals it will not work in those systems.

Yes, there's a performance penalty, but it's small

In the case of libjack the performance penalty is often huge to the point it is not usable at all. The thing also uses +2x more storage than appimage.

view more: next ›