Please don't unofficially ship Bottles in distribution repositories
usebottles.com
usebottles.com
Of course many distros will just tell the upstream to pound sand, and more power to them. When I'm perfectly happy running the version that shipped with my OS, I DON'T want your updates. Just leave me alone.
But that's exactly what jwz asked!
He wanted to be left alone by the army-of-people-who-are-not-you that kept reporting long-fixed bugs because they didn't know they were living in an ancient version of Debian.
For a distro that blithely patched the entropy out of OpenSSL (in order to quiet a valgrind warning), you'd think they could figure out how to write a script that substitutes an Debian maintainer's email addy for the author's.
To me it's this, Linux and it's distribution mechanism is skewed towards servers, and IT since that's where most of it's installed base is.
That's great. The distro/repo system is great, and works well. In addition to it, we need another system that serves workstations better. They don't have the same requirements in general. In particular there's a big divergence in availability, and security requirements. I really doubt there's enough economic inventive to serve this second use-case, but it's too bad, because I think we could have the best of both worlds.
It's not just servers—not having a very capable, standard, base set of packages to rely on for a workstation-targeting release (say, of GUI programs) is a huge problem. Instead, distros differ wildly on what they provide, users may have different versions of packages or even entirely different programs or libraries (the entire window server may differ!) serving similar purposes, some libs may simply be absent, et c. This is kinda OK if you stick to running software your distro bundles and only at the official version for your release of the distro, but quickly becomes hell (for the people packaging your programs, if not for you) as soon as you step outside that.
This is why you see a lot of companies that support Linux for their commercial software being very specific about supporting e.g. only one or two distros, at some very limited set of versions. It's very hard to support "Linux" in general, especially for desktop-targeting software, because the Linux GUI and multimedia stacks are... well, they're a shitshow, frankly.
GUI heavy application like chrome, firefox or openoffice run on all districts without any hiccup!
what am i missing ?
The closest thing to a solution is picking one of the two big desktop environments and targeting that to give you some amount of consistency and stability, but it's not like people will only run your program in that DE (again, possibly not even in the same window server you developed on) so you may end up with bugs when e.g. your QT/KDE program runs under Enlightenment, plus a ton of basic stuff can still vary a lot even if you restrict support to one DE (think: audio daemon) which may affect all kinds of things in unexpected ways.
> GUI heavy application like chrome, firefox or openoffice run on all districts without any hiccup!
Ever seen a thread full of people exchanging advice on how to get these programs not to exhibit certain widespread glitches on Linux, many of which have been a problem for years? Thinking especially of things like tearing, or multimedia playback problems. They even crop up here on HN from time to time.
In the era of servers that were hand-tended by a BOFH who upgraded only rarely (and screw the users who want to use something newer), the distro/repo system worked. But even servers are not generally maintained that way anymore. I honestly think we're going to see that model fade away in the next decade or so.
I’m fine with an author saying “I no longer want bug reports from that version,” and I’d like someone with the distro to act on those instead.
If you need local development/production environment version parity, use container images or package locking files available in most programming language ecosystems.
I strongly disagree about the difference in security requirements. I don't want anybody to pwn my banks servers, not less or more than pwning my home desktop or mobile phone.
Debian is almost there, but it's stopped almost there for a long time already.
These days I think distros should ship only the core OS components and let tools like flatpak give you user level apps direct from the source. I largely don't care about having the absolute latest version of Gnome or systemd. But I very much do care that all of my applications, especially internet connected ones are. I stopped using distro packaged telegram binaries because it would take a month before they got updated and in that time I'd have to use my phone to view all the unsupported messages sent.
This is the problem with encouraging this "use our kitchen sink" behavior. It encourages poor development practices, and it ends with developers grovelling and asking users to switch their packaging systems. Imagine if you tried installing an app on Windows or MacOS, and they demanded that you install a separate package manager along with it. It's an unacceptable demand to make of anyone, and certainly shouldn't be the behavior we encourage if we want to live in a world of high-quality Free Software.
This is basically how Windows works. There's no package manager, so effectively anyone shipping larger software ships their own auto updater, their own dependencies and either embeds or downloads extra installers for the MS redistributables at install time. They don't ask you, just effectively do it anyway.
The upstream developers here are complaining because they get the bug reports, but can't fix the issue (at least the way they want to).
That's independent on those few large groups that poped-up on the FOSS community that push a lot of badly maintained software. Yes, those are a problem too, just a different one.
It's not even specific to Bottles or Flatpaks or whatever; it happens with regular Linux software too. In the systemd tracker you'll find people complaining about issues that have been fixed in systemd's git repo, but because the people are running distros with older versions they think the issue hasn't been fixed yet.
Most error messages I've googled have led me to unresolved Linux bugs in various distros. Fedora users seem especially good at reporting bugs to their distro maintainers, though this does not always result in any kind of solution.
In my opinion, every distro should be allowed to ship their version of a package, but the moment packages get frozen (i.e. for LTS distros) or custom patches get added (i.e. Debian) all contact links to upstream developers should be removed immediately and replaced with the email address of the maintainer of the package. This should hopefully prevent the jwz problem while at the same time bringing the users of these distros the stable release cycle they want.
If more people are like me, then that wouldn't help solve the problem at all.
Even then I've found that many Flatpaks are broken on Ubuntu that work fine on Manjaro. Weird distro configurations really are a terrible burden on developers, this stuff makes me never want to publish software that gets absorbed into distros.
Mozilla was right to force Debian to rename their modified version of their browser. More packages should use such policies in my opinion, especially if they're complex to set up right like this piece of software.
Given that I'm not using Linux From Scratch, I'd say no: part of the reason I'm choosing a distribution is because I want to make somebody else deal with tracking updates (including security). I recognize that this comes with downsides (e.g. sometimes new versions have new bugs).
I kind of miss the pre-internet times when shipped software is, well, shipped and static, and typically bundled all of its dependencies outside the OS (which was just listed on the box). On the other hand, I'm typing this on a smartphone that couldn't exist in that model…
I guess what I would really want is a) manually built packages install into opt and use a mechanism like update-alternatives to get things into PATH or wherever they need to be. b) Possibility to track an https endpoint for information about new releases. Could be something as simple as a text file of all versions with url of tarball and a flag for whether the version has known security issues.
Yeah, that's all that really needs to be said about that. And people wonder why the Year of the Linux Desktop never arrived.
Because every time it did, people moved the goalposts.
I, for one, am grateful that things like FlatPak and AppImage are finally gaining traction and I hope the trend continues.
I struggle with this question as well but a small nit here is the folks at Fedora or Debian are not third party. They are a trusted source for me.
I don't know what would be a good solution. Being available on flathub is a good start but I'd argue it is not enough. I'm going to say the proper solution is the same that I advocate Google Play and Apple App Store to follow:
1. require developers to submit source code and machine readable build instructions
2. the store should build the application (fat binaries, differential small updates, whatever, the app store is in charge)
3. ...
4. Profit?
C.f. Iceweasel
> This software is not mature yet. Beta testers are highly welcomed, but neither users nor developers get value from people running a beta release that is over a year old.
Which is a perfectly reasonable position for a software project to be in. And if they want to continue to treat their project as Beta software indefinitely that's fine too, but I will treat it as such.
You don't get to write off all software that's not super compatible with some distros' packaging models as "beta software".
So even if you have a personal definition of "beta" which categorises this software as "beta"... that's not even remotely related to the contents of the article.
many of these unofficial packages behave abnormally due to the nature of distribution models
Bottles is a complex software that receives frequent updates and requires several dependencies at a minimum specific version to properly work
but yes, you are right, arguing that bottles is beta seems besides the point. the problem appears to be that distribution packagers seem to think that linking bottles to old libraries is better than not having those bottles at all. if that is really the issue then i agree that this is not always a good idea.
unfortunately the article is not clear about that. they could have said:
do not package bottles unless your distribution can satisfy the exact version requirements that the bottles need.
on the other hand, it is not true that old libraries are always a problem. which brings us to lack of QA to test if those backports actually work. again, the article just hints at the issue without spelling out the problem in detail.
Our invitation is addressed to all those who are packaging Bottles incorrectly and/or do not provide adequate tests
was added later.
in summary though their request is reasonable. they do invite the packagers to work together and are not bitter or spiteful. let's hope that the packagers will listen.
Beta is the last step before release. Nowhere in the definition of "release" is there a requirement that there will be years until the next release, or whatever you think "stable" means in this context. And frankly, release frequency isn't even the topic of the post; a lack of distros doing QA of their packages is the topic. Which hardly falls on Bottles for being "unstable".
if frequent releases are caused by bugs that need to be fixed then that's not stable.
It really needs those frequent updates, which makes it a bad candidate for distro packaging. The correct decision, in my opinion, would have been to break it up into a stable GUI / configuration system and a daily updated "core engine", similar to how antivirus software updates its detection lists. Distros then package the stable parts and the core engine is updated on-demand.
But instead they insist on merging everything and all dependencies into one huge (and in my opinion very bloated) flatpak image which you, the user, then re-download for every tiny update. 10kb code change? re-download all dependencies and all assets!
I will eat the disk space and heavy updates if it means I have an easier time of running windows applications.
I have never experienced this with flatpak. The updates have always been very small unless they require a new platform version, but these platforms are shared between packages as well.
Having custom updaters in every package to fetch a new "core" sounds like the worst of all situations leading to something like windows where every time you open an app it prompts you to download the new version.
The effort required to implement this in practice is pretty sizable, and antivirus software ships out signature updates at a much higher frequency than Bottles would be.
> 10kb code change? re-download all dependencies and all assets!
Any unchanged files are not redownloaded.
Would any distro allow this? AFAIK they don't allow distro packages to depend on outside stuff.
Bottles is asking the various Linux distributions to stop offering Bottles through the distribution repositories. The Bottles team wants to own the relationship with the end-user under their own terms: only recent versions, only installers that were tested by them personally, and they will support the community issues. Today distros often deliver older versions and modified installers, while still sending the community to get support from the Bottles team.
The problem with this is that all they have available on their site for Linux users is source tarballs which the user is then expected to build themselves, which leads to some of the same problems that come up with distro builds.
I think it's legitimate for projects to not want to be included in distro repos to avoid problems with misconfiguration and the like (though I think it's probably better to design the project such that this kind of failure isn't possible), but doing that should go hand in hand with providing officially supported binaries in some way, whether that be via flatpak, AUR, custom PPA's, etc so there's always an option that is known to be built correctly.
How do other software creators deal with this problem? I can see how getting reports for issues could be frustrating if they weren't easy to replicate due to the distribution having a different version of that software.
1. Simpler software doesn't usually have issues with broken installers.
2. A lot of software doesn't get frequent-enough updates that old versions would matter.
3. High-profile projects usually have personal connections with the major distributions' packaging team (or even a "personal union", where it's actually the same people).
And there are other cases. I think Bottles got stuck in a spot where their software is _very_ complicated to install correctly, updates often (young project + interactions with 3rd party software such as games), and they're a small team that doesn't have a way to work efficiently with the distributions.
They embed time bombs in their software to berate the Debian maintainers for leaving ancient versions of packages up.
A Linux distribution (often just "distribution" or "distro") is an operating system that combines an assortment of software packages together; typically a kernel (some version of Linux), core system utilities (coreutils, an init system / service manager), a package manager (program to install software from specified sources; this will become important in a moment), and frequently some sort of graphical system (Desktop Environment). The name is because it distributes a collection of software together.
The thing is, the vast majority of software shipped in/by a distribution isn't written by the distro; a distro is at some level simply a collection of scripts to download sources, compile it into package files, and then bundle those into a usable system. While there are exceptions, most distros have official repositories of software that's been packaged for that distro.
What's happened here is that Bottles is a software package that explicitly doesn't want distros to ship it. Bottles views the packages built/shipped by Linux distros as "unofficial" because they weren't created by the Bottles project.
This new Bottles project is appealing to the community to change their behaviour as they are doing something the new Bottles finds undesirable.
> The Manage Bottles functionality lets you manage the Windows software you have under CrossOver, and displays information regarding the bottles they are placed in. You can think of a bottle as a selfcontained Windows environment. Bottles can come in several different flavors—Win98, Win2K, WinXP, etc.
https://media.codeweavers.com/pub/crossover/marketing/Review...
I think I'd be happiest in a world where distributions make their own decisions about what to package, but in a way that doesn't lead to their users filing unhelpful issues in the upstream bugtracker.
AFAIK most distros also view that as a bug, actually; every time I've seen it discussed was in the context of telling people to file bugs against the distro's bug tracker, both because distros can and do have local bugs that don't even make sense to upstream, and because distro maintainers are generally much better placed to triage and sometimes debug issues.
> Our invitation is addressed to all those who are packaging Bottles incorrectly and/or do not provide adequate tests, thus invalidating the user experience. We are happy to help anyone who would like to keep their package, adapting to our quality standards (i.e. making the application work as it intended).
If your system package manager and the people who package Bottles for your system are both very competent (i.e they don't break the software they package and don't introduce problems), Bottles isn't asking your system's packagers to stop packaging the software.
If you're not going to support some users, don't be surprised that somebody else ends up doing it I guess?
I think something that is worth discussing is the model of the Linux distribution that leads to poor user experience like this, the distribution issues they are having would be worth discussing in a longer and more technical blog post. It's come up many times among criticisms of Linux ecosystems and distributing user software, but it doesn't seem like the message lands well.
It's remarkable how much easier it is to write software on Linux yet equally remarkable how much more annoying it is to reliably distribute it, compared to say MacOS .apps, the iOS/Android app stores, and to a lesser extent Windows. I don't think there has to be a tradeoff here between Freedom and UX.
That depends on goals and what they're willing to do to accomplish those goals; it's quite reasonable to not want to stop being open source over this and to try asking nicely.
> I think something that is worth discussing is the model of the Linux distribution that leads to poor user experience like this[...]. It's come up many times among criticisms of Linux ecosystems and distributing user software, but it doesn't seem like the message lands well.
Because it's not universally viewed as a bug. Plenty of folks explicitly want to download software from their distro's official repos, get something that's specifically tested (and if need be, patched) to play nice with the system, and stay on a known stable version. Because the flip side of this complaint is distro maintainers pointing out that if you downloaded random 3rd party software and added it to your system, they're no longer capable of assuring you that the result will work.
> It's remarkable how much easier it is to write software on Linux yet equally remarkable how much more annoying it is to reliably distribute it, compared to say MacOS .apps, the iOS/Android app stores, and to a lesser extent Windows. I don't think there has to be a tradeoff here between Freedom and UX.
Some folks would argue that it's harder because you shouldn't be doing it; https://drewdevault.com/2021/09/27/Let-distros-do-their-job.... . But if you want to go that way, there's always flatpak/docker/snaps to go around the distro and ship directly to end users.
For example, distros don't provide the guarantees you're talking about - they arbitrarily introduce fragility (for example, by requiring shared dependencies that may have conflicting versions) and don't keep up to date with the upstream software that has bug fixes. That's precisely why software authors prefer to release as flatpaks - regardless what distro teams claim, bugs and crashes manifest as problems in the distributed software (not the OS) and are reported to the upstream authors whose users demand fixes.
In short, distros can't provide assurances that software will work. They can't fix it if it's broken, either.
I disagree that it isn't the software authors' job to distribute their software and fix bugs for their users when using it. The only folks who seem to insist that this is The Way Software Should Be Installed are distro authors and a tiny minority of users who are ok with broken code shipped by their OS authors instead of working code by the original authors.
Imagine if an app crashes on Windows or MacOS, a user reports the app crashed, and the author replies: "Sorry it's Microsoft/Apple's fault for shipping broken software on their end, complain to them instead." Because that's the same quality of user experience when a distro ships older versions of software or try and link against invalid dependency versions.
It is a very rare occurrence that my distro's packages are more than a week out of date from upstream releases
> That's precisely why software authors prefer to release as flatpaks
This implies that "software authors" do "prefer" releasing flatpaks, a plainly false statement for the vast majority of software.
> distros can't provide assurances that software will work
based on interpretation, either plainly false or a misrepresentation. They can't guarantee that software will always work because they operate in the realm of reality, but their raison d'etre is to package software together so they interoperate.
> They can't fix it if it's broken
In fact, distros regularly patch software so they're not broken before (if ever) those patches are merged upstream
> a tiny minority of users
A "tiny minority" of users prefer using their system's package manager? Implying that the vast majority would prefer all their software be packaged and flatpaks and appimages and docker containers? I don't know where you're pulling these numbers from but I bet it smell crazy in there
Remember Iceweasel?
And regardless, I'd expect expect someone asked to stop using a given name & logo to be more willing to cooperate than someone told to stop packaging it entirely.
An open letter is a much softer approach. There's room for options between "legally permissible, end of story" and "completely prohibited".
Then put that support policy front-and-center on their website and in the LICENSE.txt file so that anyone seeking support knows that the Bottles team only supports Flatpak installs.
I don't get this part. Why can't they enforce their constraints at build / start-up time instead?
PS: many problems with packages on NixOS are on NixOS. If something is not working always try first to discet it yourself and seek help on Matrix if you are stuck, need help or just have general questions. If you can find a fix, PRs are always welcome. If not that's okay. Maybe you created interest on matrix and someone is going to jump on the fix train. Also you can always creame an issue with all the information you already gathered and logs.
It's amazing how far up their own butt people can get with this stuff. Sure the intended audience for this blog would know what all this stuff is, but it's comical how little sense it makes when all the names of things sound like English, but clearly are overloaded. Bottles, FlatPak, Flathub, distribution repositories, etc.. This is especially confusing coming from HackerNews since there's a bunch of stories about shipping containers recently (as it the 40' long steel boxes that go on large cargo vessels across oceans).
I realize that not everything can be written for any random person on the internet to stumble upon and have it make sense, but since any random person can end up on a blog page, some context would be helpful.
It's always baffling to me the web sites for newspapers or restaurants which assume that I know what city/state/country they are in, just because I've landed on a page. Perhaps putting that somewhere in the header/footer just to help ground people would be ok?
Now I'm leaning toward Debian and alike, as mainteners do a lot of work I value while developers of many modern products don't. I remind myself about it each time I have to fight with npm issues, for instance.
Another GNOME Trojan horse, I suppose. Perfectly comfortable dropping Bottles for Lutris though.