Lab PCs Run Windows, Learners Bring Macs: Delivering One Lesson in a Mixed Room ​

We · November 2026

This is the sixth article in the "AI Learning Environment" series, written for academic operations and IT. The five before it answered, in turn: which machine each of six tracks needs before enrolling, why week one stalls, how much one comic-drama installs, how to state requirements during an admissions enquiry, and how a curriculum team pins a course version. This one covers the link that breaks most once they share a room: the lab is installed centrally, own devices are installed individually, and the two sides split further into Windows and Mac — so how does one lesson get everyone to the point of handing in work.

This article is about roles and rosters only. It evaluates no institution: no names, no comparisons, no pricing, and no claims about what any product can do. The tests here come from the system requirements carried on app detail pages, the verbatim hardware requirements on our workflow pages, and the PC client documentation, compiled in November 2026 — a reference, not a guarantee.

1. What's hard isn't Mac; it's one lesson producing two answers ​

The conclusion first. What makes a mixed environment expensive isn't that some class of machine won't install. It's that one lesson produces two answers at the same time.

The teacher demos on the lab's Windows machine and reaches "choose your runtime environment" — on the Mac students' screens that row simply doesn't exist. The assistant validates something on a lab machine and says "it works here", and the student on the dorm laptop is still failing the next day. Nobody said anything false, and the two didn't hand over the same thing.

Article two explained the cause: these two classes hit different walls, one lacking capacity and the other lacking ecosystem coverage. That isn't repeated here. This article answers the next link: how the process has to be arranged so one lesson delivers both sides.

The answer we want isn't "make every machine the same" — that's neither possible nor worth it. What is possible fits three questions: who installs, who accepts it, and what you do on the spot when the two don't match. Write those down before the course opens and you remove half the back-and-forth for the whole term.

Boundaries first, so this doesn't overlap with the others:

• How to read an error, and how four version layers fall out of line, are in Five Things That Stall Week One.
• Which five things a pinned version writes down, how the image, environment package and assignment bundle each cover one stretch, and when an update is due, are in How to Pin a Course Environment. That article treats the image as one carrier among three; running the lab week to week is this article's subject.
• Lab planning, budget tiers and the build path are in the Vocational College AI Lab Construction Guide and the AI Teaching Environment Selection Guide. This article assumes the lab is already built and covers only what happens weekly after that.
• How far Apple silicon, older Intel Macs, AMD and Intel Arc machines each get belongs to the later article "It Is Not NVIDIA or Nothing". This article gives administrative actions, not a machine capability list.

2. Divide by who is responsible, not by Windows and Mac ​

The first version of most institutions' split is written by operating system: a Windows group and a Mac group. That table always misses machines.

Because the room actually holds four piles of equipment and only two operating systems. The shared computer in the dorm, the notebook borrowed out of the lab, the teacher's own old machine — by operating system nobody knows which group they're in; by "who installs" they're immediately clear.

Columns three and four are what the table is actually for. A table split by system has one column, "can it install", and when something breaks nobody catches it. A table split by responsibility has a name on every row.

Two reminders.

The last row causes the most trouble. Most homework is done on the dorm machine, yet it sits on nobody's responsibility list — the lab doesn't own it and the assistant can't demand to see it. Fold it into the "own device" column and accept the submitted result only, without requiring an identical environment.

Row three has to state what it is being accepted against. What a Mac student hands in looks different from the demo. Judged with the Windows acceptance sheet, every Mac student fails. Settle this now and the roster in section six holds together later.

3. The lab side: only four routine actions ​

Once the lab exists, only four things need a place on the duty roster. Each can be written as a sentence a person can execute, and none of them require anyone to understand AI.

Of these four, the second saves the most money and deserves two more sentences.

After the client is installed, application data defaults into the Documents folder on the system drive: C:\Users\<username>\Documents\lmd_data_root on Windows and /Users/<username>/Documents/lmd_data_root on Mac (the wording and migration steps are in the Data File Migration Guide). Anything on the system drive goes back in time with the restore point. Restore today, and yesterday's downloaded models are gone.

The correct lab practice is to move the data directory onto a drive outside the restore scope — a shallow path like D:\lmd_data_root — and only then restore and dry-run. You can skip that and still get through, at the cost of re-downloading a batch of models after every restore. Models are counted in tens of gigabytes, so that download time belongs in the roster. It gets overlooked more easily than "reinstall it", because it never errors; it's just slow.

The same guide carries a sentence worth using when a lab creates its shared accounts: a Windows username containing Chinese characters or spaces causes compatibility problems and may stop certain apps from reading and writing their data, and paths should also avoid spaces, special characters and cloud-sync directories. On a student's own machine this surfaces in week two; in the lab, avoiding it during account setup costs nothing.

The fourth action, logging, is what a mixed environment needs it for. The lab machine and a student's own device hit different walls, so the log needs one more column before you can tell which side a problem is on. That column reads simply "has this machine been restored?", answered yes or no.

4. The own-device side: send three checks before the course and let students run them ​

Own devices cannot survive on support alone. The likeliest queue in week one is everyone installing software separately and then asking "why won't it open" in the same group at the same time.

The fix is plain: send one self-check sheet before the course starts and have each student complete three things. None of them need an assistant online, and all three take about twenty minutes.

The order can't change. Identify which class the machine is, then look at capacity, then run the example. Plenty of people do it backwards: two hours installing, then discovering the path doesn't exist on this machine, then reinstalling. That is the biggest waste of week one — not an underpowered configuration.

Row three is the only row with value here; the first two exist to make it possible. The minimal example doesn't test "does it open", it tests the pace of your machine. The same workflow returning a result in thirty seconds or in eight minutes decides whether this course's assignments can be handed in on schedule. How far that figure varies by direction is worked out by track in article one and by stop in article three; it isn't repeated here.

One honest note: even after the sheet goes out, some people won't fill it in. The difference is that those who did can bring six items of information when they ask, and those who didn't need three round trips. Support volume rarely falls because the sheet was sent after the course opened.

5. The Mac side: three administrative actions, none requiring technical staff ​

The judgment first: most Mac-student problems don't need a technical answer; they need somebody to make one decision in advance. All three actions below are administrative, and none requires anyone to write code.

Action one: ask for the platform during enrollment and put it on the roster. One sentence to ask, and article four's disclosure checklist gives it its own column. The cost of not asking isn't a missing field; it's discovering it live on the first class day. How many Macs are on the roster decides whether action two needs a demo machine.

Action two: before the course opens, pick one path through this course that works on Mac. The test isn't something to ask anyone — it's printed on the page, and copying it into the course plan is enough. Two common wordings happen to be two kinds of answer.

One states that it was tested on one side only. The hardware requirement on the Qwen Image Edit 2509 GGUF page reads, verbatim: "This LoRA is currently tested only on Windows and doesn't work well on macOS."

The other states that Mac needs one more parameter changed. The SeedVR2 video restoration and upscaling page reads: "It can run directly on Windows systems with NVIDIA graphics cards installed. When running on macOS with M chips, change the device parameters of the two SeedVR2 custom nodes to mps."

The difference between those two sentences is exactly what a course plan has to act on. If the first page happens to be this course's key assignment, Mac students don't need technical support — they need an alternative assignment. Making that decision before the course opens is far cheaper than making it in week four, by which point students are already racing to submit. The second page needs no alternative assignment; it needs "which parameter to change" written into the Mac version of the steps, so nobody has to guess.

Action three: allow different results, never different steps. This is classroom discipline, and the line teachers miss most often.

The reason is concrete: the runtime-environment options in the client appear only on Windows machines with an NVIDIA card. On other brands of card, or on macOS, those options are not visible at all (verbatim from Deploying ComfyUI with One Click: Choosing the Right Runtime Environment). In other words, the "choose your environment" step does not exist on a Mac screen. If the teacher doesn't say "Mac students skip this one" in advance, someone in the room concludes they installed it wrong.

The reverse also holds: Mac students hand in the same assignment, not the same screenshot. Writing that into the course description removes a whole category of "my button doesn't match the recording" from support.

As for how far Apple silicon and older Intel Macs each get, and which apps are usable on them — that's a different article. This one lists nothing and draws no "it runs" conclusion for any class of machine.

6. Staffing week one: three question types, two shifts ​

The most common failure in mixed-environment support isn't an unfilled rota. It's everybody answering a couple of sentences, in different ways. So classify the questions, then assign the people.

The third row deserves its own note. It looks technical and isn't. Article five separated three kinds of change, and only environment changes are a technical question; an interface change needs one explanatory sentence. Let it into the technical channel and the conversation turns into comparing two people's screenshots, and a good lesson becomes an argument about whose machine is broken. One scripted reply from the class advisor beats ten from an assistant.

With the roster set, three rules.

Rule one: collect all six items before troubleshooting. Article two lists them: system and version; chip or card model plus VRAM or unified memory; the app name and when this setup was installed; which workflow or which model file; the complete error sentence; and whether the minimal example runs. Turn the six into a fill-in form and pin it in the group — that works far better than instructing people to "remember a screenshot". Miss one item and you add a round trip, and in a mixed environment the first round often asks about the wrong machine.

Rule two: when the same error appears twice, it goes into a table. Record only three things: the symptom, which machine column it came from (lab / own Windows / own Mac), and which environment was in use. On the third occurrence, the shift answers directly. At term's end that table is next cohort's pre-course page, already written.

Rule three: validation has to happen on that class of machine. This is the hardest of the three. A Mac student reports it won't run; the assistant runs it once on the lab's NVIDIA box, it succeeds, and the reply is "fine on our side". That is the worst possible answer, because it reframes an ecosystem-coverage problem as a student error. If we don't own that class of machine, say so and give a fallback route at the same time. That plain sentence protects trust better than any script.

7. Three failures: how to save the day, and how one page prevents it ​

All three scenarios are the common ones in a mixed room; one column gives the same-day fix and one gives the pre-course prevention.

All three rows point at the same thing: a mixed-environment contingency plan isn't a technical question — it's whether somebody walked through it before the course opened.

The third row deserves a further word. Many institutions discover after the course starts that "the one workflow this course depends on, Mac students can't complete". Before the course opens, that discovery costs one class hour; after, it costs a cohort's worth of withdrawal conversations. One person who knows the curriculum plus one person who owns a Mac spending half a day walking the assignments is the only action in this article worth real hours.

That is also where a Mac demo machine pays for itself. It isn't spare hardware; it's the teacher seeing, on that screen, the interface Mac students see. With it, action one and action three from section five get done as a side effect. Without it, the assistant is improvising from imagination in a group chat.

8. Three sentences to carry away ​

First, group by responsibility, not by operating system. Two piles — what we install, and what students install themselves — with an acceptor and a deadline named on each. What's left is an execution problem, not a compatibility problem.

Second, the costliest thing on the Mac side isn't the configuration; it's that nobody decided in advance. Asking the platform at enrollment, picking one assignment path that works, allowing different results — all three belong before the course opens and none needs technical skill. Leave them to week four and they arrive bundled with withdrawal conversations.

Third, the lab does four actions and the fourth one is logging. Restore, check the data directory, dry-run, log. The first three make today's class possible; the fourth is what lets somebody answer directly the second time the same error appears.

The next article takes the capability line: it is not NVIDIA or nothing — how far Apple silicon, older Intel Macs, AMD and Intel Arc, and cards under 4GB each get. That one supplies the list, and the role table in this one is exactly what uses it.

Disclaimer: The configuration statements in this article come from the system requirements carried on app detail pages, the verbatim hardware-requirement copy on our workflow pages, and the PC client documentation, compiled by us in November 2026. Software and model versions update monthly and wording may change; the processes and tests here are a method reference, not a guarantee that any app will run or deliver on any device, and not a commitment about lab build plans or product capability. No specific institution is referenced and no course is evaluated.