Slashdot Mirror
Firefox Is Going 64-Bit: What You Need To Know
An anonymous reader writes "Firefox product manager Asa Dotzler determined that figuring out the 64-bit confusion surrounding Firefox it will be 'near the top' of his to-do list this summer and fall. One could conclude that Mozilla has no idea at this point what people are expecting from a 64-bit version of Firefox, so Dotzler is asking for some feedback. More speed? More security? What about plug-in availability? All of the above, please."
I would like to see them put in a timer of sorts. So that when you start the browser up it asks: "How long would you like to browse the web for?" and offer 15, 30, 45 and 60 minute options. At the end the browser would save the "state" of the browser then turn off and refuse to start for another hour.
An app idea I had (programmers contact me!) was to incorporate something like this for the entire computer with an app for a smartphone. It'd tell you "Go for a walk" or whatevever then the app on the phone would start reporting back the GPS info to the computer. The computer would know if you've moved about and how fast, so you couldn't get in your car and drive around for 10 minutes and fool it.
It sounds drastic, but when I brought it up at a Chirpractic seminar open floor, there was initially a lot of chuckles but as the idea fleshed out, folks got interested. Sitting on your butt in front of a computer all day is a 100% guaranteed way to develop vertebral subluxations which can cause all sorts of ills. Ever stand up and stretch your back after sitting for a while? That's your body dealing with neo-subluxations which have formed in that short period of time.
More serious subluxations must be dealt with by a professional Chiropractor. Only they are trained to detect and eliminate this scourge. Since people became predominately "office workers", the rate of subluxation has skyrocketed, especially in IT workers.
Take care,
Bob.
Chiropractic Saves Lives!
Then why make a 64 bit version at all? If the company has no idea what people expect, then they don't need to be messing with it in first place.
Perhaps if they instead focused on fixing the memory leaks, pushing out 64-bit builds wouldn't be so pressing an issue?
Then why make a 64 bit version at all? If the company has no idea what people expect, then they don't need to be messing with it in first place.
Hurray! With 64 bits, Firefox might be able to address all the memory it uses...
-- IANAL, this isn't legal advice, and definitely isn't legal advice for you. Also, Squee!
Firefox has served as the alternate web browser for years. Now, that the KHTML inspired, Webkit browser engine has matured, it is time to thank Firefox for its years of service, and switch to one of the many Webkit based browsers, such as Chrome, Safari, or Midori.
64-bit Firefox: Now with 192 gigabytes of memory leaks!
I'll be happy if it correctly renders the web pages I visit that are over 4 GB in size. Of course, they're mostly Flash.
Why does a browser need to be able to access more than 4GB ? Has anyone hit that limit yet ? Or even close ?
I thought I had been running a 64bit Firefox for years. So I wasn't? Or is this about finally doing a 64-bit Windows build? Probably since Moz Corp is entirely focused on Windows and treats Linux as a red headed stepchild.
Democrat delenda est
The OS X version is 64 bit already. At least, I can choose whether to launch it in 32- or 64-bit mode.
Comment removed based on user account deletion
I am expecting a browser that runs in 64-bit mode under 64-bit versions of Windows. Sincerely, Captain Obvious.
Should have been: Firefox is going 64-bit on WINDOWS
I've been using a 64 bit version of Firefox for 6 years now (on Linux). Even Flash works.
What's the problem with 64 bits? Firefox worked just fine with it for years. Unless you're using a doorstop machine or a doorstop OS, even having 32 bit libraries is a waste of disk space. Heck, even phones start having 2GB ram, suggesting ARM will need to transition soon. MIPS (Longsoon) is already there.
When project electrolysis finally lands on Firefox trunk, the only current benefit of 64 bits will be gone, but that's still not a reason to have a complete set of 32 bit libraries in memory (or even on disk).
Limits of 32 bits are annoying. For example, gcc-4.6 can partition flto compilation but it still needs to load everything into the memory. It'd be a huge waste of programming time to implement your own swapping if the OS is perfectly capable of doing that. If the address space is big enough, that is. You currently cannot compile Firefox with flto on a 32 bit machine at all, and it gives a huge (~20%) boost on typical C++ code.
Thus, your precious 32 bit systems are a doorstop architecture that would be nice to get rid of.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
This sounds like like the, "Why should we rewrite our perfectly good 16 bit applications just because everybody else is jumping on the 32 bit bandwagon" conversations that we went through back in ancient times.
...back when I actually gave a damn. More specifically, when I ran Windows, which was a hell of a long time ago now (in computing terms)... back before mid to late 2006. Now, I run Linux, so Firefox, or Iceweasel, or whatever spinoff is included in the distribution due to the Mozilla Corporation's bitching is often included as 64-bit by default--as long as it's a 64-bit distro.
To top it off, with all of the bullshit Mozilla has been pulling off for quite a while now (starting not long after the formation of the corporation and their increasing grasp and restrictions on the use of their products), I've been considering switching. There are a bunch of extensions that IMO are must-haves, and they make the switch more difficult, but every release, every news story of Mozilla/Firefox is making me consider jumping ship before this titanic sinks. They already seem to be so disillusioned from everything they already stood for, it's rare for them to impress me any more.
What the hell has become of the Mozilla of the Firefox 1.0 to 2.0 era? They've really jumped off the deep end. First they started wanting more control and placing more restrictions on the distribution and use of the software, then they started chasing Chrome in every way possible. And more recently, they switch to a clusterfuck of a release/versioning system, forcibly breaking extensions every couple months.
Ditching this Asa dipshit (never did like the guy) and scrapping the whole "Mozilla Corporation" idea would be a great first start. Oh, and listening to the users, instead of blatantly copying the competition's (specifically Google's) every last move... most of which of which are just bad ideas in the first place, at least in the context of Firefox. If I want Chrome, I'll use it; make Firefox actually be Firefox. Us Firefox users want Firefox, not some fucking Frankenchromeopera; if we did, we would have escaped from your increasingly controlling grasp long ago.
I forced myself into some of the changes in 3.x eventually, but with all the needless shitty changes in 4/5 and the new rapid major version releases, it looks like I've reaching the end of my use (and recommendation to others) of their products.
Since version 4, Firefox just stops functioning at random, with no warning. The menu bar becomes unresponsive, keyboard shortcuts and commands are not recognized, and tab switching is lost. You can still browse within the page you're on, but that's it. I went back to version 3, and realized that it was incredibly, incredibly slow.
Frustrated with no fix, I tried Google Chrome. So far, I am not impressed. It got caught in a loop when it tried importing my saved passwords from Firefox.
I may go back to Safari. I can't believe how obscenely hard it is to find a decent browser. So many choices, none of them any good.
Firefox 64bit - now capable of completely glooping 2 exbibytes! At current rate of leaking, this means you now only need to restart one a day! (Warning, depending on speed of swap device, Firefox 64bit may take more than a day to restart.)
Red to red, black to black. Switch it on, but stand well back.
Why would anyone WANT to read a PDF inside a browser?
It's not a web format and shouldn't be treated like one by any browser.
OS X has the only tolerable PDF viewer already (Preview.app). If anything, the other platforms are worse off with PDF support.
I haven't posted in so long, my sig is out of date.
Releasing a 64-bit install is about compatibility in the environment. But an implication by the parent is that Mozilla can't work on increasing compatibility and fix bugs at the same time. These two things aren't related at all where we should welcome things like this.
Or another way to think about it: We should applaud Mozilla for releasing the 64-bit installer and continue to complain about the bugs.
A 64 bit version number and support for IPV8
They need 64-bits because the version number won't fit into a 32-bit unsigned integer.
This entire article makes no sense.
We simply want a version of Firefox that takes advantage of the additional resources our 64-bit machines have.
Sure there are probably specific optimizations you can do, but really the most important thing is simply to compile it to a 64-bit program instead of the x86 they use currently.
Can someone explain to me why anyone would think differently?
Troll is not a replacement for I disagree.
Please don't add native PDF support. Feeping creaturitis is never the answer.
A rolling stone is worth two in the bush!
PDF in the browser is a sin.
Climate Progress - Hell and High Water
Yay, with 64 bits it'll be able to leak MORE than 2-4 gigabytes of RAM.
Of course, I understand what 64 bit means, and if my browser is hitting the 32 bit memory limit, I'm dumping the fucking browser anyway.
I've been developing for years, have apps for windows that are 32 and 64 bit, and several fat OSX binaries that support 32 and 64bit, if the 64 bit version runs differently than the 32 bit version, you did it wrong.
I have nothing against making it a 64 bit binary in general, but there really is absolutely no advantage to doing so. If your browser is eating more than 3 gigs of memory, your browser is broken, you should fix that problem first, not make it so it can eat more memory.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Here's an idea. How about not breaking add-ons with every new version? That would be great!
I'm in the Firefox beta program, so they FORCE me to upgrade over and over and over again (really obnoxiously). And every single time, Firebug and Greasemonkey stop working. Problem is, I need Firebug, in particular, to do my job, so it's inconsiderate at the very least, a horrible way to treat your beta testers. And yet, much of my coding is in preparation for HTML5, so I need to use what's in the beta too.
So that's my suggestion for 64-bit. Use some of the extra address space to track add-ons better and not refuse to load them just because they haven't yet been certified to work in your tiny little frickin' point release.
Thanks a bunch!
who uses 32-bit systems any more?
At this time, Mozilla seems like a baby screaming for attention. They seem to be scrambling to match Chrome. I had been a Firefox user for ages. I didn't try Chrome because I don't like that Google runs background process to update Chrome. So I decided to go with Chromium (which does not have auto update feature but gets updated via Ubuntu repository). I found, once you go Chromium you never go back. Chromium is blazingly fast and stable. Even Firefox 5 is no match for it. Chromium uses way more memory than Firefox, but guess what? It doesn't have memory leaks. Firefox uses less memory but keeps leaking it. Fix memory leaks and stability issues in the current version (call it Firefox 100 for all I care). 64 bit version would be nice but not at the cost of basic problems that need fixing.
And a security risk. But hey...who care's about security. We want feature creep!
Om, nomnomnom...
Maybe this will FINALLY mean no more nspluginwrapper crap;
Every time I try to open more than one PDF (Ubuntu 8.04 LTS / 10.04 LTS) nspluginwrapper goes nuts, no more PDF rendering....
Firefox has been available as 64 Bit for years. The article is about 64-bit WINDOWS.
I'm surprised they didn't just decided to support 128 bit and deprecate 32 bit.
On a side note, my Firefox is using 1.2GBs of RAM while Debian in a VM is using 400MBs.
Why would you want to launch a whole 'nother application, especially on a platform where PDF is built-in to the OS and can be displayed much faster than launching bloatware like Adobe Reader. Maybe you like Reader or want to disable PDF altogether for security, but I agree it would be nice to have an inline option, this a major reason I use Safari (browse research papers online, with *drumroll* the browser!)
Hasn't a linux 64 bit version been available for a few years now?
I'm with you on all points, though I will say that FF4 introduced a really nice feature that saves time for me every day. That is, being able to type non-URL queries into the URL field to search FF's history database has really made my browsing more efficient. But that doesn't make up for the fact that FF4 & 5 are as leaky as the Titanic.
Agreed, it's sad that Windows fucking sucks for PDF support, and that Chrome's half-implemented plugin crushes every other Windows reader, both in interface and security; and partially in speed (it takes longer to load, but it navigates quicker than anything else). I don't even trust other 3rd-party readers not to root my Win7 gaming machine these days. Implementing security by ignoring specification features only goes so far before actual preventative measures are required. Even Apple understood that, and OS X is hardly ever targeted by malware.
~ $ which firefox
~ $ file
Wow. I just kind of assumed it would have been 64bit several years ago seeing as how that has been the standard processor for a while now.
It's not exactly a new platform
they truly needed that, because soon enough they'll run out of 32 bit integers they use for version numbering.
You can't handle the truth.
/Madge
I'm running the 64-bit nightly right now. Everything seems to be working EXCEPT for the WMP integration. That's been the only downside I've been seeing.
Bryan
and justifiably so...Linux is still considered the cheapskate OS.
Development of FF for Linux takes resources. There are only 3,000 Linux Firefox users out there when, every year, FF Windows browser crashes affect over 40,000 people. They should drop Linux support and instead focus their development on the Windows version, a lot more people would be saved!
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
That's all you need to know.
Quite the opposite really, especially if you don't have plugins loading on demand. I doubt your fav reader on Linux is running under full chroot/AppArmor like the Chrome PDF process... and the Windows reader you use is almost certainly one API call away from nuking all of your documents.
Basically take away every feature since Firefox 1.0, make Awesomebar, Orange menu, hidden status bar, sync, etc and put them into extensions. Then make a version of Gecko that is fully HTML5/CSS compliant, which is furiously fast and memory conservative even on the slowest of celerons and memory gimped systems such as your grandmas e-machine special she bought in 2001.
Then maybe Firefox should deserve some of the $50 million a year it gets instead of wasting its money on memory bloating features.
Bigger memory leaks.
I don't know what the hell you guys do to make firefox unstable. Since 3ish ive been having month long up times with dozens of tabs open, closing only for browser upgrades and security patches(system reboot) The only thing that brings firefox down with any regularity are bad addons and buggy plugins. Fix your setup, in other words. It's you, no the browser.
Actually I notice most of the people that bitch about firefox are OSX. Sorry, OSX is a bastard child platform as far as firefox is concerned. Stick with safari.
Also, how can anyone call firefox bloated? It's download package is tiny! If it was a 200meg+ blob you could say bloated.
Pale Moon is already available for people to check out. It's Windows-only, but I've been running it for a while as a secondary browser at work, and it works pretty well, albeit with a few minor quirks.
$ file /usr/lib/firefox-5.0/firefox-bin /usr/lib/firefox-5.0/firefox-bin: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
Say what?
Fix the damn UI Hanging issues, get ASLR fully working along with DEP and full process isolation before adding stupid features and Don't forget multithread support working correctly.
I'd much rather they fix these issues while moving towards 64bits as these alone should improve the damn stability and security. Hell if a damn Add-On hangs or creates problems, I'd love to be able to kill the thread/process that's hung instead of shuting down the entire app.
Mod me up/Mod me down: I wont frown as I've no crown
32 to 64 bit makes virtually zero performance difference to 99.9999% of applications. People forget that CPUs have 2 main buses - the address bus and data bus. The data bus has essentially been 64 bit for years on "32" bit intel cpus. Upping the address bus to 64 bit and increasing standard ALU integer registers to 64 bit (the floating point registers have also been 64 bit for years) will only benefit applications that require huge amounts of memory and/or ones that required large integers. Eg DMBS. For most desktop apps it'll frankly make fsck all difference.
Great, my current firefox is running at 1.5GB, I can't wait until I can let it spill over 2GB!
I have a 64bit Pentium running 64bit Win 7 pro, but the FF install is the 32bit version. The Flash player crashes fairly often, on Flash content which didn't crash it before on an all 32bit machine. Is it the 32/64 bit difference? Will a 64 bit Firefox solve this problem?
--
make install -not war
The only difference between the 32bit and the 64bit version should be that the first one is 32bit and the second one 64bit.
Adobe recently released the flash 11 betas which include a 64-bit linux version, so that shouldn't be a problem.
I want Firefox 64bit to stop crashing on any error of any plug-in.
.
Asa Dotzler is a dick.
But that's probably asking too much...
Way too many web sites (especially banks) that require IE.
... There are only 3,000 Linux Firefox users out there ...
I find this hard to believe. Firefox is installed by default on many of the most popular Linux distributions (such as Ubuntu, Fedora, etc.). When you consider the millions of Linux users using these distros (yes, I can back that up with reliable sources - can you say the same?), it's not hard to imagine that the number of Firefox users on Linux extends well over a million (maybe millions).
Bear in mind that Firefox is usually installed via a package manager, so the number of Linux downloads (if any) from the Firefox website are not to be relied upon as a true indication of the amount of Linux users using Firefox. In addition, there are also many of us who prefer to compile from source, as we are then free to modify and tinker, or just study out of academic curiosity.
Besides, although I'm not familiar with the Firefox codebase, I'm pretty sure that there is no "Windows version", and it's just recompiled for each operating system. Development "of FF for Linux" is, I think, not an issue.
Just my 2c.
Does Evince even support Javascript? Of course there could be attacks on the engine itself, but why target Cairo when you could target GDI or something. Plus that's just harder than attacking via JS.
Climate Progress - Hell and High Water
On other CPU architectures with both 32 and 64 bit modes, the 64-bit code tends to be slower. This is because pointers in 64-bit code are twice as big, so there's more data to move around. Thus, the only advantage of running in 64-bit modes was a larger address space.
The difference in x86(-64) is that amd64 doubles the number of general purpose registers, so it actually is faster than ia32.
ARM already has a decent number of registers, and I doubt anybody's going to try running a huge RDBMS on their iPhone anytime soon. Perhaps somebody would want to mmap a blue-ray movie, but that doesn't seem very compelling.
I run mostly 64-bit OSes and I'd rather have them fix the current memory leaks in Firefox.
Seriously!
Right now, on a machine that was rebooted 4 hours ago, Firefox 4 is using 750MB of RAM!
I don't care about 64-bit browsers and can't see any reason beside security-sucking-direct-driver-access to go 64-bit. Don't we all know that is a really bad idea already?
Seriously!
I don't have any plugins.
I block most JavaScript, don' t use flash, visit text-only web sites.
What could possibly be eating all that RAM?
Seriously!
FIX THE MEMORY LEAKS ALREADY!
Develope a cross platform, touch screen, front end /osx/linux replacement browser / file manager
ie. a touch screen windows
= win (before windows 8 comes out)
I just thought I'd go ahead and mention...there are already 64 bit binary installers available for Firefox. For Windows. Like right now. And since 2008.
They're not official Mozilla builds, mind you, but they're community built (there's 3 or 4 different ones out there) and usually based on the current nightly of whatever the production version is at the time. I ran one for 3-4 months on XP x64 (which, I should mention, was a very, very halfassed 64-bit system itself) and noticed my memory consumption after a week was around 20% lower doing the same things. The lack of a 64 bit flash plugin for windows forced me back to 32 bit Firefox.
Now I dual boot. I'm running 32 bit Firefox in Windows 7 x64, and 64 bit Firefox in Linux Mint 11. Same, current version. Linux tends to rely much more on shared libs than windows, but my observation still puts memory usage about 20%-40% lower on the Linux 64-bit install.
So yes, there's a definitive benefit.
Expecting: Launch faster, operate faster. I don't expect much difference in security from 32 to 64 bit. Also, I would hope that most plugins are compatible
And stop adding crap like pdf readers - you wanna display something you use external apps.
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
There's some braindead copy protection software using USB "security" dongles that unfortunately is required before you can run some very expensive applications that are used in some engineering and geophysical workplaces. One variety of that is 16 bit only and the idiots even wrote 16 bit MSDOS USB drivers to make it work instead of dragging it into the 1990s with 32 bit support. That keeps some stuff that could actually use a bit more memory firmly on WinXP 32bit unless it's a pirated version (and apparently the workaround is very trivial). In practice a lot of that "security" software only punishes the innocent.
Not sure, but Evince shares the Poppler library backend with Okular, which uses FreeType 2 internally, which was susceptible to the iOS JailbreakMe attack. Okular crashed to one of these hijacked PDFs, likely because the payload targeted iOS and not Linux. Beware the PDFs :).
I roll my own Windows builds of Firefox and have been using Win64 versions since before FF4 actually came out; the difference is really minimal; I use 64-bit Flash (square) and Java, everything works and it's native. Currently there is a patch in the works to enable Firefox x64 to use 32bit plugins via the wrapper, which I get the feeling will probably encourage Adobe to not bother releasing a "proper" x64 Flash.
Cuz 32-bit version runs out of memory when you have it open for several days and 100's of windows/tabs?
Cuz, the 32-bit version doesn't work well on 64-bits because it isn't aligned right and suffers terrible performance penalties?
(during a bogdown today, where it had it's cpu 'peg'ed...(why the windows threading model doesn't support multiple cpu's is ... well, linux really lucked out in choosing their 1thread/proc model)
Here's the stack trace:
0) ntoskrnl.exe!memset+0x64b
1) ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
2) ntoskrnl.exe!KeWaitForSingleObject+0x19f
3) ntoskrnl.exe!__misaligned_access+0xba4
4) ntoskrnl.exe!__misaligned_access+0x1821
5) ntoskrnl.exe!__misaligned_access+0x1a97
6) js3250.dll!JS_IsAboutToBeFinalized+0x38
7) xul.dll!??_7gfxPDFSurface@@6B@+0x34600
8) xul.dll!?sDPI@gfxPlatform@@1HA+0x1d0
9) xul.dll!NS_LogInit_P+0x388d
10) nspr4.dll!PR_AssertCurrentThreadOwnsLock+0x12
11) js3250.dll!JS_IsAboutToBeFinalized+0x38
12) js3250.dll!JS_DHashTableEnumerate+0x6c
13) xul.dll!?TimerCallback@?$nsExpirationTracker@\
VgfxFont@@$02@@CAXPAVnsITimer@@PAX@Z+0x239f
14) xul.dll!?GetUnderlineOffset@gfxWindowsFontGroup@\
@UAENXZ+0xcbfe
15) xul.dll!NS_LogInit_P+0x388d
16) js3250.dll!JS_SetPrototype+0x29c
17) xul.dll!?SetLineBreaks@gfxTextRun@@UAEHIIHHPANPA\
VgfxContext@@@Z+0x1b6
(It never recovered from it's peg -- finally just crashed, but notice that out of the above 17 calls, 3 are for misaligned access's handed by exception handlers (x86 machines still get misaligned access exceptions when you access words that aren't hw aligned, they are just normally handled 'automatically' by all x86 OS's that then patch the pieces together -- at the expense of entering a system exception handler that has to glue things back together.
So Maybe it's because of issue's like the above, but compiling for 64-bit usually gives a ~15% performance boost over 32 bit code, and in the above trace 17% of the call stack nest is due to misaligned code/data.
Anyway, the baloney that they don't know what to expect is just that -- it's them spewing garbage for being way late in getting a Win64 version out -- as they've had a 64-bit linux version (coexisting with a 32-bit version for at least a few years -- and they also have had 64-bit on MacOS....so it wouldn't be "doing" something different, it would be bringing the windows platform up to parity with the linux and Mac platforms.
All the time I encounter things where programmers cling to past ways of doing things because they can't be bothered to learn something new, to rewrite their code and so on.
A big one I remember was with Windows 2000 (and then XP) and the WDM device model for soundcards. NT had some pretty bad soundcard support. I mean it played audio and everything, but was a problem both in terms of what it could present to apps and in terms of limits on drivers. Well WDM fixed that. Wonderful new system, fixed a ton of issues. However the pro soundcard I had refused to support it. They said it couldn't do what pro apps needed. Nonsense, that it could do those things was right in the docs. Then when they finally got one out it had massive problems, not the least of which being it only supported 2 of 8 channels, again they claimed that was a limit built in to WDM.
They finally got on board, after like a year and a half, but it took forever and probably many people like me bitching.
64-bit is even harder since Windows does 32-bit compatibility so flawlessly. Users can't even tell if apps are 32-bit or 64-bit without specifically looking for it, there isn't a speed penalty (that you can notice) or different interface or anything. Ring 3 32-bit apps work just like they always did (Ring 0 stuff has to all be 64-bit).
So devs are lazy. They release only 32-bit versions since you still need to support that, there are plenty of non 64-bit system, and since "There's no reason to have 64-bit.
Annoys me to no end since the reason is simply to run natively on the new system. No, you don't need a 64-bit browser but why not have one? Why shouldn't everything move to the new architecture?
It also annoys me because people find this shit bites them in the ass eventually. One way we saw this happen was 32-bit apps with 16-bit installers when 64-bit Windows came out. Companies kept using the old installer since "It worked," and "There's no reason to change." However then along comes 64-bit Windows, which cannot run 16-bit apps since you can't switch to Virtual 8086 Mode when running in Long Mode. So now their shit can't install, even though it would actually run in the new Windows.
Programmers really need to get less lazy about supporting new technologies. Part of working in a tech field is being willing to keep up to date on a quickly moving landscape. Things change all the time, you need to change with them. I see that from the IT end all the time. A great example is virtualization. Just 10 years ago it was a new term, emulation was really what I'd heard of, and something that was mostly a toy. I played with emulators for old game systems. I'd never consider virtualizing a PC to do work on, way too slow, much less a server. Now we have almost everything virtual, not just to save money, but to take advantage of new features it offers, like say snapshoting a computer. I can't very well say "We didn't do it this way in the past so we aren't going to change." When new technology comes out, we look at it, consider if it will help us do what we do better, is it worth the cost, and learn about it.
I get tired of programmers that have to be drug in to a new way of doing things kicking and screaming. 64-bit is here, now, and it is the future. It is not new, it has been around for quite some time. Support it. All apps should have a 64-bit version, yes even if you don't need the memory. It isn't hard, and things run more efficient natively in Long Mode than in Compatibility Mode. Get with the program.
nt.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
> A vanilla install of firefox doesn't seem that bad - but
> once you add a handful of addons, things do get
> leaky as hell.
> Would that be Mozillas fault, or the addon writers?
Howsabout leaving all the cutsie features for addons, rather than hard-coding in every addon that's been downloaded a dozen times or more?
* get rid of spellcheck, etc, etc, etc
* get rid of the relational database to store bookmarks and various settings. We all know how successful binary data blobs like the Windows Registry turned out... !NOT
Showing my age. I remember years ago all the "about:kitchen_sink" jokes about Mozilla 0.9x. It was a breath of fresh air when Phoenix (later renamed to Firebid and then to Firefox) came out. They actually got rid of the usenet news and the email and the HTML website builder. That greatly reduced the memory footprint and sped up the browser.
But then they went back to their old ways. Remember how AOL f***ed up Netscape when they tried to make it into a OS-on-top-of-an-OS? Seems like the Mozilla foundation is repeating that mistake. I don't want a f***ing "application platform" with a buttload of built-in features, I want a web browser.
One reason for the occasional freezes on the linux version is due to the SQLite RDBMS which is used to store a bunch of stuff that belongs in straight text files. Don't blame the people that wrote SQLite. A real RDBMS is supposed to do stuff like fsync() to commit transactions and ensure database integrity. Then again, an RDBMS is usually intended to be run on a dedicated server, not as part of the infrastructure of a stinking web browser.
Another stupidity in the linux version is the braindead insistence on dereferencing symlinks. Here's what happens... .doc file, I set the "helper application" to /usr/bin/abiword /usr/bin/abiword is just a symlink to /usr/bin/abiword-2.7, which in turn is a symlink to /usr/bin/Abiword-2.7. /usr/bin/abiword to /usr/bin/Abiword-2.7 /usr/bin/Abiword-2.8, and /usr/bin/Abiword-2.7 is removed. .doc file, and Firefox starts crying about "application not found".
* first time I run into a
* but
* Firefox "corrects" the application name from
* I do a system update, and there's a version bump to
* I click on a URL to a
If Firefox wasn't so braindead, and was willing to accept what I had typed in, rather than de-referencing it, it would've found /usr/bin/abiword, which is properly symlinked to /usr/bin/Abiword-2.8, And this doesn't even begin to address applications that respond differently, *AND EXPECT DIFFERENT PARAMETERS* based on which symlink name thay're invoked with. At one point, I ended up hacking into the chrome directory, grepping for "/usr/bin/Abiword-2.7" in a config file, and replacing it with "/usr/bin/abiword". When that config info ends up in an SQLite RDBMS, that hack is no longer possible.
Oh yeah, this message is coming to you via Opera. If I had a million dollars, and access to a bunch of coders, I'd love to launch a project to backport the latest HTML implementation to Firefox 2.x.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
yes that is right i think also they truly needed that, because soon enough they'll run out of 32 bit integers they use for version numbering.
friends for coll tricks logon to http://www.hacks4al.blogspot.com
I haven't programmed in a long time, but isn't this just a matter of a compiler switch to make it quadword-aligned? If the program is asking the OS for blocks of memory and not addressing it itself what does it matter?
for our 64-bit HTML?
It's Windows-only.
No Portable edition yet.
http://www.palemoon.org/palemoon-x64.shtml
If you run a 32 bit process multiple times under a 64 bit os, it will use ("not leak") More memory. Users often don't have a choice in this, but developers have!
One of the things MS states is " Working set. WOW64 increases the size of the application's working set.". It s impossible to set a number on this, but i bet if you have an odd applications that uses a lot of small resources this increase might be very noticeable. Users night decribe this as a memory leak, but since it is by design, this will not be confirmed. Especailly since nobody will provide tools to determine this overhead, since the logical solution is to go 64 bit instead.
For developers the solution is simple: offer a 64 bit version. Users only have a choice if a 64 bit verions is available, and they will choose 64 bit if the OS is 64 bit.
THis is yet an onther reason to abandon java and flash, it is part of the browsing expierence, but the browser developers barely have an influence on these components.
The biggest reason to switch to 64-bit on Windows is to use more than 2GB of RAM (since 32-bit apps get a 2GB userspace / 2GB kernelspace virtual memory split). However on Windows 7 64-bit, apps marked as Large-Address-Aware get the full 4GB of virtual address space to themselves. The only 'disadvantage' is that you have to stop using any tricks which assume that the full range of pointer values won't be used; it's just a runtime flag stored in the executable which tells the OS to let it have the full 4GB if possible.
The one time I ported an app to 64-bit, memory use grew by around 50%. Maybe that's not typical. But for me it means I'm going to try my damndest to keep an app 32-bit using the LAA flag until I really truly need that 16PB address space.
Between running Google+ and Pandora in Pin-As-App tabs, and my other regular browsing, FF has been slurping up resources in my Slackware and Arch installations like there's no tomorrow. It's getting old. Maybe today's project should be getting to know Chrome/Chromium?
Nocturnal Slacker
Sorry, but Firefox devs shouldn't be asking what the public expects. They should have enough sense to know two things: First is that if their market is demanding it. Second, as developers, the benefits over 64-bit native vs 32-bit virtualized.
To be perfectly honest, I feel the reason they are reluctant is the shear stupidity of a lot of their users. People who insist the memory footprint is already too big. All the bells and whistles features of memory caching, history, prefetch, javascript, plugins, all spread across the 50-100 tabs in a browser window that's never closed add up. With 64-bit allocation, this memory bloat effectively doubles. I am sure there is some fat to be trimmed, and leaks to be plugged, but the real problem are the tradeoffs for speed, useability, and some absurdly unreasonable user expectations.
But honestly, at this point I will only believe a 64-bit native Windows build from them when I see it. They have been promising this for around 5 years now with every major release. Yes, they build 64-bit nightlies, but they always stop at the betas, and have never delivered on their release promise. Not everyone wants to be the guinea pigs, and the same code builds into a fully functional 64-bit product on all of the FOSS platforms.
Disclaimer: I am a sometimes contributor to both Firefox and Chromium, and helped porting these apps to FreeBSD, where both build and run 64-bit native on the appropriate platforms.
Shiretoko?
Maybe I'm missing something, but Shiretoko has been around for years. Are they finally fixing its extremely buggy code?
One could conclude that Mozilla has no idea at this point what people are expecting from a 64-bit version of Firefox, so Dotzler is asking for some feedback.
That's ridiculous. I think that people just want Firefox to *work* on their latest computer, and they don't want to care about either "how many bits their computer has" or whether their OS is 32 or 64 bit or whether the version of Firefox they just downloaded is 32 or 64 bits. Why even ask questions like what people expect from a 64-bit build?
I think that once computers stop shipping anything less than 8GB RAM, OSs too will try to shrink their installations by removing 32 bit libraries by default. Just as Windows stopped including 16 bit libraries once XP replaced both Windows 2000 and Windows ME.
It would be a good thing.
Good idea to go 64 bit, so there is no more need of fixing Firefox's memory leaks. Looking forward to see Firefox's using 16G ram in taskmanager.
"Windows 64-bit XP used twice the memory (32-bit * 2)"
"64-bit applications use more memory, often times twice as much as 32-bit apps"
"improved security (32-bit encryption vs. 64-bit encryption)"
The amount of nonsense in the article makes me speechless.
It's not the bus width - there were some pentiums that had 64-bit buses, but that didn't make the pentium itself a 64-bit CPU. Similarly, some of the processors out there - like Itanium - have 128 bit buses. Some processors like the DEC AXP 21066 had multiplexed address-data buses, while most were totally non-multiplexed. So which one is the definition?
It's the default size the ALU uses when it's processing arithmetic & logic operations. It's totally independent of the address bus width, data bus width, whether address and data share the same bus, and so on. The latter are I/O operations, but what defines the CPU bit length is how much its integer (not its FPU) unit can handle.
Hence Intel has been 32-bit, and now 64-bit, Phlenom is 64-bit, UltraSparc, Power7 and MIPS IV are 64 bit, Pentiums Core2Duos and Dual cores are both, ARM is 32-bit and so on.
If somebody makes a CPU w/ 18 bits, it would be an 18 bit CPU. Not that there is one - I believe that the VAX at one time was 24 bit or some non-power of 2. And yeah, by power of 2, one means that the CPU can be 8, 16, 32 or 64 bits. I don't believe 1, 2 or 4 bit CPUs ever existed, and I doubt that a 128 bit CPU (i.e. 128 bits of integer ALU) will ever be needed. Not exactly the same as 640k being all you need, or 4GB being all you need.
Hopefully the extra 32 bits will finally let us turn the damn tabs off...
I'm pretty sure "__misaligned_access" in that stack trace is a red herring. Notice the large offsets and multiple frames blamed on the "same function". It's probably a section of ntoskrnl for which you don't have full symbols.
In theory you can get a decent stack trace (or even stack traces for all threads) by following the instructions on How to get a stacktrace with WinDbg. In theory. I tried once and got about as far as you did.
The shareholder is always right.
That was a dump from window's sysinternals process explorer --
which is configured with the dll for the debugger you mention
(C:\Program Files\Debugging Tools for Windows (x64)\dbghelp.dll)
and with downloaded symbols in standard location
(C:\Symbols)
So....I might get more out of winDbg, but since procexp seems to use .dll and symbols, wouldn't be extremely convinced of the need to go about doing it in winDbg (though I have used it to examine kernel core dumps...(such joy!)...
the same