MacInTouch Amazon link...

macOS 10.15 Catalina

Channels
Apple, News

Ric Ford

MacInTouch
I've set it up with Mojave running under HFS+ on the internal drive.
T2 functions are disabled (insofar as they can be, using the Startup Security utility).
It boots and runs just fine with HFS+.
If I need to update the OS, I keep a "mule drive" formatted to APFS with a copy of Mojave on it, and Software Update can be used on that drive. But other than for updates, it is never booted or used.
That's an interesting approach, but how exactly do you coordinate updates with your main system? That is, how do you migrate and merge updates from the "mule" drive into your main HFS+ system without causing problems, such as wiping out user preferences or breaking compatibility with something due to update changes?
 


I have grumbled here before about my main 32-bit concern. I have an absurdly expensive Hasselblad Flextight X1 film scanner that looks like becoming a giant paperweight when my last Mac running High Sierra dies. It requires proprietary software from Hasselblad, and they refuse to say what their plans are. I know they approached a large scanning software company but couldn't make a deal (LaserSoft, I believe). Ed Hamrick has said he can adapt VueScan but they won't give him any engineering details to permit this.

I fear Hasselblad will abandon these rather special scanners. I did make a VM in Parallels that will run the software fine, but Parallels can't see FireWire ports.

Amazingly, High Sierra can see and communicate with the scanner using a FireWire 400-to-FireWire 800 cable, a FireWire 800-to-Thunderbolt dongle, and a Thunderbolt to USB-C dongle, all daisy-chained. I guess if a VM environment is made that will utilise the USB-C ports on current Macs, it might be worth trying again.
 


I fear Hasselblad will abandon these rather special scanners. I did make a VM in Parallels that will run the software fine, but Parallels can't see FireWire ports. Amazingly, High Sierra can see and communicate with the scanner using a FireWire 400-to-FireWire 800 cable, a FireWire 800-to-Thunderbolt dongle, and a Thunderbolt to USB-C dongle, all daisy-chained. I guess if a VM environment is made that will utilise the USB-C ports on current Macs, it might be worth trying again.
It should be able to be passed to the VM environment by Parallels as a USB (or Thunderbolt) attached device. Some combination of these settings should do it:
 


Given that I would have to pay thousands of dollars to replace my 32-bit software, I, for one, would be willing to pay $200 for continued 32-bit support...
No need to pay; just keep using what you have. When Apple releases 10.15, just don't upgrade to it. Save your money for any repairs needed by your existing equipment. It may mean having to abandon some of the subscription software from vendors who are transitioning over to 64-bit but that's the other vendors, not Apple. With a little imagination and effort, one may keep using the 32-bit versions for many more years.

Alternatively, there's Windows (or Linux, if you don't mind the sort of applications that pass for professional level there). I am not being facetious here. I used to say that Windows wasn't that bad but Apple's laughable UI and file system changes have made macOS and Apple hardware much less desirable.
 


You hit the nail on the head, and, in fact, Apple's customers are paying a great deal of money for software updates, it's just that Apple hides that with accounting tricks that make software expenses appear to be "free" when they are actually incorporated in Apple's exhorbitant hardware prices and counted as subscription revenue!
The two go hand in hand. If Apple would unbundle the software pricing (e.g. charge money for upgrades), then they would have a clear indication, on their balance sheet, of how many people want the new software and how many do not (because the sales figures will indicate how many people are actually willing to pay).

By bundling it all together as "free" upgrades, they have no clue. Their revenue is completely unaffected, whether everybody upgrades or if nobody does. And they get lots of people who upgrade simply because it exists, without giving it any thought - people who would consider that decision if it cost them $130 a pop.

So, Apple has no (financial) feedback about whether anybody likes or wants their new software, and we can all see the result.

You could argue that hardware sales will reflect this, but that's a much more tenuous connection, and it is probably impossible to link those figures with what customers think of the software.
But why must there be two sets of APIs? Back to z/OS: it doesn't have different APIs and services for 24-bit, 31-bit, and 64-bit programs. There's just one set of APIs and services for applications to use.
There are separate sets of APIs. The fact that you might type in the same function calls in your C program (or whatever language you're using) doesn't mean there aren't three different libraries containing three different implementations of those calls, all of which need to be maintained, tested and supported, and which IBM's customers pay quite a lot (in ongoing maintenance fees) in order to have.

The only way you could truly have only one set of calls would be for every single system call to result in sending a packet of data to a completely independent API server process (some kind of remote procedure call). Doing that for literally every system call would completely cripple performance, so it's unlikely anybody would do it outside of a research project.

(This is, of course, one of the fundamental design points for microkernels and is also why microkernel-based operating systems don't perform well and are not used commercially without hacks that violate this design for many timing-critical parts of the OS.)
Now, if you're talking about dropping the Carbon framework, that could save on development effort. But that's not what they're doing here. Apple is also dropping support for 32-bit Cocoa applications. In fact, as far as we know, Apple is changing macOS so it won't even execute 32-bit code, even if it uses no frameworks or APIs. Are there really separate 32-bit and 64-bit Cocoa frameworks? Why was that necessary?
There are most certainly separate 32-bit and 64-bit Cocoa frameworks, as there are 32- and 64-bit versions of the underlying BSD/Unix functions, the C library, and all of the other library code that an application requires.

There also needs to be code in the OS kernel to correctly execute both 32- and 64-bit code at the same time. It doesn't "just happen". The scheduler (that makes multitasking happen) needs to switch the CPU between the two operating modes, which include two representations for process/thread state and lots of other critical functions.

All of this is software that needs to be maintained, upgraded and supported. You and I can argue about whether it is wise for Apple to spend money on this maintenance and support, but you can't argue that the work doesn't have to be done.
 


There are separate sets of APIs. The fact that you might type in the same function calls in your C program (or whatever language you're using) doesn't mean there aren't three different libraries containing three different implementations of those calls, all of which need to be maintained, tested and supported, and which IBM's customers pay quite a lot (in ongoing maintenance fees) in order to have.
This may be what Apple did, but I still don't see why they had to do it this way.

What IBM did for z/OS is to just make the API's compatible at the higher address mode. To go from 24-bit to 31-bit, they made the APIs and services 31-bit compatible, but they can still be called by 24-bit programs. In some cases, to get full 31-bit capability, a 31-bit program needs to change their call slightly; otherwise it still works the same as it did for 24-bit.

Behind the scenes, increasingly large parts of the run-time systems operate in 64-bit mode, even if the caller is 31-bit. It isn't like, if you're 31-bit, you don't get to use the 64-bit implementations of the function calls.

I think you're saying that to have one run-time would require an RPC-type call, in order to switch from a 32-bit process to a 64-bit process. That's not how it works on z/OS. Any process can switch modes at any time, even in application code. It takes a single instruction.* So, if you're in 24-bit mode but need to be in 31-bit mode, you just switch the mode. So, in the system code, if it is called by a 31-bit program, it can switch to 64-bit mode and then back again.

On z/OS the scheduler switches the mode while multitasking, but the mode is just a single bit on the hardware's Program Status Word, so this is not a performance impact. There are not different process states or anything like that.

Maybe really what's at issue here is the z/Architecture Instruction Set architecture. It doesn't have different instructions for 24-bit vs. 31-bit vs. 64-bit mode. Any program can use any of the instructions. All the address mode does it tell it how to interpret addresses; for example, in 24-bit mode it ignores the first byte of an address, in 31-bit it doesn't. A 31-bit program can use instructions that use all 64-bits of a register.

(I suspect one of the drivers of Apple's moratorium on 32-bit code is there could be two different Objective-C run-times, with different formats for the Objective-C compiled objects. But I still don't see why there had to be two different run-times, instead of one run-time that handles both object formats.)


* It actually takes less than a single instruction, because you switch modes and branch at the same time. So if you're already branching to somewhere, you get the mode change as a bonus. And, the system automatically changes modes when needed, such as when one program calls another via a "link".
 


<lots of good comments>
Of course, the driver for these changes may not be anything yet discussed...

Consider the cost for conversion of code to another instruction set processor, for example, Intel to ARM.

Or, even, code memory and storage footprint. The fewer applications and library variants that exist, the less testing and support costs.

Along with this, fitting high-function code into wearable devices becomes more feasible. For iDevices (iPad, iPhone, Apple TV, ...), less storage for code means less memory and bandwidth occupancy and more room for all those downloads.

This is most likely part of the general trend from Apple Computer to Apple, the media and life { style | support } company.
 


I would rather pay for a solid major upgrade every two years or so than deal with Apple’s yearly releases—especially if Apple were also releasing compelling hardware on a reasonable schedule.
Absolutely! I think the prospect of potential lost sales motivated Apple to do a better job [in the past]. It was an incentive to release quality software and to quickly fix any serious bugs that did slip through. I had no problem paying $129. The way I see it, the time it took me to save up the money gave them time to fix the initial bugs.
 


Absolutely! I think the prospect of potential lost sales motivated Apple to do a better job [in the past]. It was an incentive to release quality software and to quickly fix any serious bugs that did slip through. I had no problem paying $129. The way I see it, the time it took me to save up the money gave them time to fix the initial bugs.
Absolutely. I'd rather pay for quality software and privacy than have neither for free.
 


I think you're saying that to have one run-time would require an RPC-type call, in order to switch from a 32-bit process to a 64-bit process. That's not how it works on z/OS. Any process can switch modes at any time, even in application code. It takes a single instruction.* So, if you're in 24-bit mode but need to be in 31-bit mode, you just switch the mode. So, in the system code, if it is called by a 31-bit program, it can switch to 64-bit mode and then back again. On z/OS the scheduler switches the mode while multitasking, but the mode is just a single bit on the hardware's Program Status Word, so this is not a performance impact. There are not different process states or anything like that.
Interesting. I've never seen anything like this in the Unix world. Multi-architecture systems, including Linux, Solaris and others require each process to be a single architecture, 32- or 64-bit. Standard shared libraries (like the C library and other system services) require both 32- and 64-bit versions in order to dynamically link against processes of the matching architecture.

Switching modes on an x86 processor is definitely not cheap. Note that 64-bit mode adds additional registers that don't exist in 32-bit mode, and all the registers change size. Trying to change modes while preserving the memory organization (page tables, pointers, caches, etc.) is going to be a non-trivial operation - definitely a lot more than a single lightweight instruction.

An RPC mechanism might not technically be necessary, but it would still require an expensive mode switch when entering and leaving system library code if you want to keep a single set of system libraries for both modes.

If mode switching is so lightweight on Z-series computers that this can be done without a significant performance penalty, then that's great, but it's not going to port over to x86.

Would this also be the case on ARM (or PowerPC)? I don't know those architectures well enough to know, but it would almost certainly require a significant change to the portable BSD kernel that Apple uses in macOS.
 


.textclipping files are apparently resource files.
Very interesting. I wonder what is going to happen in macOS 10.15, when the 32-bit APIs (including all of Carbon, where the Resource Manager lives) get deleted. They're going to need to do something about text clippings.

I can imagine a few possibilities:
  • Make a Cocoa port of the Resource Manager (or at least a basic subset of it), so the necessary APIs will remain available in the 64-bit world. This would be my preference, but it also seems unlikely. I can only see them doing this if there are a lot of different standard file types that all depend on resources.
  • Migrate the parts of the resource manager needed for text clippings into the text clipping code itself, so the text clipping library will open the resource fork as an opaque block of data and manually read/write the resources contained within - a hack, but an acceptable one if there aren't any other standard file types that require resources.
  • Change the format of text clipping files to something that doesn't use resources, converting all existing clippings as a part of the OS upgrade - probably the best for most users but will really tick off people who run multiple macOS versions and share clipping files among the systems. (Side question: does anyone actually do this?)
  • Change the format of text clipping files and don't auto-convert existing clippings, but keep an importer module that can read the old format for the next few OS releases, dropping support in the future. Maybe offer to upgrade clippings as they are used as well.
  • Change the format of text clipping files, don't convert anything, and let old clipping files break (the fastest, easiest and cheapest option, even though it is the most user-unfriendly).
I wonder if there will be a third-party (open source?) project to create a resource manager for 64-bit code. I assume the resource fork organization is well documented and it's not likely to change, so there's no technical reason why it couldn't be done. If the developers consist entirely of people who have never seen Apple's source code, working only from public information, there shouldn't be a copyright problem.
 


New Apple Tech Note confirms Aperture will not run on any macOS beyond Mojave.
Apple said:
Migrate your Aperture libraries to Photos or Adobe Lightroom Classic
In June 2014, Apple announced the discontinuation of development of Aperture. Since that time, Apple has released five major macOS updates. For technical reasons, Aperture will not run in future versions of macOS after macOS Mojave. To continue working with your Aperture photo libraries, you must migrate them to the Photos app included with macOS, or migrate them to Adobe Lightroom Classic.
 


I just ran across this article about the IINA media player.
TidBITS said:
IINA is based on the open source mpv video player application (which is, in turn, based on FFMPEG) but is designed as a proper Mac application, so (unlike VLC, which is also based on FFMPEG) it should be easier for Mac users to learn and use.

I don't think it can convert formats (the way VLC and Handbrake do), but it may still be an important tool, given the soon-to-be-abandoned QuickTime 7.
 


I just ran across this article about the IINA media player.
IINA is based on the open source mpv video player application (which is, in turn, based on FFMPEG) but is designed as a proper Mac application, so (unlike VLC, which is also based on FFMPEG) it should be easier for Mac users to learn and use.
I don't think it can convert formats (the way VLC and Handbrake do), but it may still be an important tool, given the soon-to-be-abandoned QuickTime 7.
It also has the ability to find and download subtitles which is also useful.
 


Ric Ford

MacInTouch
It will be interesting to see how compatible Apple's FileMaker products are with macOS 10.15.
FileMaker An Apple Subsidiary said:
FileMaker Pro 17 Advanced release notes
As FileMaker Pro Advanced evolves, the list of supported technologies, APIs, and features will change. As part of this evolution, certain operating systems versions, hardware, and features may be deprecated in favor of newer ones. Although deprecation does not mean the immediate deletion of an item, you should migrate your solution away from deprecated technologies, because these technologies may be removed in a future version of the product.
 


I'm still running macOS 10.12.6 Sierra happily on my two main Macs, and I've been very hesitant to upgrade to either High Sierra or Mojave.

I have a spare Mac in the office, so, after hearing so much about the demise of iTunes and other changes, I went ahead and installed the WWDC build of the macOS 10.15 Catalina beta (19A471t) on it. The spare machine is a 13" mid-2012 MacBook Pro (non-Retina) with 8 GB RAM and a Core i7 CPU. The hard drive is the machine's factory-original 5400 RPM 750 GB spinning disk.

Upgrading this machine directly from Sierra to Catalina took almost exactly an hour from launching the installer to landing in the Catalina Finder, including the conversion of the hard drive from HFS+ to APFS.

So far, I'm very pleasantly surprised by Catalina's performance on this older MacBook Pro. Even with only a 5400 RPM drive, the machine feels very snappy and responsive. I may be imagining it, but it almost feels like opening windows and other basic Finder tasks are faster than they were on this machine under Sierra. Web browsing with Safari also feels quite brisk for a seven year old machine. On the negative side, booting and logging in both feel noticeably slower than under Sierra, but not objectionably so.

Some minor notes:

Apple has switched from BASH to ZSH as the default shell in Terminal.app for new user accounts, but it does not appear to force the switch for existing accounts. Instead, if a user is not using ZSH, a banner message appears at the top of new Terminal sessions explaining how to switch to ZSH manually. This is much better than the last time Apple switched default shells. When Apple moved from Jaguar to Panther, it switched all users from TCSH to BASH without warning users. Maybe Apple is recognizing that there are a lot more developers using the macOS command line today than in the past.

The new Music, Podcasts, and Apple TV apps do not appear to be complete rewrites of those functions but seem to be based on existing iTunes code. For example, the Preferences windows for each of the apps are just slightly modified revisions of the old iTunes preferences, with the same look and feel as the old iTunes preferences. In contrast, the main windows of the new apps have refreshed interfaces. My guess is that the preferences windows will be refreshed to the new look in future betas.

I was expecting that these new iTunes-based apps would continue Apple's recent pattern of poor interface decisions, but, at first glance, they're not bad at all. I actually think the switch to the new apps feels much less jarring than when Apple dropped support for multiple playlist windows in iTunes 11.

That said, I am disappointed that the browsable list of "Internet Radio" stations seems to have been dropped, but at least you can open third party music streams manually using the "Open Stream" command. I had feared that Apple would drop the ability to listen to non-Apple radio streams altogether. If you like having a browsable list of Internet Radio stations handy, I strongly recommend creating custom playlists of stations from the Internet Radio browser before upgrading to Catalina, as it will be much less convenient to create Internet Radio playlists after the upgrade removes the browser. (Note: additions/modifications are no longer being accepted to the iTunes Internet Radio browser, so it looks like that feature probably will just degrade over time if you keep running iTunes on older versions of macOS.)

Unfortunately, installing the Catalina beta removed the old version of iTunes from the Mac, and attempting to run the standalone iTunes 12.8 installer fails with the message that "macOS version 10.13.99 or earlier" is required.

I haven't loaded any third party tools on the test Mac yet, but, bottom line, my initial impression is that Catalina looks very promising, including on older supported hardware.
 


Apple has switched from BASH to ZSH as the default shell in Terminal.app for new user accounts…
I guessed this was due to licensing issues, and a web search shows,
The Next Web said:
Why does macOS Catalina use Zsh instead of Bash? Licensing
Newer versions of Bash are licensed under the GNU General Public License version 3 – or GPLv3 for short. This comes with several restrictions which could potentially have caused a few headaches for Apple further down the line.
Caveat Casual Catalina User:
Catalina's bash is probably version 3.2.57 or so, if that matters to you. The current version is 5.0.
 



Apple has switched from BASH to ZSH as the default shell in Terminal.app for new user accounts, but it does not appear to force the switch for existing accounts. Instead, if a user is not using ZSH, a banner message appears at the top of new Terminal sessions explaining how to switch to ZSH manually. This is much better than the last time Apple switched default shells. When Apple moved from Jaguar to Panther, it switched all users from TCSH to BASH without warning users. Maybe Apple is recognizing that there are a lot more developers using the macOS command line today than in the past.
On a similar note, Apple is now including Python 3 in addition to Python 2.7. Considering Python 2.7 is going end of life in 2020, Apple is really late to the game. It is going to take time for admins to move their scripts to Python 3. There are probably tons of legacy scripts that will never be updated.
 


On a similar note, Apple is now including Python 3 in addition to Python 2.7.
But not for long! Per the Catalina release notes:
Apple said:
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app.
What this means is developers won't be able to assume the existence of any version of a scripting language other than the shell and AppleScript.

Think about how today some installations are started by running a script. It is a chicken-and-egg problem: how does a script download the runtime if the script requires the runtime to run?

Maybe we'll be lucky and Apple will include stubs for the scripting runtimes, that will trigger a prompt to download an installer package, such as how, when you try to use something that needs Java 6, it triggers the Legacy Java 6 installation. (I ran into that recently when using an old version of TurboTax.)
 


I know the Back to My Mac service was often hinky, but it worked well for me. I can also use my work TeamViewer account, but I found the BTMM interface much superior - for example, being able to scroll through the window in zoomed-in view mode. Any ideas why Apple is completely pulling the plug on this?
 


But not for long! Per the Catalina release notes:
Apple said:
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app.
What this means is developers won't be able to assume the existence of any version of a scripting language other than the shell and AppleScript.

Think about how today some installations are started by running a script. It is a chicken-and-egg problem: how does a script download the runtime if the script requires the runtime to run?

Maybe we'll be lucky and Apple will include stubs for the scripting runtimes, that will trigger a prompt to download an installer package, such as how, when you try to use something that needs Java 6, it triggers the Legacy Java 6 installation. (I ran into that recently when using an old version of TurboTax.)
I really have a hard time believing that Apple can remove scripting languages from installs. Mac admins in both enterprise and education live by Python, Perl, and Bash scripts to do their jobs. Heck, Jamf teaches scripting as a key part of Mac management.

But, this is Apple, let's see what they do.
 


Ric Ford

MacInTouch
macOS 10.15 Catalina is bringing radical APFS/file system/installer changes, taking the SIP concept to a whole new level with new mechanisms1 that allow Apple to move system files (/usr/bin) to a hidden, read-only volume, which is stitched together behind the scenes with the writable volume to present what appears to be a single volume but isn't2.

See the WWDC19 presentation by Max Matveev, What's New in Apple File Systems, for more details.

These huge changes impact backup and restore, so Apple has created "APFS Volume Replication with ASR" (Apple Software Restore).3 And macOS Catalina gains the ability to restore from an APFS snapshot (using a delta mechanism to copy only the differences between the snapshot and target volume).

1Including invisible "firmlinks" created by the installer, new filesystem objects that function as a "bi-directional wormhole in path traversal" (different from traditional symlinks).

2Instead, it's an APFS "Volume Group."

3This process defragments the volume, too.
 


Ric Ford

MacInTouch
More major changes and compatibility/deprecation issues, starting with macOS 10.15... kernel extensions (kexts) are being deprecated (with security/reliability justification).
Apple WWDC19 videos said:
System Extensions and DriverKit
One of the next steps in modernizing and improving the security and reliability of macOS is to provide a better architecture for kernel extensions and drivers. Learn how to make this transition with System Extensions and DriverKit.
 


This article clears up some of the confusion over the change from iTunes to individual apps. I am curious what this means for the ability to rip (and burn) audio CD's, for those of us of a certain age who still like to do that. The document does mention that already ripped content will remain accessible, but that's all it says. Does anyone know the answer?
 


This article clears up some of the confusion over the change from iTunes to individual apps. I am curious what this means for the ability to rip (and burn) audio CD's, for those of us of a certain age who still like to do that. The document does mention that already ripped content will remain accessible, but that's all it says. Does anyone know the answer?
We went through some of this over on the WWDC thread. However, the ability to still burn an audio CD from the new Music app is a very good question. Perhaps JoseHill can provide an answer?
 


More major changes and compatibility/deprecation issues, starting with macOS 10.15... kernel extensions (kexts) are being deprecated (with security/reliability justification).
Apple released new driver kits for USB drivers, HID drivers (input devices like keyboards and mice) and some Network devices (VPNs, etc.). Those new driver kits move device drivers for those areas out of the kernel and into "user space". If they crash or are found to have security problems, they will cause fewer problems. It's kexts for those areas that are being deprecated. The next version of macOS will move other driver types out of the kernel and then those will be deprecated. They clearly want all drivers out of the kernel. Keep in mind that drivers are in the kernel because of speed, so it's an open question whether low-level networking card drivers and graphics drivers can be moved.
 


... The next version of macOS will move other driver types out of the kernel and then those will be deprecated. They clearly want all drivers out of the kernel. Keep in mind that drivers are in the kernel because of speed, so it's an open question whether low-level networking card drivers and graphics drivers can be moved.
Kernel extensions (kext) are being replaced by System Extensions. While System Extensions are moved to "user space", they are not normal programs/applications. They are restricted in what they can actually call/invoke, which libraries are included, and some other constraints. As a trade-off, they can request capabilities ["entitlements"] for access to certain parts of the kernel and run at different priority levels then normal apps.

The core of macOS is built around Mach. Mach started off as microkernel operating system back in the mid 80s and refined through the 90s. So it isn't a totally "open question", since this has been researched and implemented for decades. Earlier versions of Mach took Inter-process communication (IPC) a bit to the extreme. The quick fix generally applied to also get better BSD Unix compatibilty was to weave bigger chunks back into the kernel (making it is not so 'micro' anymore). What Apple appears to be doing is a bit of a prune (going back to smaller). There are new mechanisms that support virtualization of IO (e.g. leveraging the IOMMU capabilities of modern x86 CPUs) that could cut way down on IPC overhead. Plus, CPUs are generally much faster than they were in the 90's now.

System extensions can get a capability to get "raw" access to the hardware they are a 'driver' for. So, if you have USB driver capability, then you get low-level access to a USB hardware but only to USB hardware (can't access resources of a GPU or general kernel buffers, but they should not need those). The notion is to give "just enough" access to get the specific task done and no more.

Extreme low-latency Remote Direct Memory Access (RDMA) networking would probably be a problem, but macOS doesn't really support very many 50+ GbE or Infniband networking cards now. General mainstream networking shouldn't be a problem (the kernel needs to provide some efficient copying mechanisms but that shouldn't be a big problem).

Graphics is going to be an issue because it is really the shape and scope of the interface that is both 'below' and 'above' the GPU driver. There is likely a non-trivial interaction with Metal (Apple's GPU interface API) there.

So the "need for speed" isn't really a good enough reason in many cases. Being in the kernel is also a dual-edge sword, because drivers can't do too much. Other parts of the kernel, like the scheduler and general system admin, need resources at a higher priority (if in charge of implementing priority, that trumps everyone else's priority). That means that kexts were limited in how much 'work' they could do, because they needed to 'get out' quickly.

System extensions get higher priority than normal apps, so they are going to get first access to time on CPU after the core kernel gets its stuff done. When the kernel is trimmed down, the resources for "speed" will be there for all but ultra-razor-thin latencies at the ultimate limits of the CPU.
 


So the "need for speed" isn't really a good enough reason in many cases. Being in the kernel is also a dual-edge sword, because drivers can't do too much. Other parts of the kernel, like the scheduler and general system admin, need resources at a higher priority (if in charge of implementing priority, that trumps everyone else's priority). That means that kexts were limited in how much 'work' they could do, because they needed to 'get out' quickly.
User space graphics drivers have been tried in the past (Windows NT 3.x) and performance issues required them to move into the kernel. Context-switching is a killer.
 



I don't know if anyone here is beta testing 10.15, but one thing I haven't read is whether or not the new Apple Music app will have the ability to rip CDs anymore.

Some of the broadcast radio stations I work with use Macs in their production studios and often still rip discs to ingest into their automation systems, and while there are plenty of apps out there that can do this, some preferred the simplicity of iTunes. I wonder if this will be their push to have to lean toward something else, such as XLD.
 


I don't know if anyone here is beta testing 10.15, but one thing I haven't read is whether or not the new Apple Music app will have the ability to rip CDs anymore. Some of the broadcast radio stations I work with use Macs in their production studios and often still rip discs to ingest into their automation systems, and while there are plenty of apps out there that can do this, some preferred the simplicity of iTunes. I wonder if this will be their push to have to lean toward something else, such as XLD.
The forum member here, JoseHill, confirmed that you can still rip CDs as normal. It's now also documented in my MacStrategy article, along with lots of other useful questions and answers:
macOS 10.15 Catalina Frequently Asked Questions
Q. If iTunes is discontinued/gone can I still "rip" a physical CD?
A. Yes. The process is exactly the same as before, but now done by the new Music application - inserting a CD launches the Music applications, looks up the Gracenote/CDDB metadata, and offers to import the CD.
 


User space graphics drivers have been tried in the past (Windows NT 3.x) and performance issues required them to move into the kernel. Context-switching is a killer.
Yeah; but, as noted, processors are quicker these days, and we have many cores to hand. It should work well enough, and probably a lot better.
 


User space graphics drivers have been tried in the past (Windows NT 3.x) and performance issues required them to move into the kernel. Context-switching is a killer.
Windows NT 3.x is the same mid-1990s context that Mach 2.0-3.0 was in. The amount of hardware in the CPU to support rapid virtualized contest switching was relatively non-existent. The huge push over the last 10 years in x86 (and other instruction sets) to support the massive amount of deployed virtualization is very substantial.

Folks today are running cloud gaming services where multiple gamers are logged into the same GPU running different games at the same time. With the hardware from the 90's, that wasn't practical. It is now.

Apple pruning off systems with relatively slow (or no) IOMMU capabilities opens windows of new possibilities.
 


Given that I would have to pay thousands of dollars to replace my 32-bit software, I, for one, would be willing to pay $200 for continued 32-bit support...
It is not just software that you might have to replace but hardware that has 32-bit drivers. I love my Canoscan scanner. Their driver is 32-bit. As they no longer sell it, they seem to have no interest in providing a 64-bit driver. Yes, there are programs like Vuescan, but try to use it with OCR programs!

I think many users will be surprised about the number of 32-bit software programs on their computer. Even though I update all my programs on a regular basis, many are still 32-bit.
 


It is not just software that you might have to replace but hardware that has 32-bit drivers. I love my Canoscan scanner. Their driver is 32-bit. As they no longer sell it, they seem to have no interest in providing a 64-bit driver. Yes, there are programs like Vuescan, but try to use it with OCR programs! I think many users will be surprised about the number of 32-bit software programs on their computer. Even though I update all my programs on a regular basis, many are still 32-bit.
The one thing I won't be is surprised. macOS keeps reminding me, quite frequently.
 




I wonder if you get reminders about hardware drivers or only about software.
With an iMac with only external storage (via Thunderbolt) and a scanner, there aren't (m)any hardware drivers to worry about — I only use the scanner with Image Capture.

Come to think of it, most of the rat's nest of thin cables on my desk are for charging and/or communicating with iOS devices and third-party cameras, battery packs, &c.
 


The forum member here, JoseHill, confirmed that you can still rip CDs as normal. It's now also documented in my MacStrategy article, along with lots of other useful questions and answers:
How does macOS 10.15 deal with audiobooks, such as those downloaded from audible.com and loaded onto an iPod Nano?
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts