Alpine still keeps /bin and /usr/bin separated.

And iirc the next fedora release will finally unify everything under /usr/bin.

Yeah I meant this: https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin

https://github.com/mgord9518/aisap/blob/main/profiles/profile_database.json

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.

There is usually misunderstanding behind this type of questions. for example "why isn't ilike on macos where it is ~/.Trash" and then one has to explain what XDG_DATA_HOME is and why it makes sense for trash to be there (And that it doesn't have to do with the desktop environment as well).

Or op just lost something important thinking that the trash was somewhere else.

Btrfs

We need something like this for home, I hate that programs like steam and firefox place themselves directly into home instead of ~/.config and ~/.llocal.

I even move my personal themes to /usr/share/themes because not everything works with ~/.local/share/themes and needs a ~/themes directory instead.

This is really bad lmao.

flatpak is bloated mess. It basically installs a whole distro onto your existing distro.

That person is also lying very badly by saying that appimages bloat the system... they are actually even smaller than native packages due to their compression (like for example the entire libreoffice suite being 300 MiB while a native package is 600 MiB).

This is the space that flatpak takes to install firefox, just firefox: https://imgur.com/a/WRcRWIL

While this is 15 appimages, that includes libreoffice, kdenlive and two web browsers: https://imgur.com/a/YxjUYdt

EDIT: After being accused of misleading people by @BananaTrifleViolin@lemmy.world I decided to install firefox, libreoffice and kdenlive to flatpak, just those 3 applications, because I was told sure the deduplication was going to do miracles:

https://imgur.com/ExH84gV.png)

)6.2 GIB WTF** (15 appimages was 1.2 GiB once again kek, how can flatpak be this bad lmao)

EDIT2: This actually isn't the real size, I moved the flatpaks to their own partition and checked that instead:

Alright I just moved flatpak to its own partition and checked the size of the partition instead:

with firefox, kdenlive and libreoffice:

Disk (/var/lib/flatpak) 2.69 GiB / 19.12 GiB (14%) - ext4

That’s much better now. But still twice the size that 15 appimages took.

This is with now having firefox librewolf brave kdenlive and libreoffice:

Disk (/var/lib/flatpak) 3.40 GiB / 19.12 GiB (18%) - ext4

Still though, the appimages take less space. A by a large margin.

Flatpak is just a bloated mess, even with deduplication:

And this is what flatpak uses with just firefox installed:

Sorry for misleading people, turns out flatpak doesn't use near 3X as much as 15 AppImages when it just has firefox installed (which once again those 15 AppImages use 1.2 GIB). It just uses 1.35GiB when it has a single app kek.

On top of that flatpak is not terminal friendly, you have to start everything with flatpak run org.etc.etc (this also breaks scripts that expect the simple binary name in PATH).

Flatpak is also non XDG base dir compliant, and they said over and over that they wont fix that issue: https://github.com/flatpak/flatpak.github.io/issues/191

This person is complaining that appimages suck because you have to put the desktop entry yourself, when apps like am or zap and appimagelauncher do it for you lmao. (And at least am also makes a symlink in PATH so it fully integrates the appimage unlike flatpak ever will)

EDIT: That github link is really bad, it even links this article for saying that sanboxing with appimages isn't secure:

https://madaidans-insecurities.github.io/linux.html#firejail

WHEN THAT VERY LINK SAYS THAT FLATPAK ISN'T GOOD EITHER, it even calls out the flatpak devs for it.

Foobar2000, it is the only windows app that I miss.

Deadbeef is close but it is missing several features, it can't even encode using more than 1 cpu core lol.

Koss KSC75, I've been using them for almost 10 years now.

Interesting that manjaro got kernel 6.9 before arch.

I find it funny that thumbnail with a "fail" I'm actually surprised that it got 48% right.

I like flatpak as it helps me keep bloat down

Impossible. Like flatpak itself with 5 applications was using more storage than my entire distro with the same apps as appimages on top.

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.

The AUR doesn't assume arch packages, if the package your aur script wants isn't in your repo then the package simply fails to update/install.

Edit: This is true even for Arch linux, as the Aur package might be out of date.

Avoid Ubuntu and Manjaro: despite being marketed as “beginner friendly distros”, and despite often running perfectly fine, these two have major issues in management, packaging policies or philosophy that might make your life as a beginner difficult.

That makes no sense. Manjaro is actually one of the few distros where a beginner won't need to touch the terminal ever. You won't have to deal with adding PPAs or removing snaps like in several debian/ubuntu based distros.

https://wiki.hyperbola.info/doku.php?id=en:philosophy:incompatible_packages

I just want to know what did conky do to get in that list lol

They actually stopped using the linux kernel all together as well.

May I know why did you ask this?

Edit: Why didnt people like this comment lol

because the UX of using a sandboxed CLI app sucks

I think it is more because of this issue because as far as I know snaps have some level of sandbox and you can still use CLI apps as you said.

Also endeavour is not really arch with a graphical installer, or that is what I've seen at least.

I tried to help someone once that installed endevouros and for some reason their kernel parameters were being overwritten every time they updated, turns out that was an issue because endeavour installed dracut instead of mkinitcpio by default? I don't know wtf was that. They ended up switching to arch after that lol.

Also their /efi directory was set as read-only to the root user, meaning that to even see if their kernel parameters were there they needed sudo lol

I don't use bash. As there is no way to fix bash leaving dotfiles in home lol.

I use zsh with $ZDOTDIR set to $XDG_CONFIG_HOME/zsh and there my .zprofile contains my environment variables that I posted. zsh is my login shell so they get applied once I login.

But you made a good point, I will test defining XDG_CACHE_HOME in /etc/profile just to see if that fixes the issue.

Gimp 3 alpha is pretty crazy, as GTK2 was very nice and usable, but already with GTK3 everything got huge, so now the buttons dont fit as well anymore.

I reported that issue to gnome a while ago: https://gitlab.gnome.org/GNOME/gimp/-/issues/9907

Hopefully they will fix it one day because it means I wont be using gimp 3 otherwise.

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.

How are they going to stop using zenity? it is a dependency of steam. And right now the gtk4 version needs a bunch of hacks to follow the system theme as well.

Appimages also install another distro onto your system. May be small,

Would you say portable builds (like deadbeef) also install another distro onto your system? This is what appimages primary replace...

If they use compression, you replace disk space with CPU power.

You can also extract the appimage and run the AppRun script, comes with the downside that it increases the size of the appimage but you don't have that trade off anymore if that is a problem. And yeah you will have to umcompress a lot of appimages before the space usage is comparable to that of flatpak lol.

And that on a 1TB drive is just not important.

Yeah but there is a big difference in saying that appimages bloat the system when they DO NOT, and now dismissing? flatpack usage it as "is just not important" wtf.

Yes they break that strange XDG idea, and that makes sense

Is it strange idea to not want my home cluttered by a bunch of useless top level dotfiles?

Appimages can be placed in ~/.local/bin/ which makes them kinda okay for terminal use. But none of the formats is terminal friendly

Package managers like AM automatically place the appimage in /opt and make symlinks to /usr/.local/bin (it also keeps the appimage up to date by comparing the version from that of the repo). I use it for terminal apps like amdgpu_top, which ships as an appimage by the creator themselves.

It also has a portable mode called 'appman', I use this one and I drop my appimages in ~/.local/opt and it automatically makes symlinks to ~/.local/bin (this last one is also a XDG location btw).

Both also automatically install the desktop entry to the appimage, something that seems to be too hard for the person that made that github thing. There is also zap and appimagelauncher for that. And even gearlever for the flatpak users that want to use appimages.

CLI stuff is not covered but that is also okay.

It is not ok at all, flatpak could be much better but they don't want to fix it, that is the issue, and I haven't gone into the performance issues you can have with flatpak because like in the case of yuzu, the flatpak was compiled for x86-64 generic while the appimage was x86-64 v2, and it also had a bunch of issues because flatpak ships its own version of mesa iirc. Honestly if I'm forced to choose one thing out of everything, it would likely have to be nix, and nix has the small issue of not being FHS compliant lol. So yeah it really sucks.

appimages could also be much better, if the runtime statically linked glibc they would also work on musl distros which is a shame they don't.

Alright, here is an update.

before starting sway: https://i.imgur.com/ZcePiEa.jpeg

after starting sway: https://i.imgur.com/TocM2dC.jpeg

I use my ksc75 daily with the headphone jack.

Windows 11

Also maybe there are programs that does not respect XDG and have hardcoded paths to ~/.cache.

That's what I'm thinking, and it seems that program is all wayland compositors for some reason, there is likely a hardcoded path to ~/.cache what else could be making a ~/.cache/mesa_shader_cache directory when logging in that doesn't happen on X11?

I made sure XDG_CACHE_HOME was set before starting sway and it still happens: https://lemmy.ml/post/16201068/11319192

Deadbeef is getting there, but yeah it is still missing features: https://imgur.com/rBeurjO.png

This is another issue with:

https://github.com/flatpak/flatpak/issues/46

https://github.com/flatpak/flatpak.github.io/issues/191

https://github.com/flatpak/flatpak/issues/1651

Others like valve have just ignored the issue for years, but the flatpak devs decided to argue that it doesn't apply to them, to the point that one even mentioned modifying the spec so that they are exempt...

But that’s not how politics work, you always have to compromise somewhere

THAT IS how politics works. You have to always try to make as much noise in getting what you want with the hopes that once it comes to a compromise somewhere you end up in a better position.

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.

Try using yuzu-mainline-git from the aur and change your compile flags (edit makepkg.conf) to match=native mtune=native and O3. That gives a 15% boost in totk.

Also use zram instead of zswap as that that causes terrible stuttering on yuzu if you are short of ram. The usual recommendation is to use zstd compression but I can tell you that lz4 performs better on yuzu.

"sudo pacman -S zram generator" then "sudo nano /etc/systemd/zram-generator.conf" and paste this:

[zram0]
zram-size = ram
compression-algorithm = lz4
swap-priority = 100

Also make sure you are running gamemode with yuzu. Same with steam games.

I mean I use bash for some of my scripts, but I mostly try to keep them POSIX compliant, and yes I also use dash as my sh. zsh is just my interactive and login shell, which by being the login shell I export all my variables on .zprofile instead of what you are doing with the sway wrapper.

I also try to use mawk instead of gawk as that one is even faster than dash. (And in some tests, even faster than C++ btw), check this out if you want: https://github.com/Samueru-sama/dotfiles

I just went with zsh because I first tried to get bash to work and couldn't lol.

I have .librewolf (if you want to not have this(this approach works with pretty much all firefox derivatives/family), then make a script, which basically launches librewolf with different home, like HOME=$XDG_DATA_HOME librewolf (or wherever you want),

https://github.com/Samueru-sama/dotfiles/blob/main/.local/scripts/xdg-hammer/librewolf.sh

I also use this one with steam: https://github.com/Samueru-sama/fixsteam/blob/main/steam

touch ${XDG_DATA_HOME}/bash-history

You may wanna move that to either XDG_CACHE_HOME or XDG_STATE_HOME (couldn't hold my xdg vigilantism sorry).

No steam doesn't run when starting. The same programs when I start i3 which does not have this issue are the same programs that start when I start sway, as sway uses my i3 configuration.

I've also tested hyprland and cosmic and both of those have that issue as well.

Worth mentioning that when I'm on x11 ~/.cache never gets created, even when I run apps that use mesa.

I moved from a gtx 1060 to an RX580 and it has been terrible, recording in obs is horrible to the point that the cpu yields better results and now a recent kernel version broke the power meter on all the polaris gpus.

Wanna know something? I've been trying for about 5 months to fix this issue without success. I appreciate the help.

I haven't bothered to report this because A) I don't know who to report this to as I'm not sure what is creating the directory, and B) I've already reported other issues I've run into when using sway that were just ignored.

I have good news, looks like this issue actually just sway only issue, it just happened that on archlinux all the other wayland compositors also have this issue lol. https://lemmy.ml/post/16201068/11320955

Now I know who to report this to.