12 ms·

The OBS Project is threatening Fedora Linux with legal action

295 points by TheFreim 2y ago

boredatoms 2y ago
Linux distributions have often whitelabeled software that make trademark threats
- denkmoon 2y ago
  Seems perfectly reasonable and would achieve the desired goal of making it clear it's a third party package not "official" OBS.
  - like_any_other 2y ago
    That is in fact one of the solutions proposed by OBS: "We would like to request that this package is either removed, or made clear that it is a third party package." Which seems pretty reasonable to me, so I can't really fault OBS here.
- wmf 2y ago
  Yeah, but in this case the issue is so minor Fedora should just fix it.
tuananh 2y ago
who should do packaging for each distro? - upstream maintainer: too much work. each distro requires certain best practices/convention. - distro: may not meet certain standard set by upstream maintainer.
- zaruvi 2y ago
  I think the main issue in this case is that the maintainers provide an official flathub entry themselves. People using the fedora flatpak are not aware that they are using an unofficial (and incomplete) package, and then go to upstream with their issues.
- cperciva 2y ago
  Simple answer: Whoever the upstream decides should do it. For my code I'm very happy to have distributions shipping packages because it means the code is available more easily for users and with less work from me -- but if a distro was shipping a broken package I would absolutely say "please stop doing that".
  - ddtaylor 2y ago
    It's free and open software we specifically give the right to modify and redistribute.
    - gjsman-1000 2y ago
      But not the right to distribute with an intact trademark. No open source license provides that right. If the Blender Foundation one day decided that only the Windows and Mac App Stores can distribute Blender, yes, Linux distributions would be forced to use a different name.
      - akerl_ 2y ago
        Is there legal precedent for that claim?
        gjsman-1000 2y ago
        Absolutely. 1. Just read the license. Never is a trademark granted. Source code can and is granted completely independently of trademarks (otherwise, as one example, how does Apple license iOS SDKs without permission to use the name “Apple”? It’s just a more stringent license than a FOSS one.) 2. It’s already happened, Debian wanted to change Firefox, Mozilla said no, lo and behold we had “Iceweasel” for a decade. https://en.m.wikipedia.org/wiki/Debian%E2%80%93Mozilla_trademark_dispute https://en.m.wikipedia.org/wiki/Debian%E2%80%93Mozilla_trade... 3. Trademarks never expire, unlike patents, trade secrets, etc. Unlike source code, the trademark owner has near-absolute leeway in how they are used.
- iamjackg 2y ago
  Well, in this case it seems like there already is an official Flatpak, but Fedora is overriding it with their own, which is of lower quality. The problem was already solved, unless Fedora is claiming that their Flatpak is better in some specific way.
  - worble 2y ago
    From what I can tell reading the pagure.io thread (https://pagure.io/fedora-workstation/issue/463#comment-955418 https://pagure.io/fedora-workstation/issue/463#comment-95541...) the claim from Fedora is that is that OBS is using an EOL qt. It's hard to follow exactly what the issues are with the Fedora flatpak but I can only assume they forcefully updated qt and that's what caused the issues (just a guess from the context). There's a lot of interesting debate in the linked thread about Fedora giving leeway to "verified" flatpaks, or what they're calling "probably safe" apps that do not request too many permissions, so even if there are vulnerabilities in the source then due to the nature of flatpaks, they won't be able to cause much harm.
    - jcelerier 2y ago
      > the claim from Fedora is that is that OBS is using an EOL qt. what's amazing with this is that if for instance OBS had written their own toolkit from scratch just for the app, which by a stroke of luck ended up being exactly the same code than the Qt version they're using and which solves the use case they have - maybe it would be OBSObject or OBSString instead of QObject / QString, then this entire issue would not exist as no one would think of saying that their implementation is "EOL" since it's part of their app even if the actual GUI implementation files may not have been touched for 5 years.
      - comex 2y ago
        I would differentiate your scenario in five ways. First, the risk is higher. When a vulnerability has a public patch, it means the nature of the vulnerability is also public. Sometimes there is even public exploit code. While attackers sometimes find their own vulnerabilities (zero-days), it makes their job a lot easier if they can just use an already-known vulnerability. Second, if the code was part of the OBS project, then anyone reporting security bugs in the code would report them to OBS. OBS would then be able to quickly release a security update if they decided the issue warranted it. But since Qt is external, security bugs will be reported to Qt, and it’s unlikely anyone from OBS will hear about these reports. So there is no process for the project to respond with quick fixes even for severe issues. That is, unless they have someone watching the list of CVEs - but that seems unlikely. Third, if the OBS project had written the code, then it would be reasonably likely that someone on the project knew the code well enough to properly maintain it over time. This isn’t always true. Sometimes projects are stuck with huge piles of code that nobody wants to touch, whose author has left the project, or perhaps just forgotten how it works. But it’s true more often than not. In contrast, most projects don’t engage with their dependencies’ source code to such an extent, especially not for something as huge as Qt. Fourth, on a related note, vulnerabilities often come from newly written code. Probably the biggest reason for this is that security bugs often double as regular bugs, causing crashes or other issues for normal users. This isn’t true for all security bugs: a decent chunk of them have very specific triggering conditions that are essentially impossible to produce by accident. But it’s true for many. If OBS really had left the code untouched for 5 years, then that would probably be because the code worked pretty well. Maybe it’s legacy, maybe it’s not well-maintained, but if the issues it’s causing were really bad, someone would have gone in and fixed it. That in turn reduces the chance of security bugs somewhat. In reality, OBS actually is regularly updating Qt and thus pulling in new code that may not be well tested. (But not regularly enough to be up-to-date with security fixes.) Fifth… at the risk of sounding entitled, it’s not just about the risk but also about the potential upside. If there are security bugs in OBS-specific code, that’s bad, but all the ways to improve the situation involve doing OBS-specific hard work. With Qt, there is already someone else doing the job of finding and fixing security vulnerabilities; OBS “only” has to pull in the fixes. In practice, of course, it’s more complicated than that. But if we have a system where it’s Hard to pull in security fixes that someone else has found, well, maybe that’s not OBS’s fault, but that does mean it’s a bad system. We should aspire to do better.
- Cyph0n 2y ago
  Upstream if they want to. Downstream if no official upstream package is available. Downstream can have their own package either way, as long as it’s marked as unofficial.
- Gigachad 2y ago
  This problem was already solved. OBS ships a package on Flathub which can be installed on any distro. There is no reason for Fedora to package their own broken version.
- lmm 2y ago
  If distro maintainers are going to futz with packages, for good reasons or bad, then they need to bear the corresponding support burden themselves and ensure it does not fall on the upstream maintainers. This is not really any different from the Debian OpenSSL fiasco, or the Debian cdrecord fiasco, or the Debian xscreensaver fiasco, or...
  - tuananh 2y ago
    in this specific case, yes they are responsible for flathub. but Fedora is pushing Fedora Flatpak down to user's throat without user's awareness.
  - yjftsjthsd-h 2y ago
    > or the Debian cdrecord fiasco I'm not sure I'd call that a fiasco, and https://en.wikipedia.org/wiki/Cdrtools#License_compatibility_controversy https://en.wikipedia.org/wiki/Cdrtools#License_compatibility... says it was hardly a Debian thing. More to the point, I'd argue that there is a meaningful difference between "we're going to patch this" and "we aren't confident that we can ship this at all".
- rcxdude 2y ago
  Whoever's going to do the best job. Sometimes that's the distro packager, sometimes it's the upstream app developer. With complex applications with lots of dependencies and a large surface area for breakage between versions of dependencies, it's far more likely that the upstream developer will be in a position to do a good job than a distro packager who's responsible for 100 other packages, and maybe never actually uses the application, especially when they're constrained by distro policy on vendored dependencies or multiple library versions (which, like, I get the reason for, it sucks for a security fix to need applying in many different places, but it's a policy that will inevitably create bugs). This is something which grates when reading the defense of Fedora's flatpak repo in the thread linked elsewhere in the comments, claiming that Fedora is going to package with much higher quality and more testing. I can believe that relative to some rando 3rd party on the internet, maybe (at least that rando probably has packaged it because they would like to use it personally), but relative to the developers themselves? I think that's pretty unlikely.
- saidinesh5 2y ago
  The whole point of flatpak is so that the upstream maintainer can release one well tested binary and it works on all distros... As a long time Linux user and someone who tried to get in some software into Few Linux Distro Repositories, it's high time we start recommending the above model. Not my words, but at this point I'll even take just a zip file with apps that always just works over having to deal with all the headaches from distro package managers for user level software.
kattagarian 2y ago
Why would fedora have their own version of OBS studio when the package is already supported by the official team on flathub? Isn't this exactly the reason why flatpak was created, to avoid all the needless packaging that every distro had to do in order to install the program?
- mulmen 2y ago
  Flatpak provides an alternative to the distro package but the distro package is still useful. The distro package provides tighter integration with the OS and provides stability guarantees that Flatpak does not. The distro version also allows an OS deployment with a single tool. They’re both useful.
  - yuriks 2y ago
    The concern isn't about Fedora packaging and distributing an RPM, but they they also package their own flatpack that overrides the official OBS one.
    - mulmen 2y ago
      Ah! The conflict makes more sense then.
  - Scion9066 2y ago
    The distro package in question here is a Fedora-specific Flatpak, not the Fedora-specific RPM distro package version. From my understanding, it is missing things like patented codecs which then causes bug reports to be filed with upstream, OBS, instead of the ones responsible for the package, Fedora. Fedora has its own Flatpak repo as the default instead of Flathub (which has the official OBS package from the upstream developers).
- deleted 2y ago
  [deleted]
- ddtaylor 2y ago
  My understanding is that OBS is licensed in a free compatible license, so why someone in specific wants to keep maintaining any and all versions seems moot.
ajross 2y ago
Meh. Seems like there's some unstated background context here. The proximate cause isn't the linked bug at OBS, it's this bug report to Fedora: https://pagure.io/fedora-workstation/issue/463 https://pagure.io/fedora-workstation/issue/463 Basically it demands that the FlatPak be removed from the repository citing "problems" that aren't detailed. Then 22 days later they start throwing bombs on their own gitlab (again, without details about what the problems with the FlatPak) and get those posted to HN? Lots of steam, no meat. If this did go to a lawyer, the first question would be "Well, did you try to work with them?" Seemingly the answer is no. Or if it's "yes", it's somewhere back in the history of a pre-existing conflict. This isn't the first conflict between an upstream and a distro about packaging process and it won't be the last. By definition the feature we users want from the distros is that they are making opinionated choices about how to present the world of software to us.
- nikitalita 2y ago
  It seems that issues started here: https://pagure.io/fedora-workstation/issue/463#comment-955418 https://pagure.io/fedora-workstation/issue/463#comment-95541... Basically, the discussion somehow got turned into berating the OBS team for relying on an EOL runtime (which, as they carefully explain, was due to regressions when upgrading). I assume that waiting three weeks for any sort of movement and then getting insults in return is what caused them to reach for the nuclear option.
  - adamwill 2y ago
    The argument about Qt maintenance and the original topic are kinda orthogonal. Even in the same messages where he's criticizing obs upstream's handling of qt, mcatanzaro is still saying he wants to demote fedora flatpaks, which is what obs upstream wants - https://pagure.io/fedora-workstation/issue/463#comment-955418 https://pagure.io/fedora-workstation/issue/463#comment-95541... . the start of that comment is debating the Qt EOL thing. The end of the comment says "I agree with this argument. Fedora Flatpaks have had their chance but have not been successful. I'd say it's time to move on. Based on our discussion so far, I think Workstation Working Group does not want to tell Fedora developers to stop packaging things, but perhaps we can exclude the Fedora Flatpak repo from the default software sources and require that users enable it manually if they really want it."
stolen_biscuit 2y ago
Does anyone have more context for the name-calling and poor communication from the Fedora team? Seems like pretty poor behaviour from them if true
- tecleandor 2y ago
  This thread is giant, but I feel like it could come from here (and further responses): https://pagure.io/fedora-workstation/issue/463#comment-955412 https://pagure.io/fedora-workstation/issue/463#comment-95541...
  - MatthiasPortzel 2y ago
    These two comments stand out to me as inappropriate (directed at OBS). > keeping up with runtime updates is one of the most basic expectations of a maintainer, and I suspect it's a sign there may be other problems as well. > I won't mince words: allowing the runtime to go EOL is unacceptable and indicates terrible maintainership. I don't use Fedora but I do use OBS… on Mac, because OBS is hands-down the most popular application for streaming on any platform. It's crazy that OBS works great on Mac, works great on Windows, works great on Linux if using the OBS Flatpak, and when the Fedora-packaged-flatpak breaks and this Fedora guy starts saying that this is indicative that "there may be other problems". If OBS isn't good enough for Fedora to ship a working version, then show me the streaming software that is.
    - MatthiasPortzel 2y ago
      Also worth pointing out, Qt versions are supported for 6 months before EOL, unless you purchase enterprise support.
    - Jap2-0 2y ago
      Those two as well as > Flathub maintainers are sometimes just bad at maintaining their packages, and, well...
    - daurentius523 2y ago
      As person who does not use OBS. "If OBS isn't good enough for Fedora" - fanboyism is never good. If OBS has issues in development then what? What would you do if it stops updating Qt permanently? Think not let emotions act. "works great" - doesn't mean it is secure. You can write application that works great and is swiss cheese from security standpoint. You can write secure application that works like nightmare. "inappropriate" - why? If it is statement of fact then it can not be inappropriate. Also mind you OBS blocked the issue about fact that they use EOL qt on github - this does not look to me as good project. "the Fedora-packaged-flatpak breaks" - is it broken? Because no one even speaks about real state of package! Or by "broken" you mean - does not have functionality I want! Or it uses Qt version which breaks the application! Because In first case that not breakage - that's loss of functionality and if motivated by legal reasons - I can understand (not approve since US software patents are from my perspective idiocy), if motivated by security I wholeheartedly approve - because you are shooting messenger(fedora) of bad news(OBS bad practices) here. In second - Qt is broken so send regards to them and their policy: Update it so often to make GPL/LGPL version as miserable as possible. Which they then use to sell companies the LTS versions under proprietary license. I agree with breaking (it is good feedback about software state) to modernize dependencies - but then again I'm using Arch so…
akerl_ 2y ago
Given that OBS is GPL licensed, any legal action would have to be trademark-based, right? It feels like they'd have a hard time making that case, since package repositories are pretty clearly not representing themselves as the owners of, or sponsored by, the software they package.
- dismalaf 2y ago
  > Given that OBS is GPL licensed, any legal action would have to be trademark-based, right? Yup. The issue isn't the code but misrepresentation of the origin. It's like back in the day when Debian "forked" Firefox for reasons... Edit - worded it poorly - never meant to imply Debian did anything wrong, only that they changed the branding to respect Firefox's trademark and avoid the situation that OBS is threatening Fedora with.
  - akerl_ 2y ago
    That's sort of the difference, isn't it? Debian forked Firefox and changed the code, so they had to rename it. But this doesn't look like changing the code, it's building it with different versions of its dependencies / different wrapping around it. Maybe there's a case here, but it feels pretty tenuous.
    - lmm 2y ago
      > Debian forked Firefox and changed the code Debian didn't actually change the code, but they consider the right to change the code important, and don't accept Debian-specific exceptions.
    - ChrisMarshallNY 2y ago
      That's "changing the code." The main issue that I see, is that OBS doesn't want to be held responsible for the Fedora version, which is different from the "officially-supported" OBS version. They didn't modify anything other than the build, to exclude certain dependencies. But modifying the build, is modifying the code. They are allowed to do that, but they probably aren't allowed to slap the OBS name on the result.
wilg 2y ago
Lots of Linux-related drama on HN lately. Maybe someone should offer free conflict resolution classes for libre software maintainers.
- exsomet 2y ago
  OSCR, I’m building the pitch deck as we speak. AI generated SaaS app launching in Q2 and we’ll IPO later this year.
- xyst 2y ago
  The "Linux-related drama" is child's play compared to what I have seen occur within corporate governance meetings.
  - llm_trw 2y ago
    Hey remember that time that Sam Altman got fired, started a mutiny, then took over and ~executed~ fired everyone who stood against him? Crazy how much drama happens in open projects like openAI.
- nullc 2y ago
  The people most likely to offer that service are the same people most likely to ferment useless conflict.
guelo 2y ago
Centralized App stores are bad enough, but App Stores tied to each OS release and the random whims of distro maintainers is insane. It holds back the whole ecosystem.
- dralley 2y ago
  There's little real difference between OBS packaged as flatpak and OBS packaged as distro RPMs. This is basically the same conflict between upstreams and distro developers that has been raging since time immemorial.
  - rcxdude 2y ago
    I think there's two big things involved: firstly, that distros just bump library versions of frameworks like Qt and regressions in the frameworks introduce regressions in the app, which is exactly the kind of conflict that causes annoyed users and upstream devs (and it'll especially annoy the devs if they're called 'irresponsible' for not keeping on top of the release treadmill for vague security concerns). Secondly, OBS has features which need various API keys to integrate with different services, which I think third-party builds can not easily include just by the rules of those services. That's a bit more of an annoying one to deal with, because it means even a packager doing a good job and actually testing the software still can't reach feature parity, but it's also not something OBS can really do that much about.
    - deleted 2y ago
      [deleted]
  - guelo 2y ago
    Well I'm not for distro RPMs either. Windows and MacOs were fine for years without distro stores.
johnea 2y ago
Moral of the story: Don't use flatpack...
- senthilnayagam 2y ago
  initially used redhat then fedora till 2006 switched to ubuntu for desktop and debian for server in 2006 for my company, by 2020 most developers chose mac for desktop and debian/ubuntu for server
- Gigachad 2y ago
  It works if you use OBSs own flatpak. It's just Fedora which modified it, broke it, and shipped it broken.
- rerdavies 2y ago
  Wouldn't the moral of the story be "don't use Fedora Flatpack"? Tbh, the moral I drew from the story was "Don't use Fedora".
diego_sandoval 2y ago
Last time I checked, Flathub was rife with unofficial packages posing as official ones (using the URL of upstream, with no verification, when the upstream dev has no association to the package). That's the main reason I never took Flatpak seriously.
- iotku 2y ago
  It's greatly improved with Flathub's "Verified apps" [1] implementation, but you can make similar arguments about downstream packaging (e.g. from distros) not being clear about being independent of "offical" builds. It's also very worth noting that `Fedora's Flatpaks` are sourced separate from the "Main" `Flathub` service which most people expect flatpaks are generally being sourced from which has many "official" flatpak releases of software directly from projects leading to extra confusion. Flathub itself is fairly auditable (but not trivially so) and built through their CI, but I still agree that the unofficial packages are often of questionable security/quality. That said, Many of the "native" (e.g. not Flatpak) distro packages are using far from supported/official builds with often missing/broken features and it's an unreasonable support burden when nearly all of issues related to distro packaging end up on the upstream issue trackers/support channels. It's especially troublesome when the upstream has official builds available and it's unclear to the user reporting issues that they are not actually using official builds. [1] https://docs.flathub.org/docs/for-users/verification/ https://docs.flathub.org/docs/for-users/verification/
rincebrain 2y ago
This seems like a flashback to the xscreensaver fights with Debian of yore, given that the entire fight seems to distill to "OBS is shipping EOL Qt because of unfixed regressions in newer Qt, Fedora views shipping EOL Qt as unjustifiable neglect and repackaged it with newer Qt, which, as described, breaks things." [1] For those who don't have that in their context - jwz got very upset at people reporting bugs against xscreensaver that had been fixed for a long time in upstream but e.g. Debian doesn't just ship upstream updates every 30 minutes. He requested Debian stop shipping it (or update it? I didn't go reread the entire chain before replying), Debian declined. He then put in a piece of code that popped up a notification if the system time was sufficiently far past the hardcoded value, informing people they should upgrade, and Debian debated patching his message out. [1] - jwz dot org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/ (Link turned into not a link because I had forgotten how jwz feels about HN referrers.)
- alexjplant 2y ago
  Don't link to this guy's site. He has a serious personal problem with every reader of HN (including the vast majority he's never met and knows nothing about) and serves an NSFW image to anybody that has this site in the referrer request header.
  - rincebrain 2y ago
    Yeah, I remembered that after, had to open another browser window to confirm it because otherwise I just got the cached one, and then edited.
  - quickslowdown 2y ago
    This is a piece of Internet lore I'm not familiar with! Any good summary or article or anything you'd recommend?
    - dTal 2y ago
      Why do you need an article? Just find a link to some page on http://jwz.org http://jwz.org somewhere on news.ycombinator.com, and click it. Note that you will get a (really quite tame) NSFW image. Said image will explain jwz's feelings regarding Hacker News.
mappu 2y ago
There is some additional commentary/background in the OSNews reporting: https://www.osnews.com/story/141723/fedora-should-not-push-its-users-to-its-own-flatpak-repository/ https://www.osnews.com/story/141723/fedora-should-not-push-i...
halifaxbeard 2y ago
more surprising is there's no way for them to delete it from the flatpak registry https://pagure.io/releng/issue/12586#comment-955583 https://pagure.io/releng/issue/12586#comment-955583
- lmm 2y ago
  That's unsurprisingly consistent with the general quality level I've come to expect from the whole flatpak toolchain TBH.
deleted 2y ago
[deleted]
gbraad 2y ago
The package was already updated before this post was made: https://src.fedoraproject.org/flatpaks/obs-studio/history/container.yaml?identifier=stable https://src.fedoraproject.org/flatpaks/obs-studio/history/co... which reads: ``` end-of-life: The Fedora Flatpak build of obs-studio may have limited functionality compared to other sources. Please do not report bugs to the OBS Studio project about this build. ```
- gbraad 2y ago
  Honestly, the flatpak should be made on only published by the project maintainers; I do not understand why someone still puts efforts into a Fedora-based flatpak to publish the application. Who understand better how the application works? I had this discussion with several packagers on the project, and they insist on their work. I do not understand why a Debian or Fedora packager would know better how to do this. It is a container/userspace abstraction, not distro specific. I understand there is a use case for Silverblue (and derivs), ... though this is duplication; an upstream exists with a possibility for extensions/plugins, that this doesn't. It does not take away that this feels pretty unnecessarily hostile, as Neal already informed him to work with the packager to resolve this: https://pagure.io/releng/issue/12586 https://pagure.io/releng/issue/12586. It is not clear if the reporter actually ever did.
  - thomasfortes 2y ago
    One of the comments in the main thread says that the original vision for the fedora flatpaks was to be mainly for things that fedora wanted to have tight control and be preinstalled in their distros (Firefox, LibreOffice, GNOME and apps, etc...), which makes a lot of sense, but at some point it lost their original vision and started packaging everything under the sun. In another comment someone says that most of the extra packages are maintained by a single person (more than 700), there's no way a single person can validate and test all these packages (or even use them).
    - gbraad 2y ago
      Not sure where you saw this, as that was also my argument why Flatpak gave "application developers are in control of the release cycle" again instead of this being the packager; they can't perform the same quality control. They should never package what rpmfusion offers, or distribute a new flatpak when something is already available. That worked when flathub didn't exist or was mostly empty, but that time is gone now. Note: I want to understand what led to the comment of the C&D-like legal threat.
attentionmech 2y ago
why don't they just block the obs project and let users install it in unofficial manner while removing themselves as middleman? I mean, they have certain let's say guidelines but why go about enforcing them in this weird manner.
uneekname 2y ago
I am a happy Fedora user, but the "Software" application it ships with has always been a joke. Pushing flatpaks (and especially poorly-maintained ones like this) has made it worse. When I open Software I always think it's going to be a clean GTK interface for dnf. But it appears to just do its own thing, and I've learned not to trust the app listings in there.
- MathMonkeyMan 2y ago
  Similar story with Ubuntu's software app and Snap, though to be fair snap is mostly fine these days. I still uninstall it and use apt instead (and "downgrade" packages that are wrappers around snaps, and block snapd from being able to install...).
- jijijijij 2y ago
  I think Software only lists Apps with a GUI or something. Also I think that’s rather on Gnome than Fedora directly.
- Sincere6066 2y ago
  "I am a happy Fedora user" ...why?
ben0x539 2y ago
What's the term for having to choose between an deprecated/EOL version or an unstable/regressed version? It seems like it comes up over and over again.
poulpy123 2y ago
The state of software distribution on Linux has always been catastrophic and it's an incredible miracle that Linux was able to enjoy the success it had despite this
- yoavm 2y ago
  Are you using Linux? I cannot think about an operating system in which it's so easy and safe to install software on. I use Arch BTW.
  - poulpy123 2y ago
    yes I'm using linux.
    - yoavm 2y ago
      I really cannot relate then. I don't remember the last time I couldn't install what I wanted with one pacman command. No need to open the browser, search for the website, find the right download link, and then worry about upgrading when there's a new version. Once a week I run pacman -Syu, and I know I'm always running the latest and greatest.
- perlgeek 2y ago
  I disagree very hard on this. We mostly talk about the problematic cases, but most of the time when I need some software, I just install it through the package manager and it just works. Compare this to Windows, where you often have to search the Internet, download some sketchy .exe or .msi and don't know if you'll get the software, a virus, or both. It got so bad that it was common to have "cleaners", extra tools that you downloaded (often from similarly sketchy sources) that tried to delete the sketchy parts of other programs, the remnants of incomplete deinstallations etc. I still remember when putty download was http-only, no HTTPS, and that was just a few years ago...
  - gkbrk 2y ago
    > putty download was http-only, no HTTPS, and that was just a few years ago HTTP downloads are still fine in 2025 though, putty releases all come with signatures that can be used to check if anything was tampered with. This is how lots of Linux package managers can still use HTTP for downloading from mirrors without worrying about malicious package modifications.
gkbrk 2y ago
Their Flatpak repository looks cool, just added it to my own non-Fedora system to check it out. flatpak remote-add --if-not-exists fedora oci+https://registry.fedoraproject.org
countWSS 2y ago
There is an easy trick to prevent this from happening:: for every library update that you have decided to use, pick the newest, most cutting edge feature and integrate it so deep the project maintainers will have to rewrite half the code for it to function in any version below the current...(and thats why you can't have nice things in old linuxes without recompiling it manually)
daurentius523 2y ago
I find it quite funny that OBS thinks that fedora isn't giving reasonable response when they (OBS) blocked any responses to issue of them still using EOL Qt 6.6 - since December.
vaxman 2y ago
A non-profit open source project is threatening IBM with legal action. https://youtu.be/IHTaMMyK274 https://youtu.be/IHTaMMyK274
hammerhorn 2y ago
People who are not okay with being forked should reconsider their decision to be use the GPL.
Sincere6066 2y ago
Why is OBS pushing flatpak?

295 points by TheFreim 2y ago

boredatoms 2y ago

Linux distributions have often whitelabeled software that make trademark threats

denkmoon 2y ago
Seems perfectly reasonable and would achieve the desired goal of making it clear it's a third party package not "official" OBS.
- like_any_other 2y ago
  That is in fact one of the solutions proposed by OBS: "We would like to request that this package is either removed, or made clear that it is a third party package." Which seems pretty reasonable to me, so I can't really fault OBS here.
wmf 2y ago
Yeah, but in this case the issue is so minor Fedora should just fix it.

tuananh 2y ago

who should do packaging for each distro? - upstream maintainer: too much work. each distro requires certain best practices/convention. - distro: may not meet certain standard set by upstream maintainer.

zaruvi 2y ago
I think the main issue in this case is that the maintainers provide an official flathub entry themselves. People using the fedora flatpak are not aware that they are using an unofficial (and incomplete) package, and then go to upstream with their issues.
cperciva 2y ago
Simple answer: Whoever the upstream decides should do it. For my code I'm very happy to have distributions shipping packages because it means the code is available more easily for users and with less work from me -- but if a distro was shipping a broken package I would absolutely say "please stop doing that".
- ddtaylor 2y ago
  It's free and open software we specifically give the right to modify and redistribute.
  - gjsman-1000 2y ago
    But not the right to distribute with an intact trademark. No open source license provides that right. If the Blender Foundation one day decided that only the Windows and Mac App Stores can distribute Blender, yes, Linux distributions would be forced to use a different name.
    - akerl_ 2y ago
      Is there legal precedent for that claim?
      - gjsman-1000 2y ago
        Absolutely. 1. Just read the license. Never is a trademark granted. Source code can and is granted completely independently of trademarks (otherwise, as one example, how does Apple license iOS SDKs without permission to use the name “Apple”? It’s just a more stringent license than a FOSS one.) 2. It’s already happened, Debian wanted to change Firefox, Mozilla said no, lo and behold we had “Iceweasel” for a decade. https://en.m.wikipedia.org/wiki/Debian%E2%80%93Mozilla_trademark_dispute https://en.m.wikipedia.org/wiki/Debian%E2%80%93Mozilla_trade... 3. Trademarks never expire, unlike patents, trade secrets, etc. Unlike source code, the trademark owner has near-absolute leeway in how they are used.
iamjackg 2y ago
Well, in this case it seems like there already is an official Flatpak, but Fedora is overriding it with their own, which is of lower quality. The problem was already solved, unless Fedora is claiming that their Flatpak is better in some specific way.
- worble 2y ago
  From what I can tell reading the pagure.io thread (https://pagure.io/fedora-workstation/issue/463#comment-955418 https://pagure.io/fedora-workstation/issue/463#comment-95541...) the claim from Fedora is that is that OBS is using an EOL qt. It's hard to follow exactly what the issues are with the Fedora flatpak but I can only assume they forcefully updated qt and that's what caused the issues (just a guess from the context). There's a lot of interesting debate in the linked thread about Fedora giving leeway to "verified" flatpaks, or what they're calling "probably safe" apps that do not request too many permissions, so even if there are vulnerabilities in the source then due to the nature of flatpaks, they won't be able to cause much harm.
  - jcelerier 2y ago
    > the claim from Fedora is that is that OBS is using an EOL qt. what's amazing with this is that if for instance OBS had written their own toolkit from scratch just for the app, which by a stroke of luck ended up being exactly the same code than the Qt version they're using and which solves the use case they have - maybe it would be OBSObject or OBSString instead of QObject / QString, then this entire issue would not exist as no one would think of saying that their implementation is "EOL" since it's part of their app even if the actual GUI implementation files may not have been touched for 5 years.
    - comex 2y ago
      I would differentiate your scenario in five ways. First, the risk is higher. When a vulnerability has a public patch, it means the nature of the vulnerability is also public. Sometimes there is even public exploit code. While attackers sometimes find their own vulnerabilities (zero-days), it makes their job a lot easier if they can just use an already-known vulnerability. Second, if the code was part of the OBS project, then anyone reporting security bugs in the code would report them to OBS. OBS would then be able to quickly release a security update if they decided the issue warranted it. But since Qt is external, security bugs will be reported to Qt, and it’s unlikely anyone from OBS will hear about these reports. So there is no process for the project to respond with quick fixes even for severe issues. That is, unless they have someone watching the list of CVEs - but that seems unlikely. Third, if the OBS project had written the code, then it would be reasonably likely that someone on the project knew the code well enough to properly maintain it over time. This isn’t always true. Sometimes projects are stuck with huge piles of code that nobody wants to touch, whose author has left the project, or perhaps just forgotten how it works. But it’s true more often than not. In contrast, most projects don’t engage with their dependencies’ source code to such an extent, especially not for something as huge as Qt. Fourth, on a related note, vulnerabilities often come from newly written code. Probably the biggest reason for this is that security bugs often double as regular bugs, causing crashes or other issues for normal users. This isn’t true for all security bugs: a decent chunk of them have very specific triggering conditions that are essentially impossible to produce by accident. But it’s true for many. If OBS really had left the code untouched for 5 years, then that would probably be because the code worked pretty well. Maybe it’s legacy, maybe it’s not well-maintained, but if the issues it’s causing were really bad, someone would have gone in and fixed it. That in turn reduces the chance of security bugs somewhat. In reality, OBS actually is regularly updating Qt and thus pulling in new code that may not be well tested. (But not regularly enough to be up-to-date with security fixes.) Fifth… at the risk of sounding entitled, it’s not just about the risk but also about the potential upside. If there are security bugs in OBS-specific code, that’s bad, but all the ways to improve the situation involve doing OBS-specific hard work. With Qt, there is already someone else doing the job of finding and fixing security vulnerabilities; OBS “only” has to pull in the fixes. In practice, of course, it’s more complicated than that. But if we have a system where it’s Hard to pull in security fixes that someone else has found, well, maybe that’s not OBS’s fault, but that does mean it’s a bad system. We should aspire to do better.
Cyph0n 2y ago
Upstream if they want to. Downstream if no official upstream package is available. Downstream can have their own package either way, as long as it’s marked as unofficial.
Gigachad 2y ago
This problem was already solved. OBS ships a package on Flathub which can be installed on any distro. There is no reason for Fedora to package their own broken version.
lmm 2y ago
If distro maintainers are going to futz with packages, for good reasons or bad, then they need to bear the corresponding support burden themselves and ensure it does not fall on the upstream maintainers. This is not really any different from the Debian OpenSSL fiasco, or the Debian cdrecord fiasco, or the Debian xscreensaver fiasco, or...
- tuananh 2y ago
  in this specific case, yes they are responsible for flathub. but Fedora is pushing Fedora Flatpak down to user's throat without user's awareness.
- yjftsjthsd-h 2y ago
  > or the Debian cdrecord fiasco I'm not sure I'd call that a fiasco, and https://en.wikipedia.org/wiki/Cdrtools#License_compatibility_controversy https://en.wikipedia.org/wiki/Cdrtools#License_compatibility... says it was hardly a Debian thing. More to the point, I'd argue that there is a meaningful difference between "we're going to patch this" and "we aren't confident that we can ship this at all".
rcxdude 2y ago
Whoever's going to do the best job. Sometimes that's the distro packager, sometimes it's the upstream app developer. With complex applications with lots of dependencies and a large surface area for breakage between versions of dependencies, it's far more likely that the upstream developer will be in a position to do a good job than a distro packager who's responsible for 100 other packages, and maybe never actually uses the application, especially when they're constrained by distro policy on vendored dependencies or multiple library versions (which, like, I get the reason for, it sucks for a security fix to need applying in many different places, but it's a policy that will inevitably create bugs). This is something which grates when reading the defense of Fedora's flatpak repo in the thread linked elsewhere in the comments, claiming that Fedora is going to package with much higher quality and more testing. I can believe that relative to some rando 3rd party on the internet, maybe (at least that rando probably has packaged it because they would like to use it personally), but relative to the developers themselves? I think that's pretty unlikely.
saidinesh5 2y ago
The whole point of flatpak is so that the upstream maintainer can release one well tested binary and it works on all distros... As a long time Linux user and someone who tried to get in some software into Few Linux Distro Repositories, it's high time we start recommending the above model. Not my words, but at this point I'll even take just a zip file with apps that always just works over having to deal with all the headaches from distro package managers for user level software.

kattagarian 2y ago

Why would fedora have their own version of OBS studio when the package is already supported by the official team on flathub? Isn't this exactly the reason why flatpak was created, to avoid all the needless packaging that every distro had to do in order to install the program?

mulmen 2y ago
Flatpak provides an alternative to the distro package but the distro package is still useful. The distro package provides tighter integration with the OS and provides stability guarantees that Flatpak does not. The distro version also allows an OS deployment with a single tool. They’re both useful.
- yuriks 2y ago
  The concern isn't about Fedora packaging and distributing an RPM, but they they also package their own flatpack that overrides the official OBS one.
  - mulmen 2y ago
    Ah! The conflict makes more sense then.
- Scion9066 2y ago
  The distro package in question here is a Fedora-specific Flatpak, not the Fedora-specific RPM distro package version. From my understanding, it is missing things like patented codecs which then causes bug reports to be filed with upstream, OBS, instead of the ones responsible for the package, Fedora. Fedora has its own Flatpak repo as the default instead of Flathub (which has the official OBS package from the upstream developers).
deleted 2y ago
[deleted]
ddtaylor 2y ago
My understanding is that OBS is licensed in a free compatible license, so why someone in specific wants to keep maintaining any and all versions seems moot.

ajross 2y ago

Meh. Seems like there's some unstated background context here. The proximate cause isn't the linked bug at OBS, it's this bug report to Fedora: https://pagure.io/fedora-workstation/issue/463 https://pagure.io/fedora-workstation/issue/463 Basically it demands that the FlatPak be removed from the repository citing "problems" that aren't detailed. Then 22 days later they start throwing bombs on their own gitlab (again, without details about what the problems with the FlatPak) and get those posted to HN? Lots of steam, no meat. If this did go to a lawyer, the first question would be "Well, did you try to work with them?" Seemingly the answer is no. Or if it's "yes", it's somewhere back in the history of a pre-existing conflict. This isn't the first conflict between an upstream and a distro about packaging process and it won't be the last. By definition the feature we users want from the distros is that they are making opinionated choices about how to present the world of software to us.

nikitalita 2y ago
It seems that issues started here: https://pagure.io/fedora-workstation/issue/463#comment-955418 https://pagure.io/fedora-workstation/issue/463#comment-95541... Basically, the discussion somehow got turned into berating the OBS team for relying on an EOL runtime (which, as they carefully explain, was due to regressions when upgrading). I assume that waiting three weeks for any sort of movement and then getting insults in return is what caused them to reach for the nuclear option.
- adamwill 2y ago
  The argument about Qt maintenance and the original topic are kinda orthogonal. Even in the same messages where he's criticizing obs upstream's handling of qt, mcatanzaro is still saying he wants to demote fedora flatpaks, which is what obs upstream wants - https://pagure.io/fedora-workstation/issue/463#comment-955418 https://pagure.io/fedora-workstation/issue/463#comment-95541... . the start of that comment is debating the Qt EOL thing. The end of the comment says "I agree with this argument. Fedora Flatpaks have had their chance but have not been successful. I'd say it's time to move on. Based on our discussion so far, I think Workstation Working Group does not want to tell Fedora developers to stop packaging things, but perhaps we can exclude the Fedora Flatpak repo from the default software sources and require that users enable it manually if they really want it."

stolen_biscuit 2y ago

Does anyone have more context for the name-calling and poor communication from the Fedora team? Seems like pretty poor behaviour from them if true

tecleandor 2y ago
This thread is giant, but I feel like it could come from here (and further responses): https://pagure.io/fedora-workstation/issue/463#comment-955412 https://pagure.io/fedora-workstation/issue/463#comment-95541...
- MatthiasPortzel 2y ago
  These two comments stand out to me as inappropriate (directed at OBS). > keeping up with runtime updates is one of the most basic expectations of a maintainer, and I suspect it's a sign there may be other problems as well. > I won't mince words: allowing the runtime to go EOL is unacceptable and indicates terrible maintainership. I don't use Fedora but I do use OBS… on Mac, because OBS is hands-down the most popular application for streaming on any platform. It's crazy that OBS works great on Mac, works great on Windows, works great on Linux if using the OBS Flatpak, and when the Fedora-packaged-flatpak breaks and this Fedora guy starts saying that this is indicative that "there may be other problems". If OBS isn't good enough for Fedora to ship a working version, then show me the streaming software that is.
  - MatthiasPortzel 2y ago
    Also worth pointing out, Qt versions are supported for 6 months before EOL, unless you purchase enterprise support.
  - Jap2-0 2y ago
    Those two as well as > Flathub maintainers are sometimes just bad at maintaining their packages, and, well...
  - daurentius523 2y ago
    As person who does not use OBS. "If OBS isn't good enough for Fedora" - fanboyism is never good. If OBS has issues in development then what? What would you do if it stops updating Qt permanently? Think not let emotions act. "works great" - doesn't mean it is secure. You can write application that works great and is swiss cheese from security standpoint. You can write secure application that works like nightmare. "inappropriate" - why? If it is statement of fact then it can not be inappropriate. Also mind you OBS blocked the issue about fact that they use EOL qt on github - this does not look to me as good project. "the Fedora-packaged-flatpak breaks" - is it broken? Because no one even speaks about real state of package! Or by "broken" you mean - does not have functionality I want! Or it uses Qt version which breaks the application! Because In first case that not breakage - that's loss of functionality and if motivated by legal reasons - I can understand (not approve since US software patents are from my perspective idiocy), if motivated by security I wholeheartedly approve - because you are shooting messenger(fedora) of bad news(OBS bad practices) here. In second - Qt is broken so send regards to them and their policy: Update it so often to make GPL/LGPL version as miserable as possible. Which they then use to sell companies the LTS versions under proprietary license. I agree with breaking (it is good feedback about software state) to modernize dependencies - but then again I'm using Arch so…

akerl_ 2y ago

Given that OBS is GPL licensed, any legal action would have to be trademark-based, right? It feels like they'd have a hard time making that case, since package repositories are pretty clearly not representing themselves as the owners of, or sponsored by, the software they package.

dismalaf 2y ago
> Given that OBS is GPL licensed, any legal action would have to be trademark-based, right? Yup. The issue isn't the code but misrepresentation of the origin. It's like back in the day when Debian "forked" Firefox for reasons... Edit - worded it poorly - never meant to imply Debian did anything wrong, only that they changed the branding to respect Firefox's trademark and avoid the situation that OBS is threatening Fedora with.
- akerl_ 2y ago
  That's sort of the difference, isn't it? Debian forked Firefox and changed the code, so they had to rename it. But this doesn't look like changing the code, it's building it with different versions of its dependencies / different wrapping around it. Maybe there's a case here, but it feels pretty tenuous.
  - lmm 2y ago
    > Debian forked Firefox and changed the code Debian didn't actually change the code, but they consider the right to change the code important, and don't accept Debian-specific exceptions.
  - ChrisMarshallNY 2y ago
    That's "changing the code." The main issue that I see, is that OBS doesn't want to be held responsible for the Fedora version, which is different from the "officially-supported" OBS version. They didn't modify anything other than the build, to exclude certain dependencies. But modifying the build, is modifying the code. They are allowed to do that, but they probably aren't allowed to slap the OBS name on the result.

wilg 2y ago

Lots of Linux-related drama on HN lately. Maybe someone should offer free conflict resolution classes for libre software maintainers.

exsomet 2y ago
OSCR, I’m building the pitch deck as we speak. AI generated SaaS app launching in Q2 and we’ll IPO later this year.
xyst 2y ago
The "Linux-related drama" is child's play compared to what I have seen occur within corporate governance meetings.
- llm_trw 2y ago
  Hey remember that time that Sam Altman got fired, started a mutiny, then took over and ~executed~ fired everyone who stood against him? Crazy how much drama happens in open projects like openAI.
nullc 2y ago
The people most likely to offer that service are the same people most likely to ferment useless conflict.

guelo 2y ago

Centralized App stores are bad enough, but App Stores tied to each OS release and the random whims of distro maintainers is insane. It holds back the whole ecosystem.

dralley 2y ago
There's little real difference between OBS packaged as flatpak and OBS packaged as distro RPMs. This is basically the same conflict between upstreams and distro developers that has been raging since time immemorial.
- rcxdude 2y ago
  I think there's two big things involved: firstly, that distros just bump library versions of frameworks like Qt and regressions in the frameworks introduce regressions in the app, which is exactly the kind of conflict that causes annoyed users and upstream devs (and it'll especially annoy the devs if they're called 'irresponsible' for not keeping on top of the release treadmill for vague security concerns). Secondly, OBS has features which need various API keys to integrate with different services, which I think third-party builds can not easily include just by the rules of those services. That's a bit more of an annoying one to deal with, because it means even a packager doing a good job and actually testing the software still can't reach feature parity, but it's also not something OBS can really do that much about.
  - deleted 2y ago
    [deleted]
- guelo 2y ago
  Well I'm not for distro RPMs either. Windows and MacOs were fine for years without distro stores.

johnea 2y ago

Moral of the story: Don't use flatpack...

senthilnayagam 2y ago
initially used redhat then fedora till 2006 switched to ubuntu for desktop and debian for server in 2006 for my company, by 2020 most developers chose mac for desktop and debian/ubuntu for server
Gigachad 2y ago
It works if you use OBSs own flatpak. It's just Fedora which modified it, broke it, and shipped it broken.
rerdavies 2y ago
Wouldn't the moral of the story be "don't use Fedora Flatpack"? Tbh, the moral I drew from the story was "Don't use Fedora".

diego_sandoval 2y ago

Last time I checked, Flathub was rife with unofficial packages posing as official ones (using the URL of upstream, with no verification, when the upstream dev has no association to the package). That's the main reason I never took Flatpak seriously.

iotku 2y ago
It's greatly improved with Flathub's "Verified apps" [1] implementation, but you can make similar arguments about downstream packaging (e.g. from distros) not being clear about being independent of "offical" builds. It's also very worth noting that `Fedora's Flatpaks` are sourced separate from the "Main" `Flathub` service which most people expect flatpaks are generally being sourced from which has many "official" flatpak releases of software directly from projects leading to extra confusion. Flathub itself is fairly auditable (but not trivially so) and built through their CI, but I still agree that the unofficial packages are often of questionable security/quality. That said, Many of the "native" (e.g. not Flatpak) distro packages are using far from supported/official builds with often missing/broken features and it's an unreasonable support burden when nearly all of issues related to distro packaging end up on the upstream issue trackers/support channels. It's especially troublesome when the upstream has official builds available and it's unclear to the user reporting issues that they are not actually using official builds. [1] https://docs.flathub.org/docs/for-users/verification/ https://docs.flathub.org/docs/for-users/verification/

rincebrain 2y ago

This seems like a flashback to the xscreensaver fights with Debian of yore, given that the entire fight seems to distill to "OBS is shipping EOL Qt because of unfixed regressions in newer Qt, Fedora views shipping EOL Qt as unjustifiable neglect and repackaged it with newer Qt, which, as described, breaks things." [1] For those who don't have that in their context - jwz got very upset at people reporting bugs against xscreensaver that had been fixed for a long time in upstream but e.g. Debian doesn't just ship upstream updates every 30 minutes. He requested Debian stop shipping it (or update it? I didn't go reread the entire chain before replying), Debian declined. He then put in a piece of code that popped up a notification if the system time was sufficiently far past the hardcoded value, informing people they should upgrade, and Debian debated patching his message out. [1] - jwz dot org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/ (Link turned into not a link because I had forgotten how jwz feels about HN referrers.)

alexjplant 2y ago
Don't link to this guy's site. He has a serious personal problem with every reader of HN (including the vast majority he's never met and knows nothing about) and serves an NSFW image to anybody that has this site in the referrer request header.
- rincebrain 2y ago
  Yeah, I remembered that after, had to open another browser window to confirm it because otherwise I just got the cached one, and then edited.
- quickslowdown 2y ago
  This is a piece of Internet lore I'm not familiar with! Any good summary or article or anything you'd recommend?
  - dTal 2y ago
    Why do you need an article? Just find a link to some page on http://jwz.org http://jwz.org somewhere on news.ycombinator.com, and click it. Note that you will get a (really quite tame) NSFW image. Said image will explain jwz's feelings regarding Hacker News.

mappu 2y ago

There is some additional commentary/background in the OSNews reporting: https://www.osnews.com/story/141723/fedora-should-not-push-its-users-to-its-own-flatpak-repository/ https://www.osnews.com/story/141723/fedora-should-not-push-i...

halifaxbeard 2y ago

more surprising is there's no way for them to delete it from the flatpak registry https://pagure.io/releng/issue/12586#comment-955583 https://pagure.io/releng/issue/12586#comment-955583

lmm 2y ago
That's unsurprisingly consistent with the general quality level I've come to expect from the whole flatpak toolchain TBH.

deleted 2y ago

[deleted]

gbraad 2y ago

The package was already updated before this post was made: https://src.fedoraproject.org/flatpaks/obs-studio/history/container.yaml?identifier=stable https://src.fedoraproject.org/flatpaks/obs-studio/history/co... which reads: ``` end-of-life: The Fedora Flatpak build of obs-studio may have limited functionality compared to other sources. Please do not report bugs to the OBS Studio project about this build. ```

gbraad 2y ago
Honestly, the flatpak should be made on only published by the project maintainers; I do not understand why someone still puts efforts into a Fedora-based flatpak to publish the application. Who understand better how the application works? I had this discussion with several packagers on the project, and they insist on their work. I do not understand why a Debian or Fedora packager would know better how to do this. It is a container/userspace abstraction, not distro specific. I understand there is a use case for Silverblue (and derivs), ... though this is duplication; an upstream exists with a possibility for extensions/plugins, that this doesn't. It does not take away that this feels pretty unnecessarily hostile, as Neal already informed him to work with the packager to resolve this: https://pagure.io/releng/issue/12586 https://pagure.io/releng/issue/12586. It is not clear if the reporter actually ever did.
- thomasfortes 2y ago
  One of the comments in the main thread says that the original vision for the fedora flatpaks was to be mainly for things that fedora wanted to have tight control and be preinstalled in their distros (Firefox, LibreOffice, GNOME and apps, etc...), which makes a lot of sense, but at some point it lost their original vision and started packaging everything under the sun. In another comment someone says that most of the extra packages are maintained by a single person (more than 700), there's no way a single person can validate and test all these packages (or even use them).
  - gbraad 2y ago
    Not sure where you saw this, as that was also my argument why Flatpak gave "application developers are in control of the release cycle" again instead of this being the packager; they can't perform the same quality control. They should never package what rpmfusion offers, or distribute a new flatpak when something is already available. That worked when flathub didn't exist or was mostly empty, but that time is gone now. Note: I want to understand what led to the comment of the C&D-like legal threat.

attentionmech 2y ago

why don't they just block the obs project and let users install it in unofficial manner while removing themselves as middleman? I mean, they have certain let's say guidelines but why go about enforcing them in this weird manner.

uneekname 2y ago

I am a happy Fedora user, but the "Software" application it ships with has always been a joke. Pushing flatpaks (and especially poorly-maintained ones like this) has made it worse. When I open Software I always think it's going to be a clean GTK interface for dnf. But it appears to just do its own thing, and I've learned not to trust the app listings in there.

MathMonkeyMan 2y ago
Similar story with Ubuntu's software app and Snap, though to be fair snap is mostly fine these days. I still uninstall it and use apt instead (and "downgrade" packages that are wrappers around snaps, and block snapd from being able to install...).
jijijijij 2y ago
I think Software only lists Apps with a GUI or something. Also I think that’s rather on Gnome than Fedora directly.
Sincere6066 2y ago
"I am a happy Fedora user" ...why?

ben0x539 2y ago

What's the term for having to choose between an deprecated/EOL version or an unstable/regressed version? It seems like it comes up over and over again.

poulpy123 2y ago

The state of software distribution on Linux has always been catastrophic and it's an incredible miracle that Linux was able to enjoy the success it had despite this

yoavm 2y ago
Are you using Linux? I cannot think about an operating system in which it's so easy and safe to install software on. I use Arch BTW.
- poulpy123 2y ago
  yes I'm using linux.
  - yoavm 2y ago
    I really cannot relate then. I don't remember the last time I couldn't install what I wanted with one pacman command. No need to open the browser, search for the website, find the right download link, and then worry about upgrading when there's a new version. Once a week I run pacman -Syu, and I know I'm always running the latest and greatest.
perlgeek 2y ago
I disagree very hard on this. We mostly talk about the problematic cases, but most of the time when I need some software, I just install it through the package manager and it just works. Compare this to Windows, where you often have to search the Internet, download some sketchy .exe or .msi and don't know if you'll get the software, a virus, or both. It got so bad that it was common to have "cleaners", extra tools that you downloaded (often from similarly sketchy sources) that tried to delete the sketchy parts of other programs, the remnants of incomplete deinstallations etc. I still remember when putty download was http-only, no HTTPS, and that was just a few years ago...
- gkbrk 2y ago
  > putty download was http-only, no HTTPS, and that was just a few years ago HTTP downloads are still fine in 2025 though, putty releases all come with signatures that can be used to check if anything was tampered with. This is how lots of Linux package managers can still use HTTP for downloading from mirrors without worrying about malicious package modifications.

gkbrk 2y ago

Their Flatpak repository looks cool, just added it to my own non-Fedora system to check it out. flatpak remote-add --if-not-exists fedora oci+https://registry.fedoraproject.org

countWSS 2y ago

There is an easy trick to prevent this from happening:: for every library update that you have decided to use, pick the newest, most cutting edge feature and integrate it so deep the project maintainers will have to rewrite half the code for it to function in any version below the current...(and thats why you can't have nice things in old linuxes without recompiling it manually)

daurentius523 2y ago

I find it quite funny that OBS thinks that fedora isn't giving reasonable response when they (OBS) blocked any responses to issue of them still using EOL Qt 6.6 - since December.

vaxman 2y ago

A non-profit open source project is threatening IBM with legal action. https://youtu.be/IHTaMMyK274 https://youtu.be/IHTaMMyK274

hammerhorn 2y ago

People who are not okay with being forked should reconsider their decision to be use the GPL.

Sincere6066 2y ago

Why is OBS pushing flatpak?