ENVIRONMENT / HELP ME CHOOSE
Use this optional guide only when a hard constraint leaves you unsure. It compares routes; it does not install anything or select a route for you.
SOURCES REVIEWED AUGUST 29, 2026 · RECHECK BEFORE USE
Good fit when: Use this when course commands will run directly on a supported Windows computer and Windows-first software or policy makes a Linux layer undesirable.
Tradeoff: You must use Windows paths and scripts consistently, and the later Linux-container path depends on a supported virtualization backend.
Verify: Check the exact Windows release, architecture, install permission, free resources, and virtualization status.
Good fit when: Use this when you want Windows desktop applications while course tools, projects, and commands run inside one Linux distribution.
Tradeoff: The project must stay on the Linux side of the boundary; mixing Windows and WSL toolchains against one working copy creates path, performance, and ownership confusion.
Verify: Check WSL 2 support, virtualization permission, available resources, and whether your editor can open the Linux-side project.
Good fit when: Use this when course commands will run on a supported Mac and its local terminal, desktop applications, and architecture meet your constraints.
Tradeoff: You must identify Intel versus Apple silicon and verify every package and later container image for the matching architecture.
Verify: Check the exact macOS release, chip architecture, install permission, memory, disk, and current Java, Python, and Docker support.
Good fit when: Use this when course commands will run on a maintained Linux computer whose distribution, device support, and required applications meet your constraints.
Tradeoff: You own distribution-specific package, permission, service, and device decisions; a derivative distribution is not automatically vendor-tested.
Verify: Check the exact distribution and release, architecture, sudo boundary, resources, and vendor support for every required tool.
Good fit when: Use this when a remote Linux VM or hosted Linux workspace satisfies local hardware, policy, mobility, or access constraints better than a local installation.
Tradeoff: Internet, account access, cost or quota, persistence, SSH or browser connectivity, and later container or Kubernetes support become hard dependencies.
Verify: Check the provider's current billing controls, supported image, resource limits, access path, stop/delete behavior, storage retention, and later container requirements.
01
WHAT THIS STEP TEACHES
“I can distinguish a requirement that eliminates an option from a preference that only affects comfort.”
A hard constraint makes a route infeasible; a preference helps compare routes that remain feasible.
Engineering choices begin with requirements, so familiarity or fashion does not silently become a technical rule.
Predict the one constraint most likely to eliminate an environment.
Do not copy another learner's choice before checking your own policy, cost, hardware, accessibility, and connectivity.
Explain why each constraint is non-negotiable and what evidence could change it.
GUIDED ACTION
List install permission, required applications, accessibility needs, offline work, reliable internet, available budget, and hardware limits. Mark every line constraint or preference.
CHECK BEFORE CONTINUING
Every hard constraint has a concrete reason and an observable way to test it.
02
WHAT THIS STEP TEACHES
“I can describe a host with the exact facts that vendor support pages use.”
Compatibility depends on release, architecture, resources, features, and privileges rather than a brand name alone.
A single unsupported part of that tuple can make an installer or container workflow fail.
Predict each value before reading it from the system.
Do not infer architecture from device age or available disk from advertised disk size.
Name which fact affects package choice, which affects capacity, and which controls permitted actions.
GUIDED ACTION
Observe the operating-system release, CPU architecture, total and available memory, free workspace disk, virtualization status, and administrator or sudo boundary.
CHECK BEFORE CONTINUING
Every required field contains an observed value and a repeatable way to check it again.
03
WHAT THIS STEP TEACHES
“I can apply the same hard-constraint filter to every candidate environment.”
Filtering removes impossible routes before preferences are compared.
Teams waste time debating attractive options that already violate policy, cost, access, or hardware requirements.
Predict which routes will survive the filter.
Do not weaken a hard constraint to preserve an option you prefer.
For one rejected route, name the failed constraint without calling the route generally bad.
GUIDED ACTION
Remove each route that fails one hard constraint and write the exact failed constraint beside it.
CHECK BEFORE CONTINUING
Every rejection cites one failed constraint and every remaining route passes all of them.
04
WHAT THIS STEP TEACHES
“I can make a version-specific support claim from primary documentation.”
A support claim includes the product, version, platform tuple, official source, date, and limitation.
A remembered guide can be outdated even when its commands still appear to work.
Predict supported or unsupported before opening each product page.
Do not treat a related release or distribution as vendor-tested without an explicit statement.
State one complete support claim and identify the sentence or table that supports it.
GUIDED ACTION
Check official Java, Python, Docker, and minikube documentation for every surviving route's exact release and architecture.
CHECK BEFORE CONTINUING
Every required product has a dated official source or an explicit support gap.
05
WHAT THIS STEP TEACHES
“I can state where commands run, where files live, and which tool installations own the project.”
An environment boundary keeps one shell, file system, package database, and permission model responsible for a project.
Accidental boundary crossing creates duplicate tools, translated paths, slow file access, and confusing ownership.
Predict the correct prompt, project path, and tool locations.
Do not install the same tool on both sides to hide an unidentified boundary problem.
Describe how you will notice that you opened the wrong terminal or provider console.
GUIDED ACTION
Write one sentence naming the system where commands execute, the project file system, and the shell that owns the route.
CHECK BEFORE CONTINUING
One sentence identifies the execution host, shell, project storage, and toolchain owner.
06
WHAT THIS STEP TEACHES
“I can make an environment decision reversible without maintaining two complete setups.”
A fallback activates only after one observable hard failure.
A named recovery path shortens disruption when policy, hardware, cost, or connectivity changes.
Predict the most plausible hard failure in the primary route.
Do not install and maintain the fallback now; that creates two sources of truth.
Explain why the fallback does not share the primary route's predicted failure.
GUIDED ACTION
Choose a second feasible route and write the exact unsupported version, denied privilege, resource limit, cost, or connectivity event that activates it.
CHECK BEFORE CONTINUING
The fallback passes every hard constraint and has one observable activation trigger.
07
WHAT THIS STEP TEACHES
“I can choose one environment from evidence without treating it as universally superior.”
A decision is a contextual tradeoff, not a permanent identity or ranking.
A clear selection lets every later instruction use one coherent syntax and boundary.
State the likely choice and its main cost in one sentence.
Do not keep reading every route after one feasible route has been selected.
Defend the choice using one constraint, one support fact, one tradeoff, and the fallback trigger.
GUIDED ACTION
Return to the environment chooser, select the execution environment, then complete its subtype and provider choices.
CHECK BEFORE CONTINUING
The site displays one saved-environment trail and sends you to only that setup path.
08
WHAT THIS STEP TEACHES
“I can test an environment decision with observable tool and project outcomes.”
The selected route remains a hypothesis until a new shell can reproduce the required workflow.
An installer success screen does not prove PATH persistence, compiler availability, project isolation, or test execution.
Predict every verification result and whether the check changes files.
Do not count one version command or an already-configured editor terminal as the whole proof.
State what each result proves, what it does not prove, and whether the fallback trigger fired.
GUIDED ACTION
Follow only the selected setup route, reopen the shell, run every required check, record redacted evidence, and activate the fallback only if its named trigger occurs.
CHECK BEFORE CONTINUING
A new shell produces the required versions and project checks with results you can explain.