OpenBSD won't update Firefox, advises users to switch to ESR • Hacker News Board

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

#191

Post by ENOTTY » Sun, Jan 12, 2020, 10:50 AM UTC

jmclnx wrote: post #139

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…

It is not disk space you should be concerned with saving, but real memory usage. I wonder how much memory a statically liked Firefox uses under a heavy load. I checked with esr (what I use) and it is about a bit more that 1.3G excluding shared. So as firefox creates threads, I would think memory could get tight with a statically linked FF. I fully agree with what OpenBSD has decided, I think the only thing worse that…

Seems to me that more aggressive memory deduplication at the kernel or hardware level should be able to mitigate memory explosion from using only statically linked binaries or letting “big” frequent updated projects manage their own dependencies.

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

#192

Post by rusk » Sun, Jan 12, 2020, 10:57 AM UTC

progval wrote: post #190

microtonal wrote: post #155

Earlier quoted context omitted.

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. In principle true, yes. But it comes with a cost. Even the nixpkgs Firefox maintainers are considering to only ship Firefox ESR starting with NixOS 20.03: https://discourse.nixos.org/t/firefox-on-19-09-could-be-mark... https://github.com/NixOS/nixpkgs/pull/72126

I won't blame them. Firefox is a huge piece of software, and is updating every month . It's a bit shitty of Mozilla to expect every single distribution (most of which are run by volunteers) to package all their new dependencies and check everything works every single month.

This sounds like ”move fast and break things” writ large, and a salutary lesson in the flaws of this approach.

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

#193

Post by gdxhyrd » Sun, Jan 12, 2020, 11:02 AM UTC

Mirioron wrote: post #173

ihucos wrote: post #170

Earlier quoted context omitted.

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/

I think containerization is going to be the future for applications in general. It would certainly make using different versions of Python easier.

Why? Using different Python versions is a solved problem and no containers are required for that.

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

#194

Post by gdxhyrd » Sun, Jan 12, 2020, 11:04 AM UTC

jmclnx wrote: post #139

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…

It is not disk space you should be concerned with saving, but real memory usage. I wonder how much memory a statically liked Firefox uses under a heavy load. I checked with esr (what I use) and it is about a bit more that 1.3G excluding shared. So as firefox creates threads, I would think memory could get tight with a statically linked FF. I fully agree with what OpenBSD has decided, I think the only thing worse that…

> So as firefox creates threads, I would think memory could get tight with a statically linked FF.

Threads have nothing to do with that and don't increase memory usage due to dependencies.

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

#195

Post by [deleted] » Sun, Jan 12, 2020, 11:13 AM UTC

jiveturkey wrote: post #57

stanferder wrote: post #53

Earlier quoted context omitted.

Does it actually work though? It seems like there is a significant difference between the expectation that semantic versioning should result in no disruption, and the experience of the parent to your comment. I'd be interested to know exactly what went wrong that lead that poster to be pessimistic.

Yes it does actually work and has for decades. The poster is either confused or doing something different, I expect. The specific notice mentions rust dependencies. Rust does not have shared libraries, so a Rust [security] update means all rust binaries must be completely rebuilt. That seems to be part of OpenBSD's concern, and perhaps this has "triggered" the poster. user blackhaz random forum post found: > mariourk…

[deleted]

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

#196

Post by strictfp » Sun, Jan 12, 2020, 11:14 AM UTC

jrockway wrote: post #166

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 develope…

Sure, that gives you working binaries. But also security problems, because you don't control which versions of libraries you are using. Suddenly, all individual software packages must do their own security updates to keep the system secure. So the whole thing is a balance.

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

#197

Post by gdxhyrd » Sun, Jan 12, 2020, 11:14 AM UTC

cptskippy wrote: post #67

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…

So this is kind of like the DLL hell Windows had?

Kind of, yes.

Nowadays (for almost 20 years actually), Windows supports and encourages programs to deploy their dependencies in their own folder.

It is trivial to do for developers and works perfectly for users.

Some people claim security updates are a problem, but many apps do not deal with untrusted input for starters. For those that do, like browsers, servers or your office suite, you really should be using one that is supported and updated automatically.

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

#198

Post by morelisp » Sun, Jan 12, 2020, 11:14 AM UTC

hendry wrote: post #185

rascul wrote: post #163

Earlier quoted context omitted.

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

debhelper

debhelper is a library of tools for building packages. Debian users should not need to be aware debhelper exists, or even have it installed.

Maybe you meant debconf? When I was a DD it was an RC bug if your package used debconf to do "magic", i.e. using it as a registry for an application, or not properly re-seeding answers from the configuration and assuming the debconf db was the source of truth.

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

#199

Post by jcelerier » Sun, Jan 12, 2020, 11:15 AM UTC

progval wrote: post #190

microtonal wrote: post #155

Earlier quoted context omitted.

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. In principle true, yes. But it comes with a cost. Even the nixpkgs Firefox maintainers are considering to only ship Firefox ESR starting with NixOS 20.03: https://discourse.nixos.org/t/firefox-on-19-09-could-be-mark... https://github.com/NixOS/nixpkgs/pull/72126

I won't blame them. Firefox is a huge piece of software, and is updating every month . It's a bit shitty of Mozilla to expect every single distribution (most of which are run by volunteers) to package all their new dependencies and check everything works every single month.

but you can just use Mozilla's official binary packages, which are tested to work with a specific set of libraries, and I think are built with higher optimization levels (O3/pgo) than what distros conservatively do (O2) because of cargo-culting early-2000 gentoo forums (that was the case a few years ago, not 100% sure it is still the case today as I could not find easily the current release flags).

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

#200

Post by jcelerier » Sun, Jan 12, 2020, 11:19 AM UTC

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…

> 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 library separately.

Well, no. Else software on macOS and Windows obviously wouldn't work, since those ship all their libraries along.

It does not matter to the users of my software that I use libraries versions X, Y, Z, what matters is that what they want to happen happens when they click the buttons. e.g. I generally use Qt - there are plenty of bugs, but what matters is that my use cases work, and it is my onus of developer to ensure it.

And it is so much more painful to ensure that it will work correctly without any regression and with best performance for every version across e.g. Qt 5.6 to 5.14, than to just ship Qt 5.14 myself built with only the features I want with all my use cases duly tested.