Change in system requirements (AVX)

[Kris_88]

Of course, only God can give an absolute guarantee. When I talk about reliability and responsibility, I mean the "probability" of an undesirable outcome, not a guarantee of its absence.

If you require a "proper" solution to this "problem," then Pale Moon is not for you.

Fine.

[Moonchild]

There is a big difference between the official build and the community build. Also, the issue of signing executable files has already been mentioned, and therefore the reaction of antiviruses. What will happen if the community suddenly stops creating builds? That is, numerous questions arise regarding reliability and responsibility.

There isn't such a big difference between an official build and a community build as you seem to think. Also, if a community maintainer stops building, someone else can take over. This has been the case for many years on multiple secondary platforms (most notably Mac). If you want some kind of company-backed guarantee regarding reliability and accountability, you are in the wrong place.

In short, community builds are not a solution to the problem, but a temporary substitute.

And in what way is that a bad thing for a temporary situation of people on unsupported hardware, who are expected to upgrade sooner rather than later when they can? If your hardware is already 10+ years old, how much more useful life do you think you will get out of it? I definitely expect this to be a temporary situation, so a temporary substitute will be just what is needed - don't expect an all-encompassing solution to this because there is none; the demands of the evolving web are diametrically opposed to using old hardware and the only solution would be a status quo where everyone loses.
Also, we are already doing a lot more here than any major browser vendor would do: we work with community maintainers to vet, endorse and distribute certain builds to provide at least some level of "you probably want to use this" instead of just dropping it entirely and distancing ourselves in a hurry, which they would do if a decision would be made to drop support for something.

They won't understand your reasoning behind all this, nor will they care for that matter.

And why should we care when they don't?
We can't do more for them. There will simply not be an update for people on old hardware and they will remain on 33.2.1 unless they choose to switch builds. While it is technically possible and not all that hard to implement, I am not automatically going to migrate people to something they did not choose to install - that is the exact same issue I was so vehemently against when JustOff tried to migrate people off of the addons site for his extensions by way of a stealth update. It is absolutely wrong to do so. What I will do is mention that community builds are available if people choose to go that route. Forcing them in any direction is what would be the wrong thing and what would lead to drama. It is their browser; they decide how to move forward, if at all.

[athenian200]

Most FOSS stuff is provided as-is, which means there is no guarantee for anything. Fullstop.

Although, often there are many people who voluntarily help and create stuff that users demand, although not in every case and often limited. This is the case here too, even for the official builds.
Some community members already stepped out and don't provide builds/packages for certain situations. Stuff comes and stuff goes.

If you like to change that, you have to step in and do it yourself or help out with money etc.

All of the work costs time and also money.

This is a better way of saying what I was trying to say, I think.

Basically, the issue is that people are increasingly accustomed to streamlined products with a high level of trust and a polished experience, because that is what big organizations usually provide.

Since Pale Moon is maintained by a handful of unpaid volunteers who are putting in their best effort, there are limits to how much QA we can do to begin with, and things may go wrong that would be caught with browsers like Chrome or Firefox.

I feel like people expect us to step up in a way we just can't, or worse, think that we "have it together" a lot more than we actually do due to us not having had many major issues over the years, and thus think that it's a good idea to deploy our software on their corporate intranet or otherwise rely on it.

[noellarkin]

Why is this an issue? There will be community versions that provide SSE2 development. Pale Moon isn't a huge company, the developers and community have to meet in the middle more often. @Kris_88, I'm sure you agree with this, given the abundance of good advice and optimizations you've offered in this forum (Eg: just the other week you showed me how to use a centralized userChrome, thanks again for that )

[ron_1]

Speaking for myself I'll be just fine using Nuck-TH's community build of SSE2 as long as it's endorsed by the Pale Moon team.

I'm happy that Nuck-TH will be providing this, and really don't understand all the drama so far (but am not surprised). I just hope the negative tenor of this thread doesn't turn him off.

[Falna]

FWIW I've also been using Nuck-TH's AVX build for several months (thanks!) with zero problems. No doubt the SSE2 build will be equally robust.

given that Nuck-TH will provide SSE2-compatible binaries, I think that it might be better to include these builds more prominently in the main downloads page to increase visibility?

It may at least be worth increasing the prominence of the signposting.

[back2themoon]

Sigh, i already said(iirc even not once) that i will swap my AVX build with SSE2 one. So any panic is completely uncalled for.

Many thanks, Nuck-TH. Super-helpful, until I manage to replace my age-old hardware (which still works adequately for my needs).

Both Windows and Linux work on this hardware and do not require special builds. MS Edge and Firefox work on this hardware and do not require special builds. Only for Pale Moon this hardware is considered "special".

Kris_88, you are comparing Microsoft (!), Mozilla, Linux to the Pale Moon team. You surely don't expect the same amount of resources?

Please don't take this system requirements change personally. It was all explained properly in those older threads and it does make sense. As mentioned, I will have to switch to the community build from Nuck-TH for my main PC but I certainly won't complain with a 15-year old CPU. The AVX/AVX2 builds have always been reliable. No reason things will change with the SSE2 version.

[Moonchild]

I don't really see anything negative in tone here, aside from a vocal few being upset. I appreciate the community builds greatly as I've said before, and there's no real reason to make such a big deal out of this or to exaggerate things for the sake of argument as has been done.
I mean, if there are people with real concerns other than "expect faecal matter on your face, soon" threats or "nice while it lasted" dramatic exits, I'd love to hear it, but otherwise I really don't know why this topic has to exist.

Yes, I will make very clear that SSE2 builds exist and where to find them, upon release.

[back2themoon]

I feel like both sides of this discussion was comprehensively covered in a previous thread (or two).

Maybe this or similar issues have already been discussed, but I missed it on the forum. In any case, no one can demand that I read all the topics on the forum in detail. And I have the right to express my opinion, regardless of whether it will lead to any changes in the developers' policy.

You probably already know this Kris_88, but you can subscribe to the Announcements section. This way, no important announcements (like the one about planned changes, back in March) and subsequent relative threads will be missed.

[Kris_88]

Most FOSS stuff is provided as-is, which means there is no guarantee for anything. Fullstop.

So what I can download from this site in the downloads section is no more trustworthy than any other Pale Moon builds I can find on the Internet. And I, by mistake, trusted this site and specifically Moonchild builds more than any other builds.
Thank you, you opened my eyes.
But then it's really not for me.

If you like to change that, you have to step in and do it yourself or help out with money etc.
All of the work costs time and also money.

This is a better way of saying what I was trying to say, I think.

Indeed, I somehow completely forgot that everything costs time and money. And here I am, poking around in the source code, looking for solutions to problems that I personally don't need at all, sharing my knowledge...
How good that you reminded me. As you said, "Stuff comes and stuff goes."
Bye.

[suzyne]

Bye.

While many of your fixes and suggestions have not been relevant to my needs, some have, and so I have appreciated your regular efforts. It is regrettable that the Pale Moon threads occasionally end up with an adversarial tone that pushes people away. Perhaps some might say that people get too easily offended, but I am not convinced that is always the case. All the best.

[andyprough]

So what I can download from this site in the downloads section is no more trustworthy than any other Pale Moon builds I can find on the Internet. And I, by mistake, trusted this site and specifically Moonchild builds more than any other builds.
Thank you, you opened my eyes.
But then it's really not for me.

I guess I've been using "untrustworthy" AVX downloads for the past several years and didn't even know it. Amazing that I've even survived to talk about it.

[athenian200]

I guess I've been using "untrustworthy" AVX downloads for the past several years and didn't even know it. Amazing that I've even survived to talk about it.

I'm glad that at least some of you understand what the project is trying to do.

I do wish I hadn't put my foot in my mouth with Kris_88 though. I really didn't need to say something as harsh as "Pale Moon is not for you if you need this problem solved," or whatever it was I said. Sure, I wasn't vulgar or aggressive, but I guess it was still a bridge too far. I was trying to limit the degree of accountability we're seen as having for our releases and be realistic, and he was just not having it, seeming to say that it was necessary for the "buck to stop here," in a way, whether we like it or not.

Truth is, when I reflect on why I said it that way, it's because of something about the direction of modern operating systems and computers that deeply unsettles me. It feels like increasingly, just publishing software and making no guarantees is not as acceptable as it once was. There's an increased emphasis on trust and accountability, and being able to deliver some kind of minimum viable product before you are seen as having a right to produce software. I'm angry about that kind of climate and culture emerging around software, when I grew up with software you download off the Internet being more of a lottery and something you judge for yourself if you can trust.

The kind of thing he was poking at was exactly the kind of thing I was dreading having to deal with, and worse it was coming up in the context of something that's already a lot of debate and disagreement. And as a result of not choosing my words more carefully, I drove Kris_88 away.

But more seriously... what exactly do people think Moonchild does when he builds Pale Moon that someone else in the community providing builds couldn't do or shouldn't be trusted to do? Most of the work involved in engineering a Pale Moon release, to my knowledge, likely goes into selecting the best point on UXP's master branch to make a release from, making sure all the fixes we want are in place and that it seems okay in normal operation on our own machines before a release is made. That is, the selection of the git repo tags that community builds are supposed to be built against, as well as the default .mozconfig we strongly encourage the use of, represent the majority of our personal contribution to the build process. There's nothing magical about our build, other than we are very slow to change our compiler or build environment for fear of introducing unexpected behavior.

The only real guarantee you get with an official build is that it's free of malware, that it was built against the tag in our repo we say it was built against, can be updated through our normal update channels, is known to have been built properly in a known-good development environment, and is digitally signed in Pale Moon's case. With a community build, it's the person building who is making those guarantees, not us. Though all you have to do is look at the satisfied users of those builds to see that there is likely nothing wrong with them. If there were major issues, wouldn't people using them notice? For instance, when stevepusser became less active, people relying on his Debian builds didn't get updates, and people commented on that and told each other those builds were obsolete, and to stop using them. In my eyes, the system works and I don't get why this has to be a big deal.

In fact, I would even go so far as to say that without our community, our own builds would be awful. Most of the time when we notice issues, it's because people in the community pointed them out, not because we noticed them ourselves. It makes no sense for us to put a seal of approval on things beyond what the community is already doing, because even our own builds rely a lot on community input and feedback to be good in the first place. There was one time a Pale Moon release was made where a large number of changes were only vetted by the developers and had not been seen by the community. That release was a disaster, and highlighted that our project doesn't truly work as a top-down thing, but as a bottom-up thing. To put it simply, our project can only be as good as the community around it.

[andyprough]

I do wish I hadn't put my foot in my mouth with Kris_88 though. I really didn't need to say something as harsh as "Pale Moon is not for you if you need this problem solved," or whatever it was I said. Sure, I wasn't vulgar or aggressive, but I guess it was still a bridge too far. .... And as a result of not choosing my words more carefully, I drove Kris_88 away.

I disagree, I don't think your words had that effect - if you look at the original post, Kris_88 was intending to leave regardless, just wanted to vent first:

In short, it looks like the developers themselves are killing this project...

It's unfortunate that Kris_88 has to take shots at the hard working developers before leaving like that. I've been a forum member a bit longer than Kris_88 and I've written almost as many posts, and both of us have helped a few users with problems - but none of that entitles me to act as though you've "betrayed" me if you were to ever take the project in a direction I don't like. Any help I give on the forum I do so out of my own personal interest, and in no way creates any sense of entitlement or being owed anything.

[athenian200]

I disagree, I don't think your words had that effect - if you look at the original post, Kris_88 was intending to leave regardless, just wanted to vent first:

Ah, thank you for pointing that out, I didn't pick up on that at first, I assumed it was something I said specifically that was the final nail in the coffin, since he quoted me and gave single-word replies twice.

[Moonchild]

I really didn't need to say something as harsh as "Pale Moon is not for you if you need this problem solved,"

IMHO you did. The "problem" is entirely self-inflicted by demanding a status quo and searching for a problem when there is already a solution. So you were not putting your foot in your mouth there (as also pointed out already for a different reason).

But more seriously... what exactly do people think Moonchild does when he builds Pale Moon that someone else in the community providing builds couldn't do or shouldn't be trusted to do? Most of the work involved in engineering a Pale Moon release, to my knowledge, likely goes into selecting the best point on UXP's master branch to make a release from, making sure all the fixes we want are in place and that it seems okay in normal operation on our own machines before a release is made. That is, the selection of the git repo tags that community builds are supposed to be built against, as well as the default .mozconfig we strongly encourage the use of, represent the majority of our personal contribution to the build process. There's nothing magical about our build, other than we are very slow to change our compiler or build environment for fear of introducing unexpected behavior.

The only real guarantee you get with an official build is that it's free of malware, that it was built against the tag in our repo we say it was built against, can be updated through our normal update channels, is known to have been built properly in a known-good development environment, and is digitally signed in Pale Moon's case. With a community build, it's the person building who is making those guarantees, not us. Though all you have to do is look at the satisfied users of those builds to see that there is likely nothing wrong with them. If there were major issues, wouldn't people using them notice? For instance, when stevepusser became less active, people relying on his Debian builds didn't get updates, and people commented on that and told each other those builds were obsolete, and to stop using them. In my eyes, the system works and I don't get why this has to be a big deal.

In fact, I would even go so far as to say that without our community, our own builds would be awful. Most of the time when we notice issues, it's because people in the community pointed them out, not because we noticed them ourselves. It makes no sense for us to put a seal of approval on things beyond what the community is already doing, because even our own builds rely a lot on community input and feedback to be good in the first place. There was one time a Pale Moon release was made where a large number of changes were only vetted by the developers and had not been seen by the community. That release was a disaster, and highlighted that our project doesn't truly work as a top-down thing, but as a bottom-up thing. To put it simply, our project can only be as good as the community around it.

You are 200% correct here.
And thank you for putting into words in 3 short paragraphs what I've been struggling to express, myself, spread out over a good handful of posts.

Software engineering and the dynamic behind it is a gradient, as well. It depends entirely on the level of interaction between developers and users, even for big companies like Microsoft (Insider program) and Google (various coding events) that are mostly approaching things top-down, even though the bigger the company gets, the less credit is given to the people who actually take time out of their lives to help make a product better in the end (and the more they tend to be ignored because of boardroom decisions...). But in the end the dynamic is the same. e.g. Mozilla relies very much on people reporting bugs to improve Firefox; without those bug reports, I'm sure Firefox releases would be "awful" as well. Automated testing and CI only goes so far, because it can only test against things that are already known to be problems. At the same time, it does not entitle the bug reporters to make executive decisions about Firefox, no matter how valuable their input is for the product. That balance is sometimes difficult to judge and I'm not without fault in that either; but that is why this community exists.

[xuuxou333]

Is it possible to set an option to enable or disable AVX capabilities?

[jobbautista9]

It's a compile-time option. You can't "enable" or "disable" it within the browser.

[ron_1]

With a community build, it's the person building who is making those guarantees, not us.

I'm assuming this is correct since MC commented on your post and said you're 200% correct. So Moonchild doesn't give community builds a "once over" before they're released even though they have the Pale Moon name on them? I really thought he did.

[suzyne]

Unless I build a program myself, I guess that technically there can't be a guarantee?

Like, if I visit a project on GitHub and go to the Releases page, I really have to take it on trust that the zip file or whatever it is that the project owner(s) have uploaded there, is based on the corresponding source. I think I am right in saying that there is no way anyone can "prove" to me that the file I download was made from the publicly visible code?

It really is about trust and never a guarantee, for those of us who don't build from the source ourselves, and I don't think there is any way around that.

So it only comes back to the track record and previous dealings and reputation of the person(s) supplying a program file. There's nothing else.