ZealOS: one release named latest, two unnamed scripts, and a boot path with three licences

The only release is called latest and points at a November 2025 commit

The repository has one release. Its name is `latest`, its title is Pre-Built ISOs, and it carries a bare commit hash, eee210f4379ba3d00b47507f336a158eefb2c993, dated 2025-11-10. A release called `latest` is a moving label rather than a version number, so there is nothing to pin in a dependency or a download script: whoever fetches that name gets whatever the tag points at on the day they fetch it. The hash beside it is fixed, though, so the release is reproducible if you keep the hash and ignore the name. The number worth weighing is the gap between that release and the repository it came from. The last push is dated 2026-09-14, about ten months after the ISO in the release asset was built, so everything committed in between exists in the tree and in no prebuilt image on the release page.

Two scripts are named and neither one comes with a command line

The build step gets one sentence: to create a Distro ISO, run the `build-iso` script, and the details go to a wiki guide linked as Building-an-ISO. The contribution step is written the same way, with a `sync` script that merges changes made inside the OS back into the repository. Neither script appears as a command, neither carries a listed flag, and no path is given for either one, so the entire build procedure lives in the wiki instead of the repository. The install guides are linked the same way, three of them, for VirtualBox, for VMWare and for bare metal. The bare metal one is spelled Installing-(Bare%E2%80%90metal), with a percent-encoded character inside the path where the other two use plain words, so any link checker that compares the visible text against the target will flag that entry and not the others.

Virtualization acceleration and C knowledge are prerequisites, not suggestions

The prerequisites list is short, and every item is a condition rather than a tip. Running in a VM requires Intel VT-x or AMD-V acceleration enabled in BIOS settings, with the note that this is needed to virtualize any 64-bit operating system properly. On a Windows host, Hyper-V must be enabled first, with a Microsoft documentation link for turning that role on. The third item is working knowledge of the C programming language. That last requirement is unusual in a list of this kind, and it lines up with what the project is made of: the repository reports HolyC as its primary language, and the change list records the step from HolyC to ZealC. A reader who has never written C is being asked to read and modify an operating system before getting as far as producing a bootable image.

The screenshots show network clients while the networking stack is still in development

The features-in-development list has four items: 32-bit color VBE graphics, fully-functional AHCI support, network card drivers and a networking stack, and UEFI booting through the BSD2-licensed Limine bootloader with the Public Domain ZealBooter prekernel. The screenshots section printed below it shows a Network Report, a Gopher client, an FTP client, GrDir and AutoComplete over a Stars wallpaper, and its caption is 32-bit color. So two of the four in-progress items have visible evidence in the same file. That leaves the list ambiguous rather than wrong: nothing in the captions gives a date, a version or a build, so a reader cannot tell whether those images came from a contributor build, from a branch, or from an earlier revision of the same fork.

Contributing means building an ISO, installing it in a VM, powering off, then running sync

The contribution section offers two routes. The first is the one credited to Terry's intent: build the latest ISO, install it to a VM, make the changes inside the OS, power the VM off, and then run `sync` to merge those changes into the repository. That order has consequences worth naming. Edits made inside the running system live in the VM's disk image and nowhere else until the sync step runs, and sync is a post-shutdown step, so an unclean shutdown costs the work with no recovery path described. The second route is to edit repository files with an external editor, outside the OS entirely. Both routes end the same way, with a pull request against the `master` branch. No test command appears in this file, so what a reviewer is expected to run before merging is not written down here.

The boot path crosses an Unlicense repository, a BSD2 bootloader and public domain code

The licence field is Unlicense, and the guiding principles name transparency, full user control and adherence to public-domain/open-source implementations. The boot path then reaches outside: UEFI booting goes through the Limine bootloader under a BSD2 licence, the ZealBooter prekernel is public domain code kept in this repository at zealbooter/src/zealbooter.c, and the graphics item on the development list points to HolyGL in another organisation's project. A licence field describing only this repository is normal practice, so none of that is a conflict on its face. What is worth recording is that one boot chain crosses three different licensing answers, and anybody who rebuilds and redistributes the ISO has to settle each of them separately instead of assuming the Unlicense covers the assembled image.

HolyC became ZealC and the whole codebase was renamed for clarity

The change list is the clearest statement of what modernization meant here: 60 FPS, VBE graphics with variable resolutions, code reformatted for readability, comments and documentation added, the step from HolyC to ZealC, and a system-wide renaming for clarity. Two of those six entries change behaviour and four change text, and only one of the four touches the language. The rename is the reason the repository still reports HolyC as its primary language while the project calls the result ZealC. The root is small, ten entries, with code in `src/`, build material in `build/`, the prekernel in `zealbooter/` and images in `screenshots/`, next to `.editorconfig`, `.gitattributes`, `.github/`, `.gitignore`, `LICENSE` and `README.md`. Reformatting a codebase that size is what makes older blame lines and older diffs stop meaning much.

Three forks between 2019 and 2021, with the middle one surviving as archives

The background section traces the lineage in three steps. Around November 2019 VoidNV forked ZenithOS from TempleOS. That repository was removed in August 2020 and reuploaded under a ZenithOS organisation, and releases of the pre-git ZenithOS are held at a mega.nz link, while the front page, a master.zip and the related links are mirrored through archive.org. In July 2021 ZealOS was forked from ZenithOS. The practical consequence for anybody comparing behaviour is that ZealOS sits two generations away from TempleOS and one generation away from a repository that changed location twice. A diff against an original TempleOS checkout therefore mixes a fork, a removal, a reupload and a rename into one comparison. The stated intent, that one person should be able to comprehend the entire system within a few days of study, is the reason the reformatting and the comments exist at all.

Editorial conclusion

Read ZealOS as a study project rather than a daily driver, and check three things before building anything: which commit the `latest` release actually resolves to, whether the features-in-development list still matches the screenshots, and which licences apply to the Limine bootloader inside the image you assemble. What carries the most weight for a reader is the reformatting, the added comments and the step from HolyC to ZealC, and none of that reaches a downloadable ISO until somebody cuts the next one. Build inside a VM with hardware acceleration enabled, because that is what the prerequisites ask for, and treat the wiki rather than this README as the real build documentation.

Frequently asked questions

Official sources

1. License: Unlicense
2. Project website
3. README
4. Releases
5. Zeal-Operating-System/ZealOS on GitHub