Linked by Thom Holwerda on Sat 3rd Feb 2018 14:15 UTC, submitted by Drumhellar
Mac OS X

When users attempt to launch a 32-bit app in 10.13.4, it will still launch, but it will do so with a warning message notifying the user that the app will eventually not be compatible with the operating system unless it is updated. This follows the same approach that Apple took with iOS, which completed its sunset of 32-bit app support with iOS 11 last fall.

This is good. I would prefer other companies, too, take a more aggressive approach towards deprecating outdated technology in consumer technology.

Thread beginning with comment 653461
To read all comments associated with this story, please click here.
Comment by ebasconp
by ebasconp on Sat 3rd Feb 2018 17:07 UTC
ebasconp
Member since:
2006-05-09

I would prefer other companies, too, take a more aggressive approach towards deprecating outdated technology in consumer technology.


Thom, why do you think 32-bit technology is outdated?

I understand we need databases to have access to more than 4gb (2^32) of RAM, animation rendering software, graphical software, etc. that needs to have huge amounts of RAM.

But our Angry Birds, a Sudoku game, our calendars, YouTube, all social media apps, etc. DO NOT need to address 4gb or RAM and in such cases, they are good staying as 32-bit apps.

64-bit apps can access more RAM and have more CPU registers available, BUT, the memory footprint of most applications is larger too because of pointers size being used intensively.

So, getting rid of 32-bit support is, IMO, only a way of saving money having less architectures to maintain.

Java 7+ has a nice workaround to have shorter pointers in 64-bit tech:

https://wiki.openjdk.java.net/display/HotSpot/CompressedOops

Reply Score: 10

RE: Comment by ebasconp
by zima on Sat 3rd Feb 2018 23:47 in reply to "Comment by ebasconp"
zima Member since:
2005-07-06

64-bit apps can access more RAM and have more CPU registers available, BUT, the memory footprint of most applications is larger too because of pointers size being used intensively.

[...]

Java 7+ has a nice workaround to have shorter pointers in 64-bit tech:

https://wiki.openjdk.java.net/display/HotSpot/CompressedOops

Hm, and IIRC there was some ~Linux effort to have system/apps which can use additional "64-bit" CPU registers but without the memory overhead of "full" 64-bit apps...

Reply Parent Score: 2

RE[2]: Comment by ebasconp
by ssokolow on Sun 4th Feb 2018 06:51 in reply to "RE: Comment by ebasconp"
ssokolow Member since:
2010-01-21
RE[2]: Comment by ebasconp
by sydbarrett74 on Tue 6th Feb 2018 01:59 in reply to "RE: Comment by ebasconp"
sydbarrett74 Member since:
2007-07-24

Hm, and IIRC there was some ~Linux effort to have system/apps which can use additional "64-bit" CPU registers but without the memory overhead of "full" 64-bit apps...

https://en.wikipedia.org/wiki/X32_ABI

Reply Parent Score: 1

RE: Comment by ebasconp
by Poseidon on Sun 4th Feb 2018 12:02 in reply to "Comment by ebasconp"
Poseidon Member since:
2009-10-31

On a compiler level and a software engineering level, it's easier to maintain only the newer architectures (especially for security) and the advantages of 64 bit and up instructions instead of the older instructions will make software even better once it is left behind.

It's not only about memory, but speed of processing and security.

Updates can also be released quicker because there's less testing and compatibility required, whilst IDEs can move beyond 1990s too...

I don't know about you, but when you install Visual Studio (latest and greatest), you need to install a lot of legacy support software just to build UWP, so yeah.

Reply Parent Score: 1

Why are they still Here...
by dionicio on Sun 4th Feb 2018 17:58 in reply to "RE: Comment by ebasconp"
dionicio Member since:
2006-07-12