Very interesting tool. So this is for appimages but also binaries?
Anything portable.
Thats not a sandbox, its a nice wrapper for firejail,
aisap uses bwrap it is mentioned in both links I gave you.
appman used to have firejail sandbox but it was dropped in favor of aisap because of that.
Are all Appimages using that, if not what percentage of the ones you know?
Usually if the appimage has a github release with a zsync you have that verification.
And are tools like Gearlever enforcing or using that signature check?
I don't use gearlever, as far as I know gearlever doesn't even let you sandbox the appimage like AM does. I don't think any of those forces signature verification besides AppImageUpdateTool and that's because that's part of the zsync update process.
Running things from random directories (like ~/Applications which AppimagePool uses) destroys that.
~/Applications is no a random place, it comes from macos. And what is appimagepool?
You mean appimagetool? that's used to turn the AppDir into an appimage.
If you meant appimagelauncher, ~/Applications is the default location but it can be changed to any location.
(including appimages which are nearly impossible to sandbox)
See that lock next to some appimages? Yes that's aisap sandbox..
It isn't perfect though, right now its biggest limitation is that a sandboxed appimage can't launch another sandboxed appimage. But dbus, pipewire, vulkan, themes, etc works.
The “open with” and “create new” things. Actually,
You can totally do that with appimages once they are integrated into the system by the previously mentioned tools, those menus rely on desktop entries in $XDG_DATA_HOME/Applications.
That concept is so broken that it needs to go.
Good thing we have choices on linux, you can make your entire home not executable if you want to.
I like to keep all the software that I need in my home, because that way I don't depend on what my distro provides. I can just drop my home anywhere (besides a musl distro) and I'm ready to go, I even have my window manager as an appimage because I couldn't compile it statically.
But the issue is that they were just thrown out there, “here devs, do the same shit you do on Windows, it is totally normal for people to double click an executable, not have any sandboxing, deal with updates on their own, dont have any cryptographic verification, …”.
AppImage is just a format, same as a deb or rpm, you decide how you handle it afterwards.
doing the actual update process (instead of deleting a file and placing a new one)
Same link again: https://github.com/AppImageCommunity/AppImageUpdate
Many of the appimage devs actually worked on making zsync2 for this: https://github.com/AppImageCommunity/zsync2
On Android you still have a package manager but the APKs are signed individually, updates just allowed if the signatures match. So you can sideload how you want, it is still secure.
You mean the APK itself does the signature verification or what? With appimage it is AppImageUpdateTool that does the verification.
(appimages are impossible to sandbox with bubblewrap, and hard with firejail (which is a setuid binary and had security issues), dont know about nsjail, crabjail, minijail or others)
Regarding what?
You still have that github repo saying that appimages bloat the system when that is a total lie. they can even use less storage than native packages let alone comparing it to flatpak...
But they dont have installers, so no verification
https://lemmy.ml/post/17283790/11897811
on Linux the entire home is executable which is a huge security issue
You still have to give the exec permission to the appimage.
no desktop integration, no context menu, no file associations.
Maybe no context menu depending on what you mean exactly, but the rest are fully possible and I do it on a regular basics with my appimages...
edit: Omg you are the guy from don't use appimages, I see you haven't changed one bit.
And Windows executables have some weird signature verification which Appimages dont have at all.
EDIT:
Appimages have no install wizard.
Appimagelauncher, gearlever, AM, etc. Which is the same as a install wizard since it integrates the appimage into the system. AppImages do not need to be extracted into the system which is what windows install wizards do.
What happened to just donwload the app from it’s own creator and install on your machine?
You have that option with the appimage, inkscape releases it themselves.
Oh it's done by assigning the same keybind to each action.
That will likeky make my config 1000 lines long 😅
That’s just the way you write the rules being deprecated, not the functionality.
I didn't say that it is impossible to do it, just that after I read the documentation it told me that.
Something that I couldn't even find in the documentation was how to do several actions with one keybind, on i3 each action is separated by a comma and you can assign variables to them, for example:
$BIND $MOD+$SHFT+Mod2+KP_1 $MVTO $WS1, $WS1, $WDUNST "$WS1"
Which means:
bindsym Mod4+Shift+Mod2+KP_1 move container to WorkSpace "1", WorkSpace "1", --no-startup-id dunstify -r 33 -t 600 "$WS1"
In english that is move the focused window to workspace 1, focus workspace 1 and send a notification of the current workspace (the last one is for some visual feedback).
hyperland itself told me that, I have a terrible picture (I didn't setup screenshots lol) of it: https://imgur.com/a/fWwmt1e
This was right before yuzu closed down btw.
and have none of the problems you mentioned.
You can move floating windows between displays with the move left/right commands? (not the move to workspace commands).
edit: Found a related issue https://github.com/hyprwm/hyprland-wiki/issues/242
Yes, I spent a while reading the documentation on how to pin workspaces to certain monitors only for hyprland to tell me that it is deprecated.
Also an issue I noticed is that you can't move floating windows between displays with the move left/right commands, move left/right moves the floating window to the left or right of the display and no more, meaning that the window gets stuck at the border of the display and doesn't move more.
Also I couldn't figure out how to make hyperland run several commands in a row with one keybind, or how to filter windows with expressions, something that I do a lot on my i3config .
And my biggest issue, and this one seems to be with wayland in general is that it seems that it is impossible to set my displays to extended more, that is turn the 3 displays that I have into a single display which I use with some games.
i3 isn't perfect either, I actually had to fork it and apply a patch that fixes and issue that I have that hasn't been merged yet either.
I will list all my issues with sway anyway, hopefully somebody out there notices it and fixes them:
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 all these bugs are the result of less than 2 days in total of use of sway, there is likely more that I haven't run into.
I also had an issue that affected xfce4 apps, but that issue ended up being a dbus-broker issue that only happens on wayland for some reason lol
I have a feeling I will be on i3 for many many years given all the issues that I've had with sway.
I use kdeconnect with this script: https://github.com/Samueru-sama/kdeconnect-any-filemanager
AppImages, which have no automated update facility, are terrible idea for software that is based on the security of the messaging syatem.
https://docs.appimage.org/packaging-guide/optional/updates.html
And if you want an example of one that self updates, ferdium.
My numbers were correct and I explained why.
Do you mind telling me the application list so I can check that myself?
because they are problematic by design. I didn’t go out of my way to cherrypick a small handful of applications that just so happened to use three different runtimes
Kinda odd, I didn't even know it was using 3 different runtimes until very recently, I just installed the biggest applications that I had as appimages to make the comparison, and yuzu because I use that one very often lol.
EDIT: Don't you think that on itself isn't problematic by design?
in order to bash it.
How should I have phrased my comment so that I wasn't bashing flatpak?
due to the huge systematic problems they have.
Such as?
I do that with appimages as they support a portable home. And that location can be moved around.
You can't get bubblewrap sandboxing with appimages in a user friendly way though, but I think I will start working on that (yes I'm serious).
Flatpak hardcoded ~/.var which I found a really bad decision and they had several issues opened on this which went really bad if you ask me:
https://github.com/flatpak/flatpak/issues/46
I know storage doesn't matter these days, but another different thing is suggesting flatpak "because it keeps bloat down".
Oh I'm very sorry, I didn't see the period before the At the expense of storage space
Flatpaks either work for everybody, or they don’t work at all.
Maybe? I've seen enough people having weird issues with flatpaks that others don't have. One recent example was somebody complaining here that the firefox flatpak took very long start, which I found odd because flatpaks aren't compressed squashfs images and should not be taking long to start up, that's an issue of appimages and snaps instead lol.
Packaging your software with Flatpak does not mean you won’t have issues. But when you do have issues, you know they’ll be an issue for everybody. So when you fix it, you also fix it for everybody.
Another issue that I've noticed with flatpaks is that they are usually built with generic flags, I don't know if this is a requirement or lazy developer, but this is also an issue that yuzu had, the flatpak was built for x86-64 while the appimage was for x86-64-v2 and that had a 8% boost on fps at the cost of people with cpus older than sandy bridge not being able to use it. (Which I mean if your cpu is that old you can't use yuzu anyway).
EDIT: And by weird distro I basically meant nix or musl distros, which I know flatpak works on because it bundles an entire distro basically, while appimage tries its best to be compatible with every distro provided it uses glibc and follows the FHS.
On that there is no dispute that flatpak/snap is your only option.
but that can and does cause reliability and probability issues.
Flatpak and snaps have been the most broken on this. Just recently I was talking about issues that I had with yuzu on that. And more recently steam as I wanted to test something...
Also I remember you, you were the guy that didn't reply when you gave a number that I found very odd (Basically impossible lol):
https://lemmy.ml/post/16669819/11551689
Were you guy that downvoted the comment btw?
Appimages don’t use any deduplication at all and usually package everything in the app.
Yes, doesn't mean anything if flatpak uses way more storage...
At the expense of storage space
What storage expense? appimage are actually the smallest thanks to their compression.
Compare the librewolf appimage vs a native pacakge, it is 100 vs 300 MiB iirc.
Same with libreoffice, it is 300 vs 600 MiB.
And these native packages seem to share very few libraries, because when I remove them from my system the removed size is that, 300, 600 MiB, etc.
My distro would not be 4.2 GIB if I dropped my appimages for native packages.
de-duplication saves TheEvilSkeleton over 50GB of storage space here: https://tesk.page/2023/06/04/response-to-developers-are-lazy-thus-flatpak/#but-flatpaks-are-easier-for-end-users
The total size 27 GIB for 173 apps works out at an average of 155 MiB per application.
The average appimage is also that size. Like besides very big applications like libreoffice which is 300 MiB and kdenlive which is 200 MiB. The rest of apps are usually 150 MiB or less.
And most appimages are "lazy" appimages made with linuxdeploy, if you do finer control on the build you can get the size of the appimage way way down.
One example is qbittorrent, the official appimage is 100 MiB, while there is a fork called qbittorrent-enhanced edition, and they got the size of the appimage down to 26 MiB
making them less reliable
Hard disagree that they are less reliable, that might be less reliable on weird distros or very minimal installations, but usually the issue is that you are missing a lib and not that the app itself is less reliable, but stability wise, they have been the most reliable, case in point was yuzu, the flatpak was such as nightware that even the devs would talk againts it due to issues with mesa.
And the support channel of yuzu in their discord was full of people having issues with the flatpak that were magically fixed the moment they tried the appimage, due to that issue with mesa being outdated in the flatpak.
But anyway, I will install my applications as flatpak and compare the storage used.
How big is your distro right now?
I am at 4.2 GIB with my distro (artix) + 30 appimages + home. Though stuff like ~/.local/steam is on a different partition.
I'm a i3 user that has been trying to migrate to sway.
I use it with these environment variables:
export XDG_DATA_HOME="$HOME/.local/share" export XDG_STATE_HOME="$HOME/.local/var/state" export XDG_CONFIG_HOME="$HOME/.local/config" export XDG_CACHE_HOME="$HOME/.local/var/cache"
Which gives me a clean home with only ~/.local for my dotfiles.
And issue that I've noticed that I haven't been able to fix is that every time that I start sway, hyprland and also the alpha of cosmic is that I get a new ~/.cache directory created in my home that contains a mesa_shader_cache directory.
Btw in the middle of writing this post I just ran into another bug, thunar for some reason decided to steal my key presses from the web browser, and even though I had the browser window focused as I have sway configured to change the border color of the window with focus, thunar was like nope wtf.
Thank you all for the help, ended up opening a bug report at sway: https://github.com/swaywm/sway/issues/8191
I have this command on my i3wm configuration, which extends the 3 displays that I have into a single one for games.
bindsym $mod+Shift+k exec "xrandr --setmonitor extended auto DP-1,DP-2,DP-3"
The only issue that I have is, once I'm done, how do I revert back to having the displays individually? This has been driving me crazy.
Searching on internet all that I've managed to find is using xrandr -s 0, which actually just turns off my other displays.
And what is worse is that if I then manually turn the displays back on, THEY ARE STILL EXTENDED "xrandr -s 0" does not even reset that lol.
So far what I have to do to revert the changes is to log out of my current session.
SOLUTION: THE COMMAND IS: xrandr --delmonitor extended
Here is the script, which is a hack that I use with i3wm, I already converted most of it to a single line and it still works:
#!/usr/bin/env bash
is-leaf-node() { i3-msg -t get_tree | jq 'recurse(.nodes[]?, .floating_nodes[]?) | select(.type == "con" or .type == "floating_con") | select(.focused == true) | .nodes == []';}; parent-type() { i3-msg -t get_tree | jq -r 'recurse(.nodes[]?, .floating_nodes[]?) | select(.nodes[]?.focused == true) | .type' ;}; if [ "$(is-leaf-node)" == "true" ]; then i3-msg focus parent, focus parent; else i3-msg focus child, focus child; fi
Here is where I'm stuck:
The script needs the #!/usr/bin/env bash to work, it is the only script that I have that needs it.
Changing it to #!/usr/bin/env bash; <SCRIPT> does not work, it has have a second line for it to work.
I'm trying to migrate from lightdm to just using startx to start my i3 session.
First I had issues with kdeconnect working which were fixed by replacing exec i3 with exec dbus-launch --exit-with-session i3 in the xinitrc.
Now even though the apps works it is not following the system theme, I checked qt5ct and it is telling me that QT_QPA_PLATFORMTHEME is not set to qt5ct.
But I do have export QT_QPA_PLATFORMTHEME=qt5ct on my ~/.profile it seems the file is not being read but I have no idea on how to fix it.