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.

Looks like we frequent the same circles, then.

I thought a lot about tech resiliance in the last days, I am from germany and the people here are stupid. They literally elect people that will make a neofascist surveillance hell reality.

But hey, Germany was responsible for the Sovereign Tech Fund, which has made a big difference for GNOME and accessibility with the Newton stack. So it's not all bad. Not that I live there.

But relying on Github is insane, it is owned by Microsoft and they dont give a damn about freedom. It is pretty scary, 90% of my Android apps are also on Github.

That's the main reason I don't use uBlue. The idea of booting my entire operating system from a container created on Github's infrastructure is just...it scares me. Even though much of the free software I rely on is hosted on Github. And yes, most of my Android apps are also from Github.

I want to build my own variant, KDE and minimal only, maybe GNOME if contributors join. But no more, all the freedom is great but it is huge maintenance.

That's a nice idea. I wonder if Sourcehut does container registries...I know people praise their CI.

I wonder how Tor, Tails and others handle their code stuff.

I know Tor uses Gitlab. Seirdy has an article series on "Resilient Git".

I thought Ciscos trick could fix that? They are a huge company, pay the max amount of money already and can just share the software with their license to anyone.

Yes, however it only covers their implementation (which is lacking) and it only covers binaries they create.

Well… rpmfusion could do that? And act like a “3rd party auditor” ?

I'm thinking about Fedora including the build in their own repositories. It would be really nice if H.264 decoding was just default and you didn't need to do anything.

doesn’t have support for High 10 Profile video which is fairly common off the web

Interestesting, never heard that.

See the following thread for all of the research I did: https://discussion.fedoraproject.org/t/h-264-support-in-fedora-workstation-by-default/114521

Michael Cantazaro had a really helpful and enlightening response: https://discussion.fedoraproject.org/t/h-264-support-in-fedora-workstation-by-default/114521/5

I use Celluloid Flatpak which is pretty great

So do I. But keep in mind there are two Celluloid Flatpaks you can install; one is from Fedora Flatpaks which disables H.264/H.265/VC-1 decoding and the other is from Flathub with all features enabled.

GNOME Software tends to select Fedora Flatpaks first. So users can end up really confused; see: https://github.com/flathub/io.github.celluloid_player.Celluloid/issues/140

Nautilus supports that via a Flatpak right? Thats cool.

File previews are supported via the Sushi extension, which is available as a Flatpak. Obviously, it doesn't work on H.264/H.265/VC-1 media because it's a Fedora Flatpak.

I really need ffmpeg because it's a crucial part of my workflow because I convert so much media. But that's fine; I just use it in a Toolbox.

But Nautilus works really well as a Flatpak. It even seems faster than non-Flatpak Nautilus and I have no idea why.

True, Flatpak is cool. Dolphin is also available as one, I need to test if it works with Flatpak ark and all that, udisks2, mounting stuff, MTP, maybe SMB.

KDE made a big push to make all of their programs available as Flatpaks. And Snaps. Which I think is great. But you end up in a weird situation where the Krita Flatpak is not officially supported by Krita because no one at Krita works on maintaining the Flatpak. Rather, they support only AppImage officially, probably because it's easier to maintain their insane patchset than with Flatpak. Not having any experience with distribution systems aside from Flatpak, I really don't know what niceties Snap or AppImage provides.

Interesting, why? I need to try it again.

Nothing much has changed since last you commented on that Toolbox thread I was reading :)

I think Toolbox is the right way to solve the problem. It's using a real programming language (Go) instead of bash, it supports a small set of important container images, and those container images are only provided from quay.io, Red Hat's own infrastructure, instead of Docker Hub.

But it lacks some features intentionally (and some just because they haven't gotten around to it). Like distrobox export. Annoying to manually patch in but not hard. I use Toolbox for Signal and Steam because I don't want to use Unverified Flatpaks.

Do you know btw how to upgrade a F39 distrobox to F40? Distrobox has some “assemble” function to rebuild it with a config file. But traditional dnf system-upgrade doesnt work.

I don't think upgrading Distroboxes or Toolboxes is supported. They're meant to be destroyed and re-created. Really inconvenient, but I guess the proper way of maintaining toolboxes/distroboxes is through Containerfiles.

So I don't use Fedora containers. Or Ubuntu containers. Or Debian containers.

I use Arch because it's a rolling release and you just keep updating it. No upgrade problems so far...aside from all the errors I ignore (everything seems to work fine). Also, I really like the Arch userland and it has Signal Desktop in the official repositories.

It really makes me feel at home on Fedora.

It’s probably the same reason you use KDE and I use GNOME (most of the time).

Why? Curious.

I think GNOME provides a more coherent and consistent experience for users. I'm okay with not having features like a system tray, desktop icons, or window buttons I never use. I really love GNOME. It's changed the way I use computers and has made everything aside from KDE feel like a completely inferior experience in comparison.

But I use KDE for my multi-monitor system because frankly, GNOME is an awful experience if you have more than one monitor with different resolutions. KDE kind of sucks too, but it's not completely broken. KDE is practical by solving problems we have now, like letting XWayland applications scale themselves. Because even if it's a total hack that works inconsistently, it works very well for most of the software I use. I find parts of KDE overwhelming (especially the System Settings) but hey, it works.

I like both KDE and GNOME and think each has their own strengths. It's nice to see KDE adopt one of GNOME's killer features (partially), the Overview. It'd be nice to see GNOME adopt a KDE feature like CTRL+META+ESC so I can kill windows graphically even on Wayland.

But god GNOME is annoying when it comes to protocol standardization. At least they're finally implementing DRM Leasing for VR users (not me).

Huh. I thought I was supposed to be sticking up for GNOME. Alright, I use GNOME everywhere else and it's still my favorite desktop by far. They focus on a great experience with what works great now. There are very few hacks in GNOME land. I just think they need to catch up to KDE with Wayland and other areas like the multi-monitor stuff.

Those instances defederated from lemmy.comfysnug.space. @neo@lemmy.comfysnug.space contacted them and a few others about refederating a few months ago; I don't know the current status.

Relevant threads:

• https://lemmy.comfysnug.space/post/305019
• https://lemmy.comfysnug.space/post/334195

I now finally know why Rocket League updates more often for me (1-2GB of updates) than my friend on Windows.

I don't really have a least favorite distribution. I mean, I guess between Fedora, Ubuntu, Debian, Mint, openSUSE, Manjaro, and Gentoo, the least appealing choices to me are Manjaro and Gentoo. Manjaro is just Arch but worse, because the packages are old and likely to cause incompatibilities with AUR packages that need really up-to-date system packages, and I...don't trust the maintainers to have configured everything better than I could have myself. Just based on history.

Debian has ancient packages. That's the only reason. I'd just end up using Flatpak packages or compiling from source.

Any other distribution I could use, including Gentoo, but Arch is the sweet spot for me.

That would be the logical conclusion, but I believe Debian uses the old version for years after it's unsupported and might backport security fixes depending on how severe they are. Either way, I personally wouldn't trust Debian or Ubuntu to properly fix security issues with a program (or in this case, programming language) that they do not actively develop or maintain themselves.

It's good to see you guys on Lemmy :)

I tested it a bit a few days ago, but I'll see if I can give it a more rigorous go today. The ones I've found Mojeek to be weak in are bug strings that programs I'm working with spit out. Although I think I've had more luck in the past few months.

I'm from an instance that does not federate with lemmy.world or sh.itjust.works, so users from those instances won't see this post. If you think this news is worth sharing and you're from an instance that federates with lemmy.world, please consider sharing it on !linux_gaming@lemmy.world

As someone who recently worked on a Github wiki...it leaves much to be desired. The first being that I couldn't actually push with git! I needed collaborator access for that. I also find Github's markdown flavor to be limiting; you can do a lot more with a dedicated Wiki like MediaWiki. It was okay for viewing, though. And having the docs in an actual repository is much harder to navigate for users who aren't developers.

So while it's something you see a lot, I think they would be easier to collaborate on and view on a dedicated wiki.

I think a dedicated wiki makes more sense for what is, essentially, documentation.

I was buying a new laptop subsidized on 80% store credit, so I could only go for what they had in stock, unfortunately. I still haven't had a single computer with an AMD GPU, but iGPU laptops give me a taste of what things could be like without NVIDIA...

The nature of the software I was writing was inter-dependent on other functions, so it needed to understand the surrounding context, which was difficult to coach it on. Its strength is definitely in isolated examples.

I've been using Kagi's Discuss Document feature for some things, like understanding documentation or an API. It's pretty useful. Also works on videos/files like PDFs.