{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Packages: {{ resultsReady ? computation.values.package_count : '—' }} Network: {{ resultsReady ? computation.values.network_label : '—' }} Warnings: {{ resultsReady ? computation.values.warning_lines : '—' }}
{{ stageAnnouncement }}
Installer rehearsal settings
Choose the package-manager vocabulary your audience expects.
Linux, macOS, and Windows chrome are presentation choices.
These values are generated presentation data, not a network measurement.
{{ package_count }}
Use 3–6 for a short clip and 9–18 for a busier walkthrough.
Enter a whole number from 1 to 999,999,999.
Turn this option on when warnings is required.
{{ include_warnings ? 'Include synthetic warnings' : 'Clean success stream' }}
{{ formatNumber(Number(line_pace), 2) }}×
Neutral default: 1.00×. Slower values make each generated stage easier to narrate.
Neutral default: hidden. Enable elapsed labels only when the recording needs them.
{{ show_timestamps ? 'Show elapsed time' : 'Hide elapsed time' }}
{{ textExportStatus }}
{{ formattedTranscript }}
{{ chartExportStatus }}

The chart renderer is unavailable. Exact stage values remain in the ledger.

StageShareGenerated timeRehearsal cueCopy
{{ row.label }}{{ row.share }}%{{ formatSeconds(row.seconds) }}{{ row.cue }}
{{ ledgerExportStatus }}

A terminal replay can teach the shape of an installation without changing a real machine. It gives a presenter time to explain package resolution, downloads, installation, configuration, and completion while the audience sees a familiar command-line sequence.

The distinction between rehearsal and evidence is essential. Real package managers inspect repositories, dependency graphs, signatures, locks, permissions, disks, and network responses. A simulation replaces those variables with repeatable presentation data. Its apparent download speed, latency, warning count, package list, and completion message describe a chosen scenario, not the state of a computer or service.

Differences between an installer rehearsal and a real installation
QuestionRehearsal can showReal installation must prove
What will the audience see?Command vocabulary, prompts, stages, warnings, and pacing.Exact output from the target operating system and package manager.
How long will it take?A synthetic duration for timing a demo or recording.Elapsed time under the real network, cache, disk, and dependency conditions.
Did installation succeed?A generated completion line.Exit status, logs, installed files, versions, and a functional verification command.

Repeatability is the main advantage. A fixed seed keeps the highlighted package and transcript stable, while playback pace lets a narrator slow the same content without inventing a different network condition. Warning lines can be included to rehearse recovery language, but they always resolve inside the synthetic script.

Use a replay for training, mockups, screenshots, video timing, and interface demonstrations. Do not use it as proof that a command is safe, a repository is reachable, a package exists, or a system was modified. Any real procedure still needs testing in an appropriate disposable or approved environment.

How to Use This Tool:

Choose the vocabulary your audience expects, then fit the generated sequence to the available presentation time.

  1. Select a package-manager Scenario. The scenario determines the visible prompt, command, repository label, and package names.
  2. Choose the terminal window style and a synthetic Network profile. Window style changes presentation only; the network profile changes generated speed, latency, duration, and warning bias.
  3. Set Packages from 3 to 18 and enter a Replay seed from 1 to 999,999,999. Enable warnings only when the rehearsal needs retry language.
  4. Adjust Playback pace from 0.5× to 2× and enable timestamps when elapsed labels help the recording. Review the estimated duration and stage timing before starting.
  5. Run, pause, step, or reset the replay. Keep the same seed and settings for repeat takes; change the seed when a different spotlight package is wanted.

Interpreting Results:

Rehearsal plan ready means every input is within the simulator's accepted range. The terminal lines, timing chart, speed, latency, and warnings are generated presentation artifacts. They do not report a live network request or package-manager process.

  • Calm contains no warning lines, varied contains one or two, and noisy contains three.
  • The stage chart divides one estimated total into fixed shares. It is useful for narration timing, not for predicting which stage will dominate on a real host.
  • Before publishing a technical tutorial, replace or verify every simulated command, package, URL, and success claim against the real target environment.

Technical Details:

The deterministic model combines a scenario lookup, a network lookup, one duration equation, a warning rule, and fixed stage shares. It makes rehearsal timing auditable while deliberately avoiding real package-manager or network behavior.

Lookup Core

Each network profile supplies seconds per package and the speed and latency labels printed in the transcript.

Synthetic network profile values
Profile Seconds per package Displayed speed Displayed latency Warning bias
Stable datacenter572 MB/s45 ms0
Home Wi-Fi828 MB/s110 ms1
Throttled VPN129.5 MB/s280 ms2
Unstable hotspot183.2 MB/s620 ms4

The selected scenario supplies package-manager vocabulary and a five-name package list. The spotlight package is chosen by taking the replay seed modulo that list length, so the same scenario and seed always select the same name.

Formula Core

Estimated duration increases with package count and the selected seconds-per-package value, then decreases as playback pace rises. The final value is rounded to three decimal places.

T=round(P×SR,3)

P is package count from 3 to 18, S is the network profile's seconds per package, and R is playback pace from 0.5 to 2. For example, six packages on Home Wi-Fi at 1× produce 48 seconds; changing only the pace to 2× produces 24 seconds.

The duration is allocated by fixed stage shares:

Installer rehearsal stage timing shares
StageSharePurpose in the transcript
Prepare12%Resolve the plan and metadata.
Download36%Fetch synthetic archives.
Install28%Place the selected payload.
Configure16%Run generated hooks and environment notes.
Finish8%Print cleanup and completion language.

Rule Core

Warnings are either disabled completely or derived from package count and network bias. When enabled, the rule always yields at least one and at most three warning lines.

W=max(1,min(3,⌊P+B4⌋))

The generated transcript contains 7 to 10 lines depending on warning count. Warning text is deliberately resolved by a retry, lock clearance, or delayed hook so the rehearsal always reaches its synthetic completion line.

Limitations and Privacy Notes:

No command runs, no repository is contacted, no package is downloaded, and no system setting changes. The replay is assembled and played in the browser.

  • Synthetic hostnames, package names, speeds, latencies, and success lines must not be presented as measurements or installation evidence.
  • Playback timing can drift with browser scheduling and a hidden tab may pause progression.
  • Do not paste credentials, private repository names, or production commands into presentation notes or recordings.