target OS is debian or linux mint

  • @boredsquirrel@slrpnk.net
    link
    fedilink
    15 months ago

    There’s: https://flathub.org/apps/org.gnome.gitlab.YaLTeR.VideoTrimmer

    This has an empty ffmpeg folder but no binary. Same with bottles, guiscrcpy, celluloid, newsflash, interstellar, digikam, haruna, krdc, obs studio,

    But searching for “ffmpeg” I found io.github.aandrew_me.ytdn

    It has the ffmpeg binary included.

    Many projects use libffmpeg.so dont know if that could be used too.

    I got a bunch of weird bugs with Distrobox in the beginning

    Honestly never had issues. I now use an Arch distrobox too, but I dont really need Distrobox anyways. The Arch repos are too small.

    There is a COPR for RStudio-copr-manager and the entire CRAN module list as RPMs. Otherwise you have a hard time getting the R plugins you may need to your distro.

    QGis needs some python integration which seems to be missing on Arch too.

    With the COPR I know who to trust, unlike the AUR, even though I now also setup yay.

    Everything nearly separated from my OS using the different distrobox homedirs which work flawlessly.

    Also distrobox upgrade --all works awesome its just a wrapper but really valuable.

    I make an exception for Anki and MakeMKV.

    I have no idea because I install everything from unverified. Should learn how to swap remotes, then I could swap all the verified apps and when removing the unverified can check what I still use.

    But unverified Flatpaks may be way better than distro packages. At least it is very transparent on Github (yeah, sucks) unlike strange distro build systems.

    I kind of hate Debian and Ubuntu’s userpsace :)

    What, GNU utils? What makes it special, apart from apt? They have nala so that is dealt with.

    DNF5 will definitely shake things up. Because rpm-ostree is going away to be replaced by dnf again.

    Yeah this will be crazy. dnf has a lot more commands for querying etc, that will be useful.

    It also sounded like they would reinvent the wheel a bit? Dont know

    • This has an empty ffmpeg folder but no binary

      That’s strange. I downloaded it just now and converted a video. It’s not in /app/bin but in /usr/bin instead. I know for a fact it relies on the ffmpeg binary inside the code. You can even access it using flatpak run --command=ffmpeg org.gnome.gitlab.YaLTeR.VideoTrimmer.

      The Arch repos are too small.

      Eh, I’ve never felt that way. Even on my Arch system, I only have 15 packages from the AUR and 2134 packages installed from the repositories. But it’s probably smaller than you’re used to if you’re coming from Debian or Fedora.

      Many projects use libffmpeg.so dont know if that could be used too.

      That library is designed for development as far as I’m aware. I noped out very quickly when looking at the documentation for using ffmpeg libraries :) I think that’s why VideoTrimmer relies on the binary instead of the library too.

      With the COPR I know who to trust, unlike the AUR, even though I now also setup yay.

      I take a different view: I don’t trust anybody, but I read the PKGBUILDs and understand them. They’re often not complicated. I don’t particularly like the AUR much anymore though for this reason.

      Everything nearly separated from my OS using the different distrobox homedirs which work flawlessly.

      I did try this for a while but I couldn’t get used to it. And programs can bypass it anyway with /home/$USER if they’re feeling vindictive, though I haven’t run into any yet. It’d definitely be nice to have more complete isolation one day.

      Also distrobox upgrade --all works awesome its just a wrapper but really valuable.

      100% yes. Be nice to have that in Toolbox one day.

      But unverified Flatpaks may be way better than distro packages. At least it is very transparent on Github (yeah, sucks) unlike strange distro build systems.

      I’m with you there. I can understand PKGBUILDs but everything else is just far too complex for me. Or unfamiliar. The docs for packaging Fedora RPMs is scary as hell.

      What, GNU utils? What makes it special, apart from apt? They have nala so that is dealt with.

      To be honest, it’s mostly apt. I really hate apt. I am also not very familiar with how the system is configured. It’s very different from Arch, anyway. I can just never feel at home on an Ubuntu system even in a container, but I do run it on servers.

      I’ve downgraded my “hate” to “it’s fiiine”.

      Yeah this will be crazy. dnf has a lot more commands for querying etc, that will be useful.

      It also sounded like they would reinvent the wheel a bit? Dont know

      I really have no idea what to expect. But if I never need to use rpm for querying or whatever again I’ll be happy.

      • @boredsquirrel@slrpnk.net
        link
        fedilink
        1
        edit-2
        5 months ago

        That’s strange

        Seems you can use all the libraries too as if they were binaries. Updated my Fedora post.

        Currently testing how to run the freedesktop.org runtime with home permission, this would allow to not give any app permanent home permission.

        But wait, you can run apps with different permissions temporarily, right?

        Like flatpak run --filesystem=home org.app.name

        but I read the PKGBUILDs and understand them.

        That is the best way but not scalable for most users. You need access control and trust. On COPR I add the repo of an individual and only get packages from them.

        And programs can bypass it anyway with /home/$USER if they’re feeling vindictive, though I haven’t run into any yet. It’d definitely be nice to have more complete isolation one day.

        This is not about isolation, even though this should totally be done. Its just about preventing dotfile mess.

        Scalable, you know. A system should stay vanilla in 20 years, in 40 years.

        In the end it would be

        • core minimal system
        • /etc has some settings pinned or none at all, the rest is always flushed from /usr/etc (issue)
        • the immutable rest is always upstream
        • the bootloader is updated with bootupd
        • flatpaks have their configs isolated, when they are uninstalled, their data is removed
        • distroboxes are ephemeral, they are used for tasks, managed through a GUI app with a set of commands (like “add this repo” and packages to install, or even building blocks or checkboxes), they are recreated with OS releases
        • the distroboxes have their own dotfiles which never overlap
        • the desktop has figured out a way to cleanup old dotfiles

        I mean we are not there yet, but close.

        I really hate apt.

        Apt is an ugly mess and nala might be python bloat but it looks fancy and automates things. Now that it runs on Debian 12 I installed it everywhere.

        I really have no idea what to expect. But if I never need to use rpm for querying or whatever again I’ll be happy.

        Yeah or add curl instructions to projects like librewolf, to avoid needing “oh and on atomic distros you dont use ‘dnf blabla’ but download it directly”.

        Even though I like my COPR command…