Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenBSD won't update Firefox, advises users to switch to ESR

undeadly.org

Post reply on HN
Print view View original

161–170 of 339 posts

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#161

Post by inferiorhuman »

int_19h wrote: post #75
jiveturkey wrote: post #63

Earlier quoted context omitted.

it wouldn't necessarily. you could just update rust, build firefox and test that. leave the others alone (with older rust). now if the complaint is solely about rust, not specifically FF, then that's a different story. it might indeed be that FF is the only package using Rust right now?

BSD ports tree can be thought of as versioned as a whole, and packages are basically a snapshot of one particular state of it. If you update one port, and it's a dev dependency for other ports, their packages will reflect that.

Right but you will also find versioned ports e.g. gcc4, gcc5, etc. It's not so unreasonable to assume the maintainers could / would do something similar with rust.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#162

Post by inferiorhuman »

int_19h wrote: post #76
floatingatoll wrote: post #28

Earlier quoted context omitted.

> Now what? Discard the outdated assumption that a single installed dependency version is sufficient for all packages, and then improve the packaging system to permit multiple releases of Rust, Python, etc. to coexist as dependencies so that packages can migrate gradually over time rather than forcibly whenever one crosses the line. Homebrew does a fine job of this. Installing python@2 doesn’t necessarily mean it’ll…

Python 2/3 is not a representative example, because it's actually designed to be installed side-by-side by the authors. Many libraries and apps on Unix are not. NixOS changes a lot of things to make it all work. If you're willing to pay that tax for the sake of package management, great! People who use BSDs generally aren't.

Python 2/3 is not a representative example, because it's actually designed to be installed side-by-side by the authors. Many libraries and apps on Unix are not.

Rust is designed to support multiple toolchains with rustup. I've got the following installed on my desktop box:

  stable-x86_64-apple-darwin
  nightly-2018-12-14-x86_64-apple-darwin
  nightly-arm-unknown-linux-gnueabihf
  nightly-x86_64-apple-darwin (default)

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#163

Post by rascul »

tobias2014 wrote: post #144
celticmusic wrote: post #126

Earlier quoted context omitted.

https://wiki.archlinux.org/index.php/Frequently_asked_questi... ? > It is the user who is ultimately responsible for the stability of their own rolling release system. The user decides when to upgrade, and merges necessary changes when required. If the user reaches out to the community for help, it is often provided in a timely manner. The difference between Arch and other distributions in this regard is that Arch is…

This is funny, I could tell exactly the same story the other way around. I came as a 10+ year Debian user to Archlinux because it did too much automagic under the hood that broke and took a lot of time to fix. No breakage on arch because no automagic behind your back. For a long time before using arch I thought too that rolling release might be more unstable, but I have come to the conclusion that quite the opposite…

Could you give some examples of the automagic stuff Debian does under the hood?

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#164

Post by avar »

zrm wrote: post #153
l0b0 wrote: post #140

Earlier quoted context omitted.

> You may want to check out Nix. Nix is a fantastic concept, and I hope it takes over the world. But the NixOS packages are a mess. I tried it for a few months last year before giving up after several packages and even whole collections of packages became unusable even in the stable repository. The repository needs some serious reworking before Nix can really shine.

It's really trading one problem for a different one. The reason traditional distributions only package one version of a given library and make everything use that same version is so they only have to maintain one version of the library. If you allow every application to choose its own version then they all choose a different one, which means someone then has to continue to maintain every different version of the libr…

It doesn't entail any of that. Traditional distributions like Debian allow you to install any number of library combinations, they just do so badly by requiring you to do so on different installations updated at different times.

Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in the wild.

It just means when users upgrade they can do so gradually for some sets of packages at a time. You can emulate this on traditional distributions by having a single VM image you use for your browser, then cloning the image, updating packages, and using that one for your E-Mail etc.

Having a mechanism like this should mean less support is needed from the distribution, because system-wide breakages are less likely to occur.

You'll get the same bugs, but users can easily back out say an OpenSSL version with a security fix for the 5% of packages it breaks with, while retaining the fix for their browser & other high-risk packages.

For example, I currently can't upgrade my firefox version on Debian testing because it ">=" depends on a version of a couple of libraries that some 100-200 other packages on my system don't like.

In Debian testing this sort of thing happens occasionally and will get fixed sooner than later, but that it happens at all is just an emergent property of how the versions are managed. If I were to run the latest firefox with those new versions and not touch the other packages until they're recompiled both myself and the package maintainers would be exposed to fewer bugs, not less.

I'd get a bugfixed firefox today, and they wouldn't need to deal with bug reports about a broken upgrade, or firefox bugs in an older version users like me can't upgrade past simply because firefox happens to share the use of a popular OS library.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#165

Post by serf »

chmln wrote: post #123
celticmusic wrote: post #111

Earlier quoted context omitted.

I left arch linux because I got tired of all the breakages, so not a great example.

This has to be one of the most inaccurate memes of all time. To counter with anecdata: I've been running Arch Linux testing repositories for over a year now with no issues whatsoever.

I like Arch. I run it at home.

That said, just because you had good luck doesn't mean that it's stable.

Here's the most trivial way I can think to explain this:

Check out Arch News.[0] Ctrl-F (Find) 'manual intervention'. Six years of results on the first page ; 13 instances of 'manual intervention required'.

Reliability != stability. Stability usually implies a platform on which one can use and develop for without expecting common major changes, if ever.

As for the anecdote of using the [Testing] repositories, a users experience with such things really depends on their use of new and currently developing software.

A simple computer with simple peripherals that is used to run emacs all day isn't likely to be broken by the Testing repositories.

Personally , my anecdote : the second someone starts using Arch for something new-fringe (hi-dpi, touch, tablets, SPDIF, SLI, NVRAM, new window managers, new x-windows replacements, prototype schedulers, filesystems, or kernels, PCI pass-through, exotic RAID configurations..) [Testing] repository is an act of masochism. It's only a matter of time before something drops out.

I found that my best bet was chicken sacrifice and Opus Dei-style self flagellation before each [Testing] 'pacman -Syu' . At least then I had a 50/50 chance of the next boot. But, granted, I use a lot of weird or fringe hardware.

All that said : other distributions don't have better [Testing] repositories. It's just that [Testing] is for .. testing. It's unstable by its' very nature.

[0]:https://www.archlinux.org/news/

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#166

Post by jrockway »

blackhaz wrote: post #14

I am arguing about this on FreeBSD forums - from an end user perspective. I think the benefits of saving disk space by sharing libraries do not justify the inconveniences we, desktop BSD and Linux users, obtain from being forced to disrupt and upgrade hundreds of installed software packages, just because one single desired upgrade requires to pull its dependencies. The whole ecosystem falls down like a card house - o…

I agree.

I also think that large projects should just vendor their dependencies, including compilers, so you git clone the thing, type "bazel build", and have a working binary. (I am fine if the dependencies are not checked in to the repository, a bazel WORKSPACE file is fine with me. It records a checksum for all dependencies, so even if you reach out to the Internet to get it, you get the same bytes as the developers working on the code.)

Building and distributing software should be very simple. But it's not, because of an accumulation of legacy tools (shared libraries) and practices ("please install these 6000 dependencies to build our project").

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#167

Post by joecool1029 »

djsumdog wrote: post #152
blackhaz wrote: post #14

I am arguing about this on FreeBSD forums - from an end user perspective. I think the benefits of saving disk space by sharing libraries do not justify the inconveniences we, desktop BSD and Linux users, obtain from being forced to disrupt and upgrade hundreds of installed software packages, just because one single desired upgrade requires to pull its dependencies. The whole ecosystem falls down like a card house - o…

Is that what's going on? I wonder how the Gentoo maintainers are dealing. They frequently unbundle libraries, but I've also see a lot of packages with use flags like system-jpeg or system-sdl to force the ebuild to use a system library instead of the built in. Firefox, Libreoffice and others big applications typically take a long time to compile because they have so much stuff built-in instead of depending on the sys…

> I wonder how the Gentoo maintainers are dealing.

I spoke to the gentoo firefox package maintainer last night. He even has firefox building on aarch64 with musl, so things are pretty good. For more common targets, there's also the option of using the official binaries from Mozilla.

Gentoo policy is to attempt to provide a way to use system libraries where possible except when those libraries are too heavily modified. If something breaks, they use the bundled package. You can see that's currently happening with harfbuzz in firefox until they bringup the patch: https://github.com/gentoo/gentoo/blob/master/www-client/fire...

From experience, it's usually fine to use system libs when available unless those system libs are unstable or development releases. Then all bets are off.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#168

Post by jrockway »

progval wrote: post #105
blackhaz wrote: post #14

I am arguing about this on FreeBSD forums - from an end user perspective. I think the benefits of saving disk space by sharing libraries do not justify the inconveniences we, desktop BSD and Linux users, obtain from being forced to disrupt and upgrade hundreds of installed software packages, just because one single desired upgrade requires to pull its dependencies. The whole ecosystem falls down like a card house - o…

> auto-update more than a thousand packages, praying my Python and other projects survive, just because I want a browser update You may want to check out Nix. It's a package manager which isolates each program's dependencies; so you can have multiple versions of the same package. > or a security fix having a centralized repository like this helps in case a it's a library that needs a security fix, because you only ne…

Is this kind of like Ubuntu's "snap" thing? (I know snap involves cgroups, which aren't strictly necessary to give Firefox a different version of rust than everything else... but it seems widely deployed and easy to use, at least if you're on Ubuntu.)

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#169

Post by pmontra »

blackhaz wrote: post #14

I am arguing about this on FreeBSD forums - from an end user perspective. I think the benefits of saving disk space by sharing libraries do not justify the inconveniences we, desktop BSD and Linux users, obtain from being forced to disrupt and upgrade hundreds of installed software packages, just because one single desired upgrade requires to pull its dependencies. The whole ecosystem falls down like a card house - o…

I never experienced that catastrophic breakage and I'm using Ubuntu as my only desktop OS since January 2009. When did that happen to you?

I have no problems with the standard approach. Actually, it makes me feel safe: a maintainer fixes a vulnerability in a shared library and all apps are fixed. If all apps shipped their own libraries I'd have to download a new version of all apps, if they ever care to fix their code.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#170

Post by ihucos »

blackhaz wrote: post #14

I am arguing about this on FreeBSD forums - from an end user perspective. I think the benefits of saving disk space by sharing libraries do not justify the inconveniences we, desktop BSD and Linux users, obtain from being forced to disrupt and upgrade hundreds of installed software packages, just because one single desired upgrade requires to pull its dependencies. The whole ecosystem falls down like a card house - o…

Generally it could be possible to run single (bloated) applications inside a container. Here is the solution I wrote for Linux: http://zpkg.plash.io/
Post reply on HN