ArozOS's manifest says JavaScript while its docs still require Go

The manifest says JavaScript and the build instructions say Go

The repository description announces a rewrite in one sentence, with an exclamation mark: it is now written in Go. The build section below still begins by requiring Go 1.20 or above, and the five commands it gives are a clone, a change into a source directory, a module tidy, a build and a run. So the documentation has not caught up with the claim in the header, or has caught up with only part of it, because the repository's own primary language is recorded as JavaScript. That combination is worth pausing on, because it means a reader has three signals and no way to tell which is current. The feature list also mentions an ECMA5-style scripting interface alongside third party Go and Python module development, so the runtime language and the extension languages are three different things and the description only mentions one of them. Nothing in the visible text says when the rewrite happened or how much of the old implementation remains.

The startup flag reference is two majors out of date

The section listing supported startup parameters is headed with a version number, and that number is two major versions behind the current release. The release history shows three tags in 2026, a three point zero, a three point zero point one and a three point zero point two, and the reference is labelled for a two series build. That is not a cosmetic staleness, because the section is the only place the flags are described, so a reader configuring the system is reading a reference for a different version than the one they downloaded. The reference is also cut off partway: the last flag listed has no description, so the list is visibly incomplete in the text that is present. The documented examples that follow are more useful in one respect, because they show the shape of the flags rather than their list: a port for the standard web port, a demo mode flag, a transport security flag with a key and a certificate and a separate port, a flag to serve both protocols at once, and a maximum upload size.

Five capability flags default to on, and one of them is autologin

Read the documented flags as a set of defaults rather than as a list. Each of the five carries an explicit default of true. Autologin allows a REST login redirection so that machines like billboards can log in to the system on boot. Cluster operations within the local network are on, as are discovery and the ability for nearby instances to scan this one. Internet of things related APIs and a scanner are on. And the system is permitted to install packages using the system package tool. Four of the five depend on discovery being enabled, which is itself on, so the chain is already live out of the box. The autologin flag is the one to read twice, because a machine that can log itself in on boot is a kiosk rather than a secured host, and it is the default. A flag that disables plain HTTP also exists and appears in the examples, so the transport security decisions are all configurable; the question is which way they point before first boot rather than after.

The installer is a second shell script fetched over the network

Installing a precompiled build is one line, and the shape of it is worth naming. It downloads a shell script from a raw address on a branch, then executes it, with the rest of the setup left to on-screen prompts:

wget -O install.sh https://raw.githubusercontent.com/tobychui/arozos/master/installer/install.sh && bash install.sh

The address points at a branch rather than a tag, so the script that runs is whatever that branch currently contains. The file then offers the alternative. Building from source is a clone, a change into a source directory, a module tidy, a build and a run, followed by a parenthetical that says, in effect, that is genuinely all of it. That path needs the toolchain the previous section still asks for. Two smaller consequences of the installer path are stated as well. It can register itself as a service, checked with a status command, or you start it by hand from a directory under your home with a privilege escalation. And after installation it unpacks the files it needs, which the file says takes three to five minutes depending on the host's processor and disk, before the web interface is reachable on port 8080.

Three of the four platform builds are called experimental

The install section covers four platforms and is unusually candid about which of them are finished. Linux is the tested path, across three processor families, with a Raspberry Pi, a Pi Zero and an Orange Pi named as examples along with a small virtual machine, and the file says it has only been tested on Debian based distributions. Windows covers one architecture, needs a media toolchain added to the path, and puts a note under it saying some features are not available on the Windows build and that the arm64 version is experimental and not tested. The router firmware target and two Linux architectures for newer processors are described as experimental and as possibly containing unexpected behaviour, with an invitation to contact the author directly if you want to test or maintain them. The container route is contributed by someone else, lives in a separate repository, and is marked work in progress. That is four platforms, eight architectures, and one of them confident.

It serves FTP, WebDAV and SFTP as part of a desktop

The feature list describes something larger than a file manager. It mounts local file systems in several formats and remote ones over three protocols, and it runs its own servers for file sharing over FTP, WebDAV and SFTP. It adds a basic authentication protected HTTP interface described as being for legacy devices with outdated browsers, which is an admission that some of the target hardware has browsers older than the desktop interface expects. It wraps that in a virtual file system with a sandbox architecture, offers file sharing on a model the file compares to a consumer cloud drive, and adds storage pools configured through a settings screen where you name a pool and give it an identifier. The interface is a browser desktop with a start menu, task bars, a file manager with drag and drop, and a settings menu. The feature list puts the resource floor in the same register as the UI claims: half a gigabyte of memory and one and a half gigabytes of storage.

The browser decides which interface you get

Because the desktop is a web page, the interface has to be chosen, and the choice is made from the browser's own description of itself. The file notes that some browsers hide their user agent and, for exactly that case, provides two fixed paths that force the layout: one for the mobile interface and one for the desktop interface, both on the local port. That is a small and sensible accommodation, and it is also the only part of the interface story the file explains. Everything else about the desktop is asserted rather than shown: the start menu and task bars are described as being in the style of one desktop distribution, the file manager as clean and easy to use, the settings menu as simplistic, and the module naming scheme as the subject of a blunt phrase that is worth quoting rather than paraphrasing. Updates are handled by a separate launcher project, which exists so that over the air updates do not require a shell on the host.

Editorial conclusion

This suits a single board computer or a small virtual machine where you want a file manager, a network dashboard and some remote mounts without installing a full desktop stack, and the resource floor it states is genuinely low. Three things to decide before you install it. Read the startup flags rather than assuming defaults are conservative, because the capability flags the file documents are on by default, including the one that lets the machine authenticate itself on boot and the one that lets the system install packages with the system package manager. Choose your platform build from the honest table rather than the headline, since three of the four are flagged experimental, untested or work in progress. And note that the flag reference you are reading is labelled for a version two majors behind the current release, so treat undocumented flags as existing and unverified. The installer fetches and executes a shell script from a branch address, so read it before running it or build from source, which is five commands and still needs the Go toolchain according to the documentation.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. tobychui/arozos on GitHub