macOS Catalina
apple.com
apple.com
Also, clicking on a dropdown box in a web browser (Safari, Chrome, or Firefox) after the computer has been asleep for a while freezes the whole computer for about 10 seconds.
Maybe it's just me, but that feels like a showstopper.
The whole 32/64 bit thing doesn't seem too bad, although I've had to use Pages instead of Word and can't use Adobe products anymore and have had to switch to open source alternatives, but I don't use those products very much so it wasn't a huge deal for me.
[1]didn't really pay attention to version numbers before 7.6, but I guess "install on public release" didn't begin until OS X...
Unless you use some of the very special features of Word, or you're in a profession that requires Word docs specifically, Pages is a very good substitute. It can even open old Word docs (and new ones too).
I haven't tried Sidecar yet because the iPad is on my wife's iCloud account since she's the primary user and I'm not sure how to make it work across iCloud accounts, or if you even can. She uses it so much I can't get my hands on it!
defaults write com.apple.sidecar.display allowAllDevices -bool YES
For Apple, you and your 2015 Macbook Pro are just poor losers.
Now, You're free to buy a new one.
However, Numbers is not at all an Excel replacement and that is going to cause a lot of grief.
If you’re even a halfway serious user of Excel than indeed, Numbers is a complete joke. But if google sheets would work for you numbers probably would too.
For simpler tasks where a spreadsheet program is obviously the right tool for the job, Numbers tends to be plenty capable and give a nicer user experience than Excel and clones. For example, a few weeks ago I discovered that Numbers is vastly better at doing time-related calculations than Excel.
Numbers fails completely when you start moving into the problem domains where a SQL database and/or scripting language are good tools to consider.
Glad to know that Pages does a good job as a Word replacement. I do track changes pretty frequently and have wondered how solid the support/translation is for that feature.
https://blogs.msdn.microsoft.com/murrays/2017/07/30/latex-ma...
https://en.m.wikipedia.org/wiki/Lighthouse_Design
Some great applications. I would love to have a direct port of all of them today. Of course I also want the shelf back and I want my menus on the side like NeXT. Oh well.
Keynote was created so Steve could have something that worked and looked the same as Concurrence. He would use his old NeXT to create presentation until Keynote.
And the icloud version of Numbers is pretty handy when you don't have a Mac around (but the collaboration capabilities suck compared to Sheets).
If Pages works for you, great: but save a copy in a different format if you want to be able to edit it in a couple years.
I have been stuck multiple times with users upgrading Pages two versions later on a desktop and then unable to read on their laptop or vice versa. Inexcusable!
Duet Display's iOS component costs US $9.99.
That's how you know Apple don't give a shit about its user base, unless you pay 2500€ every 3 years for a laptop.
Why is h.264 unusable?
Why is removing a feature better than letting run a bit slow?
If a restaurant runs out of food, there are gonna be some customers who would eat a turd sandwich, as long as they could eat something, but most customers would flip out and demand to know who would think shipping that out of the kitchen was okay.
Now the analogy isn't perfect, but I imagine there's a host of reasons around expectations of support and experience that Apple has no plans on addressing for those cases, and rather than having a lot of time wasted clogging support with something that will just frustrate the average customer regardless, better to leave the few complaints about why they can't have it, since after all, your complaint doesn't cost them a dime in potential support calls. Just a vague feeling like you're not getting everything you want for the price you're paying.
If you've ever been to Disneyland, you can see historically, the park is jam packed with people who have that same frustration, each a paying customer.
If my assumptions on their product calculus is correct, I know which of those options I'd choose, from a business perspective.
For the 2 first catalina beta, you could still activate it with 2 command line in the Terminal, but these mother* removed the ability to do so in the third beta.
That's how I know Apple don't give a shit about me and my 2015 macbook Pro unless I pay 2000€+ every 3 years.
What a fucking joke.
dude, Libre Office wipes the floor with Pages, Numbers, etc. If you haven't tried open source office programs in the last decade, they've come a long way. And I find they work better cross platform (ie they save in MS office format much more seamlessly and less buggy)
16GB RAM
1TB SSD (3rd party upgrade)
Macbook Pro, 15inch, Mid 2015 2.5GHz i7 16GB RAM 500GB SSD
Turning off iCloud capability stoped the insanity.
Have been using Apple’s betas for years now. This season was the first time I regretted it. But I like telling myself that dark mode and iPad OS multitasking made it worth it.
Some UX improvements across the board are very neat though.
In the end, new desktop runs Linux, and aside from a few issues for brand new hardware, it's been a nice change of pace.
- My scanner support (they have new version, which is insanely buggy and can't even detect my scanner properly)
- All my games (literally every single one of them turns out to be 32-bit) - I don't play that much but still, would be a shame to lose all of them
- Postal label printing app (no idea if they have an update, need to check)
- App supporting my stand-alone disk array (not using it too much though)
- My niche learning apps (pretty old, from small providers, not sure if they'd ever be updated)
Much more than I expected, given that I don't have any exotic stuff like music instruments, specialized equipment, etc. So I personally probably would hold off upgrading as long as I can.
Although I understand the Windows codebase is a nightmare.
It's not easy to get into the mindset of fixing every problem a 3rd party app creates.
Some will say Apple is offloading tech-debt onto client apps, but Microsoft is allowing client appts to offload tech-debt onto itself, and it's big enough to take that burden on so its users can still use the stuff they bought.
I dunno, sometimes I hate having to do it but it's all about user/dev experience and if you're optimising for your own employees you're making it worse for everyone else who makes your OS/machinery worth buying. There's got to be some compromise, coz it sounds like if you buy into Apple then you're SOL if they can't be bothered supporting your hardware.
Which, additionally, must contradict their environmental aims. It's not good for the environment if upgrading an OS means you throw away your printers and scanners and buy compatible ones.
I have written various (Windows) utilities over the years, and some are over 20 years old now and I use them every day. They worked on Win95, they still work through to Win10. They're all tiny single binaries that require no installation, start immediately, and are extremely responsive and low on memory usage. Ironically, it's almost impossible to do that with a "modern" toolchain now, and I'm not even sure if something like that would've ever been possible with the Mac. To me, the idea that backwards compatibility is a "burden" is absurd. Constant churn is a burden. If I had to go and "fix" all my utilities every few years because a new OS broke something that was working before, I would have less time for actual new developments. Instead I can continue to use them and write other things as the needs arise, instead of wasting the effort redoing things that should've still been working. Just "leaving well enough alone" is a big part of it.
I can't see how this is Apple's problem. Holding up development of a platform and technical progression generally for unmaintaned software is not a good working model for anyone, no matter how useful it is.
> So "recompiling every few years" is a pretty big burden.
As is "supporting everything ever implemented in perpituity"...
WTF!? You've just perfectly illustrated the attitude that's making technology worse for everyone.
What are computers for? "To control and force users to consume mindlessly" might be an accurate depiction of reality today, but that's not what they were originally invented for. Computers were intended to assist people. As the early (1930s-40s) promotional material would say, "to come to the aid of mankind". The whole point of a computer is to be useful to its users, so arguing against that is just nonsense. This discussion item is full of other comments stating exactly what sort of work they use a computer for, and how they are being affected by useless changes.
Most people take it for granted just how stable a lot of other things --- also invented to help them --- they use on a daily basis are. Imagine if every few years, your toilet, sink, bathtub, light switches, power sockets, door and window handles/locks, lightbulb sockets, and home appliance controls changed in such a way that you had to completely relearn how to use them and without some functionality they had before, and all for totally BS reasons like "development of a platform and technical progression".
As is "supporting everything ever implemented in perpituity"...
Some things just don't ever need to change.
Nonsense. I never suggested that. What I am suggesting is that whining about progress (especially when it has been known to have been deprecated for at least the last 10 years!) and layering technical debt on top of technical debt is stupid. I do agree that somethings don’t need to change, but are absurd, not to mention inaccurate. The many types of different light fittings for example are evolving. Somewhat more slowly than computing, I grant you. The same is true for locks and light switches are being developed too. Your comment about home appliances is By far the most ludicrous. I do take issue with your notion that things in Catalina have changed to the extent that they need to be relearned. Bullshit.
Welcome to the life of a Mac developer.
*year
I think part of the idea is (and how they see it), if you buy into Apple, you should have enough spare money to upgrade your hardware as needed. This sucks for us which are not exactly affluent, but that's part of the thing. Apple never tried to maximize affordability or expenses.
(Though in some cases, they have been the more affordable of the bunch, e.g. when the iPad was announced, it took about 2 years for competitive machines to reach price parity. Or now, e.g. the newly announced MS earbuds are more expensive than airpods).
It's not a platform for long term support and maximum bang for the buck, it's a platform for user convenience ("it just works, mostly"), inter-operation ("things -phone, earbuds, speaker, watch, etc- just work together, mostly"), and cohesiveness ("things have a unified vision, mostly"), plus polish (thinking some things more through in their design -- not always though, e.g. BS MBPr keyboard).
I use "mostly" above in the sense that it's not obviously perfect (and some areas far from it). But the tradeoff is in the areas mentioned above.
Just don’t go there. Use an emulator for DOS code and use the normal kernel support (modify_ldt()) for 16-bit protected mode.
Yes, it is. It’s almost exactly the same. What you can’t do is run v8086 code on a 64-bit kernel without using a VM, most of the code people care about is 16-bit protected mode code.
I maintain the messy but small amount of Linux kernel code that makes this work. It is, indeed, gross, because the x86 architecture is awful. But it works fine in practice and there is quite a good test suite these days to exercise the ugly bits in the kernel tree.
So Microsoft has already got the ability to run 16-bit Windows apps in emulation. It's a shame they didn't enable this on x86-64.
Stick with Windows/Steam/Consoles/etc. if you don't want a bunch of your games that you purchased to become unplayable every year (unless you add multi-boot to run the old, compatible OS, or run them in a VM, which usually works poorly.)
As I have mentioned before, it's a very annoying example of Apple shifting technical debt and maintenance work away from themselves and onto developers, and the overall maintenance burden is greatly increased.
I like how the platform moves forward, but I really wish that there were a way of getting desirable security patches and feature improvements in the OS without breaking all of my apps.
* 64bit processes usually can't load 32bit modules, only a 64bit OS can (true for Linux and Windows, I'm not sure if it's true for x86 overall). There's a pretty good chance that only a 32bit CrossOver could load 32bit modules.
* Has 32bit support been stripped from the kernel, or has it only been stripped from the installed dynamic libraries? I'd wager that it's stripped from, or partially stripped from, the kernel. Even if Catalina allows 64bit processes to load 32bit modules, the kernel would have to support it.
There's a one in four chance your scenario is supported. CrossOver definitely couldn't magically voodoo a 32bit module into a 64bit one, as it's impossible to determine if a register/address is a 32bit integer or pointer; if it doesn't work today, it will probably never work.
I'm not sure if macOS supports IOMMU, but an external GPU with a VM might be your saving grace here.
https://www.codeweavers.com/about/blogs/ken/2019/10/3/crosso...
And no, it isn't raw LLVM bitcode.
Xamarin among others ran into a snag but it seems they could retool and convert from armv7k to arm64_32 for example https://github.com/xamarin/xamarin-macios/issues/4864
Keeping around old code increases the security vulnerability surface. For instance, there are at least a half dozen ways of representing a string in Windows. One of the earliest widespread vulnerabilities in Windows was caused by improper handling of string encoding where anyone could run DOS commands on a web server running IIS just by encoding the commands in the browser.
https://www.sans.org/reading-room/whitepapers/threats/unicod...
That is slightly different because Apple is designing their own mobile CPU's. And indeed by dropping 32-bit ARM support they can simplify and improve their CPU designs.
OTOH, Intel isn't gonna drop 32-bit x86 support from their chips just because Apple isn't making use of it.
They will face some* backslash now, but if/when they switch Mac to their own arm chips they might achieve a painless transition.
*They announced 32-bit deprecation like a decade ago, will legacy users be pissed of? yes! Is it a excuse for developers that still relied on 32-bit support over the last decade? NO!
Essentially what Apple Arcade will end-up hosting is ports of run-of-the-mill mobile games. And I'd bet the advertised number of developers will diminish as soon as the agreements they secured for the launch expire. But if this is the kind of gaming you're interested into, you already have your iPhone/iPad.
[1]: https://www.gridsagegames.com/blog/2019/09/sorry-mac-users-a...
[2]: https://www.vice.com/en_us/article/43k4ww/its-hard-to-use-ap...
But yes, apple is in the wrong here, and should continue to support hardware that they haven't shipped in 10+ years.
I assume you're in the group that believes MS should be required to support XP forever.
No, it isn't. There were never any 32-bit x86 Macs with decent GPUs. Dropping 32-bit support only affects games that were already old enough to be commercially irrelevant or games that rely on unmaintained third-party middleware that never got a 64-bit port. Those don't add up to enough to be a major impact on the Mac gaming market. There are plenty of other factors that are much more important, such as Apple's abandonment of OpenGL and preference for Metal over Vulkan.
These aren't old games for the most part: https://www.macworld.co.uk/feature/mac-software/apps-wont-wo...
They certainly weren't making much money off these particular games even before Apple announced the deadline for going 64-bit. It's unfortunate and disappointing for customers who had already bought those games, but this deprecation didn't shut Aspyr out of much in the way of future sales.
Now, if users become reluctant to buy Mac games for fear that they'll stop working unacceptably soon, that could have a meaningful impact on demand for Mac games. But even if Apple made it official policy that they would break games after four or five years, that wouldn't completely kill the market for Mac games. If Apple made it cost-prohibitive to get a game ported to their platform in the first place, that would pretty much be "game-over for gaming on macOS".
But tbh Mac was hardly a gaming platform to begin with.
The platform has never been "attractive to players" to begin with.
Now we have Arcade though and easy porting to iOS though, which could open a multi-billion market...
It also kills any hope of wine powered support for proton in steam as many many windows games will be still 32 bit for a very long time (mind you, metal already had put a big dent in that).
Interestingly Linux users are indirectly getting affected by this: for many developers supporting Linux was just a byproduct of supporting macOS. As the latter is being dropped, support for the former is getting harder to justify. Luckily Proton seem to be a very viable alternative to native games.
Well, let's see. My main 3 purchase locations are Steam, Humble Bundle and GOG.com. I'd guess this is fairly typical, but anyone using other platforms feel free to add yours.
Steam: The Steam client is still stuck on 32bits. I'd bet it will soon be updated to 64bit, but it just goes to show that macOS is pretty low in the priorities of Valve. And if a company with the resources of Valve doesn't care, I can't see much motivation for the individual developers either.
Humble Bundle: I've went through the current and following Humble Bundle Monthly games. Windows Only: Call of Duty WWII, Crash Bandicoot Remastered, Spyro Remastered, Sonic Mania, Planet Alpha, Override-Mech City Brawl. Windows+macOS: Battletech, The Spiral Scouts.
GOG.com: There's already a 64bit DOSBox port—DOS–era games will eventually be supported. Windows–era games are gone—Catalina breaks Wine emulation and no announcement has been made for 64bit support by the Wine Team. For newer games, GOG.com will need new builds from the developers—doubtful if we ever get to see those, especially for indie games where developers don't have the resources to go back and port their released games. Newly released games are often Windows-only.
I don't know how you see this picture, but it looks pretty bleak to me.
Even just recompiling the game might be a challenge for a lot of developers in the "long tail" of the Mac game library.
> the notion that every developer of every app is part of the constant, incessant update loop that Apple encourages is fundamental to the problem. Someone's super personal narrative unity game from 2013 is not getting updated!
[1] https://twitter.com/MammonMachine/status/1181327259057082368
So devs of two year old games will need an old macOS install that can export their game to 64-bit, but also a new enough macOS install that can notarize their app (maybe these can both be Mojave -- but many indies don't own their own macs).
Also, Unity 5 is no longer available for purchase. If they're already using their license on another machine, they'll have to migrate it to these macOS installs.
Devs could upgrade to a more recent Unity and fix all the bugs, but to what benefit and at what cost?
[1]: https://forum.unity.com/threads/installing-unity-on-macos-ca...
I'll hold off too. My macbook pro is 2013 and pretty old it overheat often if I play video. This update will definatedly exacerbate the problem.
I haven't evaluated the quality of available offerings yet, but they look good in the App Store previews, and I think they're all native Mac apps (not lazy ports), using Metal and everything.
Although yeah, you can't really own any of those games and will always need a subscription, and some may be removed in the future.
And yes, there's this Arcade, but I have no interest in playing for something which is locked down to one platform.
Do you boycott Xbox, Playstation, Switch, DS etc. exclusives too?
What about Windows-only games that aren't on Mac or other systems? There are certainly thousands of those. Do you refuse to play those either?
(Even in the Linux world, which prides itself in supporting crap used by a handful of people globally, X32 is dead, to the extent it was ever alive.)
- Never needs more than 4 GB RAM (because it's not worth the usability downsides from having two binaries and letting the user choose which to use, just for a small performance boost)
- Is performance critical
- Performance is bound by memory and/or cache bandwidth
- A large share of the program memory usage is due to pointers
The intersection of all the above is just vanishingly small in reality. X32 was never more than a gimmick to score a few extra points in SPECcpu. And thus people rightfully ignored it.
And Canon is notoriously bad at updating their drivers, so my scanner will now be a brick.
I remember how it was so easy to scan directly to multi-page PDF with my Brother portable scanner. The Apple build in capture software was just so easy and clean to use. Then Apple removed TWAIN support in snow leopard, and suddenly my 2 month old 400 euro scanner was no longer usable. :(
I use it myself and ignore the manufacturers software altogether. Which form my scanner only supported PowerPC.
Careful now. Scanner manufacturers would have you believe that's nearly impossible unless you remember to make the appropriate sacrifices under a full moon on a marble altar.
Software like VueScan and USB Overdrive (just bought a license for that too $20) deserve to be in some sort of Apple Hall of Fame.
Homebrew has some broken packages, e.g. trying to run Midnight Commander dumps a nice "Bad CPU type in executable" message.
And this "doesn't seem too bad"? These are the industry standards for productivity. Pages on the other hand is only good for throw-away projects. Last time I checked, importing and exporting to Microsoft Office sucked. So, Catalina pretty much turns your professional machine into an overpriced netbook.
Microsoft/Adobe will of course eventually release 64bit versions of their software. But these will cost extra $$$ on top of the premium you have already paid for Apple hardware. A lot of money with doubtful productivity gains. This won't make any professional happy.
Still, I'm running both using a site license from my work. The upgrade cost per user in site licensing is pretty low. If I had to pay myself for a single license, I'd bet I wouldn't have upgraded for eight years either. And the Office/Adobe CC subscription costs may not be insignificant either, depending on where you live.
I am also about to buy RockSmith on Steam, but it's 32 bits at the moment. I currently used it on my PlayStation but want to have it on macOS to access more songs.
It looks like you find many games on steam that are 32 bits only.
On our side when OS X was introduced we trusted Steve when he said Carbon is there to stay and will be 64 bits. We took a few years a few years ago to do the switch...
- iOS 13.0 was so bad they released 13.1 in less than 5 days, but even now many things are still hit and miss (with 13.2 in beta)
- watchOS 6.0 is also still pretty bad and not yet fixed (with 6.1 in beta)
- macOS 10.15 GM seems pretty buggy
- Well, I think tvOS 13 is ok?
While the situation might be better for people who use the latest betas, it is still a horrible current user experience for all normal users just updating their devices.
Lots of cross-platform features introduced across these updates (like the new iCloud features and new Reminder apps, etc.) are also in a horrible state.
I'm not sure what their QA team is doing this year but it seems almost everything planned for this Fall would have been better off if pushed back a couple of months. Well, if it weren't for device compatibilities... (the iPhone 11/Watch 5 seemed to be more important than stable software across all their platforms and other devices)
iOS 11 was a complete disaster and it took an entire OS upgrade cycle (iOS 12) to control the most pressing issues. Apple is constantly releasing wild bugs and after getting burned multiple times now, they still don't seem to tackle this internal problem.
This year it has been 12 days after iOS 13.0, instead. Wouldn't really call that much of a push back. It's less than one week behind the usual schedule..
That's the boat I am in. I can afford their cloud subscription but out of principle I will try their main competitor first (Affinity: $50 one time purchase). I will try running it in a VM second. Only if neither of those solutions are satisfactory will I pay a monthly fee for software that I use very little.
Edit: it seems to be only old versions that won’t be supported (office 2011).
Here's a rundown of products that depend on 32-bit support or that haven't been tested in 64-bit on Catalina yet:
Audio products: https://www.sweetwater.com/sweetcare/articles/macos-10-15-ca...
But keep in mind these companies are usually pretty small, a lot of sole-proprietors out there, and their revenue comes from new products/sales not maintaining projects. So there's logistical and incentive problems in deploying fixes quickly.
I also think it's unrealistic for large applications to be 100% ready on day one. It's not like Apple has a GM ready weeks ago. Betas are known to change and nobody really knew when Catalina would ship (many people are surprised they're shipping what they have).
Just because Apple can bump out a new OS version once a year doesn't mind these app developers have the same bandwidth to keep up the chase. They have plenty of other priorities.
For the most part, it's not a technical issue at all but a cultural one : pro audio users are notoriously, almost pathologically conservative when it comes to software upgrades.
You'll find plenty of threads on forums like Gearslutz, asking for tips on how to downgrade brand new Macs to an older version of macOS that doesn't even support their hardware. Or 2019 threads asking if it's now safe to upgrade to High Sierra. They're typically 2-3 versions behind. Why ? Older is just safer, better in their worldview.
In that context, audio developers know they have customers on their side against "evil Apple that's always breaking everything for no benefit", and they get away with emails that read like Apple just unexpectedly dropped a bomb on them without notice, and it'll take them 6-12 months to get ready, like WWDC and 3-4 months of developer betas never happened.
I wonder what MacOS has that Windows doesn't(which is a lot more backward compatible) that makes audio people stick with them.
All mainstream OSes are moving to an unsustainable release cycle.
For years it has also had things like Audio Midi Setup, which lets you set up aggregate virtual audio interfaces from physical ones, dealing with latency compensation etc. Or MIDI over Bluetooth. All of that out the box. It just feels it's been designed with pro audio in mind, compared to Windows.
It's a technical issue. It's a bear to support older systems from newer machines. (it's a lot easier to support current stuff from dawn-of-time old systems! I keep an antique laptop to code on which allows me to support EVERYTHING all the way back to PPC Macs. Which I do support)
My choices of what I choose to buy (in Apple hardware) or even CAN buy are conditioned very much by this reality. I'll get stuff if there's a fighting chance I can build a working ecosystem on it. I'll be willing to do things like ditch Logic and switch to Reaper, and I'll be well within my rights to tell users 'this is what I can offer, and this is what I cannot'.
Because Apple is not automatically my ally. It can be my adversary, even when I'm doing its bidding (I was fairly early in porting my entire product line to 64-bit when few others bothered. Apple literally called me and offered to help me do this, so I told 'em I'd already done it three months before. I did NOT tell them that I continued to support PPC machines or maintained a time capsule dev machine as the only way to develop for a large range of cheaply, easily available hardware)
Users have every right to side with me against Apple when I'm an open source developer letting them do professional-quality audio work on computers costing only a few hundred dollars, and/or letting them continue to use known-good and predictable equipment, and Apple is locked in to a course of action requiring it to churn its userbase at whatever cost to the userbase.
I totally get Apple's motivation here, but it doesn't serve my customers.
As a user I only see "OS upgraded -> stuff broken". I'll blame the OS for that. All finger pointing and shoulda/coulda/woulda is not magically going to unbreak things,rolling back the upgrade will.
On the plus side, I've been running Kontakt 5 along with lots of other audio software since 10.15 beta 3 every day and most everything is working alright.
Some other observations:
• Pro Tools' QuickTime video plug-in prevents it from launching because it's a 32-bit only subprocess meant to interact with the now-defunct QuickTime framework. You can delete the plug-in from the application bundle and it will proceed and seems to be working normally.
• EastWest has a nasty crash in PLAY 6 that can be worked around temporarily by removing their internal word builder plug-in.
• Pretty much every iZotope plug-in as of September had a 32-bit non-pkg installer. The software works fine if you copy all the relevant parts from an install on another computer.
• MOTU hardware drivers for anything but the latest Pro Audio line won't work as the drivers are 32-bit at the moment (MIDI interfaces, CueMix-based audio interfaces).
Not saying it isn’t work, just that “I didn’t see it coming” isn’t much of an excuse.
That software is a lot like vintage gear, there may be alternatives but they aren't the same, and that's the problem.
They literally can't run without porting, disregarding performance. The benefit is infinite!
Only in misleading microbenchmarks. In the real world, the memory bandwidth saved by using 32-bit pointers in some programs that can be guaranteed to not need more than 4GB of memory (or ASLR or other features enabled by x86-64) is completely outweighed by the costs of keeping both 64-bit and 32-bit libraries on disk and in memory and in cache. That's why even on Linux the x32 ABI was never able to gain traction even among Gentoo users, and why retaining traditional 32-bit support is viewed as only a compatibility measure for closed-source code that literally can't be updated.
It's just an Apple trick to force financial turnover for owner of 32 software.
It's not that there softwares are not compatible anymore, it's MacOS which block artificially 32 bit software.
It's for the same reason MacOS block sidecar for device older than 2016,even if they are capable to run sidecar in the first place.
Imagine if tomorrow nobody could download GraalVM anymore because OpenJDK 8 stopped working for some reason (yes I know it's bundled, this is just a metaphor). It could easily be said you had years to upgrade, so why so sluggish? Well, of course, there were actual features you wanted to ship during this time too, not just doing upgrade work, especially given that Java 9 and 10 maybe didn't deliver many compelling upgrades.
A better example is the obvious impending transition to ARM, which GraalVM is already preparing for.
In fact, I'm guessing the pain of losing Java 8 will be too much for many organisations after so many years of stability and 9/10/11 breaking so much (current Gradle doesn't even work on Java 13!). Maintaining 8 will be a good business for a long time.
See the discussion here - and notice how confusing and contradicting the opinions about it are: https://news.ycombinator.com/item?id=21179970
Or that you haven't had the resources to spend on it
Depreciating 32 bit software is just an Apple trick to force financial turnover.
It's the same reason why the deactivated sidecar for macbook older than 2016.
Not saying I agree with apple's decision, but it's surely it's just about reducing their own engineering costs.
Imagine digging up an old project, recompiling it for 64-bit, and finding out that:
1. It doesn’t compile any more, with modern tools.
2. When you get it to compile, it crashes mysteriously.
3. When you get it to run, it again crashes mysteriously when you try a 64-bit build.
Yes, there are a lot of “best practices” out there to avoid this. Any discussion of best practices is moot because people in the field have to work with actual practices and legacy code that might be full of undefined behavior, custom build systems, weird hacks, and lost tribal knowledge. And you are simply not given enough time to go through and fix it.
This is not all about the 32-to-64 bit transition, but that’s the biggest part.
Then consider the smaller shops—which might only have a couple of Apple devices altogether, and not a lot of spare developer-weeks to go through and test old plugins on new systems.
> except in a well-contained module?
This is probably one of the best reasons. Game developers aren't entirely to blame here, middleware developers seem to be sticking to 32bit like balsamic glazing. Even if you could pry their cold dead hands off their archaic architecture, they'd probably make you pay full price for the 64bit upgrade.
As for DAWs? Think about all the the VST plugins out there. Most of which probably aren't maintained and only exist as zip files on the artist's dropbox.
Dropping 32bit is aspirationally sound. It's grossly inconsiderate of the very most obvious aspects of reality.
This is one reason why ecosystems like Java are so valuable! The 64 bit transition was so easy for it because of the common insistence on "pure Java" for portability. Combined with pointer compression 64 bit was hardly noticed.
Forcing it is a net-good perhaps?
One of the big ones is that integer constants are 32-bit on LP64 / LLP64 systems unless they are large enough, so e.g.
// Equal to 0x80000000 on ILP32
// Undefined behavior on LP64 / LLP64
size_t max = 1u << (sizeof(size_t) * CHAR_BIT - 1);
// Correct version
size_t max = (size_t)1 << (sizeof(size_t) * CHAR_BIT - 1);
#define K 1024
#define M (1024 * K)
#define G (1024 * M)
#define T (1024 * G)
// Undefined behavior, on both 32-bit and 64-bit.
size_t max_object_size = 10 * T;
// Correct version (#1)
size_t max_object_size = 10995116277760;
// Correct version (#2)
static const size_t K = 1024;
static const size_t M = 1024 * M;
... etc ...
void *align_ptr(void *p) {
// Mask is 0xfffffff0 on 32-bit (correct)
// Is also 0xfffffff0 on 64-bit (mistake)
return (void *)(((uintptr_t)p + 0xf) & ~0xf);
// Correct version
return (void *)(((uintptr_t)p + 0xf) & ~(uintptr_t)0xf);
}
This is why so many languages have stricter rules about converting integers to narrower / wider types.
Of course basic examples between 32 vs 64 are easy to find. I guess I should have clarified as the OP sounded like he knew the topic well.
I’ve never dug hard into C++ gaming architectures and the patterns they use.
A large project probably has lots of them. If you are lucky there is a 64 bit version of it. Very often though there isn't so you have to find something equivalent and rewrite all interactions with it.
And there might have been very good reasons for choosing those specific dependencies.
That can take ages upon ages and can be quite demotivating. You might have issue even finding out if you have any problems in your own application after you've spent months on replacing dependencies.
A lot of audio developers are dealing with legacy code that has been growing over the years with a focus on pleasing a very specific user base.
Just look at how long studios held onto OS9 because of the long tail of plugins they had that were awesome, but abandoned.
Apple has deprecated a lot of things and seems to be trying to move everything over to AudioServerPlugins, which essentially requires a full rewrite of the drivers. The architecture isn't similar at all (AudioServerPlugins actually follow a Microsoft-style COM interface, among other things). I don't even think Apple makes any sample code for updating old Firewire drivers to run on Catalina, so it's a tough slog, and low-level CoreAudio expertise to update old drivers is getting scarce. Traffic on the CoreAudio developer mailing list is down to less than a dozen posts most months. There hasn't been a single post to the mailing list yet in October.
I strongly suspect that some interface vendors are not going to update their 32 bit drivers for Catalina. (MOTU in particular is one, which kind of marks the end of an era because they used to be champions of some of the best CoreAudio features, like Firewire clock syncing.)
Surely, surely it was obvious for years that Firewire is on the way out? Why are people so reactive and sluggish? People should be ready for change.
The low-level interfaces in question were changed almost 4 major versions back. There aren't any new interfaces or APIs that haven't existed for 6+ years already. The only people complaining are the ones that procrastinated because Apple continued to support their outdated apps.
If everyone should have been prepared because this change has been in the works for so long, then surely it's inexcusable for Apple to have left the new stuff in a poorly documented state all that time. If you do feel that Apple's lack of preparation is reasonable when they had even more warning than third parties did, then it seems unreasonable to fault developers for also not being prepared.
AVAudioEngine is not a new framework on macOS. It was first available on macOS Yosemite which was in beta in 2013 and released in 2014. Developers have had 6+ years to develop and test using these frameworks.
This literally just boils down to developers complaining that Apple isn't further letting them procrastinate.
Apple expects developers to adopt new technologies, but often never gets around to documenting them well enough to drive adoption. It’s been a real issue for low level audio work on the platform.
I hear they are planning to update their 32-bit drivers for the older MIDI and audio interfaces with the exception of the PCIe devices. (There are no existing Macs that can run Catalina and the old PCIe interfaces with the exception of the new Mac Pros, but there will be no driver so...)
Huh? What x86 processor doesn’t support 32bit code?
If they move to ARM, everything will get broken, regardless if whether it’s 32bit or 64bit. Is breaking things twice really better than breaking them once?
That's the wrong question to be asking. The relevant hardware change is when x86 CPUs that don't support 64-bit code finally disappeared from the market and eventually from the install base.
There is only a very narrow range of use cases for which running 32-bit code on a x86-64 processor is preferable to running the same code compiled as 64-bit. For everything else, going 64-bit is a clear improvement if not an outright necessity. Even if it didn't require any ongoing maintenance, continuing to ship 32-bit versions means wasting storage space and network bandwidth, and leaving on the table the improvements enabled by going 64-bit (eg. better ObjC runtime). For the entire existence of x86-64 processors it has been clear that retaining 32-bit compatibility through the entire software stack has significant downsides and that the cost/benefit balance has been inexorably moving toward eventually dropping 32-bit support.
Time and resources a software publisher spends on the upgrade treadmill is time they can't spend on other efforts, whether or not there's advance notice. Essentially, it's a cost Apple imposes on developers for their platforms. And either that shows up in costs for users or the software folds.
If there's a counter to upgrade treadmill criticisms, one of the few that makes sense is if there are compelling benefits with the upgrade to weigh against the cost.
At the moment, it's entirely unclear to me what benefits I'm supposed to derive from dropping 32 bit support, and moreover, I can't think of a single compelling benefit I've derived from macOS updates since Snow Leopard.
Notably, that's not my complaint or my point. This isn't about the timing (which is why the distinction was important).
No matter how much time someone has to prepare for a change, there's a cost to making it. And if the benefits of the change don't outweigh those costs for the developer (and the user), then a complaint sure makes sense from those perspectives.
This does intersect the issue of timing, because in a resource-constrained situation, you inevitably have to defer some efforts until they're absolutely necessary (and simply rule out doing others). But timing is not the fundamental issue, cost-benefit tradeoffs are.
> [development] should include a transition to 64-bit.
Why? What's the benefit to ending 32 bit application support?
- 68K Classic MacOS
- PPC Classic MacOS
- PPC OS X
- x86 MacOS
What alternative would you prefer? That Apple ships the latest MacOS with a 68K emulator, a PPC emulator, all of the 32 bit libraries, classic MacOS in a VM, and all of the Carbon libraries forever?
I'm not sure if you'd be so ready for change if it meant replacing expensive gear that is still totally functional.
No? How come I can use Ableton Live 10 in 32 bits to make music then?
1 at least on Windows
I could never justify a long term hardware life knowing that I’m signing up with a short term software life cycle. Not only a short term software lifecycle, by a short term computer hardware/OS lifecycle. Want more memory or a faster processor? Not with that old OS! Btw, you have to rewrite all of your software if you want that extra memory.
1) Although everything is "notorized," the Safari extensions aren't installed on app start up like it's supposed to in most cases.
2) The following API call works, UNTIL macOS wakes from sleep mode, in which case it always returns 'false.' SFSafariExtensionManager.getStateOfSafariExtension(...)
Unfortunately, the only way I’ve found to figure out why this happens is to sprinkle breakpoints throughout Safari…
Outside of audio, I know of companies that ignore prerelease stuff because Apple has been known to change APIs during the beta period. It's not like Apple has a GM weeks before it is released publicly.
The concern seems to be more of wasted time developing on a moving target. Often people report battery issues after major releases, people are reporting weird hangs after waking from sleep. Audio stuff is real-time in an OS that cannot guarantee it. Accommodating these things is a large undertaking and I'm sure there's gambling going on about what Apple will fix and what you can rewrite before Apple decides to ship.
Many audio tools have to deal with third-party, paid, and often abandoned drivers and plugins. So the 32-bit transition made for some difficult decisions. Nobody is arguing this is a surprise.
In every Apple technical decision, there is a financial motivation.
Both my audio macs are on Mojave now. I don’t think I’ll have any good reason to go to Catalina soon. I’d like to try it since it’s new but... too much could go wrong and it takes too long to restore backups to be worth my while.
It was still the fastest way to access:
- Multiple calculators
- Multiple sticky notes
- Multiple unit conversions
- Stocks
- Weather widgets
Notification center as currently implemented is just not cutting it. The amount of widgets I can quickly access is dependent on screen size, and worse, they're moving targets! — The weather widget causes all the ones below it to shift up and down while it loads. Not to mention I can't see my notifications when in Widget mode.
What a sad state of affairs for what was once a very powerful feature.
EDIT: For fun here's Steve Jobs' intro to Dashboard widgets https://youtu.be/XQQPTtdzBig?t=4872
(And I'm sure a 3rd party replacement will pop up, if there are enough frustrated users).
A good example was usage of LLVM on the PPC->Intel transition which then helped when they ported OSX to ARM (ie, iOS, nee iPhoneOS).
Another is Safari (which was useful/needed on Mac at the time) but more importantly was critical in making the iPhone successful - mobile browsing sucked before the iPhone.
I’m not an Apple insider, but I don’t believe LLVM played a substantial role in either the PPC-to-x86 or x86-to-ARM-for-iOS ports — the former was accomplished with Rosetta and a lot of bugs.
The current rumor, OTOH, is that Apple’s collection of LLVM bitcode for apps is intended to allow painless migration for applications when macOS is switched over to ARM.
Has anyone been able to execute built-for-x86_64 bitcode on aarch64 ever?
I will say, however, that executing LLVM bitcode on different targets than the compilation machine is a subject of active research. It's one of the things that I work on in my day job.
Bitcode is not [12:30] a magic solution, though. You can't take a 32-bit app, for example, and run it on a 64-bit device. That kind of portability isn’t something that Bitcode can give you, notably because that is something that's visible in C. As you're writing C code, you can write #ifdef pointer size equals 32, and that’s something that Bitcode can't abstract over. It's useful for very specific, low-level kinds of enhancements, but it isn't a panacea that makes everything [13:00] magically portable.
What’s funny, is later on after Apple shipped a 64 bit chip for the Apple Watch. He admitted that forcing developers to ship watch apps as bitcode allowed Apple to recompile all of the third party Watch apps on the fly to support it, he knew that was coming, but couldn’t say anything at the time.
https://twitter.com/clattner_llvm/status/1046960724646465541
Similarly, someday MS will remove live tiles from the start menu. It’s inevitable, but clearly internal politics are keeping the feature around. Guaranteed that 99% of humanity will rejoice when it happens, but equally guaranteed that someone on HN will express how appalled they are that a company as big as MS didn’t choose to keep the feature alive for the sake of the handful of people who liked it.
I can't even recall how to invoke Dashboard. The fact that was always hidden meant I never used it.
This was a space that was useful, and then became saturated and commercialized to the detriment of usefulness. It was just before we had good off-screen rendering, right as the html-and-js-as-desktop-apps was starting to take off, and when transparency in window rendering was still difficult. I could share a lot more thoughts
Is there an opportunity to fill the void? I'm really not sure. Bear in mind that this was well before the iPhone hit and smartphone apps got huge. Most of the things we did with widgets back then are far easier done on our phones now. Kapsules had some good parity with what Konfabulator and Apple Widgets had offered, and I can't name a single widget for Kapsules, aside from the silly barking hamster, that doesn't ship by default with our phones now.
The widget craze was a fun phase of app development, and no doubt influenced UX and mobile apps, but I consider it merely an interesting footnote now. If anyone is interested in the source code for Kapsules, I can probably dig it up from one of my old HDDs. It was written in C# on .NET 4.0.
Also siri can be configured to have text-only input. a long hold of cmd-space will pop up an additional window where I can type "weather in london" or "time in london" etc.
I missed multiple calculators by default as in Windows. I found a simple Apple Script accessed with 'mcalc' that made this a bit easier for me.
do shell script "/Applications/Calculator.app/Contents/MacOS/Calculator -background >&/dev/null&"
I use multiple calculators for quick reference and when testing various implementations of my work, and was baffled that Apple explicitly stopped my from doing that with their stock calculator.app
open -n /System/Applications/Calculator.app
When I four-finger swipe left for Dashboard, stocks and weather take several seconds to load, and to use the calculator I actually have to click inside of it. And visually they all look like toys that bear no relation to current OS look and feel.
Two-finger swipe-left from right edge brings up Notification Center with weather and stocks always instant (so much faster), and I use cmd-Space for Spotlight for all calculations and conversions without having to click/tap ever, just using my keyboard. And since Spotlight allows me to type complex math expressions with parentheses, I've never had a need for multiple calculators. And then Stickies has a dedicated app.
So except for multiple unit conversions (which I've never needed)... I'm personally very glad we've moved on from Dashboard.
Hot damn! That's the most useful thing I learned today!
Edit: and fun fact, if you hate Electron, don't go looking under the covers of Dashboard... it's tons of old-school web tech cruft. Fun, if you're into it.
For example, I know there is a contingent of people who are stuck at Adobe CS6, whose certain critical components are 32 bit. Since Adobe no longer sells permanent licenses, opting to only rent their software instead, it's impossible to get these updated. And these expensive and still-in-use licenses are going to die the moment people update to Catalina.
Parallels is, perhaps not coincidentally, not as terrible at running macOS as some other solutions, but it's still fairly poor.
It's not. I've run macOS under a hypervisor with GPU passthrough and it's essentially as fast as on metal (I think you can see a single digit percentage difference in benchmarks). I don't think anyone has a soft 3D driver though for macOS guests. Parallels and VMware have both put a lot of work into getting some level of soft VM based 3D acceleration working for Windows guests, presumably because that's where the demand is. At the same time macOS has been built heavily around GPU for everything for a very long time now, initially as a way to improve even basic interface smoothness in Aqua back in the day. So it's a dog in pure software on a VM. It really needs a GPU.
FWIW, in the past VMware did officially have Mac Pros on the hardware compatibility list for ESXi (up to 5.5 I think? maybe the trashcan lasted longer). And that in turn would be legit for running a Mac guest. I've read you can sort of get it to work on other Macs like the Mini, though secure boot must be disabled and the T2 causes other issues. Otherwise you need to patch it, or go with KVM or some other alternative.
[1] https://notebook.yasithab.com/macos/disable-sip-in-macos-vm-...
I still think I'd rather dual boot though.
https://support.apple.com/en-us/HT208891
I've done this to install a beta, but not to try to install an older macOS version from a newer release. If for some reason, the Mojave installer won't launch from Catalina, then you could create a bootable Mojave installer:
Installing macOS on a separate APFS volume https://support.apple.com/en-us/HT208891
“APFS makes it easier than ever to switch between versions of macOS, including a beta (prerelease) version of macOS.”
I'm actually sad because I wanted to find a replacement that had:
- layers - Good text engine - good magic wand
I use Photoshop/Illustrator for very basic collage style works and those are the tools I need.
I was excited to try gimp, but it was slow enough on this Mac that I gave up. Inkscape is on the list, but my hopes are low.
That said, I think its low price point has started working against it. New releases come at a glacial pace, and a few broken features have literally had fixes in the works for years (expand stroke is the standout). When the last thing I bought from the company was a $50 purchase four years ago, I can’t really complain, but in retrospect, I wish Affinity had gone the Sketch route with an annual upgrade program. I’d like to pay more to see Affinity Designer advance faster, but presently there’s no option to do so.
Also, while people are even more likely to forget Graphic Converter since it first came out in 1859 or something (this may be a slight exaggeration, but my point is, it's been around a long time), it has some neat tricks up its sleeve. I sent business cards to a print shop that required CMYK PSDs by doing the work in Acorn and converting in Graphic Converter.
If you were already using Cocoa, and were heeding deprecation warnings for the last 10 years, there should be zero issues.
Of course, with lots of software (especially projects started decades ago) it might have been difficult to do this. But the only paths forward were
(A) expect to drop support once 32-bit was removed
(B) gradually replace components which were dependent on things without 64-bit versions
(C) wait until 32-bit support was removed, then have a terrible time updating
And the writing on the wall has been there for a very, very long time.
This is fine for the producer, who can drop support for old software. It's not fine for the consumer, who may not want to pay yearly for their software and therefore don't want to upgrade to the latest versions.
I don't see why Apple couldn't provide an optional compatibility solution, even if it were something I had to download separately.
Think CS6 is still a viable option for Windows 10 users though.
It's an amazing framework. Sure Flutter and others came first and already did parts of what SwiftUI+Combine do, but being able to take an app from design mockups -> interactive prototype -> final version right in the same editor and using the same language for UI, logic and model (with native APIs and look-and-feel) is something I've fantasized about since forever.
There are many rough edges (just like Swift itself which took like 3 years to become good enough for "serious" use), you still need AppKit/UIKit for some things, and Apple's developer documentation remains appalling as ever, but I was able to turn a bunch of ideas into usable apps in a matter of hours, that traditional frameworks would have taken me weeks to do.
I hadn't even planned or expected to make "proper" apps with it, I was just playing around, iteratively adding to mockups, and boom, there was an actual app on device.
Catalina itself however was the buggiest macOS beta for me. I permanently lost random files on iCloud Drive, CPU and network usage was always high, and I had to use a temporary local user account that was not tied to iCloud to avoid messing things up.
And it's annoying that they still haven't fixed some minor bugs I reported since the Mojave beta, like unreadable white text on brightly colored tags in Dark Mode and Books jumping around between desktops on its own (the kind of stuff that would have infuriated Steve Jobs I assume but is deemed unimportant now.)
SwiftUI is walled-garden bait. Hard pass.
EDIT: Not sure why I'm being downvoted - (one of) Flutter's main selling point is that it's cross platform by default. SwiftUI doesn't do that and yet is marketed to be very similar in coding style to Flutter, which yeah great, but no cross platform so you still have to code everything twice, unless all your users happen to have iPhones. I mean really?
and macOS, tvOS, watchOS (and soon I suppose, AROS?), all counting for over a billion devices.
You can literally run the same SwiftUI code on all of them, then make small changes to adopt each OS's unique paradigms (like menus on macOS, the crown on watchOS, the remote on tvOS) and get the most native performance via Metal etc. for free.
It's ideal for publishing to services like the new Apple Arcade and macOS/iPadOS Catalyst.
How is Flutter for accessibility features? Those seem really effortless to adopt in SwiftUI.
SwiftUI gives me my device's native performance and UI.
As a view on the other side; I develop business apps. They are distributed via a local enterprise store, and never appear in the public App Store. Often, my apps replace paper in old-fashioned businesses. It's very honest and satisfying work.
I was just looking into this yesterday but found no info - so you're saying it's now possible to write an iPadOS app with SwiftUI and use Catalyst to port it to macOS? It used to be a "known issue" in the beta that this was not supported... does this work now?
You can of course write regular (non-Catalyst) projects that share a lot of the same code between Mac and iPad. In that case you may not even need Catalyst, so maybe Catalyst is only UIKit-on-Mac.
That said, the app running out of the box needs a lot of work to feel like a proper macOS app.
It's not native, it emulates native UI. What happens when they can't keep up with the updates for all the platforms they plan to support.
Also, I don't think they support platforms other than iOS/Android, desktop and web is planned, but that doesn't help me now.
I do agree with your premise though, but I use React Native for a true native UI, plus it can target Windows, MacOS, Android, iOS, and Web.
RN is Javascript so it will execute on the device's JS runtime, which I guess is connected to the browser in some way, but RN doesn't use the browser for UI. The rendering is true native UI.
The way React does this is by decoupling the core library from UI rendering. The core React library contains no UI rendering code, it just handles UI lifecycles, internal state, events, etc. for logical UI components as object instances. You then plug that into a renderer library (most commonly the "ReactDOM" lib for web browser rendering).
Close. RN uses JavaScriptCore (Safari's JS VM). On iOS it will use the system provided VM. On Android, it's bundled with the app.
Hermes (https://hermesengine.dev/) is the new Android JS VM optimized for boot time and memory usage.
ART running on Fuchsia gets better every day.
Some of my issues where that sometimes the buttons seem to have a very small hit-box (yea, I changed that but it didn't help), you have to use lists because tables mess up certain animations, lists always have this separator line, the documentation is not really there, ....
I started to use it from the 3rd beta and still, the API changed with every update and generally it felt more like an alpha. Overall I wouldn't do much more than a simple example ToDo app with it and definitely not rely on it for a product.
I definitely managed to make something a little more complex than a To Do app though. See the demos from other people like @MengTo [0] to see what's already possible.
Lists etc. will be customizable once they open up the -Style protocols. Try ScrollView -> VStack -> ForEach for now.
> Upgraded reminders aren't compatible with earlier versions of iOS and macOS. If you upgrade your reminders on your iPhone with iOS 13, your iPad and Mac using the same iCloud account can’t access your reminders until iPadOS and macOS 10.15 Catalina are available. from https://support.apple.com/en-us/HT210220
https://www.obdev.at/products/littlesnitch/releasenotes.html...
https://www.obdev.at/support/index.html?product=LS&topic=faq...
This seems like a sizeable change.
Basically for many musicians, upgrading macOS will mean killing some of their plugins.
You'll find plenty of threads on forums like Gearslutz, asking for tips on how to downgrade brand new Macs to an older version of macOS that doesn't even support their hardware. Or 2019 threads asking if it's now safe to upgrade to High Sierra. They're typically 2-3 versions behind. Why ? Older is just safer, better in their worldview.
In that context, audio developers know they have customers on their side against "evil Apple that's always breaking everything for no benefit", and every year in September/October they get away with emails that read like Apple just unexpectedly dropped a huge bomb on them out of the blue, and it'll take them 6-12 months to get ready, like WWDC and 3-4 months of developer betas never happened.
They're writing audio plugins using the AU or VST APIs. They don't ever touch hardware or even deal with realtime constraints directly : they just fill buffers as far as they can and pass them on to the host DAW application, which together with audio interface drivers + the OS deal with the hard stuff.
As a DJ, My Serato set up _works_. I don't have any show stopping bugs, and I don't want any new features. It's running on Sierra with an older version of Serato from like 2 years ago. Why do I need to upgrade the OS?
When I'm playing in the Club, I shut off wifi/bluetooth, and everything else that I can.
If I could simplify even more, I would. General Purpose computers are both great and a liability when it comes to digital audio especially for any live performance.
It's the developers job to do so, and they're basically procrastinating for as long as they can, not heeding Apple's deprecation warnings for _years_ and then trying to blame them in front of users when st finally hits the fan, pretending they couldn't possibly have known. That's simply dishonest.
To the extent businesses care about reducing losses from cyber attacks, that’s probably useful.
Now we have Catalina, which shares a base with iOS 13, which according to numerous reports is very buggy... I don't want to touch Catalina with a ten foot pole. The fact that my copy of CS6 would stop working is icing the cake.
I should get one more year of security updates on High Sierra. Not sure what I'll do after that...
I'm not updating to Catalina either, I plan to stick around on Mojave until they release something that actually makes me want to upgrade. (maybe when Catalyst matures)
How do you do a clean install? Is this available from the recovery menu?
Doing the dreaded "clean install" fixed my issues (primarily a Finder that would routinely spend up to 30 seconds or more displaying the contents of any folder).
Up until Mojave, I'd never done a "clean install" on a Mac for performance reasons. Once doing so worked for my laptop, I followed suit on my desktop.
Haven't reinstalled that software. It may have been the root cause.
I used to use uBlock Origin and forget about it, but now I don't know what to use. The market feels scammy or very expensive or even both.
Struggles with some videos, and YouTube in particular. But, as @jzl wrote in the sibling comment, most ad blockers require that their app is running as well, for them to function. "Ad And Stuff Blocker" does not, which is why I'm trying it out. Has been treating me well for two weeks.
I tried the demo earlier this year and liked it a lot, and they even happened to have a promotional discount at the time, but for whatever reason the purchase button was broken for me. I’m sure it was either just my machine, or Phase One has fixed the bug long ago.
I'm curious about what kind of T&C will need to be accepted for this to work.
https://www.stclairsoft.com/Go64/
Note: I haven't tested it.
1. Click the Apple symbol () in the menu bar on your Mac's desktop.
2. Click on About This Mac.
3. Choose "System Report" at the bottom of the window.
4. Scroll down to the Software list on the sidebar.
5. Select "Applications."
6. Scroll all the way to the right to see the 64-bit list.
[0] https://www.macrumors.com/guide/32-bit-mac-apps/
You can sort on the "64-bit (Intel)" column to separate 32-bit from 64-bit apps.
When I tried this on my crufty main machine, Step 5 would yield a timeout and a very unhelpful error message. Works OK on my work machine. YMMV
[0] https://www.macrumors.com/guide/32-bit-mac-apps/
EDIT: formatting, punctuation
Apple's become a phone company that grudgingly still makes computers, and this is reflected in their treatment of end users.
If you're using Chrome, this may be the result of a bug in Chrome. Have a look in Safari, it should be fine there.
Other issue is that arduino flashing is broken for my redox wireless keyboard, so I have to flash firmware on my old laptop for now. Something to do with super low baud rates not working in catalina!
Other than that, nothing in catalina that gets me excited, the screentime thing is pretty broken, it shows the same amount of time for all apps pretty much, so kinda pointless.
https://bugs.chromium.org/p/chromium/issues/detail?id=100596...
I remember when Apple dropped the CD-ROM drive....I haven't used a CD/DVD since 2013...over 6 years ago and I cannot remember a time when I needed to use one other than playing old DVDs which is not a big deal with Netflix & co.
Until now I've pretty much been a day 1 updater with MacOS. Nope.
This means you're probably already using latest Catalina on the device that's on the beta cycle and you will continue getting new minor releases before the general public release one.
To see what's still 32-bit on your mac, go to:
Apple icon > About this mac > system report > applications > then click the 64-bit column to sort. No will be 32-bit apps.
I have a playlist called "ipod" that I select to sync to ipod. I have certain podcasts that I select to sync to ipod. I plug my ipod in and click sync. The end. I've been doing this for 10 years.
Now what?
- return of scripting, alright maybe not AppleScript, but JS, Python, anything: I want to automate my UI meanderings, what the hell
- return of services: make this a reminder, make this a note, send this as email, etc. come on
- a chat app with windows: why is it exactly that every Telegram and Twitter and whatnot has me clicking back and forth and back and there and back and here, why? also why can't I open a chatroom with these three WhatsApp peeps and this one Twitter dude and my mom on Skype? this is backwards
- return of managers: at some point iTunes stopped being my 90+GB music library manager, and became hell knows what. same with Photos, Safari, Mail. all full of cloud and gotchas and eye-candy that keeps me away from my stuff by making me wait.
- the return of self-published dashboard widgets. they are awesome. I'll be where they are, thank you very much.
- Services isn't gone.
- Yeah, that's fairly annoying. I think Skype has tear-off-able windows but that might only be for voice calls, not chat windows.
- The new Music app (which is really just iTunes with all the videos, podcasts, and other crap ripped out) now just manages music — it's oriented towards Apple Music by default but a couple of clicks in the View menu changes that.
Python is still installed by default. Launching /usr/bin/python (2.7.16) prints a big warning about how "future versions of macOS will not include Python 2.7", but that's because Python2 is EOL.
At a glance, the new Podcasts app isn't scriptable but the TV app is.
Script Editor.app and osascript both support Javascript
Is this directed towards Apple? Cause they only make one chat app, called Messages, which lets you open conversations in separate windows.
Each time I tried to enter my password the focus would glitch back to the large background window, which oddly could still be clicked. So I had to keep clicking grayed-out Continue buttons in the background setup window, until the desktop finally appeared and the password prompt (which was in front the whole time) would finally accept input.
I mean, this is the first thing you see when you launch the OS, these are exactly the kinds of bugs that need to be found by Apple and not by users.
When I upgraded my iOS devices to 13, my shared To Do lists stopped working in macOS. Each item in the list has a warning triangle next to it that explains I have to upgrade my desktop OS to use the lists again.
It turns out that I underestimated the importance of the grocery list shared among my family members. I now have five gallons of milk and no kitty litter in the house.
(1) wipe disk, install new OS, & reinstall apps & documents
(2) let apple try to upgrade in place
Have they fixed mission control's top bar not expanding by default yet? That would be the only reason to upgrade.
Instead of showing you labels or icons in a task switcher, they just showed you all your windows. Direct representation instead of symbolic proxies.
"Desktop 1/2/3" is meaningless. Show me what's on it so I can see where my windows are. Don't put a dumb gesture between me and what I need to see.
They only did this because of tiny screens, it makes zero sense on any decent monitor.
Old Apple would've put in a hidden pref, tracked its use, and then quietly eaten crow. New Apple thinks they know better than even their power users. It's ridiculously arrogant.
overall performance seems better. connects to wifi network faster.
default shell on terminal is now zsh.
will upgrade homebrew managed packages now, Catalina bottles are available.
Yeah, no thanks. Until Apple learns to release non-buggy crap I'll wait out the horror show for at least the next 6 months. You guys have fun debugging this for me!
EDIT: Pretty funny watching all the Apple fanboys going through my account and downvoting all my posts. Oh no! My fake internet points! /s
Don't fool yourself. Maintaining 32-bit support is "easy" (with all the technical issues we all know). This is simply a sales strategy.
It's the same strategy than disabling a glorified vnc (Sidecar) on three years "old" laptops. Sure you need a lot of horsepower to display a remote image in real time. Never done. Yeah.
Apple is taking the "appliance route". Your (my) Apple computers, your (my) Apple phones...are closed appliances (no ram upgrade, no battery upgrade, no significant OS upgrade). This appliance version do this, the next appliance version do that. Soon we'll see that they're no longer upgradeable computers, and we will be fine with it...sadly.
It's that experience and knowledge that makes me question some tactics.
I think it's not bad to question things, right?
[ ] We remove 32-bit support because is better for our users. [ ] We remove 32-bit support to push a sentiment of obsolescence on our users.
Choose yours.
Otherwise it was all Apple or irrelevant.
(Sufficiently out of it to wonder if Catalina was related to Messalina ...)
I searched for "Catalina" in a private browser window and got exactly two results about today's release news, then a whole lot of Catalina Island results.
Very disturbing that one of the biggest companies around can't keep 32-bit support, at least in some capacity.
Removing 32 bit support hurts users.
However, I think it's worth asking, who was that hurting? Users certainly aren't going to notice, and license activation isn't performance-critical code.
No, but DRM is pretty likely to require your OS to remain exactly bug-compatible with older versions. After all, the entire point is for it to cause trouble if it detects unexpected changes in system configuration or behavior, even if those changes are within the scope allowed by loose API definitions or undefined/unspecified behavior. E.g. it's pretty much expected that when an OS tightens security restrictions, it'll break a lot of DRM and video game anti-cheat systems. Inserting a new compatibility shim is also likely to be mistaken by those systems as a circumvention tool.
It drives me nuts that installers and license managers are old and crufty. I do understand why. A few times now I've encountered situations where the installer cannot run even though the software it installs is fine.
Separately, I feel like Apple should deal with it. They're one of the richest companies in the world and they can afford to maintain extra copies of libraries, possibly indefinitely. No one is asking them to go full-on Microsoft and explicitly test against old 3rd party apps. But, Apple clearly doesn't care, and I can't do much.
I hear a lot of post hoc justifications from Apple fans about how hard to maintain the compatibility layers are. But. It strikes me that a job has fun and not so fun parts. If there is really an ongoing maintenance issue generating more work release-to-release maybe look to re-design how the compatibility layer works.
I agree. The problem is when the major ISVs abuse this and force Apple to keep doing high-priority QA to preserve binary compatibility with major applications that are mission-critical for many Apple users and are still maintained to some degree.
Users of unmaintained applications are generally somewhat understanding or accepting of gradual breakage driven by real technical necessity. Users with an active subscription to Adobe CC rightfully have higher expectations that their software continue to work without being broken by OS updates - but Adobe was trying to make that entirely Apple's problem, just as they did for migrating away from PowerPC and Carbon APIs.
If you run `otool /System/Library/Frameworks/AppKit.framework/AppKit -f` you'll see 2 slices, one for "cputype 16777223" (CPU_TYPE_X86 | CPU_ARCH_ABI64) and one for "cputype 7" (CPU_TYPE_X86).
This is exactly what Linux distros are planning to do.
Linux solves it differently, it uses separate binaries for separate architectures. You can install the libraries into separate paths, have separate dynamic loader and everything works. Apple has no such option.
(This even applies to the base Unix system calls. Go previously did syscalls by hand but recently switched to dynamically linking against libSystem and using its wrappers, because they’re the only guaranteed-stable interface.)
> Nobody wants to carry support for both 32- and 64-bit forever.
Support means money and developer time, no one wants to waste money unless they really have to. In this case they don't have to, because everyone should have already updated whatever they use that was first made only for 32bit to 64bit.
imho the actual blame lies on whoever have resisted moving to 64bit(again mostly because of money).
On the other hand, yes Apple has great margin but companies are not charities, they don't stop making money when they have "enough". When they make more money than expected, their stock rises, they pay some dividend, CEO gets a nice bonus and everyone gets back to work to figure out how to make even more money.
You can argue that Apple is already charging a premium to be user friendly, and 32bit support is also an item that can count as being user friendly. That would be a valid argument.
Actually this might be the reason they are only now stopping it and have been ok with supporting it until now(2019). Similarly there is a reason Apple computers don't have CD-ROMs anymore, this is because the vast majority of their users, don't care about CDs at this moment, the industry has mostly left it behind to better alternatives, those who have not(think medical devices that are expected to be function for 50 years because they are expensive) make support agreements for 20 years or something with corporate friendly manufacturers/developers such as Oracle and Microsoft etc. or just write their own OS that no one can deprecate. See how Redhat Support of Python 2 for example, Python 2 will be ancient on January 1 2020, but Oracle needs to support it because that is how they make money, being very very reliable in terms of supporting stuff. [1]
Finally actually Apples' profits has been dropping as far as I remember because of decrease in iphone sales year over year, so they need to do something to cut costs and get back to the "largest margins" you mentioned again.