LCOS: a Devuan-based Linux system with one person in charge

Seven refusals, and a base that already removed Systemd

The list that defines LCOS is a list of things it will not do: no age or ID verification, no online accounts needed, no built-in AI features, no weird politics, no Systemd, no forced Rust clones, and modern tech with a 90s UI. Five of the seven are about what the system refuses to ask of you or put in front of you. The other two split cleanly: No Systemd and No Forced Rust Clones are about the code underneath, and read as a refusal to replace working software with a newer language for its own sake, while Modern Tech. 90s UI. is a statement about the surface. The base makes one refusal cheap. LCOS is built on Devuan, which the project describes as a fork of Debian that removes Systemd, so No Systemd is inherited rather than fought for. The browser choice follows the same logic, a stripped-down Brave Origin as the default. GitHub counts CSS as the repository's primary language, which fits a project whose stated aesthetic is modern internals under a deliberately old-looking shell.

The King has total control, and that is the pitch

A section of the README is titled that LCOS is a monarchy, and the body is two sentences: LCOS is not a community project, and the King has total control, both technologically and organizationally. The benefits offered are specific. The first is that political activists cannot seize control, which the README connects to what has happened at other open source projects and organizations. The second is focus, since there are no committees to pull the work sideways. Read as an operating constraint rather than a boast, it means every decision about what ships, what gets patched and who can change it rests with one person, and a user who disagrees has no in-project path to argue it. The repository root matches that model: it holds a CodeOfEthics.md and no CONTRIBUTING.md, no MAINTAINERS document and no .github/ directory.

Upstream first, with hiring instead of a patch set

LCOS tries to avoid LCOS-only code changes whenever possible and prefers to ship vanilla versions of upstream projects. When a change or a fix is genuinely required in an upstream project, the stated preference is to hire that project's own developers to implement it upstream, so the work benefits everyone and the engineers get paid. The consequence is that source deviations from upstream are kept to an absolute minimum, and new code, including entire new packages, is written only where there is a clear benefit. That is a coherent policy with a real cost: a fix the project needs can wait on someone else's schedule, and the funding model behind the hiring is not described anywhere on the page. For a user, the practical effect is that LCOS packages look boring, which is the point, and that a local bug stays local until upstream agrees to carry it.

Each release publishes its own package source list

All source code for all packages, including the specific versions in use, is listed in a PackageSourceList.md file for each release. The repository makes that concrete: six files sit at the root named LCOS-02-PackageSourceList.md through LCOS-07-PackageSourceList.md. The numbering runs ahead of the release names, though, because the recent releases are 0.6, 0.7 and 0.7.1 and there is no file whose name matches a version string directly. So the promise is auditable but the mapping is not self-evident: to find out what a given release shipped, you open the lists one by one and match the versions yourself, which is exactly the work the Upstream First policy leaves you with, since deviations are minimal but not zero. The three working directories beside them, lcos-packages/, lcos-updates/ and lcos-xlibre/, are where the packaging work sits, the README does not explain what the last of those holds, and a screenshots/ directory stands empty of images on the published page.

No AI in the build, no policy against AI in the source

LCOS takes two different positions on artificial intelligence and states both. On the product side it is a classic desktop operating system with no requirements for online accounts, no ID verification and no AI features by default, phrased as one of the seven refusals. On the user side, someone who wants to install AI tools is left alone: LCOS will not stand in their way, on the stated principle that a person should be able to install whatever software they like on their own computer. On development it declines to rule at all, because the Linux kernel LCOS already uses is heavily developed by AI nowadays and banning AI in LCOS development would be hypocritical. That combination means a default system with no AI in it, no lock on what you add, and no contribution rule either way.

Feature complete for 1.0, and still called beta

The status section is short and worth quoting closely. LCOS is in the Beta stage of development, which the README defines as meaning the system is considered Feature Complete for the 1.0 release while still containing potentially significant bugs. So the feature list is meant to be done and the quality is explicitly not claimed. The release cadence backs up the beta label: 0.6 shipped on 24 September 2026, then 0.7 and 0.7.1 both on 29 September, three releases in six days, with version numbers written without a v prefix. The repository is not archived, the code is GPL-3.0, the default branch is master rather than main, and the last push to that branch is dated 30 September 2026, the day after 0.7.1.

The support channel is a paid forum, not an issue tracker

The Lunduke Journal Forum is named as the best place to ask questions, provide suggestions, report issues or talk with other LCOS users. The same paragraph explains why you will find it closed: the forum at forum.lunduke.com is available only to Lunduke Journal subscribers at lunduke.com, and the stated reason is to keep trolls away. That means the practical answer to a broken install is a paid subscription rather than a public thread, and the repository root carries no .github/ directory where an issue tracker or a workflow file would live. Combined with the monarchy arrangement, the support path and the decision path are the same person, reached through a commercial front door. The README also ends with a Screenshots heading whose images are not present on the published page.

Editorial conclusion

LCOS fits someone who wants a Debian-derived desktop with no Systemd, no account prompts and no vendor AI in the way, and who is comfortable with a project where one person decides what ships. It does not fit anyone who needs an open contribution path, a public issue tracker or a community that can fork the distribution and keep it alive, because the README calls the project a monarchy and the only support channel is a subscriber forum. Before you try it, read the package source list for the release you are considering, since each release publishes one and the file names do not line up with the release numbers, and check whether a fix you need exists upstream first, because LCOS prefers to pay an upstream developer rather than carry its own patch.

Frequently asked questions

Official sources

1. BryanLunduke/LCOS on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases