Mozilla Stops Firefox 64-bit Development

What the hell is WaterFox, and why haven't I heard of them!?
 
I thought with Windows 7, Microsoft managed to get out a proper 64 bit OS, years after. Looks like it's still a failure.


LOL what does Microsoft's Windows 7 and x64 have to do with Mozilla sucking at developing software for a hardware platform? They refuse to put the effort into it because they know there isn't going to be much they get out of it. It's as simple as that. Excuses are just excuses no matter how you flip them. They don't see the motive in driving the development so they wont bother until it becomes reasonable to do so.
 
Firefox for Linux always was, and still will be, 64 bit. Actually, it's also working on ARM, PowerPC, Itanium...
I thought with Windows 7, Microsoft managed to get out a proper 64 bit OS, years after. Looks like it's still a failure.

I think it has nothing to do with the OS, their problem is plugin developers don't want to produce 64 bit ports of their.. well plugins,I bet what they are saying is they are having a hard time making 32 bit plugins run reliably on the 64bit client which they admitted to be having a hard time implementing.
 
waterfox smauterfox. Now that pontiac has gone belly up, can't we go back to calling the browser firebird?
 
I think it has nothing to do with the OS, their problem is plugin developers don't want to produce 64 bit ports of their.. well plugins,I bet what they are saying is they are having a hard time making 32 bit plugins run reliably on the 64bit client which they admitted to be having a hard time implementing.

Wouldn't it be simpler for browser developers like Firefox switch to and allow the plugins/extensions be coded as Javascript/DHTML (or even HTML5) code?

That way plugins would be universal regardless of OS and browser build (32-bit or 64-bit), and operating system-- mobile or desktop..
 
Why does a web browser need to be 64bit apart f4om epeen?

Because certain attacks which are popular on 32 bit software, are just impractical on 64 bit software. A Heap Spray on 64 bit is way harder to spray in the right area, when the area is the size of a city, instead of the size of a parking lot.


The above post is my personal views and opinions, not that of my employer.
This posting is provided "AS IS" with no warranties, and confers no rights.
 
at the moment Firefox hasn't let me down , is there a need for 64bit,well of course moving forward is the way . . but is Microsoft hasn't done it proper or neither adobe . . why should we worry at the moment it hasn't hurt me the best of my browser days
 
64-Bit Firefox works fine on a real 64-bit operating system.

The problem is that Windows uses a non-standard data model (LLP64) which breaks things and causes compatibility/porting issues. That's why you need forks of Firefox like Waterfox. I've been using 64-bit Firefox on GNU/Linux for almost ten years (since before it was called Firefox) and it has always been stable.
 
There is no standard data model.

Yes there is. LP64.

Operating systems that use LP64 :
GNU/Linux
Mac OS X
FreeBSD
OpenBSD
NetBSD
DragonflyBSD
Solaris
HP/UX
AIX
z/OS

Operating systems that use LLP64 :
Windows

LP64 was in use long before there even was x86-64 or IA64 and thus 64-bit Windows. In typical Microsoft fashion, they came in long after LP64 was established as a defacto standard and went in a completely opposite and incompatible route. The end result is that 64-bit Windows isn't really 64-bit at all; it is essentially a 32-bit data model with 64-bit addresses.

The proof is in the pudding. We have a stable 64-bit Chrome. You do not. We have a stable official 64-bit Firefox. You do not. We had a 64-bit Flash plug-in years before Windows did. Don't believe me? Read for yourself : http://news.ycombinator.com/item?id=4817838

I'm one of the leads for the 64-bit Chrome on Windows work, and it is very much underway. I can't commit to a timeline, but we are attacking this pretty aggressively right now because it's a nice win on both the security and performance fronts. I'm a bit shocked to see Firefox moving in the opposite direction.

--Snip--

Well, OS X is easier because much of the work has already been done for Linux 64, as both are posix-ish lp64 architectures. Whereas Windows is llp64 plus its own APIs and ABIs, which means much more unique porting issues.

Beyond that, there's all the infrastructure you need to stand up for development, continuous integration, QA, metrics, and shipping to hundreds of millions of users. The logistics of that part are almost the same as supporting an entirely new OS, and in the case of Windows it's one with an insanely large and diverse population. So yeah, that parts actually a lot worse just because of the sheer numbers.
 
64-Bit Firefox works fine on a real 64-bit operating system.

The problem is that Windows uses a non-standard data model (LLP64) which breaks things and causes compatibility/porting issues. That's why you need forks of Firefox like Waterfox. I've been using 64-bit Firefox on GNU/Linux for almost ten years (since before it was called Firefox) and it has always been stable.
I'm not going to pretend to know as much as you about this because I don't, but according to the Wikipedia article on it, there are 2 more layers of "more 64 bit" than LP64.

Link

So if you're trying to argue that Unix Os's are "true" 64 bit, I'm not so sure about that.
 
I use Palemoon 64-bit, it works fine. No issues. Works better than Palemoon 32-bit.
 
I'm not going to pretend to know as much as you about this because I don't, but according to the Wikipedia article on it, there are 2 more layers of "more 64 bit" than LP64.

Link

So if you're trying to argue that Unix Os's are "true" 64 bit, I'm not so sure about that.

Well the goal is to have at least one commonly used data type to be 64-bit. LP64 works better because there is a natural progression from 16-bit (short) to 32-bit (int) to 64-bit (long). Long long is an obscure type that hitherto was hardly ever used (and had only existed since C99 anyways).
 
Well the goal is to have at least one commonly used data type to be 64-bit. LP64 works better because there is a natural progression from 16-bit (short) to 32-bit (int) to 64-bit (long). Long long is an obscure type that hitherto was hardly ever used (and had only existed since C99 anyways).
The goal of 64-bit is to have 64-bit addressing and data types. If you want a 64-bit integer, you use int64_t, uint64_t or whatever guaranteed 64-bit integer data type is supported in your language implementation, if any. If you don't, you use something else.

Suffice it to say that relying on any integer type that is never guaranteed to be X width to be X width is an absolutely disgusting practice. You can blame it on Microsoft, or you can blame it on the guys doing shoddy design in their own applications.
 
Yes there is. LP64.

Operating systems that use LP64 :
GNU/Linux
Mac OS X
FreeBSD
OpenBSD
NetBSD
DragonflyBSD
Solaris
HP/UX
AIX
z/OS

Operating systems that use LLP64 :
Windows

LP64 was in use long before there even was x86-64 or IA64 and thus 64-bit Windows. In typical Microsoft fashion, they came in long after LP64 was established as a defacto standard and went in a completely opposite and incompatible route. The end result is that 64-bit Windows isn't really 64-bit at all; it is essentially a 32-bit data model with 64-bit addresses.

The proof is in the pudding. We have a stable 64-bit Chrome. You do not. We have a stable official 64-bit Firefox. You do not. We had a 64-bit Flash plug-in years before Windows did. Don't believe me? Read for yourself : http://news.ycombinator.com/item?id=4817838

If the proof is in the pudding, why has Windows had a stable IE x64 for years now? Also waterfox and palemoon seem to manage. I've seen the most trivial of applications, and the most complex, have x64 on Windows, so saying that FF and Chrome do not, seems to say more about chrome and FF developers, then anything else.
 
This article is BS. They do not stop 64-bit development. They merely considering to stop nightly builds.

According to the article (perhaps it's been updated since your post), the guy in charge gave the order to STOP nightly and hourly builds. So they're past considering.

And since they've stop all development, and there has yet to be a "final/stable" build, it looks like this is the kibosh on it. So, there will be no 64-bit FF64 for the foreseeable future. This isn't like it's a huge deal. IE64 has issues. Chrome is still 32 bit. Safari is dead on Windows. FF at 32-bit will be fine for those who still want to use it.
 
I use FF because I like the plug-ins: NoScript, Roboform, Penango. I use Windows because I like the programs, like games and utility software for backups, network tools, etc. and these are common to many others that I work with so I am familiar with them.

I started using WaterFox, then Comodo's IceDragon when Flash stopped allowing my volume buttons, as well as it's constant hanging or completely crashing all of my tabs at once. Both of these alternative browsers resolve these issues for me. As a side benefit, these browsers only actually download and render a tab when it is selected, so re-launching the browser isn't so time consuming. I can go straight to the tab I want without waiting on the other 20 to load.

I usually use IceDragon now. Although, it is still 32bit, performance is better, and it is more secure and more stable. Roboform and Penango(encrypted gmail support) do not have 64 bit support, but they work in IceDragon.

I discussed these browsers with the Penango Developer, and he said with constant FF updates it takes too much of his time, and there are not enough users to justify porting to 64bit. When I am forced to use FF, I still only run the 10esr version. I hate the constant upgrade cycle. It takes too much time to keep up with constant changes. The browser is a tool, it is not an end-product like a game. I do not want to spend my time figuring out updates in the new version of the browser, I just want to get to my websites.

I prefer to move to a 64 bit browser, but what I really want it a faster, more secure, and more reliable browser. I feel that 64 bit addresses these, but so does IceDragon. At least for now.
 
If the proof is in the pudding, why has Windows had a stable IE x64 for years now? Also waterfox and palemoon seem to manage. I've seen the most trivial of applications, and the most complex, have x64 on Windows, so saying that FF and Chrome do not, seems to say more about chrome and FF developers, then anything else.

Have they fixed 64-bit Internet Explorer so that you don't get a giant performance drop compared to 32-bit? Regardless, Internet Explorer doesn't have to worry about cross-platform compatibility. Firefox and Chrome do.

'then' should be 'than'.

Also here's a link about why MS chose LLP64: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/31/363790.aspx

And x64 data is allowed contrary to what your post claims, damicatz. That claim makes no sense.

What is this x64 data you speak of?

Only an idiot would use a struct like that to handle a file format in which the length of the fields has to remain fixed. There is a reason that we have things like int32_t.

The way I read that post is that they are basically catering to incompetent programmers even if it means making life harder for competent programmers. This is the whole "let's use the least significant bit of the pointer to store data even though it breaks address spaces >2gb" fiasco all over again.
 
Have they fixed 64-bit Internet Explorer so that you don't get a giant performance drop compared to 32-bit? Regardless, Internet Explorer doesn't have to worry about cross-platform compatibility. Firefox and Chrome do.

Yes, IE10 x64 is as fast as the 32-bit version, IE9 x64 performance slow down was due to the fact that they didn't make a x64 JavaScript JIT compiler, not because of issues with x64 data formats.

What is this x64 data you speak of?

Only an idiot would use a struct like that to handle a file format in which the length of the fields has to remain fixed. There is a reason that we have things like int32_t.

The way I read that post is that they are basically catering to incompetent programmers even if it means making life harder for competent programmers. This is the whole "let's use the least significant bit of the pointer to store data even though it breaks address spaces >2gb" fiasco all over again.

What I'm reading is that there are millions of apps that do so though, and Windows benefits from compatibility. It's seems both cases have upsides and downsides, but I can understand MS decision. What I can't understand, is how IE has a x64 version and FF and chrome do not, and this is because Windows has a problem in x64. Reminds me of the fact that FF said they were going to use sandboxing on Windows, but never got around to it, 6 years now after IE implemented it. Meanwhile people tell me OSS is greased lightening when it comes to implementing security features, and MS is a slug in a coma here, etc. Now if IE didn't have x64 and sandboxing, I might agree that Windows has a problem, but at this point I can't see this as anything but a FF and chrome failing (and actually, apparently, Chrome has moved to make a x64 build, and I suspect it will be done for years before FF makes a similar move, again leading me to question the explanation you and FF are giving for any of this.)
 
Thunderbird has the same problem of course. The 64-bit windows version is slower and less stable. Also, Enigmail extension doesn't work on 64-bit because there's no 64-bit Gpg4win (or a wrapper to wrap the 32-bit one), so no reason to make a 64-bit version of the extension. (The extension isn't all js etc.)

Given that, Mozilla asked users a while ago to stop testing 64-bit builds of Thunderbird.

I'm a Opera 64-bit Win7 user though (for both the browser and the built-in mail client). I like how Opera x64 supports 32-bit plug-ins via a plug-in wrapper and you can chose whether to use the 32-bit or 64-bit one.

Both 64-bit and 32-bit plug-ins are loaded in their own process in Opera x64. In 32-bit Opera, plug-ins (32-bit only) are loaded in the browse process though.

Opera x64 has been working out really well for me. But, I never had problems with Firefox and Thunderbird 64-bit builds except for the GnuPG problem.
 
Several people read your post. Your abusiveness is what they'll remember.

It's just a forum. If people take the stuff on their computers too seriously, then the computer will become a part of Soviet Russia and operate you.
 
Only an idiot would use a struct like that to handle a file format in which the length of the fields has to remain fixed. There is a reason that we have things like int32_t.
Which is exactly the kind of behavior Mozilla is engaging in, and the kind of behavior you seem to consider acceptable for them. After all, it's not Mozilla's bad design that's the problem. It's Microsoft's, right?
 
Thanks to this thread I have been running the wat er fox two days now

no problems yet, runs fast, runs ghostery

thanks guys
 
Well the goal is to have at least one commonly used data type to be 64-bit. LP64 works better because there is a natural progression from 16-bit (short) to 32-bit (int) to 64-bit (long). Long long is an obscure type that hitherto was hardly ever used (and had only existed since C99 anyways).

This is not what the C language spec says, and bad programmers - like the ones at Mozilla - assume that is the case and write code assuming it.

shorts are at least 16 bits
ints are at least 16 bits
longs are at least 32 bits

Reliance on compilers over the years has conditioned many coders to think that there is a power-of-two progression between data types, which is NOT guaranteed to be the case.

I can almost guarantee that Firefox is using native types and assuming their sizes instead of typedef'ing things that will be persisted. Like you said, idiots and incompetent programmers.
 
This is not what the C language spec says, and bad programmers - like the ones at Mozilla - assume that is the case and write code assuming it.

shorts are at least 16 bits
ints are at least 16 bits
longs are at least 32 bits

Reliance on compilers over the years has conditioned many coders to think that there is a power-of-two progression between data types, which is NOT guaranteed to be the case.

I can almost guarantee that Firefox is using native types and assuming their sizes instead of typedef'ing things that will be persisted. Like you said, idiots and incompetent programmers.

I never said anything about what the C language specs say. I simply said that it makes more sense to have that progression; why have a bunch of different data types that are all the same size?

Also, Firefox is written in C++, not C. Until last year, C++ didn't even HAVE a long long type. The biggest problem is that the way that Microsoft implemented LLP64 involves a bunch of non-standard types and keywords.

Which is exactly the kind of behavior Mozilla is engaging in, and the kind of behavior you seem to consider acceptable for them. After all, it's not Mozilla's bad design that's the problem. It's Microsoft's, right?

See above.

Yes, IE10 x64 is as fast as the 32-bit version, IE9 x64 performance slow down was due to the fact that they didn't make a x64 JavaScript JIT compiler, not because of issues with x64 data formats.

What I'm reading is that there are millions of apps that do so though, and Windows benefits from compatibility. It's seems both cases have upsides and downsides, but I can understand MS decision. What I can't understand, is how IE has a x64 version and FF and chrome do not, and this is because Windows has a problem in x64. Reminds me of the fact that FF said they were going to use sandboxing on Windows, but never got around to it, 6 years now after IE implemented it. Meanwhile people tell me OSS is greased lightening when it comes to implementing security features, and MS is a slug in a coma here, etc. Now if IE didn't have x64 and sandboxing, I might agree that Windows has a problem, but at this point I can't see this as anything but a FF and chrome failing (and actually, apparently, Chrome has moved to make a x64 build, and I suspect it will be done for years before FF makes a similar move, again leading me to question the explanation you and FF are giving for any of this.)

There are stable 64-bit versions of Firefox and Chrome...just not for Windows.

It has nothing to do with compatibility; Windows x64 is perfectly capable of running 32-bit programs. Microsoft shouldn't be encouraging or subsidizing bad programming.
 
Again guys, this is an inaccurate headline. It is only talking about a particular production run of 64-bit Nightly releases. Firefox will continue, in 64-bit, for just about all platforms.
 
LOL what does Microsoft's Windows 7 and x64 have to do with Mozilla sucking at developing software for a hardware platform?
My point is that 64 bit Mozilla applications are available for other platforms like Linux, and all that was much before Microsoft even managed to release a proper 64 bit OS.
Their issues are tied to the closed-source development model: they are stuck by all their dependencies and can't fix them. Actually, even the closed source Flash had a 64 bit version on Linux before Windows.
The Linux community made 64 bit work years ago. It's been the most popular arch for a few years as well.
 
Firefox for Linux always was, and still will be, 64 bit. Actually, it's also working on ARM, PowerPC, Itanium...
I thought with Windows 7, Microsoft managed to get out a proper 64 bit OS, years after. Looks like it's still a failure.

Well I was going to say much of this. I've been running 64-bit Firefox since it was first released. No problem downloading the source and compiling a 64-bit native on Linux. Never had a problem with plugins, mainly because I don't know of any besides Flash and Java that are big time. Mplayer pretty much handles all media I throw at it in browser and flash is handled by gnash. Java never gets installed on anything I own anymore, and if I do use it it isn't for applets in a browser.
 
My point is that 64 bit Mozilla applications are available for other platforms like Linux, and all that was much before Microsoft even managed to release a proper 64 bit OS.

Uh, what? Official support for 64bit versions of Firefox on Linux and OSX started at Firefox 4.0, which was released in 2011.

Windows XP Processional x64 Edition was their first consumer OS to support the AMD64 / x86_64 instruction set, and was released in 2005.
 
Uh, what? Official support for 64bit versions of Firefox on Linux and OSX started at Firefox 4.0, which was released in 2011.
:D
I remember using Firefox 3.0, or even older, on amd64.
http://sources.gentoo.org/cgi-bin/v...3.ebuild?hideattic=0&revision=1.2&view=markup
Firefox 3.5 is still in current Debian. http://packages.debian.org/squeeze/iceweasel

Windows XP Processional x64 Edition was their first consumer OS to support the AMD64 / x86_64 instruction set, and was released in 2005.
And it was shit. No one used it, for good reason.
The first usable 64 bit OS by Microsoft is Windows 7. And still, most software is distributed in 32 bit only.

http://store.steampowered.com/hwsurvey
 
I remember using Firefox 3.0, or even older, on amd64.
http://sources.gentoo.org/cgi-bin/v...3.ebuild?hideattic=0&revision=1.2&view=markup
Firefox 3.5 is still in current Debian. http://packages.debian.org/squeeze/iceweasel
I said official support, as in, official support from Mozilla. They didn't make 64bit Linux or OSX builds official until 4.0.

And it was shit. No one used it, for good reason.
The first usable 64 bit OS by Microsoft is Windows 7. And still, most software is distributed in 32 bit only.

http://store.steampowered.com/hwsurvey
I can sort of understand the commends about Windows XP Professional x64 Edition. it was based on a Server 2003 core rather than a Windows XP core, so there were some issues with driver and software compatibility... but nothing that prevented 64bit Firefox from being built for it (and 64bit builds of Firefox do run on Windows XP Professional x64 Edition)

But I don't see how Windows Vista is any less viable as a 64bit-OS than Windows 7. After all, Windows Vista paved the way for mass adoption of 64bit support in hardware drivers by requiring that all certified drivers have BOTH a 32-bit and 64-bit version (and making this a simpler prospect by building Vista 32bit and Vista 64bit from the same codebase).

Windows 7 simply carries on doing what Vista did as far as 64bit software and driver support goes, no better, no worse.
 
Back
Top