The original words of Phanes, tirelessly carved into a slab of "No'".

Plans for Dark Horse Linux

So, as it’s nearing a bootable ISO, some stages of development seem to be forming in terms of expectations.

A Whole Image

First, I’ll end up with something very close to an LFS build that needs alot of work to get installed onto a different system.

Gentooesque Genesis, Slackwaresque Form

Then, I’ll end up with some kind of installer that seems like it will work very similarly to slackware’s and FreeBSD’s installer, but compiled in a very gentoo kind of way beforehand. I see this piece taking quite a bit of time to get through if I pursue that as far would be expected. The important pieces will be drive formatting/partitioning dialogs and tools, bootloader installation. Copying to the mounts appropriately etc.

A Familiar Set of Tools

Some ways after that, unless it doesn’t work the way I expect, I’ll probably pivot to an rpm-based system that, a certain point after librpm is compiled, binary packages are downloaded that replace the packages already compiled and installed. Systemd. Firewalld. Then the decision needs made about whether I’ll use DNF or an inhouse built package manager. One drawback I see about this is, some users will probably use rpms from SUSE and RH and Rocky and Fedora and run into build compatibility problems. On the other hand, some of the time it’ll actually work with a little tweaking of binaries. On the other hand, using a familiar ecosystem for the core pieces of the system will bring with them the stability those pieces are known for, they are tried and true, and will be already familiar by many, many users. So there’s a tradeoff to consider. It also prevents me from having to reinvent package management. Life’s just too short and I’m one person.

On Package Management

It’s dangerous to go alone.

Take this.

Leaving it without package management is just not an option in the currrent security theatre. Modern systems need not just build systems for distributable packages but patching systems built in with pipelines established for those patches to reduce overhead. Patches that are free, open source, and available in other package-based distributions. In some cases, with associated CVEs. This will require lots of infrastructure to do sustainably even if I weren’t just one person.

I think what I ought to do is find some way to faciliate that infrastructure, designed in such a way where it waits for contributors to do the things. So, if someone thinks its too slow, a pull request from a stranger (or a familiar maintainer, even) gets submitted so that I don’t have to do the work. It gets reviewed and merged. The more people involved the better, but, it /could/ work with one person, just very slowly.

Next Post

Previous Post

© 2024 Phanes' Canon

The Personal Blog of Chris Punches