openbsd support

[swish99]

Hi Palemoon and Basilisk devs / users

Would be great to get openbsd support too for this project. I see freebsd support is complete. OpenBSD support too would be great, I'm sure many users in openbsd would like to have this browser available.

Any plans to get it built there?

[Moonchild]

Due to OpenBSD's diametrically opposed policy (to our approach) of insisting no in-tree libraries are used in programs, as well as the rather uncooperative attitude of OpenBSD devs resulting in considerable friction in the past, we currently have neither the incentive nor desire to make OpenBSD Pale Moon builds a thing. Sorry to disappoint.

[swish99]

OK, thanks for the input. I'm not familiar on the in-tree library issue. It's unfortunate about the attitude thing though.

Hopefully there is some other openbsd devs around that may be more willing to help this along some day.

[athenian200]

That's probably the only OS that we won't be able to support, unfortunately.

OpenBSD has a totally different development philosophy from Pale Moon, and the two are just not compatible. OpenBSD appears to be a totally locked-down system where no applications are allowed to use internal libraries. Specifically, they seem to frown on projects relying on their own vendored libraries rather than targeting compatibility with "stock" versions of those libraries that can be updated at the convenience of the OS maintainers. The burden is placed on applications such that everything has to be kept compatible with whatever library versions happen to be available on the underlying OS, and that's just not something that works for us. So there's an impasse... they need tight control over which versions of libraries run on their OS because those are the versions they've tested, and they effectively exclude versions of things we rely on because they haven't tested or vetted them. We might wind up supporting a fork of OpenBSD called HyperbolaBSD when that's done, but OpenBSD itself is basically off the table.

There is actually a port to FreeBSD, and I maintain one to illumos and Solaris intermittently (that is, I tend to get sidetracked when it comes to updating it). There isn't one to NetBSD, but in theory I think NetBSD could run the illumos binaries.

[Moonchild]

See also viewtopic.php?f=5&t=23706 for an explanation why system libraries don't work for us (and for any large and complex application like Pale Moon, for that matter)

[andyprough]

OK, thanks for the input. I'm not familiar on the in-tree library issue. It's unfortunate about the attitude thing though.

Hopefully there is some other openbsd devs around that may be more willing to help this along some day.

Can't openbsd users just build Pale Moon themselves? I've built it on all kinds of different GNU/Linux setups and it clearly builds on FreeBSD. It doesn't take terribly long to build.

[Moonchild]

Can't openbsd users just build Pale Moon themselves?

Potentially they can, for their own personal use. But it won't be following OpenBSDs library paradigm in that case. I don't know if it builds or not; possibly it will with how we restored FreeBSD as a target but it may also need extensive patching.

[swish99]

Thanks for the additional detail. Does palemoon differ to chromium and the old (and new) firefox in-tree libraries?

I mean, there's obviously a lot of large apps in openbsd ports, that seem to not have the same issue.

[Moonchild]

Thanks for the additional detail. Does palemoon differ to chromium and the old (and new) firefox in-tree libraries?

Yes

[Moonchild]

that seem to not have the same issue.

Oh I'm pretty sure they make exceptions to their policy for Firefox and Chromium because they are big well-funded projects.

[CrimsonAkiha]

See also viewtopic.php?f=5&t=23706 for an explanation why system libraries don't work for us (and for any large and complex application like Pale Moon, for that matter)

Oh I'm pretty sure they make exceptions to their policy for Firefox and Chromium because they are big well-funded projects.

I'm not sure, but it doesn't seem to look like it. According to the OpenBSD port's Makefile, Chromium is configured to use what seems to be entirely all-system libraries without issue:
https://raw.githubusercontent.com/openb ... m/Makefile

And the various Firefox-related ports seem to include logic from a central "mozilla.port.mk" file, which also seems to force the use of some system libraries (with "--with-system-X" I presume) with some exceptions for a few libraries that are modified too much in-tree or compiled with Firefox-specific options:
https://raw.githubusercontent.com/openb ... la.port.mk

I'm no expert, but Pale Moon seems to be the only outlier, even though you'd expect the former two examples to be a lot more complex/dangerous to use system libraries with (assuming the same reasons Pale Moon doesn't use them)... Maybe they're doing something special with the first two that I haven't noticed? (Could it be possible to do the same thing to Pale Moon?) The most I could find about the technical issues was a large conversation that seemed to take place on GitHub here: https://github.com/jasperla/openbsd-wip/issues/86
Maybe someone else can make more sense of that kind of thing ¯\_ (ツ)_/¯

[athenian200]

I'm no expert, but Pale Moon seems to be the only outlier, even though you'd expect the former two examples to be a lot more complex/dangerous to use system libraries with (assuming the same reasons Pale Moon doesn't use them)... Maybe they're doing something special with the first two that I haven't noticed? (Could it be possible to do the same thing to Pale Moon?)

Well, actually, notice that the smaller the project, the more dependent on specific library versions. Chromium has the ability to more or less keep itself in a state where it can be tested against the latest versions of most libraries because they have the resources to throw at something like that. Firefox has a few in-tree tree libraries that are too modified for using system libraries, but still has enough resources to support a ton of different library versions. Meanwhile, Pale Moon is the smallest project and has even greater dependency on in-tree libraries than Firefox does.

So a big part of it is just not having the resources to support every possible configuration. Pale Moon isn't bigger than Firefox or Chromium in terms of codebase size, sure, but it's a huge codebase maintained by a very small team.

The most I could find about the technical issues was a large conversation that seemed to take place on GitHub here: https://github.com/jasperla/openbsd-wip/issues/86
Maybe someone else can make more sense of that kind of thing ¯\_ (ツ)_/¯

I was afraid someone might link that issue... :/

I cringe whenever I see it, because it's usually followed by "and this is why we won't allow Pale Moon in our repos" from various other repo maintainers...

[CrimsonAkiha]

Well, actually, notice that the smaller the project, the more dependent on specific library versions. Chromium has the ability to more or less keep itself in a state where it can be tested against the latest versions of most libraries because they have the resources to throw at something like that.

It was my impression that the OpenBSD community was (and is, for the other two ports linked) maintaining patches to support their system libraries themselves, it doesn't seem to make much sense to place that burden upon Pale Moon upstream (although I'm sure it would have been a nice-to-have). It seems like the major reason they would go to all of that effort to use system libraries is because the system libraries have already been ported to OpenBSD, so the effort involved for them to make Pale Moon work with those libraries is less effort than it would be to port all of Pale Moon's in-tree libraries to OpenBSD, which would require both duplicating patches and ensuring someone maintains all of them in parallel to the patches already made to the system libraries. I can only guess that having to maintain two sets of patches for the same library would mean that the Pale Moon-specific ones would inevitably fall behind or face the same lack-of-manpower issues you've described with Pale Moon itself, which could end up making Pale Moon more broken if in-tree libraries were used, rather than less. If Chromium and Mozilla Firefox were switched to use in-tree libraries as well, that would mean having to maintain patches to port four different versions of the same libraries to OpenBSD.

I did read through the issue eventually, and I don't really know what to think of it. Given everything I said above, and the fact that it seemed like OpenBSD's ports maintainers were effectively willing to do your work for you and trying to cooperate in good faith (one of them even posted a very friendly looking message in this very forum prior to the events of that issue), it seems like they were entirely compliant with point 8b of the MPL (which seems to be more in the "spirit" of primarily preventing changes to "browser preferences and the supplied profile defaults" anyway, not which version of, say, bzip2 is used under-the-hood), which is probably why Mozilla hasn't sent them any legal threats even though they've done exactly the same thing with Firefox (There doesn't seem to be a separate agreement between them explicitly stating they can do this). I could be wrong, but if I wanted to port Pale Moon to NetBSD (something I have been thinking of trying), this is exactly how I would do it in order to reduce effort, bugs, and prolonged maintenance -- FreeBSD seems to be the only one that can get away with using in-tree libraries without any patches, maybe because FreeBSD seems to go out of its way to be compatible with GNU/Linux software, and many upstream projects already go out of their way to support FreeBSD as it is the largest one.

It doesn't really feel fair to me to compare the requirements for FreeBSD & GNU/Linux with NetBSD or OpenBSD. They are very different operating systems with much more extensive needs and smaller teams, and I can imagine a lot of the people in that GitHub issue must have seen Tobin's posts there as being similar to the technical impreciseness of threats from lawyers working for big corporations, inaccurately referring to OpenBSD just as "BSD"(?) and misunderstanding the underlying details & mindset behind the project being threatened, accusing them of expecting everything to be "near-public domain" when they clearly don't (and would have had to go to court many times before if they really did), etc. I have hope that things may change for the better now that he's gone, as issues like this don't just dissuade package/port maintainers, but also dissuade the experienced people who use those systems from contributing.

[Moonchild]

It seems like the major reason they would go to all of that effort to use system libraries is because the system libraries have already been ported to OpenBSD, so the effort involved for them to make Pale Moon work with those libraries is less effort than it would be to port all of Pale Moon's in-tree libraries to OpenBSD

One major problem with that is that it would no longer be Pale Moon. It would be a patched browser and platform building on a different set of libraries. it would effectively be a fork. That's fine but then you should not brand it as Pale Moon -- and that's where that whole discussion that got out of hand was rooted in. Don't change the recipe of something and then expect you can label it as the original.

As an aside: I don't see OpenBSD doing all the compatibility work themselves for every application they want to have, indefinitely. As an OS publisher that would just not be feasible. I also never got the impression that anyone but us would be responsible for our code.

Either way, that issue and discussion is old and water under the bridge, i don't want to rehash it yet again as it's pointless -- on top one of the main reasons it escalated into people being rather disingenuous and unrealistic was Tobin, and he's no longer involved.

[athenian200]

It was my impression that the OpenBSD community was (and is, for the other two ports linked) maintaining patches to support their system libraries themselves, it doesn't seem to make much sense to place that burden upon Pale Moon upstream (although I'm sure it would have been a nice-to-have). It seems like the major reason they would go to all of that effort to use system libraries is because the system libraries have already been ported to OpenBSD, so the effort involved for them to make Pale Moon work with those libraries is less effort than it would be to port all of Pale Moon's in-tree libraries to OpenBSD, which would require both duplicating patches and ensuring someone maintains all of them in parallel to the patches already made to the system libraries. I can only guess that having to maintain two sets of patches for the same library would mean that the Pale Moon-specific ones would inevitably fall behind or face the same lack-of-manpower issues you've described with Pale Moon itself, which could end up making Pale Moon more broken if in-tree libraries were used, rather than less. If Chromium and Mozilla Firefox were switched to use in-tree libraries as well, that would mean having to maintain patches to port four different versions of the same libraries to OpenBSD.

Well, you see, that's kind of the main problem. The same updates to their internal libraries that make Firefox and Chromium work wouldn't be the ones Pale Moon needs. They would effectively be asking us to "keep up" with those other browsers in terms of library support. And to be fair, Pale Moon's internal libraries are pretty portable... I didn't have much issue following the guidelines and getting Pale Moon's in-tree libraries to compile on Solaris and OpenIndiana, which I think is more of an apples-to-apples comparison than FreeBSD which, I will concede, is the most popular Linux alternative.

The thing you describe sounds like a reason why OpenBSD just isn't a good target for Pale Moon... they have their own way of doing things that just isn't very compatible with how we do Unix support on Linux, Solaris, and FreeBSD. I'm sure being a smaller OS has a lot to do with that, now that you mention it. Not to say they don't have their reasons, but it does create certain issues for us. They did in fact do the work of getting it to compile and run, but the way they did it just was... a bit hacky and not something we were prepared to trust to work reliably, you know what I mean? Ultimately, I feel like a lot of the confusion probably came from a branding exception that was in place for Linux, which was never really intended to apply to other operating systems. Building for an OS that has no history of support is something that could very well change the configuration enough that permission to use the branding would have to be obtained by request anyway. In general, I think we would probably want someone porting Pale Moon to another OS to work more closely with us to ensure that it's up to the expected level of quality before they put our name on it. That's a little different from how other projects in the open source community tend to do things nowadays, I know, but I don't think it's totally unreasonable or unheard of.

It doesn't really feel fair to me to compare the requirements for FreeBSD & GNU/Linux with NetBSD or OpenBSD. They are very different operating systems with much more extensive needs and smaller teams, and I can imagine a lot of the people in that GitHub issue must have seen Tobin's posts there as being similar to the technical impreciseness of threats from lawyers working for big corporations, inaccurately referring to OpenBSD just as "BSD"(?) and misunderstanding the underlying details & mindset behind the project being threatened, accusing them of expecting everything to be "near-public domain" when they clearly don't (and would have had to go to court many times before if they really did), etc. I have hope that things may change for the better now that he's gone, as issues like this don't just dissuade package/port maintainers, but also dissuade the experienced people who use those systems from contributing.

Ah, I can see why that part bothered you. I had a few discussions with... that guy in IRC a long time ago about how Linux became popular partly because BSD was facing legal issues from AT&T for so long, and you can probably guess why he jumped to conclusions in that regard. It's not uncommon for people, especially older people, to think of Linux as more trustworthy because we know for sure that none of it was based on Research Unix.

Still, hopefully you can appreciate why OpenBSD is kind of a sore spot with us. People who are from the OpenBSD project or who sympathize with them have caused a lot of problems for Pale Moon over the years, and that kind of thing doesn't exactly make us want to support them. Granted, what you're saying is the disagreements we had with them probably didn't need to escalate to the point of no return, and I would agree... I can imagine that if MC had been the one to notice the license issues first (instead of that... guy you mentioned), it might have ended with a lot less drama. But it happened the way it happened, and now we'll never know what could have been.

[BenFenner]

OpenBSD just isn't a good target for Pale Moon...

But it is a perfect target for New Moon, and if someone gets the motivation again to work on that, it should go swimmingly.

(Readers should know I'm taking athenian200's quote above out of context to discuss something unrelated to its intended meaning.)

[Moonchild]

Off-topic:

(Readers should know I'm taking athenian200's quote above out of context to discuss something unrelated.)

Then use offtopic forum tags, please.

[BenFenner]

Off-topic:
My post is related to this thread, and is on topic. Hence the lack of OT tags. My post is not related to the exact sentiment the original quote was discussing and I didn't want anyone to think I took their words out of context for some deceitful purpose. I've edited the disclaimer to be more clear.