Author: phanes

This is the new product pipeline map based on recent updates:

After a great deal of thought, I’ve decided to fork Pyrois. The new project is called Cyrios.

Cyrios will be kept under the SILO GROUP umbrella and not the Dark Horse Linux Project space. Its source code is available at:

https://source.silogroup.org/SILO-GROUP/Cyrios

I will at a later date set up a downstream mirror on github.

Pyrois will continue to be part of the Dark Horse Linux Project and will remain where it is, but will be specialized to produce Dark Horse Linux images.

For those of you who are visual thinkers, this is the current state of the project structure:

And this is the future state of the project structure:

The reason why I’ve decided to fork my own project is a bit nuanced, but in essence, the goal of Pyrois is both important to me and limiting of its utility to the Dark Horse Linux Project at the same time. This solves both angles.

Here are the highlights:

• Pyrois was successful in providing a way to build a non-specialized ISO image for someone to be able to extend to create a new Linux distribution image to just about any configuration imaginable. It’s supposed to be a “generic distribution factory” that doesn’t make too many assumptions about what you want to build beyond a standard source-based system that is cross-compiled from raw sources. While there are many projects that will produce a linux image, I’m not aware of any that do not provide a highly specialized system beholden to upstream project interests with large sponsors behind them.
• Pyrois is currently used by Dark Horse Linux to create its images. Now that Dark Horse has reached a certain level of maturity in planning, I need to extend Pyrois to be specialized to generate the Dark Horse Linux image, and specifically an installer ISO.
• I didn’t want to destroy Pyrois’ current facilitation of distribution genesis by just specializing it to DHLP, so I’m forking it to a new project called Cyrios to serve that function.
• Cyrios won’t be able to get as many resources as Pyrois, so, I’m expecting it to largely stay out of date but to provide a base on which others can build by refreshing it using the LFS documentation.
• This will pave the way for a more developed DHLP image and eventually an installer image.

I was able to reduce the generated livecd ISO image from its eyesore of 8GB down to just under 2GB, putting the ISO size for the Dark Horse Linux livecd on par with other distributions.

You can grab the latest image here.

The issue was ultimately an overzealousness to make the image “provable” from a security perspective. The debuginfo in the compiled binaries of the system, particularly the kernel modules and shared libraries, accounted for about 6GB of the storage. Stripping that debuginfo consisted of almost all of the size reduction. 75% size reduction is really quite worth it.

This version also has some repaired filepaths, as well as additional safety in the scripts that generate the image.

You’ll probably see in the git logs that there are a bunch of fairly recent additions of set -u in the bash executables that Rex is kicking off. This tells bash to treat any reference to an unset variable as an error and exit immediately. That way if you do the admittedly dumb rm -Rf ${unset_path}/${also_unset_path}, bash will refuse to execute that line and fail the project run of rex due to a non-zero exit code. Obviously this is a stop-gap measure until I can do a full cycle focused on code safety rewrites.

Next is (besides some more clean up on the pyrois codebase) the introduction of RPM and presumably DNF, followed by some formation of what an installer ISO will look like.

It would potentially be a turning point for this project as it could be the point at which the distro moves from source based to precompiled binary package based, depending on how much infrastructure gets introduced during the RPM and DNF build/research work.

Make sure and subscribe to the new mailing list for updates as well.

As part of the productization effort of Dark Horse Linux, one of the things that needed to be done is getting Dark Horse Linux resources off the SILO GROUP domain.

One of those included email. Another included mailing lists.

So, I’m bringing mailing lists back. If you’re looking for how to contribute, the dhlp-contributors mailing list is a great place to ask questions and find out about the project:

https://lists.darkhorselinux.org/mailman/listinfo/dhlp-contributors

If you want to contact someone personally, I can be reached at:

chris (dot) punches (at) darkhorselinux (dot) org

As always, I’m eager to bring more people onto the project, so if you know of any potential volunteers, please feel free to point them at that mailing list or to me directly.

I think I may be running out of excuses to focus on the installer and bringing in RPM.

As a result of community feedback, I have created a new website for dark horse linux, and it is in production now.

I am lukewarm with the results, but it does meet the intended purpose for now.

The documentation system is an acknowledged gap, one that presents an eyesore, and I’m not sure how I’ll approach it yet.

I’m not 100% convinced I should be writing the documentation so much as overseeing community contributions to that and ensuring the content is accurate.

Within the next hour or so, I’ll be uploading a new livecd to the downloads section of the site. It is a rather clean and faithful production of an LFS system, with overlayfs added as a dracut module so that the livecd can actually be used as a system with a writable root filesystem.

Changes won’t be persistent, but, this is a much better proof of work than what was up before it.

At this point I do encourage people to try it by downloading it and firing it up in an emulator and provide feedback. I’d be thrilled to hear someone got it running on a physical machine.

While cool in and of itself, this paves the way for transitioning the image to an installer ISO, where Pyrois copies the sysroot to a subdirectory in itself to put on to a target machine to boot from local disk after some basic configuration prompts.

ISO Image file size is still an issue at 8GB. I’ll have to depart from LFS to fix that. So, this might be the “goodbye LFS” post I’ve been building up to. Not sure yet.

I am excited to announce a milestone in the Dark Horse Linux project.

The code in the repo has finished creating the initial target system, including the kernel compilation using the default Fedora Linux kernel config.

There is an exception, the fstab file, which has a chicken-egg problem to resolve but I consider this to be minor and can be resolved during the ISO file generation, which is the next piece.

I should be able to use grub-mkrescue or genisoimage/xorriso or some combination of these with a thought out init ram disk to complete that part.

Once complete, I’ll start polishing the codebase for Pyrois up, branding a fork of it for ALFS-NG, and tag and release that for now.

For the long term, the `ALFS-NG` spinoff is just a side project that got spawned by this effort. I haven’t decided if this is something I want to give to the LFS folks to revive/modernize their seemingly abandoned ALFS project, or if it should remain wholly separate due to the Darcy infection. I have a desire to “play well with others”, but, that can’t occur in a vacuum, and I need to be certain it stays shielded from Canonical based on previous behaviours.

On the other hand, it’s likely to go very stale if I keep it under my thumb as it’s not a priority for me to keep it up to date more than to facilitate it as an instructional device. I suppose that begs the consideration that they’ve already abandoned that project once, so, it may not be a priority for them either. They likely wouldn’t want it.

I will then want to decide whether I want to introduce librpm for the next phase, or whether I want to create an installer disk, presumably with something like `anaconda`, though, I am hesitant about introducing an upstream dependency on the RH ecosystem based on the goals of the DHLP project.

I will want this system to be very familiar to RH-based distro users for many reasons, but, all cooperation with external projects must be a voluntary effort that can be easily severed for this mission to work. This is, after all, a contagion firewall. I’m already going the librpm route, which is maintained by RH, but, many distros use librpm. Not many use anaconda, so, their maneuvreability is different with that piece. Not that I think anything would happen there, but, it’s a risk surface that needs gaurded.

I suppose I’ve answered my own question thinking it out — anaconda is a package-based distro installer, so, if I’m going the librpm route I need to do that first before anaconda.

I suppose one approach might be to build my own basic installer that is a modification of the sysroot I’ve created that just copies the unmodified sysroot to a target system after the user selects and mounts all their target mounts. That’s a thought. Copy it off, when it’s done in the build, then engage in a 6th stage that turns one of the copies into an installer that puts the intact copy onto the target system.

I may do that first to move forward on a known working path, and then do my reductionist cross-reference with other similar projects to synthesize a new process. It’s a bit of a longer path but it’s one that can provide consistent progress.

Of course, things are always subject to pivot based on what I learn as I go through this. I have no experience with this aspect of things, so, I’m certainly open to ideas.

Automation of the 11.3-systemd rc1 has been successful on a Fedora build system up to Chapter 9.

At this point what’s left is:

• populate some of the system config files (/etc/*)
• set up udev
• set up the timezone
• some minor systemd disablement
• set the system locale
• compile the kernel
• set up kernel module load orders
• configure grub to be on an iso and install the bootloader to that iso (this will require deviation from the LFS book)

The fun part is that I’m not going to be using stock values for these. It’ll give you curses dialogs asking for input on alot of the stuff you’d normally configure on your OS, though, I may be reserving alot of that implementation for an “installer ISO” so that the values aren’t baked into the ISO in future versions.

After that, it’s an RPM variant.

After that it’s a reductionist rewrite cross-referenced with other unrelated projects to create a more minimal system without sacrificing on the core components.

All in all, looking back through the work, this process would have only taken a couple days, maybe a few hours for someone who’s done it before, but, automating it — I think that’s where this project’s value is.

I would like to see someone fork it, containerize the process, and then use pull requests with automated unit tests to accelerate OS development.

In the meantime once this ALFS-NG baby project is wrapped up, I’ll rebrand it as that, and then use the Dark Horse Linux label to build out the real deal.

After some review of the dual licensing of LFS, it’s occured to me I need more segmentation in my planning for how to get to a new distro that I can offer commercial support for and distribute for commercial use.

That’s not the core reason for doing this, but, I’d like to be compensated eventually for all the hard work, and perhaps hire people and build a company around it.

I think in order to get there, I’ll need to make some pivots on approach on this.

To get around the non-commercial shit in LFS’ licensing, I’ll probably, once I get to a releasable state, release this build as a project called “ALFS- NG” that inherits the crap they snuck in there and have DHLP be a non-derivative rewrite.

I’m still thinking about it, but, if that’s the direction, once ALFS-NG is good to a certain point, I’ll be able to apply what I’ve learned to Dark Horse Linux. I feel as I’m going through this process that LFS has many, many unnecessary steps to do something like this.

I may even do a second build with one of the RPM variants of LFS/BLFS to get an idea of what I’m in for in terms of introducing binary package management cleanly.