All right, and this lesson I want to talk a little bit about, Mako aspersions really focus on the
most formost recent releases from MacHeist High Sierra through MapQuest, Big Sur High Sierra was based
on the 10 to 12 Sierra version that was updated to ten point thirteen, which was a more polished release
of of that code set.
macOS Mojave is known as 10 to 14, and there were some additional changes made from a standpoint of
privacy.
This is really where Apple started to get into more of their consent and transparency and privacy policies
and bringing those into Mac OS MapQuest.
Catalina was more of a it's a 10 to 15 and it was more of a polished version of Mojave builds on a lot
of the features that were introduced in Mojave.
And then that's also the last release that Apple called Macalester, starting with Mac, Big Sur.
They moved to 11 and they are on the verge of releasing Mac OS 12, which is also known as MapQuest
Monterey.
Later in 2021.
So there's been a number of changes here under the hood.
And I just kind of want to talk about some of this.
This really all started a number of years ago at a worldwide developer conference event where they started
talking about bringing features which had debuted in iOS back to the Mac.
And so they have they've had this kind of running thing going since around the 10 to 12 turned out 13
era where they continue to make more of the changes in the Mac to have a function more like iOS.
It's really been something that has made the Mac more secure.
It's really, you know, focused on privacy, simplicity, mobile management.
And they've also been making these changes to sort of support where their hardware is going as well,
specifically around supporting Apple silicon as we get into things like Mac OS, Big Sur.
So because we go through and talk about a number of different concepts in this course, I thought it
was important to just sort of touch on some of the differences between these versions, because not
only as a system administrator, you probably not going to be great if you could, but probably not
going to run into a situation where you're able to support the same operating system version across
all of your hardware.
Apple's done a pretty good job of providing backward compatibility for hardware.
But as we're moving into the Apple silicon realm, you know, we know that over time you're going to
sort of be stranded, depending on some of the hardware that you may have in production, can't move
to the latest version.
So it is important to understand some of the underlying changes.
This is not an exhaustive list of changes, but these are some of the big ones and certainly some of
the big ones that you may run into as you do some of the exercises as we get into the course.
So let's talk a little bit about the main areas of difference.
So these are the four areas I'm really going to go through here.
Like I say, there's a lot more that are going to be different, you know, little user interface things.
I'm not going to get into a lot of the user facing things.
You have the icons are a little different.
The doc may look a little different.
There's dark mode, light mode, you know, all these kinds of things.
But I really want to talk more about the underlying technologies.
And, you know, those are going to be the disk and system design of the operating system itself.
Command line and some specific commands, a big one being profiles, which I'll talk about kernel extensions
and system extensions and then mobile device management, whether it's nice to have or an absolute requirement.
And I will tell you, spoiler alert as we get into the more recent versions of Mac OS, as we get to
10 to 15 and 11 and 12, MDM is becoming more of a requirement than a nice to have.
So let's first talk about disk layout and the operating system.
So I'm really going to focus on four major variants here, really three.
And then, you know, we're going to be looking at Big Sur on both AM1 and Intel.
So I've got Mojave.
I've got Catalina.
I've got Big Sur on Intel and then Big Sur on Apple.
Silicom, which is the one that has a little AM1 chip next to it.
So let's talk first about physical disc on Mojave.
So this is pretty close to what you would consider a traditional setup for a maquilas disc.
I'm going to focus specifically on Apple are the APOs Apple file system.
Each of us plus which predated APIs is even cleaner than this, but it's very similar.
You don't have the container.
You just have the volumes underneath that physical disk.
But when we take a look at API first, what we have is we've basically got your EFY, which is your
firmware on the intel platform, and then you've got an API container, which contains a number of volumes.
They have the Macintosh hard drive volume, which is the one that mounts on your drive that the user
interacts with.
There's the pre boot volume that is available before the machine boots up.
There's the recovery volume where the recovery tools sit if you need to boot your machine into recovery
mode.
And then we have virtual memory, which is just a small amount of memory paging file, essentially swap
disk space, whatever you want to call it, that bounces its own volume as well to work with the RAM
system and help your performance of your of your memory system.
And the Iot.
So pretty basic set up there.
This is the one that, you know, most people would be familiar with if you've been doing any amount
of MapQuest support.
When we start looking at Catalina, they start to enhance on this a little bit.
And one of the things that Apple has done is they've really started to move towards having a protected
Macintosh hard drive volume that's locked down and then a Macintosh hard drive volume that's basically
labeled as a dash data volume.
And what that is, is that is basically where the user can make changes.
So that's where, you know, your applications would be.
And, you know, any of the other data that you've created and saved things like the user users folder
documents, for example.
So this is rewrite space from a user perspective in the Macintosh HD data.
And then the Macintosh HD is basically the operating system system folder, a large amount of the applications
folder that are preinstalled with the operating system.
Those kinds of things would be on that Macintosh hard drive volume.
And Apple does a little bit of fancy work with the way that the the system looks to kind of build the
symbolic links so that from an end user perspective, you just see Macintosh hard drive.
But actually, what you're interacting with, some of it is on that Mateusz HD volume.
Some of it is on the Macintosh HD dash data volume.
And those are put together in what's called a volume group, and then that sits inside the apex container.
So what that's basically set up to do is, is keep the files on your Mac that end users shouldn't modify
on modifiable while allowing you to modify the files that are allowed to be modified.
And then when we move into Macross, Big Sur, things get a little bit more complicated, and I will
admit I really try to, you know, condense this down.
There are articles out on the Web that you can read that will get far more in depth on this if you really
care.
But I thought, you know, for our purposes today, to just give you an idea of where things are going
and how this works.
I try to keep it as simple as possible.
So we basically take what we've done in Catalina with a volume group.
This time we have a sealed system volume, which is just the volume that is not available to be modified.
And then there is a snapshot of that sealed system volume that becomes the Macintosh HD.
And that snapshot is basically just a copy of what's in the sale sealed system volume.
If something needed to be restored, it could that snapshot could be replaced with a new snapshot of
a sealed system volume as it exists and then restored.
So you've got the the Macintosh hard drive snapshot of a sealed system, and then you have your Macintosh
HD data.
And those now comprise the volume group that are inside the apex container.
And so very similar to the way that Catalino works.
But just one more level of sort of you know, you're working on a copy of Macintosh hard drive to just
give you one more level of security and restore capability from an integrity of your of your main system,
operating system, system folder, library folder and those packaged applications.
And that's pretty much the same on Big Sur with the M1.
But there's just a little bit of a difference here.
You still have your apex container, you still have your volume groups, you still have your snapshot
of your sealed system volume.
Macintosh HD dash data is considered just data under the the AM1 architecture.
And then we have the Recovery OS and a different firmware, the apps ISC as you on the physical disk
that comprises the basic setup of the M1.
And remember, the this physical disk actually lives inside the Apple silicon architecture.
So you're looking at having Recovery OS and the firmware right alongside your entire apeace container
on that same system on a chip and then all of the data inside there.
So I just thought I would point that out.
It's a subtle difference.
But just in the interests of being thorough, I wanted to kind of show how that lives inside the anwan.
And the next thing I want to talk about is colonel extentions and system extensions.
So one of the things that when you look at legacy Mac OS kernel extensions are little bits of code that
third party applications can install.
This is typically things like drivers would be a good example there.
If you've got I think I mentioned in an earlier lesson, did you design Pro Tools where they have an
external breakout box of, you know, maybe it's a control board or some sort of recording recording
capture device that connects up to your machine over Thunderbolt or USB?
They would use a kernel extension to tie in for those drivers to drive that that piece of equipment.
You see this a lot with security software as well, antivirus and Gaulois software that will install
kernel extensions on on your machine.
And for a long time, that was the main way to do this.
But Apple is moved, is moving into something called system extensions, which are similar to kernel
extensions, but more secure, and they don't actually inject code directly into the kernel.
So system extensions require an application to be rewritten or at least updated recompiled to use system
extensions instead of kernel extensions.
So it's been a little bit of a slow, slow road in getting there, but a lot of developers are starting
to move in that direction.
And more of the software, especially as the update for Apple Silicom.
We're going to provide system extensions as the native format for these kinds of things.
But just as you look at across the different operating systems, K kernel extensions are are basically
available in Mojave.
But system extensions are not, as you move into Cattalini sorry, Katalina and Big Sur.
We have the introduction of system extensions, but we also provide support for kernel extensions.
And this is where Apple started to put warnings in.
If you're running an application on these operating systems that do have a kernel extension, you might
see a box that pops up at boot that says this application is, you know, using something that will
not may not be available in the future version of Mac OS.
Please contact your software vendor and ask them to update it.
That's that's Apple trying to get the user community to put some pressure, I think, on developers
to go ahead and move away from this.
But they really will work hand in hand on these two devices without any any differences.
When you when you're talking about those operating systems that when you start moving over a Big Sur
on the M1, now you've got system extensions are the priority and cakes are always supported.
If you go in to the recovery OS and change your your boot security so that you've got reduce security
mode and from from full.
So, you know, it's a additional step for administrators to have to do a little bit annoying, but
they still allow them to run.
But, you know, time is running out on kernel extensions.
So developers really do need to start moving to system extensions.
And I mentioned it only in the context here that, you know, you depending on the applications you
run, you may never even see this.
This may not even be a problem for you or software you're running may have already been updated to use
system extensions.
But I pointed out, in case you're seeing those kinds of messages with certain applications, you're
not sure why or you're having a problem getting a certain application that maybe does have a driver
to run on the M1.
You know, potentially the reduced security mode could work.
But know typically when you're talking about third party software, it's probably a good idea to reach
out to the vendor for support on their specific application, on on these different operating systems
and then now hardware platforms as well.
I'm talking about the command line, so in McCoist 10, that 15, we've moved to the S.H. as being the
default command line interface.
Prior to that, with Mojave and Older Bash was always the default.
So, you know, that's more of just an FOIA.
You know, a lot a lot of the commands that I've used are working fine between Basche and Zeza.
But you know, something to point out that that is something that has changed as the operating systems
have changed, I believe.
Most of the code, if not all of it in this course, really would work interchangeably between bad passions.
Yes, but in the interest of just full disclosure, I want to point out that that has changed in formal
command line perspective.
And then the last thing here is the profile's command, so as we're talking about, you know, command
line tools and things like that, later in this course, you're going to see some options to install
mobile config profiles via the profiles command.
And this can be very handy.
This allows you to use something like Apple profile manager app configurator in some cases, depending
on the payloads that you're you're building to create a mobile config profile and then export it out
or just using, you know, a raw XML editor to configure your payloads for mobile device management.
Maybe the arrangement of the doc, which icons are in it, if it's on the bottom, the side, what size?
Those kinds of things in Mojave and Catalina.
Essentially what you would call Mac OS 10, not necessarily maquilas, 11 or 12 or Mac OS 11 on on the
Apple silicon platform.
The profiles command is is no longer there.
It's been deprecated out.
And so that means that if I was using one of the operating systems that were, you know, classic Mac
OS 10, I would be able to create a mobile config profile and then use a command line profiles and then
the path to the profile to actually install that profile.
And where that could be very handy is if I'm using a tool like Monkey or Apple Remote Desktop, and
I wanted to push a mobile config profile onto one or group of machines.
I used to be able to code using a script.
The profiles command to go ahead and install and enable that profile.
Now, as you move into Macross 11 and 12 and Apple Silicon, the only way to install a profile is command
without being physically present in front of the machine, interactively clicking on things and authenticating
and accepting and things like that to dialog boxes is through an MDA.
So this is where you start getting into, you know, is an MDM required?
Well, maybe if you have a workflow where you're pushing settings out to your machines using mobile
config profiles today and you're using a profiles command, do it note that going forward in these newer
operating systems, you're going to have to use an MDM to push those out.
And so there will be an additional MDM cost per unit that you'll have to factor into your overall expenses
of supporting Macalester.
That is one of the changes that Apple's made.
And, you know, you can still manually install profile, but you have to do it interactively on a machine
by machine basis, which is a lot more tedious than being able to script it.
So just want to make sure that everyone's aware of that.
We do have some lessons on mobile device management and MDM systems in the course as well.
So, you know, if you're if you're primarily on MapQuest, then today and you haven't made that move
to Big Sur or or the M1 architecture, you can certainly continue to use profiles.
To this day, I've been using the profiles command on 10 to 15 Two-Stage machines without an issue.
And I would expect to be able to do that on 10, 15.
But as you sort of plan your migration strategy, perhaps to newer hardware or the new operating systems,
please keep that in mind if you don't have an MDM today.
It is something you're going to need to look at doing if you want to move that workflow of installing
those profiles automatically into these new OSI's.