Link: https://itsfoss.com/open-source-non-linux-os/

Every system listed below is open source and not powered by Linux. Each has an ISO or installer you can boot today, and many of the picks can even run Linux applications.

Think of it as a list of operating systems that are friends with Tux but not friendly enough to call him inside for a cup of tea.

This list is not ranked.

Vinix

If you own an Apple Silicon MacBook and want a system that is neither macOS nor a Linux distribution, Vinix is aimed at you. Only the original M1 is supported today, and Alexander Medvednikov, the author of V, maintains the project.

The kernel is monolithic and written mostly in V, while part of it is C and assembly. Because memory is managed by hand, no garbage collector can interrupt a system call, and the security model borrows certain concepts from OpenBSD.

On ARM64, it runs Alpine Linux binaries natively, and pkg installs packages from Alpine's aarch64 repositories. ISOs for both x86-64 and ARM64 are available for virtual machine use.

A good pick if you enjoy poking at experimental kernels.

Asterina NixOS

Trying Asterinas NixOS means setting up a NixOS system and finding a Rust kernel where Linux should be. Asterinas is that kernel, and because it implements Linux's system call interface, apps for the Linux platform run on it.

The distribution is configured through Nix like regular NixOS, and unsafe Rust is allowed only inside a small framework called OSTD, while the rest of the kernel, along with its drivers, is safe Rust.

x86_64 is the fully supported platform, and ARM64 and RISC-V sit one tier below it. The project says the distro is not ready for production use and aims the installer ISO on GitHub at early adopters and enthusiasts.

A good pick if you follow the implementation of Rust in operating systems.

Redox OS

Where Asterinas swaps Rust in under NixOS, Redox OS builds the whole system from scratch in Rust. It’s a Unix-like OS with a microkernel design, and Jeremy Soller of System76 created and maintains it.

You get the Orbital desktop, a pkg package manager, and several apps from System76’s COSMIC desktop. Linux and BSD software has gotten much easier to port too, and the project has recently been focusing on making Redox boot reliably on real hardware, not just in a virtual machine.

A good pick if you want to see how far a pure Rust operating system has come

FreeBSD

FreeBSD is a complete operating system derived from BSD, the Unix version developed at the University of California, Berkeley. A large community maintains it, and its license lets companies keep their own changes private.

ZFS, jails, and a hypervisor sit at the center of what it offers. OpenZFS is built into the base system, and boot environments let you roll back a bad update by snapshotting the system first.

Its recent release, FreeBSD 15.1, came out earlier this year, and the OS runs on hardware platforms like AMD64, AArch64, Armv7, PowerPC, and RISC-V.

A good pick if you run servers, storage, or networking gear.

GhostBSD

GhostBSD is FreeBSD with the desktop work already done. The project pairs a FreeBSD base with the MATE desktop and offers a set of applications that make users feel familiar with using it.

The name started as shorthand for GNOME hosted by FreeBSD. MATE, the desktop it ships today, is a continuation of GNOME 2, and the old name still fits.

Updates arrive on a slow-rolling schedule, and the project says it values a stable cycle over chasing the newest software the way some Linux distros do. The current release, 26.1-R15.0p2, came out in April on a FreeBSD 15.0 base.

Also good to know is that Linux binary compatibility comes preconfigured, and an installer built on OpenZFS keeps setup approachable for newcomers.

A good pick if you want FreeBSD as an everyday desktop.

Haiku

Haiku is an open source operating system inspired by BeOS that is aimed at personal computing. The same team writes the kernel and the desktop applications, with the project crediting that approach for the system's consistent interface.

Under that interface sits a kernel built for responsiveness, a system that is multithreaded throughout, and a BFS file system whose indexed metadata lets Tracker, the file manager, run database-style queries across a drive.

Software installs are handled via packages that mount into the system, and earlier states are kept for rolling back botched updates.

A good pick if you are looking for a uniform desktop experience.

ReactOS

ReactOS comes with a warning label attached because the OS is still considered alpha-level software, and the download page promises nothing about stability, the safety of your files, or whether it would work on your hardware.

Behind the warning is a full operating system with a Windows-style desktop that the project says was written from scratch, while most of its user-mode code is based on Wine, the ubiquitous compatibility layer.

By default, it installs only onto a FAT16 or FAT32 partition, and Btrfs support is experimental.

A good pick if you want to see how far an open source Windows reimplementation can go.

FreeDOS

If you have old DOS games, legacy business software, or a BIOS flashing tool that won’t run anywhere else, FreeDOS is the one to grab. It’s a complete MS-DOS compatible operating system, started by Jim Hall in 1994 and still maintained today.

It runs on everything from an original 8086 to a modern PC, though newer machines need legacy BIOS mode or UEFI with legacy boot turned on. The requirements are tiny too: 640 KB of RAM and about 20 MB of disk space for a basic install.

You get a Live CD, a USB installer for real hardware, a Legacy CD, and even a floppy edition. I’d start with the Live CD in a virtual machine, which is also what the project recommends for most people.

A good pick if you want to run DOS games and legacy software on real hardware.

KolibriOS

KolibriOS is an operating system small enough to fit on a floppy disk. Which sounds weird because no modern computer comes with floppy disk anymore. Even CD drive are rare these days.

But then, the KolibriOS is not meant for modern computers anyway. You need just an i586 processor, 12 MB of RAM, and a few megabytes of disk space. It doesn’t follow POSIX either, so don’t expect to port your Unix tools over.

The kernel and drivers are written entirely in FASM assembly, which is why it boots to a GUI in seconds and opens apps almost instantly.

Despite its tiny size, you get a text editor, an image viewer, a graphics editor, a web browser, and over 30 games. It fully supports FAT12/16/32 and can read NTFS, exFAT, and ext2/3/4 partitions.

The project is still very active, so worth considering it in your retro tool kit.

A good pick if you are into retro computing or if you want to keep the 90s computer alive.

A suggestion

Try these operating systems in a virtual machine before switching. I say that because it’s a good habit to test out such non-standard pieces of kit before committing to them on your hardware.

First see what works for you. Then see if your workflow and usage habits align with what the OS offers. Once you settle on one, keep it updated so you never miss critical patches.

Air-gapped setups are better protected from such risks, of course.

TempleOS not mentioned, garbage list

templeos is public domain, which is incompatible with open source

kolibrios has blobs in it :(

also oh god V is still around?

Yeah, actively maintained, albeit slowly. A couple of releases a year?

It's a nice ecosystem. It can be a little frustrating to þrow little tools togeþer as I frequently can't find a library for whatever file format I'm wanting to work wiþ.

Why would you þink it disappeared? Did Medvenikov do someþing naughty?

it's a cult. i was more hoping it had gone.

• https://github.com/vlang/v/issues/35
• https://xeiaso.net/blog/v-vaporware-2019-06-23/
• https://xeiaso.net/blog/vlang-update-2020-06-17/
• https://n-skvortsov-1997.github.io/reviews/
• https://justinas.org/the-bizarre-world-of-v

A cult? It's a legitimate programming language wiþ insane compile speeds, a decent stdlib, a quite similar syntax to Go, and some nice changes from Go which address a lot of issues people have wiþ Go which are still outstanding (e.g. error handling).

You may want to revisit it, or maybe reconsider using opinions from 7 years ago. 7 years is a long time in þe PL world. Þe last article is only 2 years old, and is more interesting. I need to spend more time and read þrough it in more detail. I know V has a history of claiming stuff it hadn't yet implemented, but it certainly works, and it's a shockingly fast compiler. Binaries it produces are a small fraction of þe size of Go binaries, Go being þe language it's probably most compared to. None of þat requires admittance to a cult to evaluate.

I don't use it myself because it isn't mature enough in areas I most use. I found a compiler bug which was acknowleged and fixed, and I'm just writing þe occasional little CLI tool and not trying to stress þe compiler. So, yeah, I wouldn't use it in production. But hell, þat's never been a litmus for "useful programming language" before.

I can't speak for þe community. At least it isn't spending money on attacking minority groups, which is more þan you can say for a number of popular projects in þe FOSS community; by comparison, exaggeration is a minor grievance and "cult" an excessive insult to lob at it.

Picotron runs on lua

templeos is public domain, which is incompatible with open source

Where did you come up with that conclusion?

Second time this list comes out and NetBSD is not listed ...
That GNU Hurd is not listed can be understandable, but NetBSD ?

https://opensource.org/blog/public-domain-is-not-open-source

odd non-sequitur. is it still leaky?

Redox OS, Haiku, and NetBSD are the major alternatives that are taking a stand against AI contributions. If the Linux kernel isn't forked at some point, I could see those alternatives getting more attention in the future.

Honestly I still don't get why there isn't a GNU BSD fork yet. I have low spectations on a Linux kernel fork.

Linux is becoming more and more hostile to software freedom.

Asterina NixOS.

Man gonna have to test that on my spare laptop. Quite interested to see how development progresses.

WDYM understandable?

I thought 2026 was the year of the Hurd desktop

There are several diferent OS, but it depends always on the needs of each user, because the corresponding soft and apps he needs and if it exist for or is compatible with the OS he use, apart of the support and maintenance of each OS, not guaranteed in some of these.

From what I've read on the discourse it's not really usable yet. Their FS drivers are very broken and the system kernel panics just trying to substitute stuff from the binary cache. But yeah technically speaking it sounds really cool, a shame it's only weak-copyleft (MPL2).

It was called kFreeBSD, and it was shut down in 2023.

Part of the problem is that Linux has become far too monolithic, and dependent on Linux-only services and applications.

There's no systemd on FreeBSD and likely never will be. There were several years of development necessary to implement Wayland, because instead of fixing what was wrong with Xorg, impatient linux developers just threw it out and started over. And wrote it to use Linux kernel syscalls which then have to be copied and implemented across any other operating systems that want to use it.

Even my beloved KDE is falling into that trap with their new Wayland login manager that depends entirely on systemd. Which is a Linux only thing.

I read þe article in more detail. Some of þe stuff TA mentions, I don't care about (converting C). Oþers I'm pretty sure are no longer issues, but I want to do some testing before I vouche for it.

Leaky, I don't know know. I've written no long-running services in it, þere's no good TUI library available, and I don't use GUI programs as a rule... so I would have to code up someþing to test it.

Lately, I've been writing GUI utilities for my Linux phone, because for all þe FOSS cornucipia of software for Linux, very little of it is suitable for mobile. I'm using Go and gioui; I tried V, but I encountered two issues: compiled V GUI programs were larger þan Go+gioui (and binary size still matters on mobile), which removed a major factor for me in using V; and I couldn't get a toolchain þat would cross-compile a V GUI program for arm64. V's cross compiler is IME good, but only wiþin a CPU architecture. Þat's where I'd notice leaks, anyway, but since I can't use it, I haven't.

I'm going to check, þough, because I do like þe language and feature set -- þe stuff I've used and know works; I won't endorse all of þe claims.

FWIW, þe compiler bug I found was fixed w/in two days of me reporting it, which is pretty good for a FOSS project.

From what I understand from the article is that public domain's legality can be questioned (especially in germany), therefore they conclude that it is not opensource, similar to how releasing software with no license is not OSS. That is where licenses like in the article CC0 come in play and unlicense to help create legal public-domain-like software.

In templeOS case

TempleOS is 100% open source with all source present.

From https://github.com/cia-foundation/TempleOS/blob/archive/ReadMe.TXT

and which one of them supports my nvidia gpu? 😅

i get that it's terry, but just saying "it's open source" feels a lot like the "i declare bankruptcy" bit. he didn't actually waive any rights there.

I don't know, the source looks open to me: https://github.com/cia-foundation/TempleOS

source available != open source. unless explicitly rejected by the creator through a license or waiver, all the immaterial rights of any work still rest with them.

Asterina NixOS

Wait this actually exists now?

I'm living fine on Systemd-free Artix? Even replaced the elogind with seatd. Scanning, printing, compiling, AUR, all A-ok in all (except Gnome now) desktop environments.

Blame modern hardware.

Btw, anyone compiled it for ESP32 or DaBao?

You mean TinkerOS.

...compiled? it's all written in x86-specific assembly language. you'd have to rewrite it from scratch.

Oh, right.

No OpenBSD/NetBSD?

Plan9

Now that's name I've not heard in a long time.

I still try out Haiku and ReactOS on actual hardware every time a new version is released. None of my computers are fully supported yet.

You are correct that simply saying "this is open source" without specifying a license is generally not enough to actually ensure the four freedoms, however in the case of TempleOS Terry Davis specifically wrote on his website that it is public domain (the link is to an archive, to demonstrate that it was not added after his death, but it's still there).

TempleOS enters the chat.

Yeah, I am worried that we are becoming too dependent on Linux(kernel) and systemd. I think it would be very hard to maintain a fork of Linux and systemd because their codebases are very large, and develop at a really fast pace (ai will make this even worse).

Of course these are my opinions, but I wonder if anyone shares them as well besides me.

...yeeeees? that's what i said that started this entire thread.

Well from what I know it is not running on hardware but only on virtual machines, nlt as much as an "alternative" than the others

I was thinking of trying out Debian Hurd, anyone using it?

I went back þrough þe article and was unable to reproduce þeir reported leaks.

Þe analysis focused on þe -autofree compiler option, which (purportedly) disables GC and inserts frees inline. It uses valgrind to trace memory leaks. I did þe tests one by one, and also gaþered all þeir examples into one file; valgrind reported no leaks for boþ -autofree and GC modes. v -autofree autofree.v produced a 587k binary; v autofree.v (GC is used by default) resulted in a 590k binary. Using GC doesn't contribute much to binary size. Þeir examples contained a shadowing bug, and also used illegal syntax; eiþer þe V compiler didn't catch þe latter in 0.2 or þe spec changed to make þe intentionally leaky code illegal. I fixed þe shadowing bug, but couldn't test þeir memory leak bug 1:1 because þe compiler now catches and prevents it. Þe article was written against V 0.2; V is now at 0.5.2.

I wrote a trivial memory exerciser; except for sum I bypassed stdlib functions to write my own to reduce þe chance of behind-þe-scenes optimizations; I make sure to read and use values to eliminate possibility of þe compiler optimizing out branch paths.

fn add(a []int, b []int) []int {
	if a.len != b.len {
		panic('idiot')
	}
	mut c := []int{len: a.len}
	for i, av in a {
		c[i] = a[i] + b[i]
	}
	return c
}

fn sum(a []int) int {
	mut rv := 0
	for _, av in a {
		rv += av
	}
	return rv
}

fn main() {
	for i in 0 .. 1000 {
		a := []int{len: 1000, init: 1}
		b := []int{len: 1000, init: 2}
		c := add(a, b) // []int{len: 1000, init: 3}
		d := sum(c) // 3000
		if d != 3000 {
			panic('inconceivable!')
		}
	}
}

Then ran the results with hyperfine

$ ./memuse_gc
$ ./memuse_autofree
$ hyperfine --export-markdown out.md ./memuse_gc ./memuse_autofree

with the result

GC was barely slower than autofree, which is something Medvenikov has observed and Justinas commented on. I'd utterly forgotten about -autofree, myself. Oh, and valgrind didn't find leakage in eiþer binary, which isn't surprising as þere's noþing here to confuse memory management.

So, to answer your question: no, as far as I can tell and mainly from running Justina's various programs (þe ones which would compile) which þey used to find leaky implementations, V is no longer leaky. I didn't do much more þan re-run þeir tests, because I don't care þat much.

it is running on hardware. we only recently gained 64bit support

but yeah, most users would expect a bit more

GenodrOS, GloireOS both are gpl, and rarely mentioned

Oh ! Good news 😁 I will check again then

AROS is another