[HN Gopher] Please don't unofficially ship Bottles in distributi...
___________________________________________________________________
Please don't unofficially ship Bottles in distribution repositories
Author : ddtaylor
Score : 47 points
Date : 2022-06-07 18:10 UTC (4 hours ago)
(HTM) web link (usebottles.com)
(TXT) w3m dump (usebottles.com)
| Night_Thastus wrote:
| Could someone here clarify exactly what the problem is? I don't
| know what Bottles is, or what it means to be "shipped in
| distribution repositories". What does it mean to be "unofficial"?
| [deleted]
| nailer wrote:
| Bottles is a wine UI and encapsulation layer, similar to the
| separate previously existing project Bottles, which is is a
| wine UI and encapsulation layer.
|
| This new Bottles project is appealing to the community to
| change their behaviour as they are doing something the new
| Bottles finds undesirable.
| AshamedCaptain wrote:
| Why would you ever use one of these random "Bottles" wrappers
| instead of the actual Codeweavers Crossover (the company
| behind many of the salaries of actual Wine developers) is
| over me.
| brnt wrote:
| Last time I read about Bottles, they refered to a kind of Wine
| prefix. A dir or package that'd run your Windows program.
| [deleted]
| yjftsjthsd-h wrote:
| Bottles is a software package that makes it easier to run
| Windows software in Linux-based operating systems (using WINE
| as the compatibility layer, hence the name).
|
| 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.
| rsstack wrote:
| Bottles helps run Windows apps (especially games) on Linux.
| They have their own installers and updates channel. Generally
| when using Linux, you will usually install software from the
| Linux distribution's (like operating system flavor) software
| repository. It makes dependency management simpler, you get
| updates only after they're tested, etc. Those repositories are
| officially supported by the Linux distribution team (which
| could be employees for a company like Canonical, or volunteers)
| but not officially supported by the Bottles team.
|
| 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.
| kitsunesoba wrote:
| Anki does something similar by telling Linux users to _not_
| use the version from their distro 's repo and to instead
| install from the Anki site, citing misconfiguration on the
| part of distros.
|
| 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.
| Night_Thastus wrote:
| That clears it up mostly, I think. Thanks!
|
| 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.
| rsstack wrote:
| I think it's a complicated question to answer because there
| are so many possible combinations.
|
| 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.
| mjw1007 wrote:
| 4. A lot of modern software would be so painful to
| package that nobody can face packaging it anyway.
| arccy wrote:
| once you get enough reports, you recognize the pattern, and
| close them as "packaging/distro error" and kick the can
| back to the distros
| duped wrote:
| The solution to this is to change the license to forbid
| redistribution, not to write an open letter.
|
| 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.
| yjftsjthsd-h wrote:
| > The solution to this is to change the license to forbid
| redistribution, not to write an open letter.
|
| 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.
| duped wrote:
| I think this is a much more productive line of discussion
| than just asking not to distribute software.
|
| 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.
| SkyMarshal wrote:
| Or just keep the permissive free license, but commit to only
| supporting Bottles installed via Flatpak and no other way.
|
| 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.
| oh_sigh wrote:
| That will not stop users from trying to get your help, even
| by deceiving you about how they installed their software.
| smoldesu wrote:
| GNOME is in a position where any of their sponsored apps
| switching off of GPL could threaten their FSF endorsement.
| Creating a redistribution-hostile license forcing users to
| install Flatpaks instead of native packaging would definitely
| be an infraction of the FSF values, and it would certainly earn
| the ire of a non-insignificant number of users who have never
| touched Flatpak before or have no intentions of using it.
| jefftk wrote:
| _> The solution to this is to change the license to forbid
| redistribution, not to write an open letter._
|
| An open letter is a much softer approach. There's room for
| options between "legally permissible, end of story" and
| "completely prohibited".
| flaviut wrote:
| The other option is trademark enforcement. That's the approach
| Mozilla took when they were unhappy with how Debian was
| distributing their software:
| https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_...
|
| Remember Iceweasel?
| hexo wrote:
| Please, don't force me (or anyone) to use flatpak. My system
| package manager is very competent.
| mook wrote:
| I had basically the same thought: as a user, flatpak means I'll
| need to install an extra daemon for something that doesn't need
| to run all the time, and therefore it's right out. AppImage is
| better in that it doesn't need that, but it has other
| limitations for the packaged software. I've also used software
| that just plopped files into /opt/... not great, but at least
| it's mostly contained.
|
| If you're not going to support some users, don't be surprised
| that somebody else ends up doing it I guess?
| mort96 wrote:
| Then you should be perfectly happy with this ask! The article
| ends with this addendum:
|
| > 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.
| pavon wrote:
| When I see this I pretty much read it as:
|
| > 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.
| mort96 wrote:
| Why would you read it as that? It's clearly not "mature" as in
| "doesn't need to change much", but it seems like they're
| seriously committed to quality assurance and testing and stuff
| you generally don't associate with beta software.
|
| You don't get to write off all software that's not super
| compatible with some distros' packaging models as "beta
| software".
| sdkgjajggaf wrote:
| This is xscreensaver debacle all over again.
| https://news.ycombinator.com/item?id=11412081
|
| 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.
| marcosdumay wrote:
| I guess it's a reminder that most distros still don't have some
| way to report a bug for their package maintainers that is
| easier than reporting it upstream.
|
| Debian is almost there, but it's stopped almost there for a
| long time already.
| smoldesu wrote:
| I mean... for the most part, these _are_ issues that the
| upstream maintainers should be fixing. For example, the font
| rendering in Bottles broke when they updated to GTK4. Instead
| of fixing this in the actual GTK4 codebase, the GNOME
| foundation recommended that everyone start using Flatpak,
| where they could apply a very specific system patch that
| works around this issue.
|
| 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.
| marcosdumay wrote:
| If the upstream maintainers should fix, the distro
| maintainer is quite capable of forwarding the bug there.
|
| 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.
| Arnavion wrote:
| Yes. In the past users did start by reporting bugs to
| their distro, and the distro package maintainer then
| forwarded it to upstream if necessary. But lately users
| have become more savvy about talking to upstream
| directly. Probably because upstream source control has
| become more standardized and well-known (GitHub, etc) and
| easier to work with (don't have to futz with mailing
| lists and etiquette, just click the "New Issue" button).
|
| 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.
| viraptor wrote:
| > Imagine if you tried installing an app on Windows or
| MacOS, and they demanded that you install a separate
| package manager along with it
|
| 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.
| bee_rider wrote:
| I wonder if the issue could be solved by upstream. Spin up a
| new email address for each release --
| xscreensaver-1.0@some_domain.org, then once they've moved on
| to version 1.1, set up an auto response and stop checking the
| email address.
| mftb wrote:
| It is the same old problem and what's interesting to me is that
| I never see it articulated very well. I suppose it's because
| people disagree about what the problem is.
|
| 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.
| corrral wrote:
| > 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.
|
| 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.
| AnIdiotOnTheNet wrote:
| Uh, wouldn't you, as the user, rather have the power to
| determine for yourself which version you'd like to stop
| upgrading at? That certainly sounds a lot better than letting a
| bunch of unpaid third party volunteers determine that for you,
| which is how the distro/repo model works.
| pooper wrote:
| > unpaid third party volunteers
|
| 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?
| [deleted]
| yjftsjthsd-h wrote:
| In general, I trust the folks running the distro more than
| the folks writing the software in the first place. If nothing
| else, they provide/enforce a second pair of eyes to sanity
| check things before they get shipped.
| orev wrote:
| You do have the power. You can compile from source to any
| version you want. The caveat is that it breaks the primary
| reason most people use distributions--to get a set of
| packages that are consistent with each other.
| AnIdiotOnTheNet wrote:
| > You do have the power. You can compile from source to any
| version you want.
|
| Yeah, that's all that really needs to be said about that.
| And people wonder why the Year of the Linux Desktop never
| arrived.
| [deleted]
| striking wrote:
| This is the opposite of a YotLD problem, it's because
| Linux users do not usually participate in automatic
| updates that they consider this a problem. Windows and
| macOS and Android and iOS are all automatically updated
| and nudge users into updating more frequently than
| automatically.
| yjftsjthsd-h wrote:
| > And people wonder why the Year of the Linux Desktop
| never arrived.
|
| Because every time it did, people moved the goalposts.
| AnIdiotOnTheNet wrote:
| jerf wrote:
| No, that is not a relevant reason. There are people who
| have pinned their Windows versions, there are people who
| bypass Steam's autoupdates to run old versions of games,
| this is a general computing problem not a Linux problem.
| If you want to be particular about the version of
| something you're running you're not going to be able to
| rely on systems which were designed to remove that
| consideration from you, period. Nobody has ever promised
| that Linux or any other OS would just make all versions
| of everything work together all the time and you have the
| total freedom to pick anything with no consequences.
| mook wrote:
| > Uh, wouldn't you, as the user, rather have the power to
| determine for yourself which version you'd like to stop
| upgrading at?
|
| 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...
| fxtentacle wrote:
| In my opinion, the issue is mainly that Bottles is still very
| much beta.
|
| 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!
| db65edfc7996 wrote:
| You may disagree with how they develop it, but I am very much a
| happy user of Bottles (other than how needlessly hard it is to
| search). It has made configuring wine and friends so much
| easier than before. Previously, I would just give up on about
| the second random forum post indicating _this_ was the magic
| configuration required to run program X.
|
| I will eat the disk space and heavy updates if it means I have
| an easier time of running windows applications.
| smoldesu wrote:
| Why? Bottles has Flatpak-specific issues that haven't been
| resolved yet, and using system-provided WINE is a much better
| solution.
|
| Another GNOME Trojan horse, I suppose. Perfectly comfortable
| dropping Bottles for Lutris though.
| phoronixrly wrote:
| I was on-board with this comment until the uncalled for GNOME
| hate
| [deleted]
| viraptor wrote:
| > For a long time, we have included workarounds in the codebase
| to disable features or change their behavior when dependencies
| are missing or incorrect.
|
| I don't get this part. Why can't they enforce their constraints
| at build / start-up time instead?
| mjw1007 wrote:
| Maybe it's time for more free software projects to take advantage
| of the the "may require derived works to carry a different name"
| clause in the Debian Free Software Guidelines and the Open Source
| Definition.
|
| 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.
| yjftsjthsd-h wrote:
| > 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.
| whycombinetor wrote:
| I made it to the 4th paragraphs before realizing, no, they
| weren't talking about shipping water bottles. Their logo is even
| water bottles.
___________________________________________________________________
(page generated 2022-06-07 23:01 UTC)