There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

Samueru

@[email protected]

This profile is from a federated server and may be incomplete. Browse more on the original instance.

Samueru ,

Interesting that manjaro got kernel 6.9 before arch.

Samueru ,

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

Samueru ,

Btrfs

Samueru ,

Isnt fedora like the last distro that doesnt symlink /bin and /sbin to /usr/bin?

Samueru ,

In the old days distros used to separate the location of binaries in several places like /bin /sbin /usr/bin and /usr/sbin there was this idea that system binaries would go in /sbin while the rest in /bin and the similar dirs in /usr were so that you could mount a separate drive to store more binaries. This is from a time where storage was an issue.

These days distros usually just symlink all those locations to /usr/bin with the exception of fedora, which still keeps some split.

However it seems they will finally merge the remaining dirs in fedora 41: fedoraproject.org/wiki/…/Unify_bin_and_sbin

Samueru ,

(once Flatpak get that too, there is no valid reason for snaps to exist).

They said they will not fix it due to “security concerns”

Samueru ,

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.

Samueru OP , (edited )

bugzilla.mozilla.org/show_bug.cgi?id=259356

20 indeed

I use this script with librewolf, give it a try, simply place it in $HOME/.local/bin name it librewolf and export that location as first in $PATH:


<span style="color:#323232;">#!/bin/sh
</span><span style="color:#323232;">
</span><span style="color:#323232;">APPHOME="$XDG_DATA_HOME/librewolf/HOME"
</span><span style="color:#323232;">APPEXEC="$HOME/.local/opt/librewolf/librewolf" # Replace this with the path to librewolf
</span><span style="color:#323232;">
</span><span style="color:#323232;"># XDG Check
</span><span style="color:#323232;">if [ -z "$XDG_CACHE_HOME" ] || [ -z "$XDG_CONFIG_HOME" ] || [ -z "$XDG_DATA_HOME" ] || [ -z "$XDG_STATE_HOME" ]; then
</span><span style="color:#323232;">	echo "One or more XDG Base dir variables not defined, bailing out"; exit 1
</span><span style="color:#323232;">fi
</span><span style="color:#323232;">
</span><span style="color:#323232;"># MAKE FAKEHOME AND LINKS
</span><span style="color:#323232;">mkdir -p "$APPHOME/.local" "$XDG_DATA_HOME/pki" "$XDG_DATA_HOME/icons" 2>/dev/null
</span><span style="color:#323232;">[ ! -e "$APPHOME/.local/share" ] && ln -s "$XDG_DATA_HOME" "$APPHOME/.local/share"
</span><span style="color:#323232;">[ ! -e "$APPHOME/.local/state" ] && ln -s "$XDG_STATE_HOME" "$APPHOME/.local/state"
</span><span style="color:#323232;">[ ! -e "$APPHOME/.config" ] && ln -s "$XDG_CONFIG_HOME" "$APPHOME/.config"
</span><span style="color:#323232;">[ ! -e "$APPHOME/.cache" ] && ln -s "$XDG_CACHE_HOME" "$APPHOME/.cache"
</span><span style="color:#323232;">[ ! -e "$APPHOME/.icons" ] && ln -s "$XDG_DATA_HOME/icons" "$APPHOME/.icons" # Some apps have hardcoded ~/.icons path
</span><span style="color:#323232;">[ ! -e "$APPHOME/.pki" ] && ln -s "$XDG_DATA_HOME/pki" "$APPHOME/.pki" # Chromium/electron hardcode ~/.pki
</span><span style="color:#323232;">
</span><span style="color:#323232;">find "$APPHOME" -xtype l -delete
</span><span style="color:#323232;">for FILES in "$HOME"/*; do
</span><span style="color:#323232;">    FILENAME=$(basename "$FILES")
</span><span style="color:#323232;">    DEST="$APPHOME/$FILENAME"
</span><span style="color:#323232;">    if [ ! -e "$DEST" ]; then
</span><span style="color:#323232;">        ln -s "$FILES" "$DEST"
</span><span style="color:#323232;">    fi
</span><span style="color:#323232;">done
</span><span style="color:#323232;">
</span><span style="color:#323232;">
</span><span style="color:#323232;"># START APP AT APPHOME
</span><span style="color:#323232;">HOME="$APPHOME" "$APPEXEC" "$@" || notify-send "App not found"
</span>
Samueru ,

About 20 xdg-open alternatives (which is, btw, just a wrapper around gnome-open, exo-open, etc.)

I use handlr-regex, is it bad? It was the only thing I found that I could use to open certain links on certain web applications (like android does), using exo-open all links just opened on the web browser instead.

Samueru ,

$PATH shouldn’t even be a thing, as today disk space is cheap so there is no need to scatter binaries all over the place.

$PATH is very useful for wrapper scripts, without it there wouldn’t be an easy way to for fix the mess that steam does in my homedir that places a bunch of useless dotfiles in it. The trick is simply have a script with the same name as the steam binary in a location that is first in $PATH therefore it will always be called first before steam can start and murder my home again.

About /var/tmp, I just have it symlinked to /tmp, technically /var/tmp still has a reason to exist, as that location is use for temporary files that you don’t want to lose on power loss, but I actually went over the list possible issues and iirc it was mostly some cache files of vim.

EDIT: Also today several distros symlink /bin and /sbin to /usr/bin.

Samueru ,

but we still have all the other locations, symlinked there. It just makes no sense.

Because a lot of shit would break if that wasn’t the case, starting with every shell script that has the typical #!/bin/sh or #!/bin/bash shebang.

This is what plan9 does for example. There is no need for $PATH because all binaries are in /bin anyways. And to override a binary, you simply “mount” it over the existing one in place.

Does that need elevated privileges? Because with PATH what you do is export this environment variable with the order you want, like this:

export PATH=“$HOME/.local/bin:$PATH” (And this location is part of the xdg base dir spec btw).

This means that my home bin directory will always be first in PATH, and for the steam example it means that I don’t have to worry about having to add/change the script every time the system updates, etc.

Also what do you mean by mounting a binary over? I cannot replace the steam binary in this example. What I’m doing is using a wrapper script that launches steam on a different location instead (and also passes some flags that makes steam launch silently).

Samueru ,

Though in this case I would simply name the script steam-launcher and call it a day

The problem with that is that if another application tries to launch steam, it will bypass the script. And renaming the steam binary and give the original name to the script means that it has to be done every time steam is updated. Not to mention that if the script has a different name from the binary and I were to launch steam from the terminal to troubleshoot something it would also cause the issue again.

Having multiple executables with the same name and relying on $PATH and absolute paths feels hackish to me

github.com/ValveSoftware/steam-for-linux/…/1890

The last comment in that issue is mine, compare my solution to the other solutions that people came out with and you will see it is the least hacky one, before I was even trashing the steam files if it had been launched accidentally in the wrong location lol.

Also this is how snaps and appimages integrate into the system. You add their location to PATH and it is done. You don’t even need sudo to do these changes.

there are better options. I mean something like a bind mount

Do I need elevated privileges to do that?

I’m not saying we should get rid of $PATH right now.

I don’t think we should ever get rid of it, the reasons it may have been created may not be needed today, doesn’t mean it is no longer useful, like the several examples I just gave you.

Do you think the same of LD_LIBRARY_PATH? It is very useful for locally compiled applications, like i3 for example, which I compile and install into my system with a patch that is not merged into the released i3 package. Because installing it into the system /bin and /libs causes my package manager to complain that certain files already exist when updating/installing other applications.

Also do you feel the same about the XDG Base dir spec? like for example XDG_DATA_HOME, XDG_CONFIG_HOME, etc are environment variables like PATH which let you move their location around.

Samueru ,

I do, and used it today as well. My AMD gpu sometimes when booting fails to set the correct resolution on the 3rd display, and that causes the graphical session to freeze for some reason and I have to force a restart with sysreq and start the graphical session with a weird script that sets a custom res lol.

Samueru , (edited )

I love Thunar, has a ton of features + plugin support and it is very fast when opening, here is a benchmark I did on the launch time:

PCManFM (the old one): 0.15 seconds.

Thunar: 0.36 seconds.

PCManFM-Qt: 0.39 seconds.

Nemo: 0.47 seconds.

Dolphin: 0.78 seconds.

mmmm: 1.73 seconds. (I feel like I don’t even need to say which one this is lol)

Samueru , (edited )

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: imgur.com/a/WRcRWIL

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

EDIT: After being accused of misleading people by @BananaTrifleViolin 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:

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:

https://lemmy.ml/pictrs/image/2c2f3488-3dc4-4c98-a4cb-ceed9469ceda.png

And this is what flatpak uses with just firefox installed:

https://lemmy.ml/pictrs/image/fa24dfb8-ec4f-4f83-90c5-2aa943ec5fb4.png

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: 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:

madaidans-insecurities.github.io/linux.html#firej…

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

Samueru ,

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.

Samueru ,

The first app installed may seem big but often the next app will use many of the same libraries rather than redownload/reinstall them.

Do you want me to repeat the flatpak test as see if I install libreoffice along side firefox that the install size wont go from 3 GiB to 3.3GiB or more?

needs to be decompressed which causes further overhead

You don’t have to do this, you can run the decompressed appimage at the cost of increasing its size, which yeah you will have to decompress a lot of appimages before the space usage is comparable to that of flatpak.

Simple apps with few dependencies will be small, but big apps can bloat massively particularly

kdenlive is 200 MiB, is that too big for such application?

I wouldn’t want to run a web browser using a poorly maintained appimage for example

Good thing librewolf releases their appimage officially.

while every AppImage is crudely it’s own distro.

Do you think portable apps are also their own distro?

Samueru , (edited )

Wow you are really trying to mislead here.

Alright do you want to install those 15 application on flatpak and compare the space usage again? Are you 100% sure that it wont be over 4GiB if I do that? (while the appimages was 1.2 GiB I remind you).

EDIT: also, that 3GiB doesn’t include that dependencies that flatpak installed in my system lol. It is only the var dir but it doesn’t include the other stuff that flatpak pulled when it installed on my system lol.

EDIT2: I JUST INSTALLED flatpak, firefox and libreoffice, AND THE THING IS 4.4GiB NOW, HOW THE FUCK DOES LIBREOFFICE FLATPAK CAN EVEN DO THIS WTF.

Will you still say that I’m trying to mislead?

And don’t get me started on stuff like theming, lack of app updates, and downloading programs via a browser like on a Windows system.

Asif flatpak never had theming issues or lack of updates, I can tell you for example that the suyu flatpak is outdated right now while the appimage isn’t.

Also you don’t have to download appimages via a browser… why do you even bother replying if you don’t know this? I mentioned several appimage package managers in this very thread.

o 4.4 GIB

DO YOU WANT ME TO CONTINUE?

Samueru , (edited )

Holy shit my dude I just installed flatpak and firefox and it was 3 GiB like before, and then I installed libreoffice.

The var/lib/flatpak directory went from 3 GiB to 4.4 GIB

DO YOU WANT ME TO CONTINUE?

AM I STILL MISLEADING?

I installed kdenlive now, it is now 6.2 GiB, this shit is painful:

https://lemmy.ml/pictrs/image/02e33219-3233-429a-95ce-ffe2313e5db4.png

Samueru ,

Btw I just added libreoffice and kdenlive and shit is 6.2 GiB wtf.

imgur.com/gCUuW5P.png

How the fuck did libreoffice even increase the size by 1.4 GiB? the libreoffice appimage that is “its own distro” is 860 MiB uncompressed (it is 323 MiB when it is an appimage btw) , the flatpak added 1.4 GiB somehow kek.

There is nothing gained here

I use appimages because they have a lot of features that I really like, from having portable homes, taking less space than native packages, etc.

They also allow easy version control, did I run into a regresion from certain application? let me try the older appimage (this happened with ferdium to me btw).

Why use an appimage when they also have official RPM or DEB repos?

What if I’m using (I am btw) archlinux, and not that means that I need to rely on aur packages which I can’t even compile right now because my system ran into a weird bug in cmake and haven’t even been able to report because I can’t register in the cmake gitlab lol.

Also I used voidlinux for a few weeks and that really opened my eyes on how much I relied upon the aur and I made the change to switch to appimages.

and update mechanism.

I use appimages with the AM packages manager that installs them, adds a symlink to PATH, adds the desktop entry, and keeps them up to date as well.

Yes I will give you that flatpaks are safer than appimages, aur or even native packages, but from there everything else is just downsides, including performance regressions, and I don’t know about you, I don’t like that so I don’t use it, as simple as that. And it really made me mad when I saw that github thing of the other user lying that appimages bloat the system, that shit even links an article saying that firejail isn’t safe as argument against appimages, when that very article even mentions that flatpaks sandbox isn’t safe either kek.

Samueru ,

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.

Samueru ,

That is .firefox etc.

There is actually a workaround for firefox, but for flatpak you would essentially have to make flatpak have its own home dir, and that is just too much of a hack for such application. As every app being called in flatpak would be under this fakehome as well.

I guess you cannot update an app anymore when doing that.

I could make a script for am that does it btw. I’ve never had the need to do this but it is possible.

The script would run ./*.AppImage --appimage-extract the newly installed appimage, rm ./*.AppImage && ln -s ./squashfs-root/AppRun nameof.AppImage and that is it, it will work with the old desktop entry and symlink in PATH and every time the appimage gets updated it does the same thing like a pacmanhook would.

as Balena Etcher or whatever dont supply .desktop files.

imgur.com/NUZiECs.png

Samueru , (edited )

WIth the same 5 application that I had before: imgur.com/Yn5O7Ni.png

I moved it to a different partition because I had already noticed that my Btrfs filesystem level compression was makiing the size different much smaller (the root filesystem actually grew by about 3 GiB but my file manager was reporting over 6 GIB on the flatpak dir).

EDIT: Also that tool reports the flatpak size as 3.5 GiB while fastfetch reports the flatpak partition as 3.4 GIB.

EDIT2: This is after installing yuzu:


<span style="color:#323232;">~/ ./flatpak-dedup-checker
</span><span style="color:#323232;">Directories:                /var/lib/flatpak/{runtime,app}
</span><span style="color:#323232;">Size without deduplication: 5.70 GB
</span><span style="color:#323232;">Size with deduplication:    4.03 GB (70% of 5.70 GB)
</span>

It actually grew considerably for yuzu, yuzu appimage itself is 60 MiB compressed 170 MiB uncompressed.

Samueru ,

My point was that flatpaks don’t have a mechanism for updating, unless the developer builds an updater service into the program, like apps do in Windows.

Freudian slip eh.

That isn’t the amount of space it’s using. This has been explained to you. Stop intentionally misleading people.

Alright, you were right, flatpaks don’t use 6GIB for 6 applications, I am very sorry, they use 4 GIB KEK.


<span style="color:#323232;">~/ ./flatpak-dedup-checker
</span><span style="color:#323232;">Directories:                /var/lib/flatpak/{runtime,app}
</span><span style="color:#323232;">Size without deduplication: 5.70 GB
</span><span style="color:#323232;">Size with deduplication:    4.03 GB (70% of 5.70 GB)
</span>
Samueru , (edited )

You clearly don’t know what that means. Since Flatpaks do have a mechanism for updating, that statement cannot be a Freudian slip.

Why are you so mad lmao.

Flatpak is just a bloated mess, even with deduplication (Gimp increased the size to 4.8 GiB sorry 4.79GIB since I don’t want to mislead people):

https://lemmy.ml/pictrs/image/5d8137af-4011-45a7-816b-ae9ae6ebcc24.png

Again with the lies.

I have 61 flatpaks installed and it totals under 5GiB. HuR dUr FiRefOx fLatPaK usEs 3GiB

Bro, that is the size of my entire distro with the appimages included (and it also includes the home files), So yeah it is really bad kek.

Also, here what it actually uses with the suggested tool:

https://lemmy.ml/pictrs/image/fa24dfb8-ec4f-4f83-90c5-2aa943ec5fb4.png

THAT’S STILL VERY TERRIBLE and more than what 15 appimages use wtf.

Samueru , (edited )

Take 3, with the tool included (and also installed gimp):

https://lemmy.ml/pictrs/image/55df6866-f474-4511-92f4-971b4cc21ee4.png

And this is what flatpak uses when it just has firefox installed:

https://lemmy.ml/pictrs/image/fa24dfb8-ec4f-4f83-90c5-2aa943ec5fb4.png

It still uses more than 15 AppImages kek.

Samueru ,

Lol you remind me of the people that get mad when someone talks badly about their favorite video game console.

Samueru ,

Btrfs compression is filesystem wide, and it is usually zstd (the same compression that newer appimages are using, however appimages use zstd 15 by default while filesystem it is usually zstd 3 or less).

Yeah turns out that if I were to decompress all my appimages and run them that way, Btrfs filesystem compression would mitigate the issue of having several duplicated libraries.

I actually made a concept appimage for suyu that had the x86-64 v2 and x86-64 v3 binaries in it with a script that determined which binary to use depending on the system, and even though the appimage was shipping two 38 MiB similar binaries, the actual size increase in the resulting appimage was only 6 MiB thanks to the compression in the appimage.

Samueru , (edited )

Overall that also gives us ability to have multiple instances of the same app installed multiple times from different sources.

You can’t just type this like that while ignoring the fact that appimages also let you do that.

Flatpak is for desktop apps

Yeah and unfortunately I’ve already seen takes of people saying that snaps are better than flatpaks because snaps are CLI friendly and “why would I have two different systems when one does everything”, this was just a bad decision on flatpaks side.

Imo, nixos does what flatpak tries to do much better, and more importantly you can run nix alone as its own thing, while flatpak has to be on top of a existing distro.

Wayland support is intentionally broken by AppImage creator/maintainer just to be able to point finger at Wayland ecosystem and say: look - unfixable.

Link?

Also btw, wayland has been insanely broken for me, this is mostly because I’m stuck with sway as my only option though, I have 4 bug reports still open that came from two days of trying to use sway.

AppImage maintainers also showed their disappointing attitude when trying to get OBS to use it, assuming everyone will be interested in having that package format published on official projects website, while conforming to all requirements and doing the work of adjusting app to that format. To no surprise, OBS was horribly broken when built that way, and they demanded OBS devs to fix it, not getting how could they possibly not be interested in having app image, while already having well built (I use it myself, it’s great) Flatpak package.

I use OBS-studio as an appimage made by a guy that basically wraps the aur package in a junest enviroment. It is actually a whole distro in a small package at this point, the downside is that it makes this appimage 172 MiB. Which is meh. Could be better but it is better than either depending on my distro (I have ptsd from using voidlinux if you didn’t know lol) to provide me a obs-version that works, or install the whole flatpak and hope that the obs-flatpak doesn’t actually break (and this last step will be way more than 172 MiB due to the runtimes).

Flatpak does sandboxing with fine tuning abilities (using something like Flatseal or new KDE’s built-in KCM) + there is actual verification process at least for new apps on Flathub. I don’t say it’s 100% safe, but compare that to AppImages which is just running randomly downloaded binaries from the web with full filesystem access.

Cool, if only the rest wasn’t as bad.

Samueru ,

I also was at the yuzu linux-support channel before they closed down, and you have no idea how many times I saw people complaining that yuzu was broken and when I told them to use the appimage it fixed their issue every single times, there was even one case where the person wasn’t even buying what I was telling them until the moment they noticed their crashing issue instantly went away with the appimage lol:

imgur.com/p6aby3Z.png

This was because the mesa version that flatpak uses was (and likely still is) too old, and specially with amd gpus that let to users running into bugs that had been fixed for over a year in other distros.

Samueru ,

Might wanna improve the reading skills there, because I even mentioned here that appimages suck because the runtime doesn’t statically link glibc and that would improve their compatibility to 100% if they did (would work on musl distros).

going on all-caps rages

Yeah I can’t take blatantl lies like those that say that appimages bloat the system while promoting flatpaks, and I’ve already shared you enough info showing that is utterly false.

I’m considering calling you IMAX.

You’re funny lol.

Samueru ,

That vid is actually good, it exposes lots of issues that regular users run into when switching to linux, in fact debian changed apt to make it harder to remove essential packages like linus did.

On Arch to remove essential package you will not be prompted with confirmation to remove them, you will have to add --nodeps --nodeps twice to the command to be able to do so, no idea how long this has been the case on arch or if it was implemented after linus vid as well, but that is something that should have been that way a decades ago, I still see on reddit posts of people that accidentally delete grub or remove important directories from their system.

Samueru ,

I use my ksc75 daily with the headphone jack.

Samueru ,

I also have the UR20.

Samueru ,

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.

Samueru ,

Thanks, I just went down this rabbit hole and discovered xdg ninja and managed to clean most of my home, I even found a useful script that launches steam on a fake home directory on .local.

Samueru ,

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.

Samueru ,

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

What are the differences between linux distributions?

Hey guys! Trying to understand what developers actually do to create a yet another distro, or what are the differences between existing distros. Lets say we have ubuntu and fedora. What are the differences? Excluding DE, Installer, theme, installed packages/libs and package manager. They both are FHS compliant, both running...

Samueru ,

Fedora ships Btrfs and Zram by default.

web/low memory alternatives to Krita and GIMP please

recently I bought a Chromebook, I love it so much, it has Linux container enabled and I downloaded Firefox, GIMP, and Krita, but my Chromebook is only 64GB, so that can be a lot!!! So what web apps or low storage alternatives can I use?? I know Photopea, but what about drawing? Thank you!!

Samueru , (edited )

Use Btrfs partition with compression, my entire arch install takes less than 6GiB on disk space, and I have gimp, inkscape and kdenlive installed: imgur.com/HofMHUJ.png

In fact I have the OS partition limited to 35GIB. And it should have been 25GIB or less.

Samueru ,

There was a lot of misinformation about manjaro regarding the “Aur DDOS” and their finances that people still repeat to this day.

The person maintaining the manjarno repo which was a very popular site where all the critism of manjaro was recently corrected all those mistakes and then later took the website down.

Samueru ,

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.

Samueru , (edited )

the package is not there and so the AUR grabs it from the AUR as well. Perhaps it is even the Git version with an unclear version number

You will see that the aur package will use a git version and you will also be asked to remove the conflicting package when you are installing a git version.

And once again, this isn’t unique to manjaro, on my arch install yuzu broke because they were using dynarmic from the aur instead of using the one provided by yuzu itself.

Also gimp and gegl are already on both the arch and manjaro official repos, If you are using git packages and you don’t update them lots of things will break regardless if you are on any arch distro.

Now I wonder if pamac checks for updates of git packages by default, because your git packages will not be updated unless you explicitly tell yay to do so (yay --devel) I think paru every does it automatically with every update but then again most people will use yay instead.

Suffice it to say, when I used Manjaro, I got the impression that the AUR broke all the time and that using the AUR broke my install from time to time. Now that I use Arch, I do not have those issues and I realize that it was Manjaro all along.

My experience has been quite the opposite, a few months ago my install broke to the point that I could not update the system, turns out it was because of the arch migration and my system wasn’t incorporating the new pacman.conf.new.

Samueru ,

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.

Samueru ,

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:


<span style="color:#323232;">[zram0]
</span><span style="color:#323232;">zram-size = ram
</span><span style="color:#323232;">compression-algorithm = lz4
</span><span style="color:#323232;">swap-priority = 100
</span>

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

Made the switch to KDE

I’ve been using Fedora for a couple of months now, and have been loving it. Very soon after I jumped into this community (among other Linux communities) and started laughing at all the people saying “KDE rules, GNOME drools,” and “GNOME is better, KDE is for babies.” But then I thought, “Why not give KDE a try? The...

Samueru ,

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: gitlab.gnome.org/GNOME/gimp/-/issues/9907

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

Samueru ,

As long as you only keep the Manjaro repos in your system, it is like using it on Arch, which even you Arch the Aur isn’t perfect.

Because the Manjaro repos don’t sync at the same time with the Arch repos, you might not be able to install/update some Aur packages as the version of X dependency might not match during that time.

But literary, Manjaro has been the most stable distro I’ve run, even more stable than Arch that recently broke on my system and required manual intervention because of their recent changes on their repo migration.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • lifeLocal
  • goranko
  • All magazines
    •