Playing large video files on the web, short of uploading to YouTube or some other processing and hosting service, requires some preparation. For browsers to efficiently download just the portion surrounding what visitors are playing, you’ll generally want to rewrite the MP4 so its moov atom is at the beginning of the file (usually called “fast start”), allowing the browser to grab the metadata needed for playback and seeking without first having to download all the way to the end of the file.

One alternative is to provide the media in the HTTP Live Streaming format developed by Apple, which as the name suggests, was originally designed for live streaming. The format also supports post-live (oftentimes referred to as Video on Demand or VOD) playback of media. However, HTTP Live Streaming defaults to playing back pieces of the original media by chopping it up into segment files, since during a truly live recording, the end is not yet known, so segments are fetched moments after being captured and made available. It’s a convenient format for the modern web because the recording’s manifest and segments are delivered over the ubiquitous and typically network-allowed HTTP protocol instead of one of the more temperamental media streaming protocols like RTSP.

But for HTTP Live Streaming playback of post-live or pre-existing media, having to maintain a manifest and a whole pile of media segments can be kind of a pain. It’s way simpler to track and manage as few as two files instead of potentially a bunch. When producing an HTTP Live Stream with ffmpeg, you can set a couple of flags to cause it to produce just one .ts segment file:

ffmpeg \
-i input.mp4 \
-c:v libx264 \
-c:a aac \
-hls_time 6 \
-hls_segment_type mpegts \
-hls_flags single_file \
-hls_playlist_type vod \
index.m3u8

Setting -hls_flags single_file will cause ffmpeg to output index.m3u8 and index.ts, where index.ts contains the entire duration of the media rather than splitting it into several-second chunks and listing those in the index.m3u8 manifest. -hls_playlist_type vod adds #EXT-X-PLAYLIST-TYPE:VOD and #EXT-X-ENDLIST to the manifest, which tells the player the whole timeline is known up front so it can scrub freely. It also implies -hls_list_size 0, so you don’t need both. Everything else is ordinary encoding using whatever bitrate, preset, and profile settings you prefer, since none of that interacts with the single-file part.

The .m3u8 manifest text file is where the single-file mapping happens:

#EXTM3U
#EXT-X-VERSION:4
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXTINF:6.000000,
#EXT-X-BYTERANGE:1128144@0
index.ts
#EXTINF:6.000000,
#EXT-X-BYTERANGE:1093472@1128144
index.ts
#EXTINF:6.000000,
#EXT-X-BYTERANGE:1121368@2221616
index.ts
#EXT-X-ENDLIST

Unlike a live broadcast where each segment is added moments after it’s captured and encoded, the VOD playlist uses the same media file name on every line. The media is still logically divided into segments, but each segment is now a length@offset byte range into a single file rather than pointing to one of potentially many files on disk.

Single-file HTTP Live Streaming has been supported by playback clients, particularly iOS, since iOS 5. All that’s required to support this on the server side is accepting and respecting the HTTP Range header, which lets the client ask for a given range of bytes and the server respond with those bytes. The Range header has been part of HTTP/1.1 for decades and is supported by basically all HTTP servers, making serving single file HTTP Live Streaming quite convenient. This only works for media that’s already finished (i.e. isn’t live), though, since you can’t append to a file you’re actively serving byte ranges out of.

If you’re serving this with a CDN, individual segment files may still be the way to go. CDNs can have different caching and range-request behaviors, and a large single object can be less convenient to cache (or invalidate) than many smaller immutable segment objects. Depending on the CDN, a Range request may also result in more data being fetched from the origin than the client actually requested.

There’s also a variant of this that works with an MP4 container instead of an MPEG-2 transport stream, and you do get some nominal bandwidth savings. This requires iOS 10, which is long since available now, too.

ffmpeg \
-i input.mp4 \
-c:v libx264 \
-c:a aac \
-hls_time 6 \
-hls_segment_type fmp4 \
-hls_flags single_file \
-hls_playlist_type vod \
index.m3u8

Again, you get an index.m3u8 manifest, but now a index.m4s media file. The manifest gets an EXT-X-MAP tag pointing at index.m4s:

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="index.m4s",BYTERANGE="900@0"
#EXTINF:6.000000,
#EXT-X-BYTERANGE:1119832@900
index.m4s
#EXTINF:6.000000,
#EXT-X-BYTERANGE:1086104@1120732
index.m4s
#EXT-X-ENDLIST

H.264/AVC can be carried in either MPEG-2 TS .ts files or fMP4’s .m4s, but H.265/HEVC, AV1, and Dolby Vision require fMP4. If you want to use one of those newer codecs, you’ll have to use the fMP4 segment type. As well, players like hls.js transmux transport streams into fMP4 before handing it to the browser’s media API, so giving it fMP4 in the first place lets them skip a step.

HTTP Live Streaming (segmented or single-file) is one of my favorite formats because it puts a complicated thing like video playback on top of a solid, well-supported protocol like HTTP. In addition to being pretty well-adopted by clients, there’s no special streaming server to run, no unusual ports to open, and nothing that breaks when someone tries to watch a video over a restrictive corporate or hotel type of network.

Xcode 27 introduced, among other new features, a new Device Hub app for developers that takes the place of the Simulator app. Where Simulator relied on separate windows for each device, Device Hub brings them all together into a single window where each simulated device is the detail view from a source list of devices on the left. It’s a more organized approach, made necessary by the wide variety of platforms Apple and Apple platform app developers have to build and test against.

For enterprise users or developers building apps that communicate with web services over HTTPS, those services need to be using a certificate pair signed by a globally-trusted authority like DigiCert or Let’s Encrypt for them to work “out of the box” in the simulated OS. If they are using a certificate pair signed by a self-signed or in-house/enterprise CA (Certificate Authority), the OS will refuse to connect, displaying a “This connection is not private” interstitial in Safari or failing with a TLS trust error like NSURLErrorServerCertificateUntrusted. Even if the host Mac has the CA root certificate installed and trusted, the simulated devices rely on their own per-virtual-device trust store.¹

In releases prior to Xcode 27, you could resolve this by importing the root public certificate into the simulated OS. On iOS, this could be done by dragging and dropping the .cer file onto the Simulator device window. Nothing would appear to happen, but you could then navigate to Settings, General, About, Certificate Trust Settings and mark the certificate as trusted. On tvOS, the process was even more complex, requiring you to open Settings, General, Privacy & Security, hold down the virtual remote’s Play button on the Share AppleTV Analytics option to bring up a hidden dialog, then enter an HTTP URL to a .cer file. Similar to iOS, you’d have to mark it as trusted by navigating tvOS to Settings, General, About, Certificate Trust Settings and enabling the switch for that certificate. This process was slow and, especially on tvOS, quite obscure.

In Xcode 27 with Device Hub, this process is much more uniform.

1. Open Apple Configurator and create a new profile.
2. Under General, give the profile a name, a unique identifier, and perhaps an organization name.
3. Under Certificates on the left, click the Configure button and choose the .cer file you wish to install into the simulated OS.
4. From the File menu, choose “Sign Profile…” and select a developer identity to sign with. Alternatively, you can sign profiles from the command line with security cms -S -N "My Signing Identity" -i unsigned.mobileconfig -o signed.mobileconfig.
5. In Device Hub, select the target device, then open the Profiles tab in the right-side device inspector.
6. Click the plus button below the list and choose the .mobileconfig file you just signed.
7. The profile and its contained certificate should be immediately installed into the simulated OS. In iOS, you can verify by navigating to Settings, General, VPN & Device Management, and on tvOS the list of installed profiles is at Settings, General, Profile.

While this new process does require you to wrap certificates in an Apple Configurator profile, this is much more consistent with how Apple’s device management system works, as it relies on signed profiles with policies, not loose .cer files. And now, just by adding the .mobileconfig to the Profiles section of the device inspector, the embedded certificate is automatically marked as trusted, greatly speeding up installation on new virtual devices.

I was so inspired by Jason Coon’s macrochips project – 4” slate drink coasters laser-engraved to look like notable chips from computing history – that I had to design and make some of my own. I don’t own a laser cutter, but the local hardware store had one available, and I was able to convince them to let me engrave similar slate coasters despite them not being among their pre-defined set of available engraving targets (keychains, mugs, and the like). But what to pick? I decided to go with some chips that were meaningful to me:

• Apple A17 CPU
• Nintendo 64 CPU
• Sony PlayStation CPU
• Broadcom Raspberry Pi 5 CPU
• NVIDIA Media and Communications Processor (from the original Xbox)
• IBM PowerPC 603 CPU (from early PowerPC Macs)
• Motorola PowerPC G4 CPU (from later PowerPC Macs)
• AMD K6 CPU
• Intel i386 EX CPU

The hardest part of designing these was tracking down vector versions of some of these companies’ now-obsolete logos, extracting them from PDF files and datasheets, but I think the designs turned out pretty good:

Once designed, it was time to hand them off to the laser cutter:

It was fun to watch the designs get laid down by the laser cutter:

The results turned out alright:

Though, there were a number of text layers I forgot to convert to outlines, so the engraving prep software replaced them with Myriad instead of the specific fonts I had chosen. As well, a few early attempts were also a little mis-aligned. I could certainly do better if I had time to sit and make adjustments with my own laser cutter…

I finally caught up to 2024 and finished playing Indiana Jones and the Great Circle to 100%. I had been putting off starting the game for some time because I’m really not much of a gamer, and I find it oddly difficult to internalize new game control schemes and menu systems. But once I finally picked up the controller, it didn’t take long to get acquainted with the intuitive grip and whip system, and I’m so glad I did, because this game is really something special.

Look and Feel

MachineGames did a fantastic job at matching the feel of the source material. The levels are dense with detail, the typography looks just right, and there are both first person in-game and third person cutscene references to the films’ cinematic choices at every turn. Most notably, the use of hard contrasting light and shadow appears fairly often while exploring. Following along with the game’s story feels like enjoying a lost installment from the original trilogy, which is a bar I didn’t expect it to clear going in.

Carefully placed spotlights and torches regularly cast Indy’s recognizable shadow.

Light reveals Indy’s eyes when he’s making a connection or solving a puzzle.

Open Kapitalen and Eurostile Extended welcome you to new regions and lend film authenticity.

Choosing a mostly first-person adventure also seemed like a big development risk. For an iconic character like Indiana Jones, it’s definitely a choice to not show him for large swaths of the game. To make it convincing, they had to lean hard into what it would be like to be Indiana Jones. So much would revolve around what you can do with your hands and whip and items. Therefore, that in-game system had to feel very comfortable to use and be pretty extensive. I had played a few previous Indiana Jones (and of course, Tomb Raider) games which were all third person, so going in, I thought first person would be weird or off-putting, but this game does it so well that I now prefer it over third person or over-the-shoulder views.

The developers clearly spent a lot of time studying the films. They picked up so many of Indy’s smirks, quirks, and mannerisms, and when combined with Troy Baker’s shockingly accurate voiceover work, you’d be surprised to learn it wasn’t voiced by and motion captured from Harrison Ford himself. The humor from the films is also ever present and used to great effect. Even beyond the dialogue, the yells, grunts, and exclamations all sound so perfect, capturing Indy’s intonation well.

What really put it over the top for me, though, is the music and sound. The game features a lovely and familiar score, threading John Williams’ original themes through new material in a way that sounds completely organic and unforced, rather than just quoting the Raiders March and calling it a day. As well, the sound effects are also very much on point, with whip, punch, and gunfire having the signature cracks, thuds, and pops that seem right out of the films.

There are a few behind-the-scenes videos that go deep into all of this, and I watched them with a big stupid grin on my face. Hearing the development team talk about watching the films together, cataloging the core details that had to be right, and obsessing over everything clearly paid off.

It’s also just a gorgeous game. The id Tech 7 engine looks incredible on modern devices, rendering lighting and geometry in more detail than I’m used to in games (again, I don’t play a ton of games). The amount of just stuff to see in the levels is impressive. I can’t even imagine how long it took to set-dress all these areas. Notably, many of these items can be used as weapons or distractions, including wrenches, frying pans, mops, and bottles.

Just marvel at the level of detail achieved here: The fine individual hair, the wear on the seams of the leather jacket, the distressed fur felt on the fedora, and the specular highlights on the sclera of the eyes.

Every region has loads to explore, little sub-plots to follow, and NPCs going about their business. Some casually relay details or hints towards as-yet-unsolved puzzles.

Gameplay

The game heavily encourages you to lean on Indy’s punch and whip maneuvers rather than using his revolver. Ammo isn’t something to be spent carelessly. Rather, you save it for the moments when you get into a jam that’s larger than you can otherwise take on. But the cost of using a loud weapon is that nearby enemies will overhear it, blow the whistle on you, and rally reinforcements, so you need to pick and choose your battles carefully rather than playing it like a run-and-gun first person shooter. While not a stealth game, climbing, disguise, distraction, and a healthy dose of hand-to-hand combat will get you further than running headlong into battle. Certain classes of enemies will also see through your various disguises and similarly call attention to you, so you need to be aware of who’s nearby.

Attention to detail is everywhere in this game. Here, the number of remaining shots in the heads-up display corresponds to the number of visibly unfired rounds in the revolver. The reload animation has Indy individually pluck out spent rounds and replace them, rotating the cylinder for each.

The game balances exploration, discovery, collection, puzzle solving, and storytelling well. I rarely found myself spending too much time doing any one of those activities. The puzzles aren’t particularly difficult, with key items often just in adjacent crawlspaces, but they’re also not too simple. They feel calibrated to make you think, but aren’t so onerous that they impede advancing the story.

Along the way, you pick up money, bandages, food, local maps, and Adventure Books that expand your capabilities. The books are the game’s skill system, where you can improve your abilities like reducing reloading time, increasing damage dealt against enemies, or boosting climb and run stamina, and finding them is a nice reward for exploration. Once learned, they make future encounters progressively more achievable and boost your confidence to take swings at more aggressive confrontations. Indy is a scholar and a problem-solver first, so getting better at the job through research feels like the right approach.

Acquiring and reading Adventure Books boosts combat, survival, brawling, etc.

Even the Pause menu looks like it belongs. Also, hey, it’s me: I’m mac_minded on PlayStation and Mac Minded on Xbox.

That Belongs in a Museum

The Order of Giants DLC is a worthwhile addition, though it left me wanting even more time in this world. What MachineGames accomplished here is astounding. Licensed games based on beloved properties like Indiana Jones have a history of often getting surface details right but missing what actually made the source material work. This one didn’t miss at all. It understood what Indiana Jones is about well enough to make a game that genuinely belongs on the same shelf as the films. I don’t know if it will happen, but I would very much love a sequel.

When deploying web apps, I use containers almost exclusively. Containerization lets you package up everything your app needs and ship all of it to a container runtime in a single archive. While it has some drawbacks, it’s still a significant net improvement over web app deployment methods that pre-date it.

I use uv to install dependencies into a container image, but I typically don’t want to create a Python virtualenv within the container because then there are two levels of isolation to contend with. Just the container alone is sufficient. However, I still want all the benefits of using uv, particularly the specific tree of dependency versions and their hashes listed in the uv.lock file. For this reason, I configure uv to install the listed dependencies into the container’s “system” Python at install time, rather than a virtualenv .venv/ directory:

FROM registry.redhat.io/rhel9/python-312:latest

WORKDIR /opt/app-root/src

# Use the "system" Python for uv (the container's)
ENV UV_SYSTEM_PYTHON=1
ENV UV_PROJECT_ENVIRONMENT=/opt/app-root

# Install uv
RUN pip install --upgrade pip==26.0.1 && pip install --upgrade uv==0.11.4

# Copy only dependency files first to cache the dependency installation as its own container image layer.
# --active: prefer the environment specified by VIRTUAL_ENV (in the upstream RedHat Python base image)
# --frozen: treat the versions in uv.lock as the source of truth and skips updating the lockfile
# --no-dev: skip dev dependencies, since this is a non-development environment
# --compile-bytecode: compile Python files to .pyc files to trade CI build time for faster container start time
# --no-python-downloads disables automatic downloads of Python so we use the container's
COPY pyproject.toml uv.lock .
RUN uv sync --active --frozen --no-dev --compile-bytecode --no-python-downloads

# Copy the rest of the codebase in a separate layer
COPY . .

CMD ["granian", "app:app"]

Those options will use uv to install dependencies into the container-provided Python environment at /opt/app-root/ in the Python image rather than creating a new virtualenv at /opt/app-root/src/.venv/. With this, you can omit uv run ... from container commands, cron jobs, etc. Opening a shell into this container will drop you into a place where the dependencies are installed and readily available without having to activate a virtualenv, prefix tool invocations with uv run, or specify a container ENTRYPOINT).