We should be proactive and warn users of installing Tor Browser 52 on Windows machines not capable of SSE 2. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1271759 installer adaptions Mozilla made. We can check that in our Linux start script later with the advent of ESR 59 based Tor Browsers as well (see: comment:2:ticket:19316).
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
Trac: Summary: Warn users when installing Tor Browser based on ESR 52 on not SSE 2 capable machines to Warn users when installing Tor Browser based on ESR 52 on not SSE2 capable machines
Well, it seems you've decided to follow Mozilla blindly in all its decisions, good or bad. But it's a cul-de-sac.
Is there any chance that you could change your mind?
If Mozilla is doing something wrong in a hurry, and you see it, why don't you tell them about it?
If they want to make supplementary things mandatory (e.g. SSE2), when other FOSS devs are doing the opposite, why don't you mind?
If they advertise the worst proprietary things in history (SSE2, needed to be "fixed" by SSE3, and Pentium 4, yes, even Intel confirmed that) in 2017(!), why nobody asks what's going on?
So, having ESR52-based TBB cross-compiled and operational (w/o SSE2), why do you still drag those ### patches into Tor Browser, even when Mozilla requires them for Windows only?
Don't break the rules, please.
Well, it seems you've decided to follow Mozilla blindly in all its decisions, good or bad. But it's a cul-de-sac.
Is there any chance that you could change your mind?
If Mozilla is doing something wrong in a hurry, and you see it, why don't you tell them about it?
If they want to make supplementary things mandatory (e.g. SSE2), when other FOSS devs are doing the opposite, why don't you mind?
If they advertise the worst proprietary things in history (SSE2, needed to be "fixed" by SSE3, and Pentium 4, yes, even Intel confirmed that) in 2017(!), why nobody asks what's going on?
So, having ESR52-based TBB cross-compiled and operational (w/o SSE2), why do you still drag those ### patches into Tor Browser, even when Mozilla requires them for Windows only?
Don't break the rules, please.
Thanks for pointing this out. Actually, we only want to have this for Windows right now, as Linux at least won't break until ESR 59 (https://bugzilla.mozilla.org/show_bug.cgi?id=1274196). I am updating the ticket accordingly.
Trac: Summary: Warn users when installing Tor Browser based on ESR 52 on not SSE2 capable machines to Warn users when installing Tor Browser based on ESR 52 on not SSE2 capable Windows machines Description: We should be proactive and warn users of installing Tor Browser 52 on machines not capable of SSE 2. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1271759 installer adaptions Mozilla made. And I guess we can check that in our Linux start script as well (see: comment:2:ticket:19316).
to
We should be proactive and warn users of installing Tor Browser 52 on Windows machines not capable of SSE 2. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1271759 installer adaptions Mozilla made. We can check that in our Linux start script later with the advent of ESR 59 based Tor Browsers as well (see: comment:2:ticket:19316).
Well, it seems you've decided to follow Mozilla blindly in all its decisions, good or bad. But it's a cul-de-sac.
Is there any chance that you could change your mind?
If Mozilla is doing something wrong in a hurry, and you see it, why don't you tell them about it?
If they want to make supplementary things mandatory (e.g. SSE2), when other FOSS devs are doing the opposite, why don't you mind?
If they advertise the worst proprietary things in history (SSE2, needed to be "fixed" by SSE3, and Pentium 4, yes, even Intel confirmed that) in 2017(!), why nobody asks what's going on?
So, having ESR52-based TBB cross-compiled and operational (w/o SSE2), why do you still drag those ### patches into Tor Browser, even when Mozilla requires them for Windows only?
Don't break the rules, please.
Thanks for pointing this out. Actually, we only want to have this for Windows right now, as Linux at least won't break until ESR 59 (https://bugzilla.mozilla.org/show_bug.cgi?id=1274196). I am updating the ticket accordingly.
Huh, it's not a surprise actually that you prefer not to answer complex questions... Let's hope it's just because of lack of time, though...
There are a lot of MoCo decisions recently which require public discussion, but we all know that Mozilla is ignoring the community, thus forking instead of ESR59 looks more and more actual.
As for your decision to break only Windows now, it looks no good. Despite your communication with mozdevs, it seems you don't know the story about this design decision, but you may ask to tell you about it.
Shortly, Windows won't break until ESR59 too, because it was required for MSVS 2015u2 and opt-in Rust (msvs target available only).
#13018 (moved) would be a compelling reason to drop non-SSE2 support everywhere since the situation would be considerably less bad.
Only lamers from google chrome think so. Look at their discussions for fun ;) Just because of such geniuses JS is not suitable for floating point computations.
Well, it seems you've decided to follow Mozilla blindly in all its decisions, good or bad. But it's a cul-de-sac.
Is there any chance that you could change your mind?
If Mozilla is doing something wrong in a hurry, and you see it, why don't you tell them about it?
If they want to make supplementary things mandatory (e.g. SSE2), when other FOSS devs are doing the opposite, why don't you mind?
If they advertise the worst proprietary things in history (SSE2, needed to be "fixed" by SSE3, and Pentium 4, yes, even Intel confirmed that) in 2017(!), why nobody asks what's going on?
So, having ESR52-based TBB cross-compiled and operational (w/o SSE2), why do you still drag those ### patches into Tor Browser, even when Mozilla requires them for Windows only?
Don't break the rules, please.
Thanks for pointing this out. Actually, we only want to have this for Windows right now, as Linux at least won't break until ESR 59 (https://bugzilla.mozilla.org/show_bug.cgi?id=1274196). I am updating the ticket accordingly.
Huh, it's not a surprise actually that you prefer not to answer complex questions... Let's hope it's just because of lack of time, though...
There are a lot of MoCo decisions recently which require public discussion, but we all know that Mozilla is ignoring the community, thus forking instead of ESR59 looks more and more actual.
As for your decision to break only Windows now, it looks no good. Despite your communication with mozdevs, it seems you don't know the story about this design decision, but you may ask to tell you about it.
Shortly, Windows won't break until ESR59 too, because it was required for MSVS 2015u2 and opt-in Rust (msvs target available only).
Have you tried to compile it with non-MSVC? If you e.g. use mingw-w64 you'd see pretty fast that that statement is wrong: https://bugzilla.mozilla.org/show_bug.cgi?id=1331335. Thus, we need SSE2 support unless we want to specifically patch code for non-SSE2 support. In addition to that, not following Mozilla here has the great risk of getting security fixes that rely in their Windows variant on SSE2. We'd have to backport those fixes as well while being under time pressure which I think we don't want to risk.
Well, it seems you've decided to follow Mozilla blindly in all its decisions, good or bad. But it's a cul-de-sac.
Is there any chance that you could change your mind?
If Mozilla is doing something wrong in a hurry, and you see it, why don't you tell them about it?
If they want to make supplementary things mandatory (e.g. SSE2), when other FOSS devs are doing the opposite, why don't you mind?
If they advertise the worst proprietary things in history (SSE2, needed to be "fixed" by SSE3, and Pentium 4, yes, even Intel confirmed that) in 2017(!), why nobody asks what's going on?
So, having ESR52-based TBB cross-compiled and operational (w/o SSE2), why do you still drag those ### patches into Tor Browser, even when Mozilla requires them for Windows only?
Don't break the rules, please.
Thanks for pointing this out. Actually, we only want to have this for Windows right now, as Linux at least won't break until ESR 59 (https://bugzilla.mozilla.org/show_bug.cgi?id=1274196). I am updating the ticket accordingly.
Huh, it's not a surprise actually that you prefer not to answer complex questions... Let's hope it's just because of lack of time, though...
There are a lot of MoCo decisions recently which require public discussion, but we all know that Mozilla is ignoring the community, thus forking instead of ESR59 looks more and more actual.
As for your decision to break only Windows now, it looks no good. Despite your communication with mozdevs, it seems you don't know the story about this design decision, but you may ask to tell you about it.
Shortly, Windows won't break until ESR59 too, because it was required for MSVS 2015u2 and opt-in Rust (msvs target available only).
Have you tried to compile it with non-MSVC? If you e.g. use mingw-w64 you'd see pretty fast that that statement is wrong: https://bugzilla.mozilla.org/show_bug.cgi?id=1331335. Thus, we need SSE2 support unless we want to specifically patch code for non-SSE2 support. In addition to that, not following Mozilla here has the great risk of getting security fixes that rely in their Windows variant on SSE2. We'd have to backport those fixes as well while being under time pressure which I think we don't want to risk.
Actually, scratch the first argument (pointing to the SSE2 compilation bug) we can fix that by not taking Jacek's patch (which would make SSE2 mandatory in that part). The other one still holds and has been the important one anyway.
Well, it seems you've decided to follow Mozilla blindly in all its decisions, good or bad. But it's a cul-de-sac.
Is there any chance that you could change your mind?
If Mozilla is doing something wrong in a hurry, and you see it, why don't you tell them about it?
If they want to make supplementary things mandatory (e.g. SSE2), when other FOSS devs are doing the opposite, why don't you mind?
If they advertise the worst proprietary things in history (SSE2, needed to be "fixed" by SSE3, and Pentium 4, yes, even Intel confirmed that) in 2017(!), why nobody asks what's going on?
So, having ESR52-based TBB cross-compiled and operational (w/o SSE2), why do you still drag those ### patches into Tor Browser, even when Mozilla requires them for Windows only?
Don't break the rules, please.
Thanks for pointing this out. Actually, we only want to have this for Windows right now, as Linux at least won't break until ESR 59 (https://bugzilla.mozilla.org/show_bug.cgi?id=1274196). I am updating the ticket accordingly.
Huh, it's not a surprise actually that you prefer not to answer complex questions... Let's hope it's just because of lack of time, though...
There are a lot of MoCo decisions recently which require public discussion, but we all know that Mozilla is ignoring the community, thus forking instead of ESR59 looks more and more actual.
As for your decision to break only Windows now, it looks no good. Despite your communication with mozdevs, it seems you don't know the story about this design decision, but you may ask to tell you about it.
Shortly, Windows won't break until ESR59 too, because it was required for MSVS 2015u2 and opt-in Rust (msvs target available only).
Have you tried to compile it with non-MSVC? If you e.g. use mingw-w64 you'd see pretty fast that that statement is wrong: https://bugzilla.mozilla.org/show_bug.cgi?id=1331335. Thus, we need SSE2 support unless we want to specifically patch code for non-SSE2 support. In addition to that, not following Mozilla here has the great risk of getting security fixes that rely in their Windows variant on SSE2. We'd have to backport those fixes as well while being under time pressure which I think we don't want to risk.
Those were just the claims of mozdevs... so we can't trust them, you see. (But, actually, ANGLE is a google's bug.)
Unfortunately, Mozilla started to break everything before the ESR, but it doesn't mean we should join...
The risk of sec patches adding unconditional SSE2-specific code rewritten for Win only is almost zero.
I attached a patch for tbb-windows-installer.git that I think should abort installation with a message if the CPU does not support SSE2.
The line using kernel32::IsProcessorFeaturePresent to check whether the SSE2 instruction set is available was taken from the firefox installer in browser/installer/windows/nsis/installer.nsi.
On my Windows VM with SSE2 support, the installation is working as before. Unfortunately I don't have a machine without SSE2 support to check that the message is displayed and installation aborted in that case.
Hm. I wonder how we could test that. mcs/brade do you have by chance a really old computer with Windows running?
Unfortunately, the oldest one we have uses a Pentium 4 processor (which was one of the first to include SSE2). I did boot it up and run the installer from comment:14 and it installed and ran fine (the OS is Windows XP, so I do not boot it up very often).
Trac: Summary: Warn users when installing Tor Browser based on ESR 52 on not SSE2 capable Windows machines to Warn users when installing Tor Browser based on ESR 60 on not SSE2 capable machines Keywords: ff52-esr deleted, ff60-esr added
Okay, the patch does not apply anymore. I added an updated one. boklm: Could you review it and give it a last test (again)? Then let's get that upstreamed and we start using it in our alpha. It's been already too long for this patch and we should be in a much better position to apply it safely with the min requirement for Windows 7 now.
The updated patch looks good to me. I have now started a build with this patch to check that it doesn't break the installer on a machine with SSE2 available.
The updated patch looks good to me. I have now started a build with this patch to check that it doesn't break the installer on a machine with SSE2 available.
I tested on my Windows 7 VM that the win32 and win64 installer are still installing correctly.