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.
People who actually use Debian and similar distros will disagree. In their view there’s nothing wrong with shipping older, patched versions of open sourced software. The license says they can do it!
So they grossly understate the problem, make it seem like it’s the person authoring the software at fault or the one who’s being unreasonable.
They’re quick to tell you how great the maintainers are, how much effort they put in for free but they don’t share that same love for the author of the package. You know, the person who actually wrote the software. They don’t acknowledge that without the author they’d have no software to begin with, and that providing support to older versions of software is a cost to the author. Not just older, but possibly broken in subtle ways because of the patches applied on top. The author still gets all the blame and all the support requests for changes they didn’t make.
To be clear, there’s nothing wrong with wanting to run old, stable software. No one questions that their distro is “the most stable”. That they cannot or will not see the costs of doing so on the author is a shortcoming, but there’s no solving that.
when it's your screensaver, and I can break into your computer using a bug that's been publicized, so every idiot with access to Google knows about it, yes there's something wrong with running old software. that's just my opinion though. btw, where's your office?
Yeah, but it's a problem for the person who wants to run old software. It's their choice, I support that choice. As long as it doesn't affect me, I'm fully supportive. Of course I'll be affected if my data is stored on such a server, but I'm assuming some level of competence here.
I personally run on latest, apply all updates zealously within a week or two.
I don't like leaving this decision up to either the maintainers or the author, TBH.
They have different goals/purposes, often, and they frequently don't line up with my own.
Maintainers are exhausting in their own right, they do a ton of work and so they think their decisions are more important because of the work they do, user be damned...
Authors usually only care about their version of the software.
I think, a better medium, would be if a third party is packaging an application, perhaps they should always explicitly state they are the ones packaging it. Then there is less confusion.
Or, you know, let the author keep control of that...
Debian is the most stable distro for a reason. They don't rebase from upstream every 30 minutes because it is a community project. It is wonderful that volunteers have continued the Debian project for so long.
In contrast, Red Hat Enterprise Linux, a distro funded by IBM and countless faceless backers, has recently stopped patching many vulnerabilities, recommending to their users to rely on mitigations instead, despite the availability of upstream patches.
Furthermore, the recent vulnerability threatscape is inundated with CVE hunters who are desperate to call the most minor degradation of service a vulnerability. For a community project (and apparently an enterprise-serving megacorporation), this causes patching fatigue.
Where is the "every 30 minutes" coming from? You and another commenter have both used this identical phrase.It sounds as though the complaint was not because a patch hadn't been applied after 30 minutes, or even 30 days or 30 weeks. More like 30 months.
I said "every 30 minutes" as a piece of hyperbole, in my original comment.
I'm not really sure why everyone is focusing on that phrase, though. I think it's pretty clear if you read any of the source material, as said, that that is not an accurate representation of what was going on, and I would have also expected "every 30 minutes" to be a pretty clearly hyperbolic expectation for anyone to process updates after.
> I'm not really sure why everyone is focusing on that phrase, though
Is everyone focusing on the phrase? I thought I asked about it, and that's all that's happened.
> I would have also expected "every 30 minutes" to be a pretty clearly hyperbolic expectation for anyone to process updates after
I couldn't imagine a benign use of hyperbole in timeliness when some expectations of timeliness are silly, and some are sensible. I thought I'd ask, in case there was a good faith reason for it, rather than just assume you're trying to use insinuation to change people's minds.
This doesn’t seem similar at all. Debian didn’t break xscreensaver, they merely shipped a two-year old version at some point, in line with their stable releases. This is unlike how Fedora apparently broke their own OBS repackage.
Yeah, I'm a bit disappointed at how quickly the perception turned against OBS. Maybe I'm missing something, but their "threats" actually seem pretty reasonable: They asked Fedora to stop shipping a broken version of OBS/make it clear that the Fedora version is unofficial, they got absolutely no response for three weeks, then they requested that Fedora cease using the OBS trademarks. This is not like xscreensaver, this is much closer to Firefox/Iceweasel/etc.
I wasn't trying to suggest I thought OBS was in the wrong here, to be clear, just that the debate between maintainers and developers, and not wanting to get bugs for things that were external, reminded me of that exchange.
There's plenty of other examples, of course - one that springs to mind was when Ubuntu shipped a patch of their own design in OpenZFS that caused data loss, and it got reported to upstream.
To be fair, not necessarily singling out your comment: I've seen mixed sentiment around the net. I think the characterization of the threats as being "legal threats" makes people more prone to see this as the OBS project being vexatious, but it seems like it's more a last resort to get Fedora to even pay attention.
And credit to Fedora, it looks like they're working quickly to fix the problem now. It's pretty obvious it wasn't malice that led them to not respond quickly.
If you read the actual bug thread with the back and forth, they weren't to the point the fedora contact was pretty hostile about their use of a slightly old QT version and was adamant about keeping it in place. The fixes only happened within hours after the trademark/copyright request presumably because that went to legal and legal WTF'd at the whole situation and their maintainer's handling of the situation and magically it got fixed almost immediately thereafter.
I’m a Fedora packager (not for this package). Like many others I have an unrelated day job.
If there’s an upstream complaint I might get to it this weekend, maybe next. If I’m busy for a few weeks that doesn’t make me stupid.
Have had my share of “discussions” with upstream who want the latest version packaged when this might not be completely in line with our guidelines. Not an uncommon issue.
Yeah it’s not fair to expect volunteers to show up on weekdays, I agree with you.
But equally, I don’t think it’s fair that packagers want to have it both ways. Packagers want to make subtle, possibly breaking changes to software they didn’t author. The end users feel the pain and complain to the author. The author has no control over the situation, and they’re feeling the pain during the working week.
So the packager has been instrumental in creating the problem with the patch, and when requested to do something about it, turns around and says “buddy I do this for free, I’ll get to it over the weekend, maybe.” Sure, but the author is feeling the pain right now.
Again, it’s nice that you’re volunteering your time for others. But it would be good if you acknowledged that the costs of packaging aren’t borne entirely by packagers. Authors bear part of the cost when they get blamed for broken software.
Sometimes changes are required to meet packaging guidelines, sometimes you can get exemptions. Of course users often don’t realise who’s done what.
I suppose my advice to upstream would be to direct the end user to the Fedora bug tracker, where the bug can land in my queue. Or advise the user to install from a different source.
The upstream that I’ve dealt with have been kind enough to lodge a bug themselves on the package I look after, which is also an option, and much appreciated.
> I suppose my advice to upstream would be to direct the end user to the Fedora bug tracker, where the bug can land in my queue. Or advise the user to install from a different source.
How is upstream supposed to make this happen when distro maintainers not only don't mark the package as modified by them, but also silently change the flatpak configuration so that installing packages from flatpak in the way that would normally install a clean upstream build doesn't do so?
> Fedora views shipping EOL Qt as unjustifiable neglect
That's rich, coming from a project very closely tied to Gtk, which has a history of massive breaking changes, and outright removing functionality, leading to many projects continuing to use older versions of gtk for a very long time.
Many different people have different priorities in fedora.
I believe they mainly remove functionality between major releases of GTK, not within a release. Can you cite an example where they have done this between gtk minor releases ? Aka gtk 3.1 -> 3.2 ?
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.
I find it insane that everybody is seemingly okay with the fact that websites get to know what a user was browsing before landing on their site. And that there's no straightforward way to disable this behavior without the use of extensions.
There's nothing much to it. Jamie Zawinski just doesn't think highly of Venture Capital etc. He thinks that the first tech boom ruined San Francisco and he thinks that Paul Graham is terrible. That's pretty much it.
Considering that I've spent many a night at Bootie SF (back when it was at DNA Lounge) on too many drugs or alcohol to respond to on-call issues, it's entirely possible that he had more power over tech than it had over his life.
Like many people in San Francisco, he is an intelligent guy with great will to power and eccentric views.
Why do you need an article? Just find a link to some page on 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.
Alright, maybe "article" was a poor word choice? Thanks for an example of of what happens when you link to their site from here, I was just curious to read into the drama, it sounds like an interesting story from a pocket of the internet I'm not familiar with.
When I said "article," I guess I meant that I don't want to watch a youtube video detailing the drama or whatever, I was hoping to just read about it. Either way, thanks for the link and the explanation further down the thread.
Coders at Work has an interview with a pretty comprehensive backstory of his time in the tech industry. If you want to get more of his vibe, he's also in the documentary Code Rush.
Honestly it's refreshing to see someone in tech stand up to the VC-only vision of what tech can be. I still enjoy HN, but got a good laugh at image that popped up and agreed he has a point.
He seems to have a pretty good grasp of the average commenter here, I don't know what your problem is with him exercising his free speech rights on his own website to deal with people he feels that way about.
You can hate jwz as much as you want but the fact remains that probably 95% of ycombinator funded startups couldn't exist without making extensive use of the gpl, bsd, Apache and similar licensed software produced by a lot of open source curmudgeons and greybeards.
Many of whom share his same opinion on VCs and late stage capitalism.
I don't hate him and didn't write anything of the sort. I've never met him. He might as well be the tooth fairy or the Easter bunny as fas as I'm concerned.
> the fact remains that probably 95% of ycombinator funded startups couldn't exist without making extensive use of the gpl, bsd, Apache and similar licensed software produced by a lot of open source curmudgeons and greybeards.
Many of whom share his same opinion on VCs and late stage capitalism.
I've been using FOSS for personal use since I was a child. I'm a literal card-carrying supporter of the FSF. I'm more passionate about it than I am shitting on random people on the internet. If he has a problem with VCs then he can spam them with pictures of genitalia and ad-hominem attacks, not me, who's just some random dude who _isn't_ worth millions of dollars from a software business exit (along with thousands of others on this site).
It's a shitty move, I'll grant you, but it's also clearly a form of protest, and acts of protest are by-design intended to make the public uncomfortable in some way. As far as this kind of thing goes, I personally find it mildly amusing, mildly offensive, and mildly clever. I think the internet is more interesting for people like jwz doing things like this. Not necessarily "trolling," because this--for all its crude imagery and sardonic language--it's a very clever way to continuously raise awareness toward a larger issue they have taken with society. I was just motivated to read a pair of blog posts from 13-years ago, ones that required additional effort to access, and considered jwz's perspective on VCs and a hyper-aggressive work culture...for anyone who's ever attempted to publish any kind of content? That's kind of impressive.
Not that I would seek to deny your valid annoyance and offense. It's a non-consensual scrotum in a teacup. I personally would have gone a different direction, I get why that would raise someone's hackles.
More importantly, the link to the referenced article, properly marked up, since some quorum of nincompoops who hate the Web flagged the other comment destroying the link for any user/agent without showdead on (which will include every agent not operated by a user):
>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.
Why do they still mingle with sw distributions? Wasn't the sandboxed blob trend born also to try blackbox strategies and have parallel versions without dealing with too much hell? Was that laziness/economical advantage (EOL'd library, no business in porting fixes, upgrade to the latest and greatest) or something else?
Backwards compatibility is not in style anymore. Upgrading several libs system-wide is likely to cause breakage in old apps. A statically linked application doesn't rot (because linux guarantees userspace compatibility). By "doesn't rot" I mean "will keep running indefinitely without requiring some maintainer to keep working on the code indefinitely."
This is crazy because it's a flatpak, which should be a blob with all its deps in there, like a statically linked application "but better" for other system reasons because e.g. you can sandbox the app by design.
For this reason I don't understand why did they changed the library in there (that build of OBS wasn't broken because of system-wide libs, it was because allegedly they changed the lib in the flatpak), whatever the security hole couldn't they block it "from the outside"?
I don't understand what the big deal was there. Debian has its own bug tracker for all of its packages so the distro maintainers get bothered about bugs in old packages shipped by the stable version of Debian rather than upstream developers. JWZ decided to voluntarily subscribe to the Debian bug tracker for his package and then add a nag screen and start a flame war over them shipping an old version.
When you look at the about box, does it say Debian Screensaver based on xscreensaver, or does it say xscreensaver? When you Google the name of the program, whose website comes up first?
An unfortunate side effect of github being extremely user-friendly, while debian's reportbug tool still greets "novice" users with "please enter your SMTP host" (I dread to think what questions it would have asked me if I'd selected the "expert" mode)
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?
The idea behind it is really for corporate uses of Fedora/GNOME. Sysadmins, through Fedora Flatpack, can re-package certain software from Flathub in accordance with their draconian corporate policies.
As a person that has had to endure stupid corporate policies and since Fedora is _mostly_ used in corporate workstation. I can understand this.
What I don't understand why it's the _default_ to prefer Fedora Flatpack software over Flathub. For people that are just getting into linux, I can see why that's painful and the UX to be terrible.
"I installed Z software. It installed some junk re-package. I only realized it installed junk re-package after a week of investigation. Installing it from different source and now it works. Thanks, Fedora! I wasted a week of my time!"
From what I've read the Fedora project has an interest in providing solely open source and non patent encumbered software like codecs. Which sounds like something OBS may infringe on
Sounds like if the want to provide their own forked and less functional versions of software, they should rebrand the software like distros used to do with Firefox. Rather than cripple it and leave people blaming OBS.
Well, for one, Flatpak is a stupid design where the downloaded software gets to tell the system what if any sandboxing is applied. The way to have it be a security boundary is by enforcing the packaging :-(
You as a user can decide to install (or not) flatpaks based on their sandboxing settings, or even edit them with a tool like Flatseal. Which is a huge advancement compared to just allowing any binary to do any change in your system (with enough permissions of course).
Also, distributions can also provide their flatpak repos (or even another third party) and vet the packages with their own set of rules (such as "no packages with full filesystem access").
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.
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.
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).
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.
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.
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.
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.
"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…
Not really and I wasted my time browsing a massive thread of non-sense where people were arguing for and against "Fedora Flatpack is better than Flathub" software and vice-versa.
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.
> This is a formal request to remove all of our branding, including but not limited to, our name, our logo, any additional IP belonging to the OBS Project
Honestly it sounds very reasonable, if you want to fork it's fine, but don't have people report bugs upstream if you're introducing them.
I mean, I think the right fix is just for Fedora to stop packaging their own version. But I think that's about being good people; I don't think there's a strong legal argument here for forcing Fedora to do that.
That's what they were originally asking for three weeks ago. Or that they would at least make it clear to users that their version isn't official. Both options have been going nowhere until the legal threat was made. Now suddenly both are happening
> I don't think there's a strong legal argument here for forcing Fedora to do that
Isn't the argument that by mangling the software, they've created a version that is no longer the original software, and the the trademark owner want them to stop using the trademark to describe this new version? I think OBS would be happy enough if Fedora simply decided to release their own "FBS" package instead that was the same, other than describing it as "OBS", which the trademark owners have specifically said it's not.
From the first line of the IceWeasel Wikipedia entry:
> At issue were modifications not approved by the Mozilla Foundation, when the name for the software remained the same.
Does Fedora's OBS ship with non-free codecs as required dependencies?
What should they call the (demanded) fork?
Also,
Flatpaks have different file paths (like NixOS, which has updated packages according to e.g repology), and so selinux fails with many or most flatpaks.
> 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.
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.
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.
> They didn't modify anything other than the build, to exclude certain dependencies.
To be clear here: They do modify it further than that by applying a number of patches.
For example, they replace libx264 with OpenH264 which also requires some changes to the UI code since it is (unfortunately) hardcoded to expect x264 to exist. While there have been efforts to upstream those changes, they have not yet been merged.
Is it? Across Ubuntu, RHEL, and Archlinux, basically every package is being built against different versions of its underlying dependencies, and is being patched as needed to work with those distros. Trademarks weaken with lax enforcement, so you'd think if that interpretation held it would be amazingly dangerous for any trademark holder whose software was being packaged for Linux distros.
I think the specific argument being made here, is that the technical details of how Fedora implements this mean that people who do not read carefully and click a checkbox may attempt to install the official flatpak version and get Fedora's rebuild of it instead, with no obvious cue that they did so, other than the bugs that they then go report, not understanding the internals of Fedora's opinions on flatpaks.
I suppose the closest analogy I can imagine from non-malicious(arguably) history would be software hosting sites that would repackage installers with their own adware or toolbar or whatever "value add".
I think it is possible that OBS could make that nuanced argument in court: that what Fedora is doing here confuses consumers specifically because of how they stack multiple default repos and override the 1st party package. But it would hinge on whether consumers are confused about the product they're getting, and I think that's unlikely to succeed. Notably, I think the fact that users are going to the OBS project to report bugs is more likely to work against their case than for it, because it shows that consumers do accurately realize that the OBS Project owns OBS, not Fedora.
I worked for a company that sold high-end imaging equipment.
They had distribution networks, authorized to carry their brand.
But there were also “gray market” distributors, that would do things like resell foreign market gear, or devices that were separated from sales promotion bundles.
These were our brand, but the company would not support them. No hardware fixes (unless paid), no firmware upgrades, and no marketing support.
Often, the savings were minimal. It was expensive gear; even at a discount.
whichever one(s) the owner of the name "firefox" allows to be called firefox. Open source code does not automatically mean you get to use the name of the project in your redistribution of it.
Oh it's a way different situation (Debian followed every letter of both the license and trademark law), but is an example that most FOSS people remember of a trademark issue related to a distro packaging an OSS project and needing to change the branding.
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.
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
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...
> I just install it through the package manager and it just works.
It just works if the software you require is not only provided by your speciic distribution but also you require the specific version of the software that is provided by your specific distribution. Good luck if it not the case.
For windows or mac, 1 or 2 files each cover all systems from the last 10 years or more.
It's not by masochism that people regularly try to find solutions for linux by reinventing the wheel like appimages, snaps or flatpaks.
> , download some sketchy .exe or .msi and don't know if you'll get the software, a virus, or both.
You compare hunting for pirated software to installing open source software. You don't have more risk downloading an installer directly from the dev than from your distribution. And probably less once you go outside the main distrib.
> It got so bad that it was common to have "cleaners"
Yes windows has issues of letting remains of software that you desinstall(don't know for mac). But linux has issues too with remains, if only in your local directory.
I'm not saying that the other systems are perfects but the developers don't need to produce binaries/installer for 200 distribution times 10 version for each distribution
> For windows or mac, 1 or 2 files each cover all systems from the last 10 years or more.
Utter nonsense. What about code signing? A 10 year old installer won't be signed, and Windows/mac will scream at you about malware and you might have to jump through a bunch of hoops to get it actually installed.
> You compare hunting for pirated software to installing open source software
Pirated? How do you download MS Office? Adobe Acrobat? VLC? For all of those, on Windows and on Mac, you have to search the net for an installer. And pray that your vision is good enough to detect phishing/scam websites. (And sometimes it isn't obvious, VLC is downloaded from videolan.org).
It's really not that hard. On Windows you just tell SmartScreen to install anyway. On macOS once you've changed the system setting to allow unsigned executables, you right click and choose open and then tell it to run anyway. In both cases it won't bother you about it again for that executable.
> It just works if the software you require is not only provided by your speciic distribution but also you require the specific version of the software that is provided by your specific distribution. Good luck if it not the case.
It also just works if you install a Flatpak, which on distros like Fedora, you will be able to do by default through the software store app.
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.
```
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.
```
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. It is not clear if the reporter actually ever did.
> 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. It is not clear if the reporter actually ever did.
Just providing context here, this is what one of the OBS maintainers said in Brodie Robertson's video [1] about this issue:
> Hi, Joel from OBS here, thanks for the coverage! I can confirm that we absolutely did not want to have to resort to this, but did not feel that they were taking the concerns seriously, and when they resorted to calling us "terrible maintainers" we felt they made their position clear. I'd like to also let folks know that Neal Gompa (who opened the request to remove the Flatpak in addition to ours) manages the RPM, and we do not, and have not, ever had any issues with the RPM which is packaged properly.
With that in context, I'd like to believe while still a bit hostile, it was necessary since they really didn't care about what's being asked here.
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).
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.
As for the C&D, the github has some issues with Fedora distros and labeled as "Dependency issues" and there's no indication if the user is using the fedora flatpak or the flathub one, so if I had to guess I would guess that they aren't that happy with:
1. Being asked to fix bugs introduced by downstream.
2. Having their brand damaged because it isn't clear that the fedora
flatpak is a way more limited version than the verified one.
3. Having their issues with their complaints minimized and ignored by
the people responsible for the fedora flatpak system.
The thing about complaints being "minimized and ignored" really isn't true. There is a gigantic thread that's a direct response to their complaints: https://pagure.io/fedora-workstation/issue/463
yes, it recently got unfortunately heated with the whole "whose idea about what to do with Qt is better" argument, but the whole way through that ticket - which was filed 23 days ago, and has had active discussion going that whole time, including being the main topic at multiple workstation WG meetings - it's been pretty clear that the outcome is likely to involve Fedora flatpaks being demoted. The very first post is a proposal - by a key member of the workstation WG - to move flathub ahead of Fedora flatpaks in the precedence order. Consistently through the discussion, catanzaro and other workstation WG members have been supporting that idea, with a lot of discussion and argument about the details, as you always get in F/OSS projects. we do all the sausage factory stuff in the open, that's the point.
it's not exactly a case of 'lost their original vision'. Fedora is generally a fairly permissive project; we let maintainers do stuff. Since the mechanism to build Fedora flatpaks was needed (for the bundled flatpaks for Silverblue), it was normal - in Fedora terms - to say hey, let's just let maintainers use to it build flatpaks of any Fedora package, if they want to.
The obs-studio Fedora flatpak exists because the maintainer (yselkowitz) decided to make one. Ditto the few hundred others that exist - https://src.fedoraproject.org/group/flatpak-sig . Some of those are dupes of flathub, some aren't. Of the ones that are dupes, in some cases the flathub build is 'official', in other cases it isn't.
and yeah, yselkowitz created a lot of them, most of which are very simple - it's not really a lot of work to create a flatpak when there's an existing package, the definitions for most of them look like https://src.fedoraproject.org/flatpaks/bless/blob/stable/f/c... . Kinda the point of Fedora flatpaks is that you get a lot of the work done 'for free' in the package build.
I don't know why he decided to create all of those, maybe the idea was to try and create a critical mass of stuff so it would be kinda viable to get all your software from Fedora flatpak repos the way you can get all your software from Fedora RPM repos, if you want to.
> it's not exactly a case of 'lost their original vision'.
Considering that one person that says that he worked at the beginning of the project writes that the original idea wasn't to compete with flathub and given the current state of affairs I would argue that the project today doesn't have the original vision anymore.
As for creating a ton of projects, today with LLMs I'm pretty sure that I can write code that scrapes github repos for installation instructions and use it to create thousands of packages for everything that can run in Linux, doesn't mean that I should because there would be no quality control at all.
It is a noble idea to create packages to help create critical mass, but even with simple packages, seven hundred are more than anyone can use specially when we're talking about software that most likely have a GUI, and if you never really use most of the packages that you create you are bound to create these issues with QA.
All of that could be avoided (or minimized) if the fedora project created two flatpak repos, one for core software and one for contrib software, but that probably would be clear competition to flathub and probably be mostly ignored.
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.
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)
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.
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.
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.
From what I can tell reading the pagure.io thread (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.
> 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.
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.
> 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.
but.. Qt is only used for the GUI in OBS. It's not doing anything network-related or processing any data stream coming from there, why would any security issue in Qt matter ? Only thing I can think of is a crafted system font causing an issue but if you have a crafted font running on your linux system you are already compromised way beyond repair
Who cares what they claim? Flatpak was invented specifically to route around finger wagging distro maintainers.
Fedora has OBS in their native repos. They can go apply all their opinions to that copy. And if they're as right as they think they are, I'm sure upstream will be happy to take their patches for inclusion in the next flathub release.
Is that all there is to it? That doesn't mesh with the separate claim that Fedora's RPM package of OBS is acceptable to upstream - surely that uses the same latest Qt that Fedora offers? Fedora 41 already ships the very latest Qt 6.8.2 release.
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".
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.
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.
I think you're misunderstanding trademarks. As an example: if I buy a 12 pack of Coke, I can set up a table and sell them one can at a time. Trademarks require that I don't present that I'm sponsored by Coke, or label my non-Coke as Coke, or a variety of other things that would confuse consumers. That's the entire premise of trademarks: avoiding consumer confusion.
To your example: Debian had to rename their package because they were making modifications to the code of Firefox, so it wasn't Firefox anymore.
OBS could try to make the claim that how Fedora is packaging their code modifies the code, but that's way more tenuous given that building the product with different versions of its dependencies isn't really changing the code.
I think it's easy enough, ignoring the technical details of why, to just look at the results: the version of the app in fedora's repos is inferior to that on flathub produced by the developers. Exactly why this is the case is irrelevant, what matters is that users are getting confused, thinking they are getting an official version of the product, and that this is causing damage to the developers who own the trademark (extra effort in dealing with bug reports, loss of reputation).
Considering that trademarks have a long case law with being used to force redistributors offline (i.e. to force my app to not be available on Download.com); I think it is fair to say that it is well established that a trademark gives the owner total distribution control except where the first-sale doctrine intervenes (resale of a product acquired through a legal seller). That doctrine only exists for physical products though, and specifically for items that can be “bought.”
In the real world, Coca-Cola would "force a redistributor offline" by not selling them products, and setting up agreements with their distributors to limit who they can sell to. That's not trademark, and it doesn't transfer to free software.
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...
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".
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.
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.
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.
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.
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
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
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.
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.
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-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."
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.
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.
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.)