I’m very familiar with you, haha. You keep popping up wherever I go these days. You’re everywhere. Maybe not quite as omnipresent as Neal Gompa.
I can think of a few Flatpaks that could fit on that list.
They dont include that? I thought they would…
It’s the same old story with codecs. Fedora would love to support as many codecs as possible, but H.264 is patent-encumbered so they can’t. They had hardware decoding support through Mesa a few years ago but then they…changed it.
Fedora Atomic wants to include the OpenH264 enablement package for Firefox inside the Fedora Flatpak eventually which will solve most of the problem as that is where people are playing H.264 most often.
So this is an issue with reproducability? I dont think so? Cisco builds the binaries for Fedora and it gets installed. The packages are not from their repos, but the typical sync issues would not occur on Atomic.
My understanding is OpenH264 is provided in binary-only format to Fedora because otherwise the royalty-free license cannot apply (i.e. Fedora can’t build it from source). Fedora only ships free software. OpenH264 is free software. But it’s binary-only. So they need to trust Cisco has built the binary correctly. I assume the reason they don’t include it by default is because the only way to trust it’s built from the same sources is to reproduce the build. Otherwise, I really don’t see the issue.
OpenH264 is not a part of the base system so you need to layer it on. OpenH264 doesn’t have support for High 10 Profile video which is fairly common off the web and is generally inferior to x264, I’ve found, but at least it’s something.
And the reason I mention “5 years” is because by then, most of the patents on H.264 will have expired. With the exception of the new ones from just a few years ago that no one really uses. Maybe Fedora can enable x264 in their ffmpeg build then and we can stop talking about it. I am so sick of talking about H.264.
I use Fedora kinoite-main from uBlue which is very close to upstream but fixes many issues for me.
Call it a personal challenge or whatever but I’m sticking to Fedora Silverblue for the foreseeable future. uBlue is almost certainly a better experience for most people.
Yeah for sure, I think for Intel and AMD too, hardware h264 for example.
That’s not true if you’re using Flathub packages. Flathub ships userspace Mesa drivers which enable hardware decoding for Intel and AMD GPUs even with H.264 and H.265.
but their base images have a ton of stuff I dont agree with (toolbox, missing random packages, too simplistic installer…)
uBlue does solve the two big issues with Fedora, which is codecs and proprietary NVIDIA drivers. Any other issues are tiny in comparison. I will say I prefer Toolbox to Distrobox, despite using Distrobox first. I certainly understand that’s an unpopular opinion and not one a lot of people share. It’s probably the same reason you use KDE and I use GNOME (most of the time).
I’ve always hated the Fedora installer. Does uBlue do something different?
Funny, I use that name not so long. Currently hyperfocused on Fedora Discuss, Lemmy and Github.
Although I should really change my stuff to some Forgejo instance and just mirror to Github.
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.
I wonder how Tor, Tails and others handle their code stuff. Apart from selfhosting their services of course. Like resiliance, I think decentralized code repos are crucial.
I really like how uBlue just used the official Fedora OCI images (that they produce but dont even use) and used all the container tooling to create this awesome project.
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.
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.
H.264 is patent-encumbered so they can’t
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.
inside the Fedora Flatpak
Not sure if that is the best way. Flatpak has runtime extensions, and rpmfusion could build one for the entire ffmpeg and more. This could just be added from an external repo and installed along.
Or they include openh264 in their runtime.
Fedora Flatpaks got quite a boost recently and even have some KDE apps not on Flathub.
the only way to trust it’s built from the same sources is to reproduce the build.
Well… rpmfusion could do that? And act like a “3rd party auditor” ?
doesn’t have support for High 10 Profile video which is fairly common off the web
Interestesting, never heard that. I use Celluloid Flatpak which is pretty great (I wish Haruna would get their basics together like customizable UI, working subtitles, working queue etc).
So the only reason to have ffmpeg is nice terminal stuff, Dolphin extensions or just video previews in Dolphin. Nautilus supports that via a Flatpak right? Thats cool.
we can stop talking about it. I am so sick of talking about H.264.
Fuck patents. I am happy that we now have AV1 and dont really know why VP9 is not more used? It is a pain!
Call it a personal challenge or whatever
I have a command text file with the exact command I need to reproduce my install. One for Fedora Kinoite, one for Kinoite-main.
It is just a few packages and I really only need the things I mentioned.
I also dont like Aurora or others that much, they have too much stuff added.
That’s not true if you’re using Flathub packages.
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.
prefer Toolbox to Distrobox
Interesting, why? I need to try it again.
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.
It’s probably the same reason you use KDE and I use GNOME (most of the time).
Why? Curious.
No uBlue uses Anaconda too, which is a whole set of stuff. They are testing the new UI (a component of Anaconda) for workstation exclusively.
uBlue pioneered in making Anaconda work for installing OCI rpm-ostree btw
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 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
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.
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.
I’m very familiar with you, haha. You keep popping up wherever I go these days. You’re everywhere. Maybe not quite as omnipresent as Neal Gompa.
I can think of a few Flatpaks that could fit on that list.
It’s the same old story with codecs. Fedora would love to support as many codecs as possible, but H.264 is patent-encumbered so they can’t. They had hardware decoding support through Mesa a few years ago but then they…changed it.
Fedora Atomic wants to include the OpenH264 enablement package for Firefox inside the Fedora Flatpak eventually which will solve most of the problem as that is where people are playing H.264 most often.
My understanding is OpenH264 is provided in binary-only format to Fedora because otherwise the royalty-free license cannot apply (i.e. Fedora can’t build it from source). Fedora only ships free software. OpenH264 is free software. But it’s binary-only. So they need to trust Cisco has built the binary correctly. I assume the reason they don’t include it by default is because the only way to trust it’s built from the same sources is to reproduce the build. Otherwise, I really don’t see the issue.
OpenH264 is not a part of the base system so you need to layer it on. OpenH264 doesn’t have support for High 10 Profile video which is fairly common off the web and is generally inferior to x264, I’ve found, but at least it’s something.
And the reason I mention “5 years” is because by then, most of the patents on H.264 will have expired. With the exception of the new ones from just a few years ago that no one really uses. Maybe Fedora can enable x264 in their ffmpeg build then and we can stop talking about it. I am so sick of talking about H.264.
Call it a personal challenge or whatever but I’m sticking to Fedora Silverblue for the foreseeable future. uBlue is almost certainly a better experience for most people.
That’s not true if you’re using Flathub packages. Flathub ships userspace Mesa drivers which enable hardware decoding for Intel and AMD GPUs even with H.264 and H.265.
uBlue does solve the two big issues with Fedora, which is codecs and proprietary NVIDIA drivers. Any other issues are tiny in comparison. I will say I prefer Toolbox to Distrobox, despite using Distrobox first. I certainly understand that’s an unpopular opinion and not one a lot of people share. It’s probably the same reason you use KDE and I use GNOME (most of the time).
I’ve always hated the Fedora installer. Does uBlue do something different?
Funny, I use that name not so long. Currently hyperfocused on Fedora Discuss, Lemmy and Github.
Although I should really change my stuff to some Forgejo instance and just mirror to Github.
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.
I wonder how Tor, Tails and others handle their code stuff. Apart from selfhosting their services of course. Like resiliance, I think decentralized code repos are crucial.
I really like how uBlue just used the official Fedora OCI images (that they produce but dont even use) and used all the container tooling to create this awesome project.
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.
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.
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.
Not sure if that is the best way. Flatpak has runtime extensions, and rpmfusion could build one for the entire ffmpeg and more. This could just be added from an external repo and installed along.
Or they include openh264 in their runtime.
Fedora Flatpaks got quite a boost recently and even have some KDE apps not on Flathub.
Well… rpmfusion could do that? And act like a “3rd party auditor” ?
Interestesting, never heard that. I use Celluloid Flatpak which is pretty great (I wish Haruna would get their basics together like customizable UI, working subtitles, working queue etc).
So the only reason to have ffmpeg is nice terminal stuff, Dolphin extensions or just video previews in Dolphin. Nautilus supports that via a Flatpak right? Thats cool.
Fuck patents. I am happy that we now have AV1 and dont really know why VP9 is not more used? It is a pain!
I have a command text file with the exact command I need to reproduce my install. One for Fedora Kinoite, one for Kinoite-main.
It is just a few packages and I really only need the things I mentioned.
I also dont like Aurora or others that much, they have too much stuff added.
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.
Interesting, why? I need to try it again.
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.
Why? Curious.
No uBlue uses Anaconda too, which is a whole set of stuff. They are testing the new UI (a component of Anaconda) for workstation exclusively.
uBlue pioneered in making Anaconda work for installing OCI rpm-ostree btw
Looks like we frequent the same circles, then.
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.
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.
That’s a nice idea. I wonder if Sourcehut does container registries…I know people praise their CI.
I know Tor uses Gitlab. Seirdy has an article series on “Resilient Git”.
Yes, however it only covers their implementation (which is lacking) and it only covers binaries they create.
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.
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
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
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.
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.
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.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.
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+ESCso 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.