Slashdot Mirror
Apple To Phase Out 32-Bit Mac Apps Starting In January 2018 (macrumors.com)
Apple will be phasing out 32-bit apps with iOS 11, and soon the company will make the same changes on its macOS operating system. During its Platform State of the Union keynote at the Worldwide Developers Conference, Apple told developers that macOS High Sierra will be the "last macOS release to support 32-bit apps without compromises." MacRumors reports: Starting in January of 2018, all new apps submitted to the Mac App Store must be 64-bit, and all apps and app updates submitted must be 64-bit by June 2018. With the next version of macOS after High Sierra, Apple will begin "aggressively" warning users about 32-bit apps before eventually phasing them out all together. In iOS 11, 32-bit apps cannot be installed or launched. Attempting to open a non-supported 32-bit app gives a message notifying users that the app needs to be updated before it can run on iOS 11. Prior to phasing out 32-bit apps on iOS 11, Apple gave both end users and developers several warnings, and the company says it will follow the same path for the macOS operating system.
and write some code
Evil Apple making me type
Die in a Fire
It is nice that they can do it. It does mean though that they don't have a huge legacy base in business. Try this on Windows and what you would end up with is that businesses would just not upgrade to the new version of Windows that blocked 32 bit apps. Hell, we even have a handful of 16 bit apps circa 1992 and have to keep around some Windows 7 x86 version for these craptastic things. Almost everything we run in enterprise is 32 bit and the majority of it is several years old. Upgrade? No, it works - and the upgrades are $. A good chunk of the business treats software like physical plant. They build a refinery and expect it to run for at least 50 years. They buy software and it should run for that long too. Crazy, but nearly true.
Also it means I have to throw away my Core Duo based macs. This is a bit why, after using macs and OSX for 15 years that I have walked away from them. I can't keep up with the pace that Apple has set for consumers.
“Common sense is not so common.” — Voltaire
Mac Mini released in August 2007 and sold until it was replaced in March 2009.
“Common sense is not so common.” — Voltaire
It stops them having to ship 32 bit libraries that need constant maintainable, and take up space on the userâ(TM)s machine for no good reason.
Yes, there is more code and complexity in the OS to maintain, and more QA testing. Apple has always never hesitated to discontinue hardware or software that no longer justifies the effort needed to keep them.
steam windows is only 32 bit and there are lot's of apps that don't need 64 bit.
Also office 32 bit is still big due to add-ins / plug-ins.
The iPhone 5c is 32-bit and was only discontinued in September of 2015. iOS 11 will not work on it, and presumably there will be no security updates for the 5c as of the iOS 11 release date.
https://www.theguardian.com/te...
https://en.wikipedia.org/wiki/...
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The majority of Macs since 2006 have 64-bit CPUs. Apple doesn't allow some of them to boot into 64-bit mode, but I'm guessing recent versions of OSX have probably eliminated this.
They're removing support - phasing would require them to gradually remove it in steps.
How horrible Apple is for offering all those free updates (including the OS) as long as the hardware supports them. Rebooting after the update is so much trouble. Remind me which company you work for please, so I don't ever get a job there having to support that 10-20 year old hardware.
A 64-bit operating system, an archetype that is known widely by developers and IT to support both 32 and 64-bit, is now going to purposely block 32-bit when we all know it will work? You know what this really is right? I have tried to tell both Linux and Window$ communities either here or on Reddit a while back about how 64-bit was nothing more than a tactic to get people to buy new hardware. The dropping of 32-bit for Linux is what actually made me angry. Now that everyone has an iPhone, maybe people will start to see when they have to buy iPhone 7's or later because their iPhone 5's no longer get updates and services block them from their network. You could get a 6, but very few would. It's a sales tactic. On top of which, if you pay attention to this kind of thing, most security vulnerabilities certain agencies have developed software for or even Dirty Cow for that matter, are primarily 64-bit. I think Apple security is going to get much worse over the next year. With 64-bit you've got way too much going on to be able to monitor like you can a simple 32-bit because things like GPU, which hackers love because of it enables faster brute force attacks.
The ideal is an operating system that runs every app ever created for any notable platform. For security reasons, the opposite should be default, with only the most recent runtime installed and running. But convenient one step process should be provided to install other runtimes. There is a galore of open source emulation/virtualization solutions and sandboxing to mitigate security risks, so maintenance overhead is insignificant for the likes of Apple and Microsoft. Why would anyone not want an option to run apps they paid for?
We have a more than a few years old Mac at work.
It already can't update the OS, but it has 64 bit.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Apple already phased out 32-bit by making the programming tools 64-bit only on the developer side in 2014. When developers stopped supporting 32-bit apps with updates, I was forced to abandon my legendary black MacBook with a 32-bit processor. Linux Mint went on the MacBook and I switched to an inexpensive Dell laptop. The only 32-bit apps in the Mac store are by developers who are going the extra mile to support the older versions of Mac OS X.
So what happens to people with Macs more than a few years old? Are they SOL for new software?
Just look at what happened to PPC macs for your answer: yes.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
In enterprise, for desktop computers, a 10 year old upgrade cycle is not "absurdly short", it's the opposite. Most companies have support contracts, and will replace hardware when it reaches the end of that period, typically something like 5-6 years.
Have you got a specific example? They haven't sold a computer without x64 support since 2009. And El Capitan still runs on Core 2 Duo, so that's at least seven fucking years. What's the oldest computer you still use?
And unlike Windows, most Mac software doesn't need the latest OS. I am currently running 10.9 on my "daily driver" and have had no need to upgrade any farther. I have other computers with 10.10 and 10.11, but that's the way I got them. In fact, I have more need to keep a computer or two running 10.6 than I do anything else.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
> Apple switched to 64 bit in 2006 except for the mac mini, which switched in 2009.
The 2007 model had a 64-bit processor, and was supported up until El Capitan, which was years after OS X went 64-bit only.
Which is exactly the kind of problem Apple is trying to avoid by pushing hard for 64-bit.
The last 32 bit plugin will cease to have relevance approximately on the day when the 128 bit architectures start rolling out. This is not a problem you can avoid by pushing hard for 64 bit now. This has happened before, and it will all happen again.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I have NetBSD on an old iMac which works OK if you don't need graphics acceleration. :(
Apple made a lot of computers without discrete GPUs once Intel started including half-decent ones, so that may be less of a problem than you think. They didn't even make a mac mini with a discrete GPU after i5/i7, and they made a few MacBook Pro models sans GPU. (And the ones they made with GPUs had problems. NVidia made some crappy chips in 2010-2012, you basically have to replace it with a newer chip by hot-air rework)
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Just wait until next year, when Apple rolls out their new 65-bit OS and accompanying product line...
iBook G3 [1999] - in orange
Power Mac G3 Blue & White [1999]
iBook SE (FireWire) [2000]
12 iBook G3 (Mid 2002)
12" iBook G4 (Late 2004)
Mac mini G4 (Early 2005)
13" MacBook Core Duo (May 2006) 1.83 Ghz - yes 32-bit only x86, my first x86 laptop mac
Mac mini (Mid 2007) - my first x86 desktop Mac
MacBook White (Late 2008) - earlier MacBook died, was expensive enough to repair that I bought a new(refurb) one instead
Mac Pro "Quad Core" 2.8 [2008] - this venerable MacPro3,1 is still alive as a Win7 gaming machine. (another refurb)
13 MacBook Pro (Mid 2009) - current laptop, dual-boot OSX and Win7
Present - (hopped off the carousel)
I think that's all my Macs, not counting the Xserve G5's in colocation (running Debian now, PowerPC OSX is kind of a dead end now). I took a best guess at the chronological order because some of the Macs on the list above I bought used. I usually would buy used around the time their replacements were announced. So if x86-64 Core 2 Duo MacBooks came out in 2007 (I think?), I didn't buy one until around 2009-ish.
“Common sense is not so common.” — Voltaire
What apple should do is automatically cross recompile the old apps to work on the new hardware. There are a lot of old apps that are excellent but will never get updated, a great many for small business, games and a huge inventory of educational applications. Nobody else will bother to write a replacement but cause the original creator was inspired and it is a small market in many cases. Yet, they are still great apps. Apple is doing this again on both iOS and MacOS. This same problem has happened before when Apple abandoned earlier MacOS versions. They are nearly a trillion dollar company. They could easily put forth the effort to bring the old apps, all the way back to the Lisa, onto the modern operating systems with recompiling. Shame on Apple for creating deadwood.
For those who think it's too hard a problem, you're wrong. I'm a programmer and have written both compilers and cross compilers. You don't need the source code. If you have the final program you can run it through a cross compiler, a just-in-time compiler or just emulate to run it on different hardware. That list is in order of efficiency and preference. This is not a hard task. Apple has done it before.
Apple should be interested in doing this is it adds value for their customers because the software you use today will run tomorrow and because it maximizes the Apple application ecosystem which Apple likes to crow about in their marketing materials, ads, etc.
With the extraordinary computing power of todays devices this is all very easy and even emulated software can run faster than it did on the original hardware.
Imagine a world where all your old books, music, photos and other documents are no longer accessible because Apple and other companies drop support.
It is time for two pieces of legislation:
1) If a company or an individual wants to release a program they must also accept that their copyright and patents end within two years of their stopping supporting the software. Same thing for hardware. In other words, shorten the protection time dramatically. This will make it so other people can pickup the product and support it if they want to as fans or as another vendor.
2) If a company is above a certain threshold, which should be very low, then they must also release the supporting documentations for source code, maintenance, etc so that other people can pick it up.
3) If a company is at the high level of Google, Microsoft, Sun, Apple and the like then they must continue to offer legacy support for a minimum of 50 years in addition to #1 and #2 above.
"It stops them having to ship 32 bit libraries that need constant maintainable"
I thought the whole purpose of Apple programs was that everything was contained inside a disk image, thus negating the need to have libraries on the OS that need constant maintenance (and can't be easily exploited because they don't exist anywhere but inside the program code and not as a separate file on disk.)
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Pentium? Try the Pentium II, which was released in 1997, and had speeds of up to 450MHz.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
32-bit ios actually stands to be the first "lost platform" in computing history. EVER!
Hyperbole? Hear me out:
Unlike almost every other platform, there's no reliable and good way to run ios software (or ios itself) outside of the hardware. The only things that look like emulators are open source, and you can't even choose to install older versions of the OS on hardware past a cut-off date. Apple has fully DRMed their platform, fully closed it off. But up until now, if you have played by their rules, there's always been a way to run any given application: the expectation that your app can't be emulated well on Linux or whatever isn't something universal, so the computing consumer world has been pretty accepting of this.
This fully closed and cryptographically sealed system is something reasonably new in computing, and Apple's smashing success with it has encouraged others to duplicate it to some lesser degree- Windows 10S tries to take their model and offer a greater degree of freedom with an opt-out for cash (instead of no opt-out), Android has taken parts of their system, etc. But so far, everything has eventually (once it is no longer a primary economic driver) been emulated, been archived, been available for the future. Perhaps the loss of 32-bit ARM code compiled for ios is no great eternal loss to the world, but the precedent is now set for the expiry of code in a way that has never been done before.
And the reason to rip out support for 32-bit?
Testing.
Stability.
Memory Footprint.
There's 3 GOOD reasons for removing nearly-obsolete support.
Wrong. I do. I build my SDR app - which is a very complex thing - for 10.6.8 and up, and XP and up, is tested on all subsequent releases of both OSX and Windows, and (among other CPUs) on core 2 duo machines prior to release level issuance. It takes awhile, but mostly its rote testing using only slightly updated test suites, since I am long past requiring new OS calls.
Unless you actually need something from a later OS or CPU, there's no particular reason to target said CPU specifically, or to artificially inconvenience or lock out users of earlier hardware/OS (as Apple has done... the "Sierra won't run on these machines" business has been shown to be an artificial limit by software patches around the "oh no you don't" code that enables it to run just fine.)
In my case, a C2D provides (just barely) enough horsepower to run my app. Since it can, I see to it that it will. Further, since I have a 17" C2D macbook pro that still works fine (albeit running 10.6.8), it is always possible that some of my users do, or a C2D mini, as well. Many are still running 10.6.8 for certain, as I get a lot of mail / forum posts thanking me for keeping them covered. My app doesn't have a huge number of users - a few tens of thousands - but there are more than enough that my dev process has to cover a lot of OS levels and CPU types to be sure I'm not kicking someone downhill without any good reason. And yeah, I still carry that laptop around, and frankly, it pleases me that my app runs adequately on it.
Apple's move to 64-bit code is interesting. But unless the CPUs involved can't run 32-bit code, I rate choosing to obsolete applications people have bought or otherwise obtained legitimately to run on previous versions of the OS as pretty high on the scale of "Hey! Let's be fuckheads!" It's not like Apple is short of resources. If they want to support those apps, again barring impossible to address CPU-specific issues, they can. Which boils down to "Apple didn't have to screw you; Apple chose to screw you."
I've fallen off your lawn, and I can't get up.
This is an interesting one - their Pro base has a lot of music writers in it, and a lot of virtual instrements including major ones like Sylenth etc. are still 32bit only. Now previously there was a wrapper available that added a 64->32bit compatibility layer, but if I can't launch my 32 bit plugin at in the first place then such a wrapper is kind of pointless.
Could lose a lot of music production-related stuff this way.
The company I work for uses modern systems, a mix of Windows 7 and 10, however there is still some legacy software running in VMs. But besides all that, 20 year old hardware? Let me tell ya something. We have a whole fleet of HP LaserJet 2100 printers from the late '90s. We also have several newer printers. Guess which ones have weekly or even daily support tickets, vs which ones we only ever hear about when the paper runs out? That whole thing about "it just works" is absolutely true with older hardware still around, and that's WHY it is still around. And it is great that HP still produces drivers for the 2100 series printers, even for an OS as new a Win10.
If we could pump enough Reality Distortion Field gas into the Apple boardroom to convince them to switch the Mac to ARM we could cause them to scuttle the whole Mac line.
Oh, there would be true believers who would stick with Apple through it all. There are almost certainly people still running OS/2 if you look hard enough.
It *should* be far less painful to simply keep support around for it? It's not like keeping i686 support on an x86_64 distro is particularly hard, and with all the platform transition stuff that is in Apple's history, this is probably the easiest.
Hell, you could run pre-System 7 68k apps on PPC OS X systems 20 years later as a result of the Rosetta and Blue Box compatibility layers.
I really see this forced migration as a bit more of Apple's gradual decline. At one point, keeping all of these layers up and working would be seen as a point of pride and a welcome engineering challenge. Now the employees there seem just as caught up in the shiny/new as all the rest.
Hire a Linux system administrator, systems engineer,
You thought wrong, and if you thought for a few seconds more, you'd realise why what you're describing would be a terrible idea.
I am TheRaven on Soylent News
But why not allow 32 bit apps? If an app does not need a 64bit memory space or ints why not allow them to keep running? What about older games and software that you still find useful?
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
We decommissioned our last PowerPC Mac last year (2016). It was running one piece of legacy software that had a $10k upgrade price for an Intel edition. We switched software, so we didn't need the PC any more.
The PowerPC transition is actually notable for how smoothly it went. Universal binaries made it easy for developers to distribute Intel and PowerPC binaries at the same time. Previously, OS 9 "classic" compatibility was included for several revisions of OS X (we shut down our last classic-using-OSX machine around 2010).
Yes, when a computer vendor switches architecture, the older architecture is going to die sooner or later. No, Apple didn't screw anyone over, and the process went as smoothly as it could. Yes, it sucks if you bought a PowerPC Mac the day before the Intel switch.
you can build a parallel-port based 8-bit logic analyzer capable of sampling at around 100,000 samples/second, using only a db25 connector and wires. Doing it with USB requires moving all the sampling logic to the other end of the USB cable, and usually storing the data in a large SRAM buffer for subsequent "chunky" transfer to the host PC.
It's no harder than, say, building a sound card. In fact, a 16 bit 48 kHz stereo audio input device has to buffer and push 48,000 32-bit frames of data per second, which is twice the data rate of the 8 channel 96 kHz logic analyzer you describe. There are USB sound cards on Walmart.com for $6.
Does "the whole ecosystem" make up for the increased data cache misses and OOM kills that an existing device with 2 GB of RAM running software with 64-bit pointers would suffer compared to the same device running software with 32-bit pointers?
Supporting 10-20 year old hardware isn't tough.
It is if you're doing it right. So you're paying people to manually tend hardware that you probably can't buy replacement parts for, and which is orders of magnitude more power hungry (therefore hot therefore likely to break) per unit of work done than a modern system. That's OK, mind you, if you're talking about one machine that has an EISA card that you simply have to support to keep the business running - and if you have a stack of warehoused replacements you can drop it into. It's also probably OK if it's an ancient mainframe running your accounting system and you're willing to pay HP / IBM / whomever $$$$$ to keep it limping along, and you don't mind having your jobs run 20 times longer than they would on modern hardware.
Of course, neither of those circumstances are relevant to the subject of Apple deprecating old APIs (because the odds of you trying to run a business on a mission-critical Quadra card, or caring about desktop hardware if you're a mainframe wrangler, are approximately zero). The more likely options are that either you're "supporting" ancient PCs because your boss is penny wise and pound foolish, or you just really felt the need to rag on Apple and wanted to boost your credibility before you went in for the attack.
It didn't work.
Dewey, what part of this looks like authorities should be involved?
The dropping of 32-bit for Linux is what actually made me angry.
What? When do you imagine that happened?
A year ago, Canonical announced plans to drop 32-bit Ubuntu. 18.04 will ship no 32-bit kernel, and 18.10 will ship no 32-bit system libraries.
I can still run 32 bit binaries on my 64 bit Ubuntu system.
This is true in 18.04 and earlier, but in 18.10 and later, you will have to run 32-bit Linux in a virtual machine on 64-bit Linux. Running two kernels and a VMM requires more RAM than multiarch, which means more thrashing swap on machines with swap or more OOM kills on machines without swap. And many devices running 64-bit GNU/Linux still max out at 2 GB, unable to recognize larger SODIMMs plugged into a machine's sole RAM slot. Or would you recommend putting swap on an external RAM drive?
Then purchase the 64-bit version of Sylenth 18 months from now once Lennar Digital finishes it. I thought Mac users were used to re-buying software periodically after architecture transitions, that is, those from 68K-24 to 68K-32 to PowerPC to PowerPC (OS X) to x86 to x86-64.
Each doubling of bits is an exponential increase in memory, not just a doubling, of course. I'm thinking you aren't really cognizant of just how large an address space 64-bit allows you. It's a big difficult to imagine any consumer-facing applications such that 16 million terabytes of RAM isn't enough. Even the current CPUs on the market that "only" support 48-bit addressing can theoretically access 256 terabytes of RAM, which is still a staggering amount.
It's not me just being unimaginative, I think (i.e. like a certain famous-if-not-quite-true predictions about how much RAM anyone should ever need). There's a practical limit to the size of our data. A video file, for instance, only needs to get as big as necessary to approach the limit of human visual and audio resolution, and after that, it's just wasting space.
So, no, 64-bit is reasonably future-proof. I think its going to be a while before we start bumping up into those limits - maybe not even in our lifetimes. If we do move to 128-bit, it will probably be for reasons other than practical limitations.
Irony: Agile development has too much intertia to be abandoned now.
If we do move to 128-bit, it will probably be for reasons other than practical limitations.
Yep. And I think it will happen, just to be stupid. We can already handle 128 bit data types on some processors.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Can somebody explain why it's news now that they stop providing software for something, which more or less failed to get newest software for 6 years already?
This isn't about stopping shipping software for 32-bit processors, it's stopping shipping the 32-bit compatibility layer for 64-bit operating systems on 64-bit processors.
I am TheRaven on Soylent News
If there's a perfectly usable piece of equipment, they'll arbitrarily can its support.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
Unlike almost every other platform, there's no reliable and good way to run ios software (or ios itself) outside of the hardware.
After some thought, I do not agree - because you can always buy newer devices to run the same software, all app data is migrated. It's not outside the platform but it's not like you cannot move forward.
you can't even choose to install older versions of the OS on hardware past a cut-off date.
You can if you jailbreak it which you absolutely can for any 32-bit IOS device.
But why does that even matter? That seems irrelevant from a standpoint of being able to continue to use the device with the software that you have, which you can. You'll just stop getting updates after a while.
You give this grad sweeping statement of this being the only time specific binaries have been left to age. But there are very probably other niche platforms for which no simulators exist. Even for iOS some simulators do exist... so I'm not even sure that is correct.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
"Can you prove that it would produce a greater return on investment for Apple Inc. shareholders than not doing so?"
That isn't necessary. Apple does a lot of things that aren't proven to produce a return for shareholders. That is part of what makes Apple great. Basic research.
But you're missing the point. Jobs promised users they would continue to have access to their digital lives into the future. To do that requires legacy support.
It is entirely possible you're to young to remember.
"Even car companies aren't held to that standard."
Time to start.
Actually I wonder if we do not go for 96 bits, or 100 bits tagged memory, to support higher level languages.
128 bit address space pretty unlikely that mankind will ever have a use for that. On the other hand it probably costs nothing to jump from 64 to 128 and marketing guys might demand it.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Never heard about a Mac BookPro without a dedicated GPU.
Any examples?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Memory Footprint.
The memory foot print for a 32 bit Application is significantly smaller than for a 64 bit one.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
windows 10 64 bit can work on 64 bit cpu macs that can't run 64 mac os as they have an older 32-bit efi. And with the mac pro 4.1 it needs an firmware from 4,1 to 5,1 (base system platform hardware is just about the same and the 4.1 needs it run newer cpu's) hack to run newer mac os to get around the soft blocks.
*looks at every .DMG he has on the only OSX machine he has - a G5*
*Notes every single one of them comes with their own libraries or subsets thereof.*
Uhh, Yea. See, originally, Apple did that type of format so there wouldn't be a mess of files all over the system.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
It appears it may mean that some or all 32-bit APIs may be going away. So that's somewhat of a serious concern for me as it would break Qt's OS interface. Of course, there's always the VM route, which I expect to keep working until/unless VMWARE goes away. Oh, and Parallels, too. And the others.
I don't sell it, I give it away, and I have (and plan to have) no dealings whatsoever with Apple's app store. So no, not really a realization for me. :)
ARC: I manage my own memory. I have no need of ARC. I'm glad it's there for others in some versions of the OS, though. The problem I can't get around is that the OS itself leaks like a sieve. Still true as of 10.12. I always hope it'll be better with each new release, but not so far. If you want to unmask the worst cases of it, just turn off VM for a week and watch your memory consumption. Pretty sad.
My kernal_task is currently consuming 2.87 GB. By far the biggest wastrel. 14.52 GB of memory in use; except, no, it isn't. Also 9.25 GB cached, which, meh, I'm not too worried about performance boost caching, but some of that stuff hasn't been used in weeks. I'll have to reboot to clean it up, or fling purge at the system, which cleans up waaaay too much.
ABI: The problem here is that it means abandoning support for earlier OS's, and there's no actual reason to do that at this time. Particularly in that there is operating hardware in the field that Apple won't let run the new OS levels. Quite arbitrarily, too.
I will confess though... if Apple and the Qt people actually made a serious effort to clean up all the reported bugs instead of only the ones that have X>N reporters, they might be able to tempt me into a new build using the latest and greatest.
Unfortunately, both of them are a lot more interested in "shiny" than they are in "works like we claimed it works." They both habitually leave broken software systems unrepaired, while leaping into the future with the New Shiny. And besides... if they did fix all those bugs, I expect I'd get the benefit without building anew. The reason I say that is that builds that are 100% under Windows are less so under OS X. It seems very likely indeed that the problem is specific to OS X, especially considering how badly the OS leaks for pretty much everything app it runs. Including itself.
I've fallen off your lawn, and I can't get up.
I think it was the 15" i5 in 2011 and all 13" since 2011 that have only used integrated Intel graphics.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Memory Footprint.
The memory foot print for a 32 bit Application is significantly smaller than for a 64 bit one.
Memory footprint of the OS.
There are potential uses for more than 64-bit address spaces. I don't know that that will ever become an issue with RAM, but memory-mapping SSD storage could be useful. Given enough connectivity, it might become desirable to have an address space that includes IP addresses separately, so maybe 256 bits. My limited imagination is not coming up with any reason to go to 512 bits, though.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Open a terminal. Run otool -L on one of those binaries (you'll find it in the Contents/MacOS directory inside the bundle). Look at all of the libraries in /Library or /System/Library that they link to. Now look at the file sizes of those libraries. Now look at the Resources folder for each of the .framework bundles that contains those libraries. Now imagine if each of those disk images had contained a copy of those and if each running process had contained a separate copy of them, rather than a CoW shared version.
I am TheRaven on Soylent News