Live data from Hacker News

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

undeadly.org

141–150 of 339 posts

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

#141

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…

RedHat’s “streams” model will certainly do a much better job of handling this than the other distributions do today. I hope that the need for having multiple parallel versions of a dependency coexist is incorporated into the other distros, because I’ve lost a lot of sanity this past two decades to the assumption that “one installed version should be enough for anybody” on Linux and BSD servers.

Just don't look under the curtains.

It's a good idea in general, and it would be cool to solve this problem, but modular "streams" as they currently exist have so many edge cases that I don't really suggest using them if you can avoid it.

https://lwn.net/Articles/805180/

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

#142
post #22

Is there a better alternative to Firefox? Of all the browsers it seems like the "least bad" choice (above Chromium, and other proprietary browsers) and I use it, but is there something safer, simpler, and more secure?

Brave. Blocks all trackers, fingerprinting and mining scripts by default, based on Chromium. Built-in IPFS, Webtorrent and Tor: https://brave.com/

The parent poster already ruled out Chromium.

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

#143
post #139

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…

Statically linked processes can’t share dependency pages with other, different processes. Multiple instances of the same process or multiple threads don’t have to incur that same penalty.

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

#144
post #123

Earlier quoted context omitted.

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.

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 might be true.

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

#145
post #119

Earlier quoted context omitted.

"brake" makes it sound like one would have to reinstall the whole thing. I don't think I've ever had that happen in the 10 years since I started using it for nearly everything. I've had my drive fail, but that was the drive's fault, and even in that case I also didn't need to reinstall everything. I just copied the good files and reinstalled only the packages whose files got corrupted.

That's a semantic point. If I sit down in front of my PC and can't do work, it's broken. That I can spend an hour or two fixing it rather than reinstalling is irrelevant.

I see, when you said "break", I thought you meant because of a bug or other error, but now I guess the fact that it needs configuration and learning how to do that configuration is what you're calling broken.

Certainly, Arch is definitely not a "it just works" OS. It's a tinkerer's OS. Different distros favor different types of users. By what you said, probably something like Ubuntu or Mint is better, something that "just works" with minimal learning curve for someone not familiar with Linux in general and that does not wish to invest the time in learning it. (Not saying that you're not at least familiar with it, but that's what these distros optimize for, I believe.)

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

#146
post #85

Earlier quoted context omitted.

RedHat’s “streams” model will certainly do a much better job of handling this than the other distributions do today. I hope that the need for having multiple parallel versions of a dependency coexist is incorporated into the other distros, because I’ve lost a lot of sanity this past two decades to the assumption that “one installed version should be enough for anybody” on Linux and BSD servers.

AppStream does not allow installation of multiple versions of the same app AFAIK. I believe this is what they refer to in the clumsy sentence "The one disadvantage of Application Streams from SCLs is that no two streams can be installed at the same time in to the same userspace. However, in our experience, this is not a common use case and is better served using containerization or virtualization to provide a second…

Ugh, I did not understand that. I'm so sorry. If I could edit my post to retract it, I would. The NixOS comments from others should still be valid.

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

#147
post #123

Earlier quoted context omitted.

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.

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…

But I also want to point out that "it hasn't broke in a year" is cute

Why be condescending? The above user has a good point, and your view is clearly against the majority of Arch Linux users.

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

#148
OpenBSD-current users are not only NOT affected by this, actually they just got Pledge and Unveil support in Firefox 71. https://marc.info/?l=openbsd-ports-cvs&m=157539245010077&w=2

If you don't know about Pledge and Unveil you can think of it as similar to Firejail sandboxing from Linux but on steroids. It dynamically limits the types of kernel calls and filesystem addresses a process can make use of so if a rogue thread causes a process to perform an illegal operation under the Pledge rules OpenBSD will kill the process with SIGTERM. Whats more Pledge and Unveil allow the process to execute whatever calls are needed when the program initializes itself but it will relinquish the privilege to run those calls for the remainder of the program's runtime once it no longer needs them (after init).

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

#149

Earlier quoted context omitted.

From looking at the commit history of Pale Moon, it is maintained by essentially three people. Their maintenance strategy is to freeze at an old version of Firefox, and randomly backport patches purely to try to keep somewhat up-to-date on JS or DOM features. Given the sheer size of the codebase, its inherent complexity (a JIT compiler is going to be very ripe for potential security vulnerabilities), and the utter la…

>utter lack of any sign of trying to mitigate these problems (e.g., fuzzing, or even merely attempting to identify security fixes in Firefox that may warrant backporting), And here's where you show you're making it up and haven't even looked at a Pale Moon release notes, http://www.palemoon.org/releasenotes.shtml

Would you please leave personal swipes out of your HN comments, or edit them out if they make it in? They break the site guidelines, you've done it more than once in this thread, and I'm sure you can make your substantive points without them.

https://news.ycombinator.com/newsguidelines.html

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

#150
post #64

Earlier quoted context omitted.

I agree, and I think that people are too emotionally invested in the package manager concept to back out now. I mean, for years Linux proponents have been touting it as the key advantage over software distribution on Macs/PCs.

I think the empirical evidence is against you here, though. If package managers weren't a good way to do things, brew wouldn't exist. Neither would the Mac app store, or whatever the equivalent on Windows is these days. As a Debian user, I appreciate that the stuff I install had at least gone through some minimal vetting first. And if I have to add a third party repository or download something myself to run, I'm muc…

I agree with the OP a little. Central repository models have advantages but they've always seemed like short term benefits in exchange for long term costs.

Things like the app store, in for profit scenarios, seem like ways to slip in monopoly control. Brew is an attempt to circumvent it.

I don't want to come across as suggesting they're a bad idea or don't have advantages, just that on balance I've always had a sense there had to be a better way.

Post reply on HN