Btrfs snapshots made me stop using ext4 all together.
Btrfs snapshots made me stop using ext4 all together.
Folders? you mean directories 👀
Mount the disk (if you ask me at /media/nameofdir
) and configure ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs
(99% of that time that would be the .config dir in your home lol) and define each XDG_***_DIR=
to the respective directory in the path of the mounted disk, no need to make symlinks, though you might need to because there is likely many apps that don’t follow xdg specs.
I would really appreciate a GUI way
I know gnome-disks has a GUI way to change the mount options, I don’t know how good it is though.
A month ago or so to be able to use zramen without root password.
I have /tmp in my fstab with these mount options.
tmpfs /tmp tmpfs rw,noatime,size=20G 0 0
And the rest of the setup is done in my zprofile
It’s empty lol, it’s a directory on tmpfs that i use to build programs and similar stuff to not be hammering my ssd with unnecessary writes.
I have $XDG_CACHE_HOME
in tmp as well and I moved the mesa sharer caches to $XDG_STATE_HOME
as that’s really the only thing so far I’ve needed to preserve.
thunar (and the smaller window is the xfce4-terminal).
zsh is actually easy and it is detailed in the archwiki
You have to set $ZDOTDIR
in /etc/zsh/zshenv
and iirc that was the only location that required root to edit.
For the rest of stuff, here is how I fix steam for example and you can check the rest of my dotfiles for how I configured zsh and all of that.
Although I haven’t updated them, I still had a .local
directory back then, it was 1 week ago that I changed .local
for Local
and that let to an issue with distrobox which I made a PR fixing it that’s still open though.
ls -A | grep "^\."
I had to make a dummy .dotfile
to test because I don’t have hidden files in my home.
Shameless flex
Speaking of doas, is there any advantage of using it when… sudo is still available to be used?
I like that its configuration file is very very simple.
Thank you for posting this @boredsquirrel@slrpnk.net
I will later see if I can convince the gearlever dev to add aisap support, since that app targets flatpak users.
Also during testing Ivan discovered something interesting in fedora, sometimes some of the xdg-user-dirs
variable for some reason were being defined as $HOME/
with a trailing slash instead of $HOME/Scrivania
(desktop) for example, even though they were clearly defined in the conf file of xdg-user-dirs
.
am
has a check in the sandbox script that unsets these variables and makes aisap use their default location when that happens to prevent giving full access to $HOME
, I don’t know if flatpak has similar measures in place.
Alpine still keeps /bin and /usr/bin separated.
And iirc the next fedora release will finally unify everything under /usr/bin.
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.
If you want my answer, this video sums it up pretty good: https://www.youtube.com/watch?v=x9qCqRTEVz0
More recently fedora pulled this move which causes headaches to everyone: https://gitlab.com/gnuwget/wget2/-/issues/661
To this day I notice that there is some skepticism with Btrfs, and I think it is because fedora also pushed it early.