Apple knows better than 32-bit
-
@El_Heffe said in Apple knows better than 32-bit:
@loopback0 said in Apple knows better than 32-bit:
@kazitor said in Apple knows better than 32-bit:
Why is "old" exempt from "supported"?
At some point you've got to stop supporting stuff.
In many cases, that's a bullshit argument. "Support" and "Don't deliberately break something for no good reason" are two entirely different things.
At home I still use Microsoft Office 2003. It works, it does everything that I need and it runs just fine with the latest version of Windows 10. I seriously doubt that anyone at Microsoft is running tests on the latest release of Windows 10 to see if Office 2003 still works. As a result, Microsoft's cost of "supporting" Office 2003 is exactly zero.
This is soooooooooooooooo wrong. Microsoft spends shittons of effort maintaining compatibility with Windows applications. That's their cost.
Because API interactions are complex, any OS will need such effort to keep applications working. Applications may need such effort depending on how they were written and how things evolve.
-
@dfdub The entire goddamn premise here is that some company depends on that product to keep their things running. Which should translate into monetary incentive. If companies need a product that does X, there should be well-supported products that do X. That's all I'm saying.
-
@dfdub said in Apple knows better than 32-bit:
@anonymous234 said in Apple knows better than 32-bit:
@admiral_p I don't know the details but backward compatibility always has some downsides.
More importantly, by breaking old programs you're sending a message that you won't bend over backwards for them
@anonymous234 said in Apple knows better than 32-bit:
Why is the software industry failing to maintain so many products
You do see the contradiction here, don't you? Pretty ironic that you posted these two statements within two minutes.
No I don't fucking see the contradiction. Apple breaks things that were not meant to be used OR things that are very old and have a new thing to replace it with. They're not dropping out of the OS market.
-
@anonymous234 said in Apple knows better than 32-bit:
The entire goddamn premise here is that some company depends on that product to keep their things running. Which should translate into monetary incentive. If companies need a product that does X, there should be well-supported products that do X.
Companies need a product that does X, but they're not actually willing to spend money on them. Windows 10 has been out for four years, and just how many companies are still on Windows 7 (or older)?
-
@loopback0 said in Apple knows better than 32-bit:
@Vixen said in Apple knows better than 32-bit:
why do companies go out of business and leave their customers with products that will never again get an update, or new version, yest is critical to the customer's business so that the cost of replacing it, if there is a suitable replacement, is sufficiently high that it is not only cheaper, but safer, to leave the old piece of software intact?
If a piece of software is that critical then keeping using something that's unsupported and no longer receives things like security updates is a major risk to the business and it should be replaced.
Just a few years ago I did a short contract for a company still using PDP-11 mainframes.
-
@dcon said in Apple knows better than 32-bit:
What timing... Raymond talks about compatibility...
Why are timer IDs and dialog control IDs 64-bit values on 64-bit Windows? Did you really expect people to create more than 4 billion timers or dialog controls? - The Old New Thing
Anywhere it's possible to put a pointer, somebody will try to put a pointer.
I'm always astonished the lengths Windows goes to in order to accommodate developers
-
@error How "fast" is a PDP-11 today anyway?
-
@admiral_p Well, it wasn't running any modern bloated software, so it wasn't terribly slow. IT ONLY SUPPORTED CAPITAL LETTERS THOUGH and that annoyed me.
-
They fucked it up so bad, they're affecting windows users.
YNAB 4 Support Ends October 2019 | YNAB
Apple announced that its newest Operating System, called Catalina, will not support 32-bit apps. YNAB 4 is most definitely a 32-bit app.
However, Apple announced that its newest Operating System, called Catalina, will not support 32-bit apps. YNAB 4 is most definitely a 32-bit app, meaning if you upgrade your Mac to Catalina, YNAB 4 will not open.
Ouch.
Because our support team uses primarily Macs, the Catalina upgrade means they will no longer be equipped to open, access, or troubleshoot for YNAB 4, even if you are using a device other than a Mac. This news forced us to make some hard decisions.
As of October 31, 2019, we will no longer be able to support YNAB 4.
-
@error said in Apple knows better than 32-bit:
@dcon said in Apple knows better than 32-bit:
What timing... Raymond talks about compatibility...
Why are timer IDs and dialog control IDs 64-bit values on 64-bit Windows? Did you really expect people to create more than 4 billion timers or dialog controls? - The Old New Thing
Anywhere it's possible to put a pointer, somebody will try to put a pointer.
I'm always astonished the lengths Windows goes to in order to accommodate developers
And this is why I actually liked Microsoft before they offshored the CEO position. I was always impressed that Microsoft software not only "just worked" but kept on working for many years. That, along with their extremely accessible documentation on MSDN, really impressed me. So often I had no clue what Linux people were so upset about.
The Saddam Nutella happened.
-
@Gąska said in Apple knows better than 32-bit:
@Mason_Wheeler said in Apple knows better than 32-bit:
It's a good part of the reason why the Mac's market share has always been abysmally low compared to Windows.
I'd say price is 99% of the reason.
I'd say price is... closer to 30% of the reason. A lot of people are willing to pay for good quality. But the purpose of a computer is to run software. If the software isn't there, because you fail at being attractive to developers, then no one is going to want your hardware because they have nothing interesting to do with it.
-
@dangeRuss said in Apple knows better than 32-bit:
They fucked it up so bad, they're affecting windows users.
YNAB 4 Support Ends October 2019 | YNAB
Apple announced that its newest Operating System, called Catalina, will not support 32-bit apps. YNAB 4 is most definitely a 32-bit app.
However, Apple announced that its newest Operating System, called Catalina, will not support 32-bit apps. YNAB 4 is most definitely a 32-bit app, meaning if you upgrade your Mac to Catalina, YNAB 4 will not open.
Ouch.
Because our support team uses primarily Macs, the Catalina upgrade means they will no longer be equipped to open, access, or troubleshoot for YNAB 4, even if you are using a device other than a Mac. This news forced us to make some hard decisions.
As of October 31, 2019, we will no longer be able to support YNAB 4.
They had 2 year's notice to do something. There are at least two ways to run Windows on a Mac. Even without this happening, not having Windows machines available when supporting a Windows application is
.
I think the developer is using this as an excuse to move as many people as possible onto their new version.
-
@Vixen said in Apple knows better than 32-bit:
and the truth is that in the business world it only takes ONE piece of software failing to work on the next OS upgrade for the upgrade to be scuppered.
That's one of the main uses for a VM. It's much easier to virtualize the old config than it is to port it to something new. (Of course, it also means that all the old problems hang around forevermore too...)
-
@Unperverted-Vixen said in Apple knows better than 32-bit:
@anonymous234 said in Apple knows better than 32-bit:
The entire goddamn premise here is that some company depends on that product to keep their things running. Which should translate into monetary incentive. If companies need a product that does X, there should be well-supported products that do X.
Companies need a product that does X, but they're not actually willing to spend money on them. Windows 10 has been out for four years, and just how many companies are still on Windows 7 (or older)?
That’s because they need a product that does X=work.
-
-
@admiral_p I recently visited the Deutsches Museum in Munich where one part of the exhibition showed the inner workings of computers. They demonstrate, for example, how to do AND/OR/NOT/... with mechanical, relais, electron tubes and transistors. Looks like this:
Anyway, they also had this old Cray sitting there. Looks nice at the front:
And then you look at the back and wonder how anyone got this thing ever to work. You also don't wonder anymore why those beasts were so expensive.
Holy Gordian Knot of Electrical Wiring Batman!
-
Cray Research, Inc. helpdesk, how may I help you?
My Cray stopped working.
Have you checked if there is any wire loose?
-
@Gurth Would also make a funny variant of those bomb defusal situations in movies:
Just cut the wire!
Which one? There's about a thousand of them!
The white one!
They're ALL white!
-
@levicki Despite being faster.
-
Anyone surprised by this doesn't know Apple.
OS9 emulator lasted a few versions of OSX before they killed it
PPC emulation lasted a few versions after they moved to intel
32 bit has been killed a few versions after they stopped selling 32 bit hardwareApple have always been against backwards compatibility. They support legacy stuff for long enough for a decent amount of software to be updated and screw anyone relying on something that hasn't been updated
-
FWIW, I checked on my old Mac laptop to see what 32 bit applications were present. They were:
- Old versions of Apple applications. I assume that if I updated, they'd be 64 bit (or gone/replaced).
- An old copy of Microsoft Office.
- Bits and pieces that I've not used in many years, like stuff to support Webex and other videoconferencing systems. (Those can die! They will not be missed.)
Nowhere on that list is anything I've built myself.
-
@dkf said in Apple knows better than 32-bit:
like stuff to support Webex and other videoconferencing systems. (Those can die! They will not be missed.)
Unfortunately also available in 64-bit, otherwise it'd be the top reason to upgrade.
-
@Jaloopa said in Apple knows better than 32-bit:
OS9 emulator lasted a few versions of OSX before they killed it
Every time I see lines talking about MacOS 9 like this, I think of something else.
(Disclaimer: many many moons ago, I ran OS-9 on my CoCo, which is why I tend to think of it.)
-
@Rhywden said in Apple knows better than 32-bit:
And then you look at the back and wonder how anyone got this thing ever to work. You also don't wonder anymore why those beasts were so expensive.
They were less expensive than the AC system / cooling plant you needed to install to stop them melting the building. The logic circuits were ECL, which is notable for two things:
- Very smooth power consumption because it's a current-steering logic.
- Very high power consumption because it's a current-steering logic.
Essentially, ECL circuits draw full power all the time and just direct it to different places, so they don't produce ugly spikes in the power supply, but in exchange, they generate heat like it's going out of style.
-
@levicki said in Apple knows better than 32-bit:
@dangeRuss said in Apple knows better than 32-bit:
They fucked it up so bad, they're affecting windows users.
So you are blaming Apple for YNAB's decision not to spawn VMs on their Macs to be able to keep supporting their own 32-bit software?
Yeah, I found that a bit weird from that company too. Either they could keep one or two of their Macs on an older OS version, or just run a VM; in either case they can still handle support for the old version. It looks more like Apple just handed them a good excuse to stop supporting it.
It was announced years ago, several times. It was slowly phased out over the last few OS updates, yet people are still complaining how "all of a sudden" Apple killed 32 bits and surprised both the developers and users?
If you’ve been a Mac user for the last few years, it cannot have been a surprise to you that some of your applications will stop working in the near future.
-
@Steve_The_Cynic said in Apple knows better than 32-bit:
The logic circuits were ECL, which is notable for two things:
- Very smooth power consumption because it's a current-steering logic.
- Very high power consumption because it's a current-steering logic.
You forgot to mention their main advantage: ECL was a lot faster than the "standard" TTL and CMOS logic of the time.
-
@Gurth said in Apple knows better than 32-bit:
Yeah, I found that a bit weird from that company too. Either they could keep one or two of their Macs on an older OS version, or just run a VM; in either case they can still handle support for the old version. It looks more like Apple just handed them a good excuse to stop supporting it.
I think that's probably the main reason - they want to drive people to the web app, which I believe they can charge for monthly, meanwhile YNAB4, they are stuck supporting even though people just purchased it once, years ago. There's no reason they can't get a windows machine to support it, or even a VM out on amazon. There's no need to be on a Mac, like ever.
-
@dangeRuss said in Apple knows better than 32-bit:
There's no reason they can't get a windows machine to support it, or even a VM out on amazon.
There's no reason they shouldn't have had access to Windows already, on a Mac or otherwise.
Supporting a Windows product without Windows is just stupid, regardless of what Apple choose to do with a different operating system.
-
@Zerosquare said in Apple knows better than 32-bit:
@Steve_The_Cynic said in Apple knows better than 32-bit:
The logic circuits were ECL, which is notable for two things:
- Very smooth power consumption because it's a current-steering logic.
- Very high power consumption because it's a current-steering logic.
You forgot to mention their main advantage: ECL was a lot faster than the "standard" TTL and CMOS logic of the time.
True, although that's not really relevant to the cost of the cooling plant, except that it explains why people put up with it.
-
@Unperverted-Vixen said in Apple knows better than 32-bit:
@anonymous234 said in Apple knows better than 32-bit:
The entire goddamn premise here is that some company depends on that product to keep their things running. Which should translate into monetary incentive. If companies need a product that does X, there should be well-supported products that do X.
Companies need a product that does X, but they're not actually willing to spend money on them. Windows 10 has been out for four years, and just how many companies are still on Windows 7 (or older)?
I'd have updated to Windows 10 LTSB years ago, but the cost of staying on Windows 7 has so far been lower than an Enterprise Volume Licensing Agreement. I'd be willing to shell on an upgrade, but not quite that much. And the lost productivity from what Windows 10 machines we already have at the workplace just keeps on pissing people off.
The other alternatives are Linux and whatever that FOSS-OS-made-around-Win32API was called. The the former is not compatible with way too much existing tooling (embedded IDEs are all 32bit Windows-only, and a scary amount of the other tooling doesn't have any FOSS replacement, even in theory). The latter was deemed a bit too immature to trust continuation of the business on.
-
@acrow if you mean Haiku OS or whatever it is called, it's basically Wine kicked up a notch and is little more than a pet project. Linux + Wine on the other hand can work quite well by experience. Would I run a business on it? Not really, but I would still test it thoroughly because lots of stuff does work perfectly or close to it. If Windows apps were limited to a very small subset and Wine happily took care of them, why not.
-
@admiral_p said in Apple knows better than 32-bit:
@acrow if you mean Haiku OS or whatever it is called, it's basically Wine kicked up a notch and is little more than a pet project. Linux + Wine on the other hand can work quite well by experience. Would I run a business on it? Not really, but I would still test it thoroughly because lots of stuff does work perfectly or close to it. If Windows apps were limited to a very small subset and Wine happily took care of them, why not.
No, the one that’s WINE is ReactOS. Haiku is based on the old Be OS, to the point where it's apparently binary-compatible for some binaries.
-
@Steve_The_Cynic said in Apple knows better than 32-bit:
@Anonymous-Throwaway said in Apple knows better than 32-bit:
@kazitor said in Apple knows better than 32-bit:
@loopback0 said in Apple knows better than 32-bit:
How much software has been broken that wasn't already old?
Why is "old" exempt from "supported"?
Uh, what actually fatally changed in Catalina (god I hate these names — it’s version 10.15) which isn’t trivially easy to recompile for (IIRC if a Cocoa program can’t be directly recompiled it’s doing something actively stupid, like casting pointers to other data types) is that support for the Carbon API has been removed.
So what if it's "trivially easy to recompile for"? When you recompile for a different architecture / environment, you have to retest everything. (Everything got compiled in a new way that it was never compiled in before, so everything must be assumed to be broken. When I rebuilt a pile of embedded software for the same hardware but a different compiler of the same language one time, with less than 64KiB of compiled code including the runtime library, I had to write a detailed test spec for it, which consumed 35 pages of A4.)
Nevertheless: debugging a Cocoa program which got switched from 32-bit to 64-bit is largely going to be verifying that things still behave as they did before. I was going to say that there were no changes which would need to be made to make code compile, but found that that's technically incorrect: back in 10.5 — which, remember is ten OS versions ago — when they published the 64-bit Cocoa specification, they changed numerical return types from int and float to the then-newly-declared NSInteger/NSUInteger and CGFloat, which — in the 64-bit API — are long/unsigned long and double, but int/unsigned int and float in the 32-bit API so that existing 32-bit binaries would be compatible.
So okay, yes, to make a Cocoa program 64-bit compatible, you’re going to need to change some variable declaration types, unless you passed return values directly to other functions.
And this is TDWTF, where we, er, "celebrate" programs that do actively stupid things.
Yes, but in that case the whole premise of the thread, that this is somehow a flaw on Apple’s part, is wrong. The stupid isn’t them.
-
@Anonymous-Throwaway said in Apple knows better than 32-bit:
the 64-bit Cocoa specification, they changed numerical return types from int and float to the then-newly-declared NSInteger/NSUInteger and CGFloat, which — in the 64-bit API — are long/unsigned long and double, but int/unsigned int and float in the 32-bit API so that existing 32-bit binaries would be compatible
Unless your code doing something actually demanding, in which case it damn well needs to know exactly how wide the variable is. But for those cases, the smart choise has long been (u)int32_t et.al....
-
@admiral_p https://wiki.winehq.org/FAQ#Can_I_use_Wine_to_install_drivers_for_my_hardware.3F
The debugger's driver is the first bit of what I meant by:
scary amount of the other tooling doesn't have any FOSS replacement
That's the tip of the iceberg. Everyone and their mother made their hardware drivers Win32-only up 'til recently. And that ship is not going to turn until
Win32 is no longer availableWinXP stops working in VMs.
-
@acrow said in Apple knows better than 32-bit:
@admiral_p https://wiki.winehq.org/FAQ#Can_I_use_Wine_to_install_drivers_for_my_hardware.3F
The debugger's driver is the first bit of what I meant by:
scary amount of the other tooling doesn't have any FOSS replacement
That's the tip of the iceberg. Everyone and their mother made their hardware drivers Win32-only up 'til recently. And that ship is not going to turn until
Win32 is no longer availableWinXP stops working in VMs.Amusing (if you're amused by such things(1)) anecdote...
I recently installed WinXP (32-bit, SP2 included) in a VM. It couldn't reach Windows Update nor the WGA thing to activate itself.
Why?
Well, my UTM/IPS firewall shouted and screamed and kicked up an unholy fuss about the VM sending HTTPS connections using SSLv2, and the stuff that survived that was using either expired certificates or certificates that were impossible to verify because XPSP2 had never heard of the new root CAs. Which it couldn't download because the code that was trying to do that was trying to use SSLv2 and being blocked by the UTM.
(1) I'm amused by such things when they break things for other people, or when my thing that breaks is a speculative "what happens if" experiment. Fortunately, it wasn't anything serious.
-
@Anonymous-Throwaway said in Apple knows better than 32-bit:
@Steve_The_Cynic said in Apple knows better than 32-bit:
@Anonymous-Throwaway said in Apple knows better than 32-bit:
@kazitor said in Apple knows better than 32-bit:
@loopback0 said in Apple knows better than 32-bit:
How much software has been broken that wasn't already old?
Why is "old" exempt from "supported"?
Uh, what actually fatally changed in Catalina (god I hate these names — it’s version 10.15) which isn’t trivially easy to recompile for (IIRC if a Cocoa program can’t be directly recompiled it’s doing something actively stupid, like casting pointers to other data types) is that support for the Carbon API has been removed.
So what if it's "trivially easy to recompile for"? When you recompile for a different architecture / environment, you have to retest everything. (Everything got compiled in a new way that it was never compiled in before, so everything must be assumed to be broken. When I rebuilt a pile of embedded software for the same hardware but a different compiler of the same language one time, with less than 64KiB of compiled code including the runtime library, I had to write a detailed test spec for it, which consumed 35 pages of A4.)
Nevertheless: debugging a Cocoa program which got switched from 32-bit to 64-bit is largely going to be verifying that things still behave as they did before.
Sorry, I didn't mention debugging. Debugging happens after the tests fail. The tests are done by QA people, not programmers. (Well, notionally, anyway.)
And this is TDWTF, where we, er, "celebrate" programs that do actively stupid things.
Yes, but in that case the whole premise of the thread, that this is somehow a flaw on Apple’s part, is wrong. The stupid isn’t them.
Oh, I agree that the stupid here isn't Apple. They've given people plenty of warning about this, just like they did for two key changes on iOS, 64-bit and IPv6. All apps in the App Store must have 64-bit builds, and all of them must work in an environment where there is IPv6 and not IPv4. They started moving developers toward that long before they made it mandatory. (And the notifications to the iThing user were similar and therefore largely incomprehensible to developers.)
-
@acrow said in Apple knows better than 32-bit:
@Anonymous-Throwaway said in Apple knows better than 32-bit:
the 64-bit Cocoa specification, they changed numerical return types from int and float to the then-newly-declared NSInteger/NSUInteger and CGFloat, which — in the 64-bit API — are long/unsigned long and double, but int/unsigned int and float in the 32-bit API so that existing 32-bit binaries would be compatible
Unless your code doing something actually demanding, in which case it damn well needs to know exactly how wide the variable is. But for those cases, the smart choise has long been (u)int32_t et.al....
If your code is doing heavyweight numerics on Cocoa and focussing on performance, then you would presumably be using SIMD rather than individual math operations. (I admit, though, that OpenCL didn't come out until a year after 10.5, so that might have been tricky on the first release… then again, Apple was the one to design OpenCL so there may have been some kind of not-yet-called-OpenCL API in 10.5; I'm not going to go try to dig through old developer documentation to find out.)
And as for "your code has to know exactly how wide the variable is": we're mostly talking about GUI function call return values. If you’re dumb enough to use custom OS types to do heavy-duty math, you deserve lousy performance.
-
@Steve_The_Cynic said in Apple knows better than 32-bit:
my UTM/IPS firewall shouted and screamed and kicked up an unholy fuss about the VM sending HTTPS connections using SSLv2
..... you know........ that sounds like your firewall is a biiiiiiiiiiiit overly paranoid if it's blocking outbound SSLv2 entirely, Sure that's no longer secure, but if you're going to block that because it ain't secure why are you letting regular HTTP traffic through? That shit ain't secure either.
I totally get rejecting incoming connections from SSLv2 and earlier, but to scream and block outgoing connections just seems like tinfoil hat territory.
-
@Vixen said in Apple knows better than 32-bit:
@Steve_The_Cynic said in Apple knows better than 32-bit:
my UTM/IPS firewall shouted and screamed and kicked up an unholy fuss about the VM sending HTTPS connections using SSLv2
..... you know........ that sounds like your firewall is a biiiiiiiiiiiit overly paranoid if it's blocking outbound SSLv2 entirely, Sure that's no longer secure, but if you're going to block that because it ain't secure why are you letting regular HTTP traffic through? That shit ain't secure either.
I totally get rejecting incoming connections from SSLv2 and earlier, but to scream and block outgoing connections just seems like tinfoil hat territory.
It's blocking traversing connections(1). It can distinguish between incoming and outgoing connections, but SSLv2 is old,(2) man, and the sooner we get rid of it for good, the better.
(1) It's a separate box in the middle of the network, although it does have an idea of "incoming" and "outgoing" connections, based on which network interface the first packet arrives on.
(2) Not as old as me in calendar years, but it's still old.
-
@Steve_The_Cynic said in Apple knows better than 32-bit:
SSLv2 is old,
We do monitoring with eavesdropping, so we have to make do with what the peers do. Our SSL was implemented 2004ish, and has never supported SSL2 except as upgrade handshake to SSL3.
They won't let me tear out either as long as I can't believably claim it's in the way for some other project.
-
@levicki said in Apple knows better than 32-bit:
@Steve_The_Cynic said in Apple knows better than 32-bit:
It couldn't reach Windows Update nor the WGA thing to activate itself.
Of course it couldn't, it doesn't support TLS1.2. The trouble is that its crypto stack doesn't support SHA256 signature verification (both for WinTrust file authentication and for HTTPS certificates), so you can't even install an update unless you either install SP3 or manually replace crypto stack with files from SP3.
A lot of it was a simple case of not even being able to reach the servers because the firewall was blocking the SSLv2 in the connections. The details of certificate verification are of exactly no importance at all if you can't receive the server's certificate.
-
@levicki
@levicki said in Apple knows better than 32-bit:
@Anonymous-Throwaway said in Apple knows better than 32-bit:
you’re going to need to change some variable declaration types
When it comes to C/C++ porting to 64-bit is often not just "change variable declaration types".
If you are doing any kind of pointer arithmetic in your code you must make sure you are using ptrdiff_t for the results or your code will compile and it may even run but you will be in a world of hurt.
If you’re doing pointer arithmetic without using ptrdiff_t, then that has nothing whatsoever to do with Apple’s APIs, though, which is what we were discussing. If you are using Apple’s APIs then you’d be using CoreFoundation for storage, working with things like CFArray and CFDictionary and so on, and wouldn’t be dealing with pointer arithmetic.
(Does anybody know of any cross-platform project which actually uses CoreFoundation? I’ve always assumed that the implementations on other OSes were more or less just for show, because Windows has its own native objects and Linux… is Linux, but in writing this it has occurred to me that maybe I’ve just missed something.)
-
@levicki said in Apple knows better than 32-bit:
@Steve_The_Cynic said in Apple knows better than 32-bit:
A lot of it was a simple case of not even being able to reach the servers because the firewall was blocking the SSLv2 in the connections. The details of certificate verification are of exactly no importance at all if you can't receive the server's certificate.
I was just pointing out that even if it could receive it, it could not validate it because:
- It doesn't have latest Root CAs in the certificate store
- All server certificates are now SHA256 and it can't verify SHA256 signatures
If you had read carefully what I wrote, you would have seen that I said that it doesn't have the latest root CAs, so you didn't need to point that out.
-
-
@ixvedeusi said in Apple knows better than 32-bit:
@Steve_The_Cynic said in Apple knows better than 32-bit:
read carefully
New to the internet?
20 year veteran, thanks. But note that I was directly implying that he hadn't read it carefully.
-
@kazitor said in Apple knows better than 32-bit:
Apple is wise enough to realise that none of those philistine Luddites are worth supporting!
There is probably few enough Luddites in Gaza and West Bank that they are indeed not worth supporting, but what about the other Luddites?
Also, racist
.</
>
OS-9 - Wikipedia
