21 ms·

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

247 points by jackhalford 7y ago

mantap 7y ago
The problem seems to be one of command line interface. In the C/C++ world, you specify the language version using a flag passed to the compiler. e.g. -std=c++98 In most other programming languages, you specify language version by installing multiple copies of the compiler/interpreter and running the corresponding version. The C/C++ way works fine if your language spec is updated once every 3 years. It does not work fine for anything much more frequent than that. Until recently C and C++ were popular enough that the other approach didn't need to be accommodated. Now it does.
- chaosite 7y ago
  I agree with the point you're making, but you're actually wrong about C/C++. It's true that C/C++ compilers usually have a flag that gates language features. However, you're still using the same libc not matter which standard you've picked. For example, there were some changes made to format strings in C99, like parsing hexadecimal numbers with scanf. If you have a C99 libc, you'll always get that behavior, even if you specified "-std=c89".
- the_why_of_y 7y ago
  It's similar in Rust, you specify the language edition with a line in Cargo.toml. https://doc.rust-lang.org/nightly/edition-guide/editions/creating-a-new-project.html https://doc.rust-lang.org/nightly/edition-guide/editions/cre...
  - umanwizard 7y ago
    Rust language editions are not similar to C++ standard versions. Every new version of the Rust compiler brings changes to the language, so the language you're actually using depends on the tuple (compiler version, edition), not just on the edition.
    - the_why_of_y 7y ago
      Rust language editions are similar but not equivalent to C++ standard versions, because compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. But you are correct to point out that old Rust editions will get new language features if they do not break existing code. https://hacks.mozilla.org/2018/12/rust-2018-is-here/ https://hacks.mozilla.org/2018/12/rust-2018-is-here/ The release process claims that the changes in new Rust releases are purely additive and backward compatible; the only exception is soundness fixes, which I'd expect affect a negligible amount of code.
      - umanwizard 7y ago
        > compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. This is not at all similar to C++ standards, and the specific case being discussed in this post demonstrates exactly why! Barring bugs in implementations, developers could develop against whatever version of the compiler they like, and as long as it supports the same language version, distro or OS maintainers wouldn’t have to update theirs, and everything would work. I worked on an open-source project that targeted C++11. It could build on basically any Linux distro you can imagine, even ones with very old versions of GCC. (it didn’t support BSD, but for unrelated reasons). This is the point the Rust project seems to miss when harping on about backwards compatibility: forwards compatibility is just as important.
        the_why_of_y 7y ago
        Okay, I see what you mean; I guess if I were a Rust programmer I'd solve that by using rustup to install a fixed Rust release for development. However the Firefox project has decided to always require the latest stable Rust release. https://news.ycombinator.com/item?id=22022834 https://news.ycombinator.com/item?id=22022834 In practice for C++ I've found it expedient to whitelist some subset of functionality from newer standards, because there's often useful features that already work in the major 3 compilers, but it'll be another 3 years until the last of the compilers adds the last obscure bits for full support of the new standard.
OrgNet 7y ago
they should make an effort, since this is Firefox...
mijoharas 7y ago
For anyone else that wasn't aware, ESR[0] stands for extended support release, so an older Firefox that still has security patches back ported (like Ubuntu LTE I guess) [0] https://support.mozilla.org/en-US/kb/switch-to-firefox-extended-support-release-esr https://support.mozilla.org/en-US/kb/switch-to-firefox-exten...
notaplumber 7y ago
> OpenBSD-current users are not affected, www/mozilla-firefox update is already committed and will be available soon on the mirrors.
floatingatoll 7y ago
(nope! wrong! deleted)
- brynet 7y ago
  No, Mozilla does not distribute Firefox binaries for OpenBSD.
  - floatingatoll 7y ago
    Thanks, sorry :(
smartmic 7y ago
> being too complicated to package (thanks to cbindgen and rust dependencies) Can anyone explain what is behind? Is it symptomatic for any programs with those dependency? Especially curious about rust because it seems to be hyped very much lately (I have almost zero rust experience and even less bias about it, just being curious)
- wbl 7y ago
  The problem is updating the rust toolchain requires testing all other ports with that dependency to make sure nothing broke.
  - jiveturkey 7y ago
    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?
    - int_19h 7y ago
      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.
      - inferiorhuman 7y ago
        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.
- nicoburns 7y ago
  I don't think it's Rust specific. It's just that distros are very C/C++ centric. The fast releae cycle of Rust might not help though.
dathinab 7y ago
So basically: - Firefox is hard to package so they won't package it (on stable). - OpenBSD-current users are not affected as firefox has already been committed. - Firefox-ESR is still maintained. > (thanks to cbindgen and rust dependencies) on the stable branch (as this would require testing all rust consumers) Can someone explain what they mean with this? What have other non firefox rust consumers to do with firefox being packaged? The best guess I have is that to package firefox they need to package cbindgen and rust. And if they package cbindgen and rust officially all packages using it would now need to be tested as now (potentially) all their dependencies have been packaged?? But this seems strange TBH. EDIT: So I guess they still will package Firefox-ESR on stable? Which will have (or maybe already has) all that dependencies, too? So it's just about having to do that packaging less often?
- floatingatoll 7y ago
  It appears that they are unwilling to update to the latest Rust-stable release due to the testing burden on the OpenBSD-stable team; which then conflicts with the Firefox Rust update policy of, as I read it, ‘latest Firefox stable will use latest Rust stable’. https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox
  - dathinab 7y ago
    Ok thanks, I guess this is somewhat understandable. Through I wonder a bit why they don't automate the tests (maybe the computation cost?). (E.g. rust automatically runs the tests of all libraries/programs published on crates.io to find regressions, through that takes a day or so to complete).
    - anjbe 7y ago
      Okay, suppose someone backporting a Rust update runs a big batch of tests and finds, say, two dozen packages with regressions. Now what? Spend two weeks investigating all the test failures? Backporting updates to these packages as well, all while users are patiently waiting for their Firefox to have its zero‐day fixed? Are the tests even correct? Were they failing before and nobody noticed? And all this to only get automated tests passing. Any regressions in behavior not tested are not noticed (or more likely, noticed by users much later, requiring further investigation at that point in time to narrow down the Rust backport as the cause). In the meantime, this packager’s work on other OpenBSD packages in -current (what most OpenBSD developers actually use day‐to‐day) completely stops. That’s some insight into the mindset of a software packager. Non‐security backports to language runtimes are a serious maintenance burden.
blackhaz 7y ago
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 - once in a while I have to say "screw it" and auto-update more than a thousand packages, praying my Python and other projects survive, just because I want a browser update or a security fix. I wonder if there are others who support this opinion that desktop Unix has very complicated future unless complex apps will begin to bundle their own libraries.
- progval 7y ago
  > 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 need a single update to apply the fix to all applications. Applications that bundle their own deps (including Docker images) will need to publish their own update with the updated version of the lib.
  - l0b0 7y ago
    > 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.
    - zrm 7y ago
      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 library separately. Doing that isn't much if any of a reduction in workload compared with getting every application to use the version the distribution ships, and is much more likely to end up with a situation where dozens of versions of the same library exist and half of them are broken in some way. The better solution is for libraries to only break compatibility between major versions. Then the packager can ship some suitably recent minor version for each major version of the library, at most two or three major versions are supported at any given time which keeps the maintenance overhead feasible, and every application can successfully link against one of those major versions or another.
newnewpdro 7y ago
Can't the required rust version be (temporarily) treated as part of firefox then, and not bother building everything else using rust with that version?
- floatingatoll 7y ago
  It seems likely the OpenBSD would consider such a patch if it were presented to them, but they might also reject it due to ideals they hold that outsiders can’t predict.
elagost 7y ago
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?
- LeoPanthera 7y ago
  GNOME has "GNOME Web", previously known as Epiphany. KDE has "Falkon". Both are quite good.
  - snazz 7y ago
    I'd still be seriously concerned about how few eyeballs they get with regards to security---Google has entire fleets of machines dedicated to fuzzing every line of Chromium code and both Chrome and Firefox use advanced sandboxing to make it so that a single exploit in the JavaScript engine wouldn't be able to result in user-level remote code execution. I'm sure they're both probably fine (if nothing else from security by obscurity) but modern browsers are complicated pieces of software that require a lot of engineering to keep secure.
    - saagarjha 7y ago
      GNOME Web is based on WebKit, while Falkon has migrated away from QtWebKit to QtWebEngine, which is Chromium based.
      - LeoPanthera 7y ago
        It's slightly ironic for KDE, as Blink is a fork of WebKit, which itself is a fork of KHTML, which was originally the KDE HTML renderer. Full circle!
  - gtk40 7y ago
    KDE also has Konqueror, which now allows you to use either KHTML or WebKit as the rendering engine. KHTML works fine on simple sites like Hacker News nowadays but chokes on newer ones often.
deleted 7y ago
[deleted]
fizixer 7y ago
This is 100% is on mozilla, given: - it's much bigger and resourceful than openbsd maintainers. - it decided to adopt this fancy update policy, and instead of making it easy/seamless, left it up to the whole open source community to play catch up. Well played.
- thenewnewguy 7y ago
  The "fancy update policy" being 'latest FF stable uses latest rust stable', which seems like a pretty reasonable policy to me.
  - cbmuser 7y ago
    I disagree. The compiler is normally something that receives major updates in every new distribution release. That's why language specs exist for. If you are maintaining a large number of machines in an enterprise environment, you're not keen on updating half of the installed system just because you update your browser, simply because the necessary testing and fixing of regressions costs a lot of time and money for no real gain for both users and administrators.
    - hashhar 7y ago
      You can have multiple Rust toolchains side by side. This is a non-issue in that case. If there's some other usecase that this breaks, I'd like to know about it and see if we can do something to improve the scenario.
      - umanwizard 7y ago
        The point is that, despite it being possible theoretically, the OpenBSD project does not want to take on the maintenance burden and additional clutter of having 40 (!) separate versions of the compiler toolchain in the ports tree with a new one landing every 6 weeks.
  - umanwizard 7y ago
    It's not reasonable at all to change the programming language you're using every 6 weeks, if you expect to be part of stable systems. Have you ever heard of any program requiring a 6-weeks-old-or-newer version of GCC or Clang, and failing to build on older ones? "Stable" is just a name -- Rust stable is anything but.
aquabeagle 7y ago
The title on this story makes it sound like OpenBSD stopped updating Firefox altogether. That's not the case, it just stopped backporting non-ESR Firefox updates to its -stable branch.
throwaway838475 7y ago
The whole modality of a single package in a single configuration at a single version is broken and dead dependency-hell of yesteryear. Still, ports and packages collections mechanically and unthinkingly continue this failed and broken modality of wasted effort. Packaging multiple versions and multiple configurations side-by-side similar to Habitat (hab) and Nix independent is the only way to go. This approach supersedes vendored dependencies because it allows garbage collection and sharing of identical dependencies rather than duplicating them. Furthermore, it allows real choices without an either-or and real real flexibility that single recipes that always attempt to track a rolling version can never possibly achieve. Also broken is maintaining multiple packages that package multiple versions of the same package with combinations of external, frequently changing platform packages like rubygems that are packaged manually. Multiple versions of the same package should share common recipe declarations as much possible and be managed more cleanly. Native extensions should be built automatically in CI/CD using polling or notifications rather than manual methods that too often lead to outdated, vulnerable dependencies and create too much pointless, repetitious busywork.
ArcVRArthur 7y ago
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 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).
floatboth 7y ago
This is why FreeBSD doesn't do "stable ports" tied to a system release version. Stable ports are a very bad idea.

247 points by jackhalford 7y ago

The problem seems to be one of command line interface. In the C/C++ world, you specify the language version using a flag passed to the compiler. e.g. -std=c++98 In most other programming languages, you specify language version by installing multiple copies of the compiler/interpreter and running the corresponding version. The C/C++ way works fine if your language spec is updated once every 3 years. It does not work fine for anything much more frequent than that. Until recently C and C++ were popular enough that the other approach didn't need to be accommodated. Now it does.

chaosite 7y ago
I agree with the point you're making, but you're actually wrong about C/C++. It's true that C/C++ compilers usually have a flag that gates language features. However, you're still using the same libc not matter which standard you've picked. For example, there were some changes made to format strings in C99, like parsing hexadecimal numbers with scanf. If you have a C99 libc, you'll always get that behavior, even if you specified "-std=c89".
the_why_of_y 7y ago
It's similar in Rust, you specify the language edition with a line in Cargo.toml. https://doc.rust-lang.org/nightly/edition-guide/editions/creating-a-new-project.html https://doc.rust-lang.org/nightly/edition-guide/editions/cre...
- umanwizard 7y ago
  Rust language editions are not similar to C++ standard versions. Every new version of the Rust compiler brings changes to the language, so the language you're actually using depends on the tuple (compiler version, edition), not just on the edition.
  - the_why_of_y 7y ago
    Rust language editions are similar but not equivalent to C++ standard versions, because compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. But you are correct to point out that old Rust editions will get new language features if they do not break existing code. https://hacks.mozilla.org/2018/12/rust-2018-is-here/ https://hacks.mozilla.org/2018/12/rust-2018-is-here/ The release process claims that the changes in new Rust releases are purely additive and backward compatible; the only exception is soundness fixes, which I'd expect affect a negligible amount of code.
    - umanwizard 7y ago
      > compiling code written for an old edition with a new edition is not guaranteed to work, due to breaking language changes like new keywords. This is not at all similar to C++ standards, and the specific case being discussed in this post demonstrates exactly why! Barring bugs in implementations, developers could develop against whatever version of the compiler they like, and as long as it supports the same language version, distro or OS maintainers wouldn’t have to update theirs, and everything would work. I worked on an open-source project that targeted C++11. It could build on basically any Linux distro you can imagine, even ones with very old versions of GCC. (it didn’t support BSD, but for unrelated reasons). This is the point the Rust project seems to miss when harping on about backwards compatibility: forwards compatibility is just as important.
      - the_why_of_y 7y ago
        Okay, I see what you mean; I guess if I were a Rust programmer I'd solve that by using rustup to install a fixed Rust release for development. However the Firefox project has decided to always require the latest stable Rust release. https://news.ycombinator.com/item?id=22022834 https://news.ycombinator.com/item?id=22022834 In practice for C++ I've found it expedient to whitelist some subset of functionality from newer standards, because there's often useful features that already work in the major 3 compilers, but it'll be another 3 years until the last of the compilers adds the last obscure bits for full support of the new standard.

OrgNet 7y ago

they should make an effort, since this is Firefox...

mijoharas 7y ago

For anyone else that wasn't aware, ESR[0] stands for extended support release, so an older Firefox that still has security patches back ported (like Ubuntu LTE I guess) [0] https://support.mozilla.org/en-US/kb/switch-to-firefox-extended-support-release-esr https://support.mozilla.org/en-US/kb/switch-to-firefox-exten...

notaplumber 7y ago

> OpenBSD-current users are not affected, www/mozilla-firefox update is already committed and will be available soon on the mirrors.

floatingatoll 7y ago

(nope! wrong! deleted)

brynet 7y ago
No, Mozilla does not distribute Firefox binaries for OpenBSD.
- floatingatoll 7y ago
  Thanks, sorry :(

smartmic 7y ago

> being too complicated to package (thanks to cbindgen and rust dependencies) Can anyone explain what is behind? Is it symptomatic for any programs with those dependency? Especially curious about rust because it seems to be hyped very much lately (I have almost zero rust experience and even less bias about it, just being curious)

wbl 7y ago
The problem is updating the rust toolchain requires testing all other ports with that dependency to make sure nothing broke.
- jiveturkey 7y ago
  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?
  - int_19h 7y ago
    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.
    - inferiorhuman 7y ago
      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.
nicoburns 7y ago
I don't think it's Rust specific. It's just that distros are very C/C++ centric. The fast releae cycle of Rust might not help though.

dathinab 7y ago

So basically: - Firefox is hard to package so they won't package it (on stable). - OpenBSD-current users are not affected as firefox has already been committed. - Firefox-ESR is still maintained. > (thanks to cbindgen and rust dependencies) on the stable branch (as this would require testing all rust consumers) Can someone explain what they mean with this? What have other non firefox rust consumers to do with firefox being packaged? The best guess I have is that to package firefox they need to package cbindgen and rust. And if they package cbindgen and rust officially all packages using it would now need to be tested as now (potentially) all their dependencies have been packaged?? But this seems strange TBH. EDIT: So I guess they still will package Firefox-ESR on stable? Which will have (or maybe already has) all that dependencies, too? So it's just about having to do that packaging less often?

floatingatoll 7y ago
It appears that they are unwilling to update to the latest Rust-stable release due to the testing burden on the OpenBSD-stable team; which then conflicts with the Firefox Rust update policy of, as I read it, ‘latest Firefox stable will use latest Rust stable’. https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox
- dathinab 7y ago
  Ok thanks, I guess this is somewhat understandable. Through I wonder a bit why they don't automate the tests (maybe the computation cost?). (E.g. rust automatically runs the tests of all libraries/programs published on crates.io to find regressions, through that takes a day or so to complete).
  - anjbe 7y ago
    Okay, suppose someone backporting a Rust update runs a big batch of tests and finds, say, two dozen packages with regressions. Now what? Spend two weeks investigating all the test failures? Backporting updates to these packages as well, all while users are patiently waiting for their Firefox to have its zero‐day fixed? Are the tests even correct? Were they failing before and nobody noticed? And all this to only get automated tests passing. Any regressions in behavior not tested are not noticed (or more likely, noticed by users much later, requiring further investigation at that point in time to narrow down the Rust backport as the cause). In the meantime, this packager’s work on other OpenBSD packages in -current (what most OpenBSD developers actually use day‐to‐day) completely stops. That’s some insight into the mindset of a software packager. Non‐security backports to language runtimes are a serious maintenance burden.

blackhaz 7y ago

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 - once in a while I have to say "screw it" and auto-update more than a thousand packages, praying my Python and other projects survive, just because I want a browser update or a security fix. I wonder if there are others who support this opinion that desktop Unix has very complicated future unless complex apps will begin to bundle their own libraries.

progval 7y ago
> 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 need a single update to apply the fix to all applications. Applications that bundle their own deps (including Docker images) will need to publish their own update with the updated version of the lib.
- l0b0 7y ago
  > 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.
  - zrm 7y ago
    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 library separately. Doing that isn't much if any of a reduction in workload compared with getting every application to use the version the distribution ships, and is much more likely to end up with a situation where dozens of versions of the same library exist and half of them are broken in some way. The better solution is for libraries to only break compatibility between major versions. Then the packager can ship some suitably recent minor version for each major version of the library, at most two or three major versions are supported at any given time which keeps the maintenance overhead feasible, and every application can successfully link against one of those major versions or another.

newnewpdro 7y ago

Can't the required rust version be (temporarily) treated as part of firefox then, and not bother building everything else using rust with that version?

floatingatoll 7y ago
It seems likely the OpenBSD would consider such a patch if it were presented to them, but they might also reject it due to ideals they hold that outsiders can’t predict.

elagost 7y ago

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?

LeoPanthera 7y ago
GNOME has "GNOME Web", previously known as Epiphany. KDE has "Falkon". Both are quite good.
- snazz 7y ago
  I'd still be seriously concerned about how few eyeballs they get with regards to security---Google has entire fleets of machines dedicated to fuzzing every line of Chromium code and both Chrome and Firefox use advanced sandboxing to make it so that a single exploit in the JavaScript engine wouldn't be able to result in user-level remote code execution. I'm sure they're both probably fine (if nothing else from security by obscurity) but modern browsers are complicated pieces of software that require a lot of engineering to keep secure.
  - saagarjha 7y ago
    GNOME Web is based on WebKit, while Falkon has migrated away from QtWebKit to QtWebEngine, which is Chromium based.
    - LeoPanthera 7y ago
      It's slightly ironic for KDE, as Blink is a fork of WebKit, which itself is a fork of KHTML, which was originally the KDE HTML renderer. Full circle!
- gtk40 7y ago
  KDE also has Konqueror, which now allows you to use either KHTML or WebKit as the rendering engine. KHTML works fine on simple sites like Hacker News nowadays but chokes on newer ones often.

deleted 7y ago

[deleted]

fizixer 7y ago

This is 100% is on mozilla, given: - it's much bigger and resourceful than openbsd maintainers. - it decided to adopt this fancy update policy, and instead of making it easy/seamless, left it up to the whole open source community to play catch up. Well played.

thenewnewguy 7y ago
The "fancy update policy" being 'latest FF stable uses latest rust stable', which seems like a pretty reasonable policy to me.
- cbmuser 7y ago
  I disagree. The compiler is normally something that receives major updates in every new distribution release. That's why language specs exist for. If you are maintaining a large number of machines in an enterprise environment, you're not keen on updating half of the installed system just because you update your browser, simply because the necessary testing and fixing of regressions costs a lot of time and money for no real gain for both users and administrators.
  - hashhar 7y ago
    You can have multiple Rust toolchains side by side. This is a non-issue in that case. If there's some other usecase that this breaks, I'd like to know about it and see if we can do something to improve the scenario.
    - umanwizard 7y ago
      The point is that, despite it being possible theoretically, the OpenBSD project does not want to take on the maintenance burden and additional clutter of having 40 (!) separate versions of the compiler toolchain in the ports tree with a new one landing every 6 weeks.
- umanwizard 7y ago
  It's not reasonable at all to change the programming language you're using every 6 weeks, if you expect to be part of stable systems. Have you ever heard of any program requiring a 6-weeks-old-or-newer version of GCC or Clang, and failing to build on older ones? "Stable" is just a name -- Rust stable is anything but.

aquabeagle 7y ago

The title on this story makes it sound like OpenBSD stopped updating Firefox altogether. That's not the case, it just stopped backporting non-ESR Firefox updates to its -stable branch.

throwaway838475 7y ago

The whole modality of a single package in a single configuration at a single version is broken and dead dependency-hell of yesteryear. Still, ports and packages collections mechanically and unthinkingly continue this failed and broken modality of wasted effort. Packaging multiple versions and multiple configurations side-by-side similar to Habitat (hab) and Nix independent is the only way to go. This approach supersedes vendored dependencies because it allows garbage collection and sharing of identical dependencies rather than duplicating them. Furthermore, it allows real choices without an either-or and real real flexibility that single recipes that always attempt to track a rolling version can never possibly achieve. Also broken is maintaining multiple packages that package multiple versions of the same package with combinations of external, frequently changing platform packages like rubygems that are packaged manually. Multiple versions of the same package should share common recipe declarations as much possible and be managed more cleanly. Native extensions should be built automatically in CI/CD using polling or notifications rather than manual methods that too often lead to outdated, vulnerable dependencies and create too much pointless, repetitious busywork.

ArcVRArthur 7y ago

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 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).

floatboth 7y ago

This is why FreeBSD doesn't do "stable ports" tied to a system release version. Stable ports are a very bad idea.