This page should answer some of the common questions.
The plan is currently to wait for
apk-tools 3.x to go stable. Since
the new version is bringing a completely new package format, we will use
this opportunity to avoid having to transition the potential repos, and
publish things after we have transitioned the build system.
The FreeBSD tools are generally more featureful and I don’t see much of a benefit in the others. Additionally, I am a long-time FreeBSD user and familiar with them.
Lastly, there is the
bsdutils project which we rely on, so it was not
actually necessary to do the entire porting from scratch.
A goal of the project is to provide alternatives to common tools. The FreeBSD components are a better fit for the system, since they are lighter weight, smaller and less crufty. Licensing also plays a minor role.
There are some GNU components in
main, but for most part they are avoided
when there is a viable BSD alternative.
I consider these pretty much the worst thing about the BSD systems from technical standpoint. They are slow, painful to maintain alongside binary packages, and contain decades of technical debt.
Since this is a new project created from scratch, the goal is to be legacy-free where it makes sense, and none of the existing systems did exactly what I wanted.
Python is more or less omnipresent and over time has become the standard scripting language on Linux. Also, its implementation is robust, portable and allows us to write the entire build system without utilizing anything outside the standard library. The syntax is also nice and flexible enough so that it can be reused for the templates themselves, which reduces work.
It uses dinit as it provides a neat, complete package with a good feature set.
While s6 is a good project, it’s more of a framework than something that is ready to use - setting it up is needlessly complicated.
It’s an explicit goal of the distro to abandon legacy cruft where it makes sense, and BSD-style init is lacking in various aspects, such as missing process supervision and parallelism.
There is no special reason - the original plan was to use FreeBSD’s
but that ended up not happening as it’s simply not ready for this type
of use on Linux and would need a ton of work, and common Linux package
managers are typically lacking in various ways, and
happened to be the thing that was easiest to integrate and matched the
intended featureset well.
It’s currently the most complete/usable alternative Linux
Chimera does aim to suck less, but not in the way “suckless” usually means. Being lightweight is important, but being “minimal” is a rather vague term and typically leads to pointless dogmatism. Chimera aims to be practical and easy to grok, recognizing the danger of complexity, but not avoiding useful things for the sake of that.
cbuild system started as a rewrite of
xbps-src, but has since
diverged a lot. Additionally, I am also a Void Linux developer, so it has
influenced the distro in some ways. However, it is also an explicit goal
not to repeat Void’s mistakes.
There is none. ChimeraOS renamed from GamerOS about a month after public development was started. This is simply an unfortunate coincidence.
Feel free to ask in the IRC or Matrix channels, and it may get added here.