Slashdot Mirror
Mozilla Dropping 64-Bit Windows Nightly Builds For Now
hypnosec writes "Plans for 64-bit Firefox for Windows have been put on hold by Mozilla in a bid to concentrate more on the 32-bit version. Eliminating the 64-bit nightly builds was proposed by Benjamin Smedberg, a Firefox developer, last week. Some of the reasons Smedberg cited include missing plugins for 64-bit version; lack of windowproc hooking which facilitates smooth functioning of whatever plugins are available; and the inability to work on the crash reports submitted for the 64-bit versions because they were not on high priority. The proposal, it seems, has been accepted as is evident from this bug report."
The bug tracking system seems unable to differentiate between 64-bit and 32-bit builds, causing a few issues since Windows 64-bit builds are much buggier. They also intend to reintroduce 64-bit Windows nightlies some time next year.
One more cut in the side of Ballmer's monooly !!
Good thing I was convinced I needed a 64bit CPU and well over 4gb of RAM.
If only the software I used daily could actually use it...
I am not a programmer, I'm just a systems guy. I mainly use Mac and Linux, and 64-bit is something I've Just Done for some time now since the introduction of EM64T, however the few times I need to mess with windows the way it works with 64-bit just baffles me as to how 'hard' it seems to be and how 'little' 64-bit friendly / 64-bit stuff there is.
Why is that?
As a rock-in-roll Physicist once said, No matter where you go, there you are.
Remember when FireFox was "the browser to have"? A couple years of poor development is really killing it off.
I am not a developer. Can someone explain why making apps 64 bit for Windows is so difficult compared to other operating systems?
"They also intend to reintroduce 64-bit Windows nightlies some time next year."
Since Windows doesn't have pure 64 bit versions, there is little reason to insist on 64 bit Firefox. Unlike most other systems, almost all libraries have to be compiled into Firefox anyway so better ABI doesn't win you much, and going 64 bit has a significant memory cost -- for typical C++ code, around 33% extra.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
It's 'hard' only because it's a huge - yes really - number of lines of code. Gigantonormous numbers.
Pointers are the main reason why software don't port between 32 and 64 bit easily. It was the same in the transitions from 8 to 16 and 16 to 32. The power of C is being close to the hardware, with less overhead. The curse of C is being close to the hardware, being harder to move to new 64-bit hardware. This is a known trade-off and it's worth it. People who don't believe it write hardware independent Java code etc, and as observed, their software usually don't provide all the desired features, hence people stick with the software written in languages closer to the hardware.
I am not a programmer, I'm just a systems guy. I mainly use Mac and Linux, and 64-bit is something I've Just Done for some time now since the introduction of EM64T, however the few times I need to mess with windows the way it works with 64-bit just baffles me as to how 'hard' it seems to be and how 'little' 64-bit friendly / 64-bit stuff there is.
Why is that?
Because most programmers in the last 20 years of x86 PC development have used data structures that are designed for 32-bit systems and switching all of those to take advantage of (or even be compatible with) 64-bit systems is a challenge.
It's even only using 1.4gigs of RAM with 20 tabs or so open.
The switch from 32 to 64 is a lot less painful than 16 to 32, because the memory model didn't change.
Even if you are writing in C, most code is probably fairly agnostic to 32- vs. 64-bit. But if you do things like cast pointers to ints, or use byte-based arithmetic when interacting with structures or unions, then you'll run into trouble. C code that conforms to the standard should be fairly portable from 32 to 64 bit, though, and this is yet another situation where the value of the standard and well-designed code pays off.
this is where the programmer mantra of "dont reinvent the wheel" catches up to the real world. We have hotrods sporting flintstone rock tires because hey why reinvent the wheel? redo all the memory management and asorted libraries just so you can have more than 3gb ram? maybe next year.
remeber. 640k ought to be enough memory for anyone.
That naturally limits FF's RAM consumption to the 32bit address space. Bravo, they've reduced it by 90%+!
With OS X the main hurdle was to move from Carbon to Cocoa, as Apple dropped Carbon and never made it 64 bit. This took a couple of people a month or two at most.
So again, why is it so hard for Windows development?
The one point that I find quite laughable as a reason for stopping work on it is that there are not that many nightly 64-bit users.
Well, first, if you want to run 64-bit, you have to know that it exists in the first place. They offered a download link for awhile on the page where you could download the beta, Aurora and Nightly, but that disappeared over a year ago when I was rebuilding my computer. Not that that particular page was well known, either. I knew it was in the FTP site, I just had to look for it.
Yeah, I understand that the compiler has started putting out invalid code for the 64-bit version. OK, well then maybe the compiler needs to be changed or fixed then?
And browsers don't use more than 4GB?? Really?? I have the memory screenshot that shows me using 5GB of RAM under these nightlies. It happens every day and usually multiple times per day for me. It's not a bunch of tabs with media opened in them, it's one tab with Google Reader running for a few hours. Can't wait to see what happens when I switch to 32-bit, and I run out of memory before I run out of physical memory on my machine. And I've only got 8GB.
There will be a time when they HAVE to support 64-bit under Windows. They are talking about some point in 2013. I can't believe that a period of a few months is going to make it easier. There was a recent patch when they went from 19.0A1 to 20.0A1 that made the nightly unstable in a matter of minutes. Works in 32-bit mode, but doesn't in 64-bit. Is waiting nine months later after bad patches like that getting into the main code really going to help debug those bad patches?
Bryan
Firefox already runs 64 bit just fine -- over half of Debian installations are pure amd64. The problems here are caused by quirks in 64 bit versions of Windows only.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Mozilla use C++ not C which if written properly shouldn't have any issues. At work we just ported a giant (1M~ lines) C++ codebase to 64-bit and it only took us about two weeks -- most of which was spent cleaning up third party components which relied on C-isms.
Microsoft took a different approach because there is very little hardware abstractions in their code base even within the Win32 API. They run their code at a much more bare metal level and so you cannot run 64bit apps on a the 32bit version of windows even if you have a 64bit machine. Microsoft even has its own separate API layer that only exists on the 64bit version to run 32bit apps on it. OS X and possibly linux seem to be able to run other bitness apps pretty seamlessly.
Jesus was a compassionate social conservative who called individuals to sin no more.
Your answer doesn't work since Firefox for 64-Bit Linux has no issue. We need an explanation for why it's hard to code for 64-bit *Windows*.
The native Windows API was always a mess, and the 64 bits API is a case of "what were they thinking?!" even when compared to the other Windows ones.
Rethinking email
One thing that comes to mind is that afaict win64 is the only common platform where sizeof(long) != sizeof(void *).
I dunno if this is the reason for firefox's problems though or if it's just a case of noone caring to debug it.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Sysadmin for an SMB here. We develop our own browser-based app in Flash/Flex that we use for a big part of our work. It's also computationally intensive, and I was often being asked how we could improve the performance of the application on the client-platform side. Sure, we have decent hardware, but we were developing for the standard Firefox build, and that meant 32-bit and the restrictions that go with it.
Eventually I convinced the development team that since they had moved the backend to 64-bit code, that the client runtime environment should be there too, and so we optimized the frontend for Chrome (which obviously, is 64-bit, with Flash built in). The speed increase wasn't phenomenal, but it WAS noticeable. Now I'm even more glad we made this change.
If you want a 64bits version of Firefox, use Waterfox :)
http://www.waterfoxproject.org/
It's 'hard' only because it's a huge - yes really - number of lines of code. Gigantonormous numbers.
Not quite Gigantonormous, but it more than doubles some sections with tests to see if you're running in 32bit or 64 bit, then using the proper size of variables.
Pointers are the main reason why software don't port between 32 and 64 bit easily. It was the same in the transitions from 8 to 16 and 16 to 32. The power of C is being close to the hardware, with less overhead. The curse of C is being close to the hardware, being harder to move to new 64-bit hardware. This is a known trade-off and it's worth it. People who don't believe it write hardware independent Java code etc, and as observed, their software usually don't provide all the desired features, hence people stick with the software written in languages closer to the hardware.
To elaborate, pointers are variables which point towards specific places in memory, and are quite useful for passing data between functions (or even other programs) without having to copy the data. A 32 bit pointer can not point to any address space beyond the 32-bit limit (4GB), so 64 bit pointers are needed in 64 bit systems, assuming they have more than 4GB RAM (often including video RAM; found that out the hard way). If one source tree is used for both 32bit and 64 bit systems, there will be the endless if-statements that I mentioned above any place where pointers are defined (and in some cases, used). And of course it affects some bit shifting, etc. This is on top of endianness, which is a whole mess unto itself.
I am not a programmer, I'm just a systems guy. I mainly use Mac and Linux, and 64-bit is something I've Just Done for some time now since the introduction of EM64T, however the few times I need to mess with windows the way it works with 64-bit just baffles me as to how 'hard' it seems to be and how 'little' 64-bit friendly / 64-bit stuff there is.
Why is that?
I would contest the notion that Linux is more or less 64-bit "friendly" than Windows. They way both of those systems implemented concurrent 32/64-bit application support feels like a giant hack.
Solaris does it fairly well since it has had to handle multiple concurrent architectures for a lot longer, like SPARC/SPARCv9 :)
On 64-bit systems prior to Solaris 11, you can just boot back and forth between 32 and 64-bit kernels. With 11, they just dropped support for 32-bit systems I think, something Microsoft and Linux distributors should be jealous of
On Linux, if you had an application that needed a 32-bit system, and you had a 64-bit install, I'd tell you to reinstall a 32-bit OS. AFAIK you can't just boot it into 32-bit mode in any supported fashion. Then there's the weird way yum and kickstart work on a 64-bit install, I don't care what you say, THAT is far from flawless. There is almost no documentation on the bounds you should be within when messing with kickstart, and you easily wind up with builds that are not 32-bit app friendly.
Then I don't want to come across as a fanboy, but why everybody didn't do what Apple did with fat binaries or uh.. the whole experience is beyond me. The average Mac user didn't have to be aware of which architecture their system identifies itself as. I don't want to get into technical details, just that I see no reason whatsoever that Microsoft and Linux distributors couldn't have provided the same experience one way or another.
The sad part is that Apple and Oracle stopped selling 32-bit systems and moved on, and they had the best support for the architecture transition (both for earlier, non-Intel related reasons I'll give you). Microsoft and Linux distros still muck around in the last and do it wrong while they're at it, IMHO :\
As a Linux user, I find it quite strange and absurd, that nearly a decade after 64 bit processors were first built into consumer PCs, there still is some reason why somebody would not do 64 bit.
My Firefox on Linux has always been 64 bit. And back in the days, when the (by definition) shitty closed-source plugins, like Flash, still failed to be 64 bit, we simply put a nsplugin-wrapper around it, and the problem was solved.
This whole thing is silly. And as a programmer, I find it even more silly.
There just is no excuse for a 32 bit version to even exist anymore, unless you're completely and utterly incompetent as a programmer. (Obviously not including those programming for limited 32 bit embedded systems, etc.)
Yes, Mozilla devs. I mean you. You make us programmers look like idiots. Stop it. And stop making excuses to hide your FAIL.
If you use the right types in C there is no problem at all.
No endless if statements needed.
However the world is filled with idiots who mix integer and pointer types.
Secure messaging: http://quickmsg.vreeken.net/
lack of windowproc hooking
What? SetWindowLong[Ptr] hasn't gone anywhere in 64 bit Windows. If they are using SetWindowsHook[Ex], the bitness of the injected code has to be the same as the process, but this would be such a horrible approach anyway, I can't imagine that is what they are doing
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Good point. I don't know about XP/7 but Windows 95 used to pass a lot of 'handles' around which were actually pointers to internal data. If the size of the handles has changed, people may have been storing them as 32-bit integers and now discovering that they're a different size in 64-bit code.
If one source tree is used for both 32bit and 64 bit systems, there will be the endless if-statements that I mentioned above any place where pointers are defined (and in some cases, used).
Uh, really? Maybe I've got this wrong, but some any code I've written works just fine with all its myriad pointers when compiled in either 32bit or 64bit.
In fact, yes, hold on:
printf("%d",sizeof(int*));
returns 4 on 32bit and 8 on 64bit.
The only things I had to change in my code where some places where I'd used int as pointer offsets - I swapped those for size_t and everything was done.
systemd is Roko's Basilisk.
What? Fuck off... that's the browser I use to check my forums etc. in Windows (because it's a 64 bit build). Like I'm going to stay with alpha quality code that's no longer updating.
Oh well, if I have to use a 32 bit browser I guess it will be Google Chrome. (I don't use Firefox in Linux anymore, I do Chromium builds once a week or so)
I don't have a build environment in Windows, that's such a pain in the ass. I just have Windows for gaming, so I don't do that stuff.
I'm pretty much all out of uses for Mozilla Firefox. I don't even like it anymore, with the stupid things they've done and the user interface etc. They even keep removing about:config options.
OMG. Where will you get your untested, bleeding-edge technology now?
I find it laughable that you think this is a big deal.
Unless you're using Linux/GNU which is going on 20 years of being portable. For fuck sake they not only go 32-bit to 64-bit they go to completely different architectures like ARM.
The problem with Windows is that it's not just about ABI when you change architecture. If you go from a flavor of x86 to ARM you get a completely different API as well as a different ABI. Even if a function has the same name and parameters it's probably going to do something different. It becomes an unmanageable mess of #ifdef's if you try to reuse the same code. You practically have to have independent code bases for every architecture you try to go to on Windows.
[Microsoft's] windows OS is tied to the PC and to an old 32bit architecture which are both going to be deprecated soon.
You claim that the PC will be deprecated soon. What will replace the PC as a tool for medium-duty to heavy-duty creation of works of authorship, especially for software development?
... and here I used up all my mod points. I don't know what their problem is, it surely can't take much to keep it compiling for x64 under Windows.
I can almost understand why it took them so long to come out with a 64 bit flash plugin (for either platform) though. Imagine what a fuckstick mess that code base would be. It's proprietary, changed hands so many times, and the result is a 10 megabyte+ monstrosity of a library (my current 64 bit libflashplayer.so is 18 megabytes, lol). It was probably a bitch bastard to get to compile at first.
Firefox has no excuse for not having 64 bit builds available. (Yes, binaries. It's a different environment. More homogeneous, which makes it easier for them, but it's also not so easy for Windows users to set up a build environment to compile their own)
One thing that comes to mind is that afaict win64 is the only common platform where sizeof(long) != sizeof(void *).
Why is the program storing a pointer in a long instead of an intptr_t or a union?
what exactly is the difference between the two?
OSX didn't didn't magically recompile/emulate 64bit code. They embedded both 32bit and 64bit code into a single binary and selected the right one based on the target architecture; it wasn't free.
Windows drastically changes the behavior of functions when it goes to another architecture. It's not like other development environments where you can just recompile. You have to go to each API call and make sure it still does the same thing.
It was easier than that on Windows -- almost none of the APIs changed! You just switch the compiler to build 64bit. If your app didn't work, it was because some dumbass programmer wrote crappy code (e.g. assuming pointers are 4 bytes), not because Windows made it hard.
luser@HAL:~$ iceweasel -v /bin/sh -c iceweasel /usr/lib/iceweasel/firefox-bin /usr/lib/iceweasel/firefox-bin /usr/lib/iceweasel/firefox-bin: symbolic link to `../xulrunner-10.0/xulrunner-stub' /usr/lib/iceweasel/../xulrunner-10.0/xulrunner-stub /usr/lib/iceweasel/../xulrunner-10.0/xulrunner-stub: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xefc8e0b22b6eb68c983888da80a2264e9a91af52, stripped
Mozilla Iceweasel 10.0.11
luser@HAL:~$ uname --all
Linux HAL 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux
luser@HAL:~$ ps -ef | grep iceweasel
luser 1037 602 0 20:06 pts/3 00:00:00 grep iceweasel
luser 32247 32160 0 19:45 ? 00:00:00
luser 32248 32247 10 19:45 ? 00:02:04
luser@HAL:~$ file
luser@HAL:~$ file
In your face bitches !!!
p.s. :D
Because the person who wrote it (incorrectly) assumed that the size of a pointer would always be the size of a long.
DLL Hell and the closed source nature of most Windows code.
Lets say you have Windows App A, it has a tie in to Windows App B which uses licensed somecode32.dll. Unless the maker of somecode32.dll releases a somecode64.dll and Windows App B recompiled to 64-bit, Windows App A has to stay 32-bit. Since there is such an insanely huge install base of 32-bit programs that are still being used but not actively developed that Windows developers stick with the lowest common denominator.
The other half is development time in performance sensitive code that's been 'hacked' in such a way that it only works on 32-bit systems. The time involved to un-fluck it isn't worthwhile for a lot of developers to fix currently.
There are way fewer plugins for OS X than there are for Windows, and most of those have 32bit and 64bit versions.
If you switched to a newer OS or a newer Office suite or a newer Whatever and you *lost* functionality, would you be happy?
Most Windows plugins don't have 64bit versions, and many which have them aren't installed on systems (because they're distinct installations - would you appreciate downloading 10mb extra data you never use - monthly?).
But why would someone ever need to make that assumption?
I'm not sure why a 32-bit Linux application would need a 32-bit kernel? Unless it's poking deep in the guts of the system, in which it's most likely going to be tied to a particular kernel anyway.
32-bit linux applications need 32-bit glibc (or whatever libc/library they use) to run. Both the 32-bit and 64-bit versions can be installed on a 64-bit system just fine. Most of the time you'd run without the 32 bit libraries since you use lots more space with them, and until you get in to specialized programs, most come with 64-bit versions. On an application that doesn't use rpm, or some other packaging to tell you what libraries you need, you can be left guessing on what you need to install, I will give you that.
But thinking Windows is more friendly then Linux on 64-bit is insane. The whole capture the system call and write it to a different directory thing... verses /lib and /lib64. Yea.
A good justification for supporting 32-bit builds is supporting all those people still running 32-bit Windows. Call it lowest common denominator. You wouldn't understand backwards compatibility because Linux is shit in that arena, even Debian with it's "longer" release cycle. XP lasted so long, I'm sure that also delayed 64-bit adoption.
It's not a big deal in many cases whether an app is 32 or 64 bit. Firefox maybe it is because it's poorly architected and could do with a bigger memory space. In many cases there is no benefit from a native 64-bit app.
I'm afraid you can't really criticise anyway when when I can't run Lightroom on Linux, yet it runs for fine for me as a native 64-bit app on both Windows and OS X.
http://appdb.winehq.org/objectManager.php?sClass=application&iId=5839
I think first of all you're overstating this. It's not like porting to 64-bit Windows suddenly makes up down, and right into left. This is a huge exaggeration.
You're also understanding the differences on Linux. I remember porting a user mode application to PowerPC Linux in the 90s and a lot of things were missing. I've also heard horror stories about fragmentation on ARM.
And as a trivial example, just look at the list of syscalls in each arch. They diverge.
..because when a developer uses windows, they suddenly do really stupid shit.
/windows/system32/) .. it was the author of the electric sheep screensaver that did this really boneheaded thing. They wouldnt even dream of doing something like that under a *nix, but there they are doing it on windows...
.. which I suspect is likely considering their battle with memory leaks .. so it allocates an extra sizeof(awesomeness) and returns (byte *)pointer + sizeof(awesomeness) .. well thats fine in win32, but can break in win64 if the resulting pointer makes it way to a picky api that require alignment to the 16 byte boundary expected on 64-bit systems.
I recall a programmer porting from linux to windows that decided it was a good idea to install to and write data out to a system folder (I think it was
Anyways, I suspect many of the bugs in mozillas 64-bit build that arent in the 32-bit build stem from the fact that in win32 the malloc alignment is 8 whereas on win64 the malloc alignment is 16, and that some API calls expect pointers aligned to these.
So suppose they have a custom allocator that prefixes memory blocks with 8 bytes of awesomeness (reference count, etc..)
If the picky api raises an exception then its easy to troubleshoot and solve, but not all api's are allowed to throw exceptions at their callers, so instead they return an error code that was perhaps unexpected and thus maybe handled improperly and now its not an easy troubleshoot, instead its a debugging nightmare.
"His name was James Damore."
I started using the 64-bit version because the 32-bit version frequently hits 4GB of memory usage and crashes. I've seen the 64-bit version over 16GB on my 32GB system. This is a problem that Chrome does not have, but Firefox has some extensions I really like that Chrome lacks. As long as I can continue using the 64-bit nightly that I'm currently using I guess I won't really care, but this seems rather short-sighted.
Handles have indeed changed from 32 bit to 64 bit, but MS has promised that the value saved in the handle will never use more than 32 bits, so it is still "safe" to cast it into a 32 bit variable. However, it is bad practice.
The truth may be out there, but lies are inside your head
A Windows 8 tablet is still a PC; if the PC is deprecated, the Windows 8 tablet is also deprecated. A Windows RT tablet isn't useful for software development without a very expensive sideloading certificate.
But why would someone ever need to make that assumption [that sizeof(long) >= sizeof(void *)]?
Because a program was written prior to 1999 when C99 was finalized, or the program is for a platform whose most common compiler was slow to adopt the new integer types in C99.
I recall a programmer porting from linux to windows that decided it was a good idea to install to and write data out to a system folder (I think it was /windows/system32/) .. it was the author of the electric sheep screensaver that did this really boneheaded thing. They wouldnt even dream of doing something like that under a *nix, but there they are doing it on windows
What's the equivalent under Windows to /usr/share or /usr/bin or even /usr/local/share or /usr/local/bin? All Windows has for software packages that aren't part of the operating system is %ProgramFiles%, which is more like /opt in that it is divided by package at a higher level than by executable (.../bin) and non-executable (.../share) files.
On Linux, if you had an application that needed a 32-bit system, and you had a 64-bit install, I'd tell you to reinstall a 32-bit OS.
Sounds like you shouldn't be giving advice. The correct process is to install whatever 32-bit libs you need.
Not only can I run 32-bit Linux programs on 64-bit Linux without having to "reinstall a 32-bit OS", I can run 32-bit Windows programs (via Wine).
I start with Linux nearly 4 years ago, and even then the 32/64 issue was a solved problem.
Do what thou wilt shall be the whole of the Law
Some of the reasons Smedberg cited include missing plugins for 64-bit version; ...
So now at Mozilla, increased security is a bad thing?
syscalls aren't meant to be portable. That's why modern OSes include libraries.
this is a great post; thanks! Saltele
Haven't got a clue what you are talking about do you?
Looks like the costs of a "free" browser are pretty high. Best to just stick with IE, at least support doesn't get thrown out the window when it's not convenient.
Here's my prophesy:
Mozilla, specifically Firefox, will continue as a 32 bit package through Firefox 185.2, (due out in a few months). By the time 180 gets involuntarily pushed out, silently, to anyone who has ever run any version of Firefox, resources at Mozilla will have been quietly shunted away from Firefox on Windows and towards, in fits and starts, Boot to Gecko, A.K.A. FirefoxOS or whatever they're going to end up calling it. That will be 64 bit only. Sorry, if you still have a 386, you're screwed.
By the time Windows 8 SP1 is released, Firefox will announce their final MS Windows release, stating it no longer makes sense to devote developers' time and efforts to a dying, archaic dinosaur of an Operating System like Windows, especially one as unpopular as 8 will prove to be. A fork will then take place like the one that engendered LibreOffice, and a group of hackers will release LibreFox 5.0, returning Mozilla on Windows to a sane, intelligible release and versioning number schedule.
LibreFox will pick all the orphaned Firefox users up within 6 months, while Microsoft Internet Explorer 12 struggles to break back into double-digit market-share, after hackers around the world all standardize on developing, exploiting and then publicizing one major security flaw in Microsoft Windows and Internet Explorer every 24 to 48 hours, at random times of the day.
Following the surge in Android device sales, the slump in iOS and OS-X based systems sales, 2013 finally and truly is the year of Linux On the Desktop.
However, before 2013 is out, it is supplanted by ChromeOS and FirefoxOS, which become the Windows versus MacOS/X Holy War of the future, as Microsoft and Apple start long, slow, inexorable slides into irrelevance and oblivion, ultimately filing for bankruptcy protection circa 2018 (Microsoft) and 2023 (Apple). Apple is kept afloat longer as principally a purveyor of music, but even that becomes non-lucrative as artists finally master the art of RIAA-free promotion and distribution of their music, cutting Apple Middleman Corp. and the RIAA bastards out completely, leaving them to wither and die, finally, like a stinking, fetid, gangrenous appendage that has years since lost any function or usefulness.
Google Inc. files for bankruptcy protection in 2027 or 2028 as advertisers figure out that everyone is using Adblock anyway, and no one actually clicks on the sponsored links, or if they do, they don't actually buy anything anymore, since by this time everything is so cheap and disposable that product differentiation by brand becomes irrelevant. Google China has long since spun off, and becomes the world's largest company and employer.
The bitching of Chinese people reaches a fever pitch by 2048, as many patriotic Chinese start clambering for companies to start making available to them for purchase products made in the good ol' Chi N of A, instead of all the cheap, shitty products washing up on their shores like so much trash from third-world countries like the United States of America & Mexico, or its almost equally impoverished southern and northern neighbors, the primarily Spanish-speaking Confederation of Texahomiana, the mainly English-speaking Commonwealth of Canada and the French-only (by law!) speaking Republique d'Quebec. The trade flow will have taken on this character because of the combination of dirt-cheap labor since the abolition of labor unions, wage protection ordinances, environmental regulations, and an almost worthless North American New Peso, and the now-permanently depressed value of gold, (the only legal tender in Texahomiana, per the Texahomanian Constitution, that under its own first article, cannot be changed by anyone for any reason,) ever since scientists from United Korea figured out how to extract gold from sea-water as a byproduct of their fusion reactors' short-chain secondary and tertiary decay processes. (Too technical to discuss here.)
Meanwhile, the Japanese minority that resettled in 2024 in southern China, and along the eas
Actually, wouldn't that be extremely easy to debug? Just have the custom allocator pad with 8 extra bytes, and see if everything suddenly starts magically working.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Oops. Forgot something.
2215, one of the three predicted aforementioned events coincidentally does that which seemed formerly impossible, namely, it results in the effective cancellation, in the middle of its 227th season, of The Simpsons. As the end of all life as we know it will be fairly abrupt, the final episode will appear hastened, and millions of years from now, when distant aliens learn to send and receive radio signals, some might figure out how to decrypt our television signals, and end up watching so much of our television. They will be disappointed in the slap-dash, rapidly concluded series too. Maggie will still have had virtually no lines.
OSX didn't didn't magically recompile/emulate 64bit code. They embedded both 32bit and 64bit code into a single binary and selected the right one based on the target architecture; it wasn't free.
Feel free to continue pulling bullshit out of your ass. A 64bit binary will operate on 32bit Snow Leopard on a 64bit machine. This was done to support early 64bit intel machines running Leopard/Snow Leopard because they booted by default into 32bit OS X to avoid issues with missing third party drivers. You could force it to reboot into 64bit mode but some drivers for third party hardware would not be available. Anything like a "driver" had to be run in the appropriate kernel but applications compiled for 64bit could run on the 32bit kernel.
Jesus was a compassionate social conservative who called individuals to sin no more.
You would only try padding by 8 extra bytes if you knew that that was a problem to begin with, so no need trying it.. you just do it at that point. Its when you have no idea why the program is behaving incorrectly, not doing what its told, that its now a nightmare that does not suggest 'pad by 8 extra bytes in that custom allocator we wrote 6 years ago that never ever gave us a problem before'
"His name was James Damore."
I'm not sure why a 32-bit Linux application would need a 32-bit kernel? Unless it's poking deep in the guts of the system, in which it's most likely going to be tied to a particular kernel anyway.
32-bit linux applications need 32-bit glibc (or whatever libc/library they use) to run. Both the 32-bit and 64-bit versions can be installed on a 64-bit system just fine. Most of the time you'd run without the 32 bit libraries since you use lots more space with them, and until you get in to specialized programs, most come with 64-bit versions. On an application that doesn't use rpm, or some other packaging to tell you what libraries you need, you can be left guessing on what you need to install, I will give you that.
But thinking Windows is more friendly then Linux on 64-bit is insane. The whole capture the system call and write it to a different directory thing... verses /lib and /lib64. Yea.
Armchair Linux vs. Real World ... why are there still i386 distributions of the most recent Linux server distributions and Windows? They are not free to maintain. Why do you have to make a decision at all? There's no reason for a system install to come in the two different flavors. These vendors aren't doing it to spare a company some measly GB of disk space or download bandwidth for the 64-bit blobs you don't need. They aren't doing it because of the prevalence of 32-bit hardware in today's data centers either, they do it because big ISV's need it, and you can't install their systems ONCE and run them in 32-bit mode.
If Oracle or SAP says it runs on RHEL 5 i386, you install it on RHEL 5 i386, period. If there was ONE RHEL 5/6 install, and it could just boot into a 32-bit kernel, PROBLEM SOLVED, none of this "linux32 bash" workaround crap. I don't care how trivial it sounds, the reality is GO MOAN TO ORACLE, SAP AND OTHERS.
For Solaris and OS X, you didn't install 32-bit Solaris or 32-bit OS X, you just installed them. It booted into a 32-bit kernel if you needed it for whatever reasons. But that was the experience, ONE install.
"Capture a system call and write to a directory" - I'm sorry, WTF are you talking about? I can't find anything substantially different between how the two implemented x86_64 support.
Kill off the 32 bit version.
On Linux, if you had an application that needed a 32-bit system, and you had a 64-bit install, I'd tell you to reinstall a 32-bit OS.
Sounds like you shouldn't be giving advice. The correct process is to install whatever 32-bit libs you need.
Not only can I run 32-bit Linux programs on 64-bit Linux without having to "reinstall a 32-bit OS", I can run 32-bit Windows programs (via Wine).
I start with Linux nearly 4 years ago, and even then the 32/64 issue was a solved problem.
Get some real world experience with this.
RHEL6 i386 doesn't exist for shits and grins, it doesn't exist due to the plethora of old systems needing to run new software. It exists because ISV's need it. Four years ago you MIGHT have convinced me we still need new i386 OS installs because of some actual 32-bit hardware in use at the time. Today, forget about it. i386 Linux is probably 99% of the time running on x86_64 hardware today, and it's for applications that need it.
Four years ago, we should have been able to boot ONE RHEL install into either 64 or 32-bit mode as needed.
Disable Face Crook Message Stealer.
That is all. It especially looks stupid when facebook.com is blocked at the firewall
BLOAT Bitchez!
Get some real world experience with this.
AC Talks Out His Ass; News At 11
Sheesh, evil *and* a jerk. -- Jade
Am I the only one to discover that Firefox doesn't play well with my window manager after the 17.0 upgrade yesterday?
Can't resize any of the windows, and most come up tiny.
Sheesh, evil *and* a jerk. -- Jade
On my work PC I have Windows 7 x64, and starting with some version (somewhat like 14.0.2) FF had a serious bug in 32-bit version. It would just stall my computer after some time. Disabling plugins/extensions didn't help. Switched to x64 version and the problem went away.
The idiots causing the Firefox problem are another class of idiot altogether. Almost all JIT compilers used for browsers and the Java bytecode itself assumed a 32-bit address space. Linux had to introduce a horrible kernel hack which bids farewell to any hope of VM security to let all this shattered shit work. Some have improved and now can run without it.
Compiling is easy in a vacuum,
Fixing all the bugs introduced by the different compiler that you haven't worked around yet, then fixing all the issues due to the 64-bit plug-ins (esp Flash) having a different set of problems than the 32-bit ones, then fixing any remaining issues due to Windows-specific code possibly making dumb assumptions about sizes of things is a different matter altogether.
Which is why 64-bit nightlies _existed_. They just don't work that well, on average.
Then the question becomes whether to make (and test, which causes even more load on the test infrastructure) these builds, which no one plans to ship to actual end users anytime in the next 6+ months. That's what the discussion was really about: does Mozilla keep spending time keeping these builds limping even though they don't have the time to make them actually tier-1, or do they just stop doing them for now and start again when they have the resources to actually do it right?
I used to work with a guy like this. Last I heard he had to re-write (again) all of the code to take care of it. The solution was quite simple (I told it to him no less than 5 times). Yet he continued to do it the wrong way. Why was he doing it this way? Arrogance or stupidity I cant tell. He would not listen to anyone else about 'his project' (even though I wrote 50% of it and worked on it 5 years before him). When he is rewriting it again next year for some other reason and still having the same issues I will again tell him the solution and he will ignore it again. But what do I care he is the one who is pulling the 80 hour weeks to make it work as he is SURE he can make it work this time.
Talking about Oracle or SAP as a Linux problem is odd, they are professionals at making large, expensive, and at many times, very fucked up software.
Also, http://scn.sap.com/docs/DOC-28792
"Why does SAP de-support 32-bit server operating systems for new releases from 2007 onward?"
I think you may be suffering from a case of "I don't know what I'm talking about".
Then again, since I'm not an armchair administrator and work in the real world I tend to know the software requirements of both the 32-bit and 64-bit packages of the software we use for both Windows and Linux.
Maybe he's doing it for job security.
Table-ized A.I.
You are mixing up different things.
A 64-bit binary will work on Snow Leopard running a 32-bit kernel, because all the userland libraries it requires are available as 64-bit versions, embedded next to the 32-bit ones. As such, even Snow Leopard with the 32-bit kernel is not really a 32-bit system - it's supports 32-bit and 64-bit user land, and (by default) runs a 32-bit kernel.
Get some real world experience with this.
RHEL6 i386 doesn't exist for shits and grins, it doesn't exist due to the plethora of old systems needing to run new software. It exists because ISV's need it.
No, 32 bit software runs fine on 64 bit systems. It's exactly how mr_playboy described it.
64 bit capable cpus are certainly the norm now, but 32 bit cpus aren't quite as rare as you make it sound. What was it, 2007 or 2008 that most of the Intel chips sold for desktop PCs and Macs were finally x86_64 capable? Five years is a long time -- but it's not *that* long. Lots of those older boxes are still in service today.
As for people running 32 bit OSs on 64 bit hardware, there's a few reasons they do this. 1) On Windows, 64 bit can be a big pain, especially if you've got XP or older. 2) if your system has 3 GB or less memory, running a 64 bit OS doesn't really provide that much of a benefit, and can in fact perform more poorly than 32 bit code would (as 64 bit systems require more memory to do the same things, as pointers are twice as large.)
Perhaps there is some software that does work on i386 RHEL6 and not on x86_64 RHEL6 -- but I've never encountered it. You install the appropriate i386 libraries and stuff just works. The only place I'd expect that might have problems would be anything that's really low level -- kernel modules, for example. But even then, x86_64 is so popular now that anything that's still supported should be ported to both and should have been years ago. If you're running really old software that's no longer supported and it requires kernel modules -- then OK. (Though then the odds of it working on RHEL6 of any architecture seems to be quite low as well.)
In that specific example: because Microsoft doesn't do C99 and thus there is no intptr_t.
However in general it's just bad code, sometimes caused by bad programmers.
Solaris "solved" the 32 / 64 bit issue the same way OS X did: a 64 bit kernel with an entirely 32 bit userland. OS X doesn't do this anymore but OpenSolaris did for quite a while. I haven't checked if this is still the case in the most recent OpenIndianas. So the seamlessness that you are referring to is simply a matter of adopting one as opposed to the other. This also limits the total address space for any given process to be the 4 GB limit. This can be problematic for something like a CAD or 3D rendering package, in which consuming 5 or 6 GB even with just memory mapped IO is the norm.
And for what it's worth, all the people saying that chrome is 32 bit only, that is likely the case only for windows:
file /usr/lib64/chromium-browser/chrome /usr/lib64/chromium-browser/chrome: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
Even with all of the asm included in the chromium source code it can still be built cleanly as 64 bit. Of course the same can be said about the Linux versions of Firefox, I suppose. I too am baffled why 64 bit windows support is this complicated. When developing for Windows I find all sorts of weirdness between their 64 bit and 32 bit compilers. I found the 64 bit C compiler strict about where declaring string buffers (had to be at the beginning or it wouldn't compile). The 32 bit compiler of the same version of Visual C compiled and ran the code just fine.
If you're using C++ correctly, the move from 32 bit to 64 bit should be a re-compile. The trouble usually comes from programmers who do idiotic things like casting pointers to integers and who rely on unspecified or implementation-defined behavior.
I believe there's offset_t for offsets and size_t for sizes.
--Yep, I can confirm Linux Mint 14 is also running 64-bit Firefox natively:
$ file /usr/lib/firefox/firefox /usr/lib/firefox/firefox: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xbecff14f9dff514573ccdae8cbeb2c9ecf119c2e, stripped
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
There's still a 32-bit Windows?
"We live in a global world" - Harvey Pitt, former Securities and Exchange Commission Chairman
That or someone whose boss wants a port out now before one has a chance to finish reading the entire contents of the MSDN web site.
I'm actually rather surprised at how hard it is to get specific information on the ARM64 instruction set at this point. [...]
The ARM architecture supports physical address extension (PAE) with a 40-bit (1 TiB) physical address space. On ARM, as on x86, PAE potentially allows hundreds of GB of RAM but only 2 GB per process. Under Android, applications can share a process, but different publishers' applications run in separate processes. Though PAE-intolerant drivers for desktop peripherals have forced Microsoft to switch off PAE for desktop Windows, 32-bit versions of Windows Server support PAE on x86, as does Linux both on x86 and on ARM. So you might see Android devices using PAE long before they go 64-bit.