• 6 Posts
  • 108 Comments
Joined 7 months ago
Cake day: November 24th, 2023
  • Samueru@lemmy.mltoLinux@lemmy.ml•40 years later, X Window System is far more relevant than anyone could guess
    1·
    1 day ago

    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).

  • Samueru@lemmy.mltoLinux@lemmy.ml•40 years later, X Window System is far more relevant than anyone could guess
    34·
    2 days ago

    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

  • Samueru@lemmy.mltoLinux@lemmy.ml•what are the pros and cons of apt vs flatpak?
    1·
    11 days ago

    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?

  • Samueru@lemmy.mltoLinux@lemmy.ml•what are the pros and cons of apt vs flatpak?
    1·
    12 days ago

    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.

  • Samueru@lemmy.mltoLinux@lemmy.ml•what are the pros and cons of apt vs flatpak?
    1·
    12 days ago

    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…

  • Samueru@lemmy.mltoLinux@lemmy.ml•what are the pros and cons of apt vs flatpak?
    11·
    12 days ago

    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.