A new Linux-from-scratch distribution with a clean libc design (openlinux) — looking for contributors

Posted by throwbly@reddit | linux | View on Reddit | 35 comments

Hey r/linux — for the past few months I’ve been working on openlinux, a new Linux-from-scratch distribution built as a cohesive, BSD-style monorepo. The goal isn’t to be “yet another distro,” but to build a clean, minimal, and fully self-hosted userspace with a clarified ABI, reproducible toolchain, and a libc designed from first principles.

I started this project because I always felt the Linux ecosystem lacked something comparable to OpenBSD’s simplicity and coherence — but still Linux-based, with the flexibility and hardware support that entails.

openlinux is being built entirely from scratch:

from boot (EFI stub + bootconfig)
to a minimal init
to a new libc implementation
to a simple shell and userspace stack

While working on Router OS at eFAB P.S.A, I learned how essential proper tooling is for OS development. That’s why openlinux ships with QEMU-ready disk images, Docker-friendly rootfs tarballs, and a unified build environment that works cross-architecture from day one (x86_64, aarch64, armv7-m).

But the most important part:
I want this project to grow into a friendly, open community — not another cold “outsiders unwelcome” environment. A place where people can ask questions, contribute, discuss design philosophy, and help shape something genuinely new.

If you’re interested in system-building, libc development, reproducible builds, minimal userlands, or just want to see a Linux system grow from zero, I’d love to have you involved. Check out the docs, the philosophy, and jump into the issues/PRs anytime. :D

[-]

dewman45@reddit

And there's the em dash.

[-]

Fenguepay@reddit

I'd be interested to know how well this works with my initramfs project (ugrd)

[-]

throwbly@reddit (OP)

our initrd just mounts things and runs real init now… maybe i will add fsck, at this point has only 2 files /init and /bootconfig.txt; we also has no bootloader we just use kernel efistab to boot from itself.

[-]

Fenguepay@reddit

if that's all it's doing, is there any real reason to even include an initrd?

what is the bootconfig stuff?

[-]

throwbly@reddit (OP)

https://github.com/openlinux-src/src/tree/main/arch/x86_64/initrd

here is how im building initrd

[-]

Fenguepay@reddit

if you're already using python you could use pycpio to actually "craft" the initrd ;)

[-]

throwbly@reddit (OP)

and including initrd is necessary to mount ext4 partition

[-]

Fenguepay@reddit

i don't think it should be if the ext4 and storage drivers are built into the kernel. You just have to be sure to mount by partuuid not uuid or label

[-]

MarzipanEven7336@reddit

Every single thing that your initrd wants to do, systemd already can do, and does it better in every way.

[-]

Fenguepay@reddit

systemd based initramfs's are larger, slower, and more prone to failing in weird ways (udev can get hung up). They also tend to require explicit config for things like LUKS settings where ugrd autodetects most of that (and validates config). It's very easy to misconfigure your crypttab, but not every initramfs system will even use that.

[-]

throwbly@reddit (OP)

beautiful project btw

[-]

Fenguepay@reddit

thanks, I've put a lot of work into it. I'd like to make it compatible with most systems, libcs, and "target" init systems. The main things which have presented challenged are really systemd which doesn't like if udev isn't used for mounts, and musl because the ldconfig stuff is done manually

[-]

deviled-tux@reddit

Are you providing glibc compatibility?

[-]

throwbly@reddit (OP)

I’m working on the glibc layer. The project is under heavy development, so I can’t say it’s finished yet. I’m also looking for maintainers to help get it done as soon as possible.

[-]

deviled-tux@reddit

Awesome, just wanted to see if it was on the roadmap as this has been a major blocking point to adoption of other libc on Linux

I’ll take a look and see how I can help your efforts

[-]

Specialist-Delay-199@reddit

if I had a dollar for every new libc implementation on Linux I'd hire developers to write another libc

[-]

throwbly@reddit (OP)

If I had a dollar for every “new libc” joke, I’d have enough funding to finish ours faster.

But seriously — we’re not writing “yet another libc” for fun. The goal is to solve problems that existing distros keep duct-taping for decades: ABI breakage, dependency chains, backwards-compatibility nightmares, and shared-object roulette.

If we can clean up even a fraction of that mess with a fresh design, that’s worth more than a dollar — and definitely more than one more glibc wrapper.

This libc isn’t meant to be “generic” like musl or glibc — it’s intentionally designed to sit much closer to the kernel. Try touching a single line in musl or glibc and see how fast the entire universe collapses on you.

We prefer something we can actually control, not a cathedral of legacy code held together by symbol versioning and good intentions.

[-]

ZunoJ@reddit

Is this an AI post? This comment has all the tell tale signs

[-]

The_real_bandito@reddit

Dang, I couldn’t tell this was an AI post. It’s true about the dead internet theory.

[-]

throwbly@reddit (OP)

im in travel right now, the only plus of ai is that i can talk to it what i want to write and then just copy paste. Its something like clang-format 🥱

[-]

Specialist-Delay-199@reddit

You might wanna stop formatting the code I'm getting compilation errors so you gotta write it by hand

[-]

throwbly@reddit (OP)

🥲

[-]

imbev@reddit

Failing to build with make[2]: *** No rule to make target 'install'. Stop.

A very interesting project

[-]

throwbly@reddit (OP)

Kidding of course! 😄 If you could share a bit more information, I’d really appreciate it. A full log from make V=1 or make --trace would help a lot, as well as the part of the Makefile that defines (or is supposed to define) the install target. Without that it’s hard to tell what’s going on

[-]

imbev@reddit

Of course! Does the project have a public chat?

[-]

throwbly@reddit (OP)

not yet… but maybe we can open discord server?

[-]

voracread@reddit

Please consider Matrix.

[-]

imbev@reddit

That would be useful. I'll open an issue on the repository in the meantime

[-]

throwbly@reddit (OP)

„talk is cheap, send patches”

[-]

BinkReddit@reddit

Kudos to you! I don't have the skill set to pull this off, but I'm glad someone like you does. My favorite operating system, by far, is OpenBSD; while it is truly excellent for many applications, it doesn't always fit the bill and that's when I turn to Linux.

I'd love to see your project come to fruition.

[-]

throwbly@reddit (OP)

Thanks — appreciated, but no need for kudos; I’m just doing my thing

OpenBSD fans are a special breed. It’s one of those systems where, if it fits your use case, nothing else compares. Clean design, clear documentation, sane defaults… it just feels right. And yeah, when you need broader hardware support or that one toolchain that only behaves on Linux, switching makes sense

I’ll keep pushing the project forward — comments like yours genuinely help. If you ever want to bounce ideas about the OpenBSD side of things, portability concerns, or how to structure the Linux modules so they don’t become a mess, Im here ❤️

[-]

Dwedit@reddit

Why not Alpine?

[-]

throwbly@reddit (OP)

Yeah, the Alpine question is fair — but here’s the thing: we’re building everything from scratch, not relying on third-party software as “packages.” The system base will be fully configurable.

What we’re aiming for is essentially an OpenBSD alternative built on Linux (mono-repo), where we have complete control over optimization. It’s no coincidence that the kernel doesn’t ship with libc — building everything from the ground up with a new approach opens doors that are closed in today’s distributions, where you’d otherwise spend millions of hours patching and praying for continuous backward compatibility.

Alpine, for the most part, relies on a stack of interdependent packages. In contrast, we want a system where you can just drop a program over with a simple scp, and it will work on another platform without dependency hell or broken libraries. I recommend reading the project philosophy — I’m always open to discussions about the direction this project should take.

Also, I suggest checking out Plan 9, articles from suckless, and catv — they explain why we don’t have shared objects or a system-wide libc.so. In our base system, there won’t even be a libc.a — it will only be available as a package for developers.

We’re also deliberately not going down the Gentoo route, where everything is compiled from source. That’s why we focus on the two most popular platforms initially. Expanding to additional platforms won’t be difficult, because the project is modular by design.

So why not Alpine? Because Alpine is not built from scratch into a complete system image — it’s glued together from pre-built “someone else’s packages.” Our toolchain only builds our own tools and libraries, while third-party libraries will be available as separate packages if needed.

[-]

adamkex@reddit

Have you read this? https://jangafx.com/insights/linux-binary-compatibility

[-]

throwbly@reddit (OP)

That’s a solid proposal, and we’ll definitely take it into account for future package builds. For now, we’re only building toolchain packages (not used anywhere yet), but we also plan to introduce a dedicated glibc layer so applications can compile in full GNU mode.

All our binaries are built statically, with aggressive dead-code elimination. We don’t plan to introduce shared binaries — we consider them harmful for optimization and, contrary to popular belief, they tend to slow programs down. So we’re sticking to a fully static approach.