The “Serpent OS” name was a quickly chosen name that stuck. Unfortunately “serpents” are often associated with
negative connotations, and we’ve had a lot of feedback over the years that the name was off-putting. Let’s be completely
honest, it’s not the most inviting name for a project. Who wants to trust a serpent? Generally speaking they’re considered
dangerous at best.
It’s fair to say we’ve spent a long time in prototype and alpha phases. In order to move forward, our identity needs
to be more befitting of the project we’re building. A move into the real world. This isn’t a hobby project, it’s a full
blown Linux distribution with serious technical underpinnings, achievements and goals. Getting the tone right from day dot
is critical.
Do note, there is no change to the internal core team, so we’re aiming for full continuity and a seamless transition.
Had enough of these snakes on this plane? We have too.
Pronounced like “Erin”, it’s a name that we feel is more befitting of the project. Pulling from multiple etymologies, it’s a name that better describes the project
now versus the project that started as Serpent OS.
“Aer” is rather obvious, Latin in origin. The phonetic “Erin” is a nod to the Irish roots of the project, and of course a home.
There are a number of reasons for the name, which will form part of the initial documentation on the new website.
Our intent is to have a name that is more inviting, and more descriptive of the project’s goals and aspirations. We’re not
anti-establishment or anti-corporation - if anything, we’re a statement that without the fiscal handcuffs, we can produce a
technically sound and user-friendly operating system.
Having already secured AerynOS.com, AerynOS.dev, plus the associated social media accounts, we’re now in the process of
rebranding the project. For sheer irony, we’ll make the final transition day the 17th of March, 2025. Yes, St. Patrick’s Day.
The Matrix space has already been updated, and any areas where a new name isn’t feasible will see almost immediate renames.
A new GitHub organisation has been created, with our first priority there to create a proper organisation structure for once.
Over the coming weeks everything will be migrated over, and we’ll mark the old organisation read-only/deprecated. Can’t have folks
thinking Serpent OS was abandoned, after all.
Stick with us, we’ve got plenty of exciting news to come over the next days and weeks, as we embrace new transparency and
shed our old skin. Plus, we’ll be starting to onboard for web properties, translations, artwork, and more. Cherry on the cake?
Admitting that we’re actually building a full distribution will allow us to put relevant priorities in place to expose
Serpent OS.. I mean AerynOS .. functionality to the wider world. Get ready for a reboot of the grassroots, independent Linux
scene. We’re here to stay.
TL;DR: Serpent OS is facing funding challenges but development continues. Alpha2 is coming soon with an improved installer. We’re seeking community support through donations and volunteers for key roles. Our technical roadmap includes versioned repositories, immutable OS features, and improved package management workflows.
We had a flurry of activity around the Christmas period, including our first alpha release as well as
enabling offline rollbacks early in January. We’re actively working on alpha2, but we also need to
talk about the elephant in the room.
Recently I posted a tweet that has been covered
by a few news outlets. The long and short is quite simple: distinct lack of funds. A very long story
short: a change in my contract led to a loss of income protection, combined with a herniated disc (C6-C7),
culiminated in having to resign. Naturally I’ve been working exclusively on Serpent OS since then, but
I’ve also got to keep the lights on at home.
This doesn’t mean the project is closing or anything like that, but it does mean that I actively need to keep
costs down whilst using daytime hours for financing. This is what’s led to the significant slowdown in the
last few weeks, and I’m just trying to be as transparent as possible and manage expectations.
Sure. The reality is that with a job, and kids, there’s very little time left for Serpent OS. I personally
believe very strongly in Serpent OS, and I want to see it succeed. As a truly independent project, we’re
in a unique position to do things that other projects can’t. We haven’t got to answer to shareholders, or
concern ourselves with market share. We can focus on making the best possible OS for our users.
But it’s not just that. We’re building the tools so that others can build their vision of the best OS.
Or provide applicances. Or <insert your idea here>. We’re building a set of tools and principles to facilitate
innovation and disruption, for projects of any size. We’re not just building an OS, we’re building a platform.
Bring your own distro, if you will.
My sincere hope is that others also believe in this vision, and can help us get there. It’s make or break time,
and you have the power to help us make it.
OK, so how can folks help? The most obvious one is funding, so we’ll get that out of the way first. Right now
it’s possible to support us via Ko-fi or GitHub Sponsors.
For the sake of transparency, as noted on the Sponsor page, we haven’t got an established company
or business bank account. In time, we’re looking towards something more cooperative. For now, the reality is
the daily running and development largely falls on me.
One way that we could certainly cut some costs, and improve scaling, is through additional infrastructure.
We’re currently hosted on a single Hetzner server, and we’re looking to expand that to a more distributed
setup. Rune Morling currently hosts 2 of the builders in his home at his own expense, and the main server
is also the primary builder, which is less than ideal.
We need to split the repository hosting as its grown enormously, and could do with a few more builders to
facilitate “try builds” of pull requests.
Lastly we’re looking at CDN solutions to improve the speed of package downloads (efforts currently ongoing).
We’re growing quickly and that comes with some pain points. We’re looking for immediate help in the following key areas:
Community management: Someone to manage social media, forums, and other community platforms.
Documentation: Once we pivot to Astro + Starship, we’ll need to focus on adding high quality documentation.
Translation: We’re enabling gettext + fluent where appropriate, and will need extensive translation work.
Web development: We need to improve our web presence, management of web properties, transition to Astro, etc.
While of course we’d also love more developers and packagers, most of the time is spent in these areas already, and the other
roles desperately need attention.
A couple of weeks back we broke the news that we were working on a new disk management library, disks-rs.
The scope wasn’t made quite clear at the time, but it’s another building block to facilitate smarter applications.
Eventually we want to support the manipulation of various filesystems and disk structures, for use in CI pipelines, etc.
Another requirement for disk-rs is to not only expose sane partitioning logic, but also to provide a way to declaratively
define disk layouts. This will be used in the installer, but also for reproducing entire installations. It forms the basis
for our future provisioning system.
Right now we’re working on a very cool .kdl based format for defining disk layouts. It takes advantage
of kdl-rs streaming parser to implement a procedural syntax complete with miette error handling for a very nice developer
experience:
Our installer has quite a nice backend, but honestly the frontend experience leaves a lot to be desired. Given that our current
focus is being able to not only onboard developers but build tooling against an installed system, we need to make the core of
this effectively scriptable. To do so will build upon ongoing IPC work for moss and disks-rs, and the introduction of a new GUI
frontend based on Slint. While early days we’re trying to think 10 miles down the road, where we can utilise
the LinuxKMS backend for minimal installer ISOs.
So we have some exploratory works in progress, and it’s time to discuss how they all relate to the future of Serpent OS.
You’ll immediately notice that these are highly circular in nature, meaning we need to switch between different areas
routinely. In order to design an effective architecture, whilst minimising disruption, we need to have a clear vision
of the future that we’re referring to as “10 miles down the road”.
As previously explained, one of the built-in mechanisms to support a rolling release with breaking changes to the format is to introduce
explicitly versioned repositories. Long story short, a local moss client will only “see” the latest version of the repository that it can
actually use. Breaking changes will mean format bumps, and newer repository versions will be unavailable until the client has updated to
a client/Serpent OS version that actually supports it.
This work requires changes to the repository format, infrastructure, and a migration path from the current repository to a new
archive. However, it is also dependent on having a new format version being available for the versioned-indices.
Frequently Serpent OS is described as an immutable OS, but in actuality it is an atomic OS. That means we’ve focused entirely
on providing a reliable update mechanism, rollbacks, etc. We have not yet enforced immutability, aka a read-only root filesystem.
Our plan is heavily inspired by composefs. Currently moss produces new filesystem trees
using a hardlink farm approach, and relies on renameat2() to atomically switch the root filesystem. This is a very fast operation,
but does not provide immutability.
Leveraging the ability of moss to dynamically construct filesystems from packages, it will be abstracted into a driver mechanism. This will
allow the classic hardlink approach for buildroots, but employ a new erofs strategy for immutable installs. The newly generated
erofs image will essentially rely on extended attributes to “point” to the underlying content addressable storage, and utilise
overlayfs to present a read-only view of the filesystem. Further building on this we’ll use so-called “mount tucking” to provide
the mechanism for atomic updates without the need for a reboot.
We’re actually going to make moss support exports to composefs format, making it an ideal match for podman use cases, deduplicating
the image content. Whereas composefs produces content from an existing tree, we’ve already got content addressable storage, independent
transactions and databases to facilitate this. This means we’ll be able to retain our composition features and very quickly produce the
new erofs images. Using composefs directly would significantly slow down the time to produce each transactions, whereas we can instead
build a similar internal functionality and integrate at higher levels.
We also plan to integrate the file digests in a new revision of the moss stone format, which will open the door to supporting
SELinux xattrs, as well as fsverity for the immutable images.
Note that this goal will inform the requirements for the next stone format, which will in turn require versioned repositories.
Of course, this also impacts the build pipeline infrastructure.
Truly the most time consuming task in most distributions is the cost of maintaining packages. This is being approached, as with all
of the planned goals, in an incremental fashion. However, it often pays to have a view 10 miles down the road to determine exactly how
to get there.
In order to provide sanity for developers, and make guarantees about the stability of the system, we need to track the binary ABI for
all packages. Furthering on this, we can of course immediately detect any breakage and schedule rebuilds as appropriate. This will also
add a higher degree of confidence for pull requests as we’ll know if its consistent or introducing problems.
The workflow for packaging right now is for someone to open a pull request, which contains their recipes, the automatic “build records” (manifest)
and our assumption that they built it using a local repo based on top of the latest repository. What is actually needed here is for the infrastructure
to perform automatic (low priority) builds of each pull request in a transient repository, making those builds available for verification
purposes.
Another limitation with the current infrastructure is the reliance on a global build queue. Simply put, once a PR is merged, all of those builds
are scheduled and individually published to the target repository upon completion. This is very naive, and leads to a lot of “nannying” in the
event of a failed merge.
In future, those builds will be scheduled in a transient repository, and upon successful completion the resulting artefacts would be published
to the target repository in a single atomic operation. This will also allow for the introduction of “try builds” for pull requests.
Another issue which partially relates to bootstraps, is the bleed through problem. This is an artefact of using layered repositories, such as a local
repository, to build updates that would change the providers available in the underlying repository upon merge. Take for example, LLVM.
After completion of libLLVM-19.so, the local repository would contain the new version, but the main repository would still contain the old version.
Locally this would allow the circular build dependencies to work as rust builddep for rust could still resolve libLLVM-18.so. However, upon,
merging to the repository, we have a new problem. The main repository would now contain libLLVM-19.so, but the rust package would still be
built against libLLVM-18.so. This then breaks the dependency chain for rust, requiring manual intervention.
To solve this, we’ll ensure that filtered repository views are introduced both for local builds and our build infrastructure. This will mean
that the index of the local repository will occlude the main repository, and eliminate bleed-through.
Whilst ABI tracking is very important, it doesn’t actually solve the bootstrap problem of circular dependencies. This is a consequence
of using an incremental development model for a binary-first distribution. In reality the only real way to solve this is by eventually
altering the tooling to support a “world view”, with intermediate recipes that are not published to the final repository. In effect, combined
with ABI tracking for dependency chain invalidation, we can determine which recipes need to run again as part of an invaldation-solver loop
that relies on “cached artifacts”, i.e. the final packages.
This isn’t an immediate issue to solve, but it will inform our next steps to ensure we get to that point without requiring extensive
overhauls or “stop the world” rewrites. Our eventual vision is that building any new package will feel much like it does now, but changing a
reverse dependency will evaluate the dependent chain for rebuilds. To make this streamlined, the infrastructure will by this time have
grown to a point where we can share the compute power by way of so-called “try builds”, and a shared cache of artifacts.
A large portion of the burden is in reality chasing updates. Currently we have a very simplistic utility that cross-references
release-monitoring.org to spit out a list of recipes that have available updates. Truthfully
we could easily generate diffs for these updates, and even automate the process of updating the recipes. This is dependent
however on having confidence in the pull request, which in turn is dependent on ABI tracking being in place.
We have a complex series of interdependent goals, which require research and frequently shifting between focus areas. Not all of them will be immediately realised,
and some are simply informing the direction for our future. Additionally, we need to keep moving without any “rewrite the world” pauses.
It’s important to highlight that none of this is a reinvention of the project, but a series of steps to “1.0” and beyond to ensure that
the project is sustainable and reliable. This means that delivery continues, and the delivery itself becomes simpler and more trustworthy.
Despite the interdependencies, once we’ve finished scoping the end requirements we can work towards the immediate concerns:
Pull request workflow
Repository consistency (initially ABI story)
Update automation
Immutability
Note: These timelines are estimates and may adjust based on available resources and community support.
We’re at the point where we need a functional OS for contributors to be able to work on the project. It also presents a paradox because
we wish to keep the project lean whilst we work on extending the scale-out capabilities. In reality this means that we’re going to permit
a limited amount of repository growth:
Onboarding requirements (such as Matrix clients, documentation, etc)
This in turn also requires a more reliable installation experience, which is why we’ve been spending cycles on the installer project.
Internally we want the installer to support a variety of scriptable configurations in order to provide better test coverage for our updates
and boot management, whilst we also intend to incrementally improve the user experience.
Alpha2 is coming, and will feature a preliminary version of the updated installer. The plan initially is for a simple “use whole disk” strategy
and will be followed up with supported for encrypted installations (post alpha2). Quite simply, some employers require their developers have encrypted installs,
and not supporting this configuration will restrict our ability to onboard developers.
We’re doing the Alpha2 as a baseline, from which all update testing, infrastructure adjustments, etc, will be measured against. This is the
point at which the project will formally “open the doors” for more developers and testers, with the explicit view that growth is
sustainable and manageable. Per the requirements set above, we’re not going to “explode”, but enable specific workflows that in turn will permit
us to scale out the project and inform direction.
It’s important to me that we’re explicit in how we take our next steps. As stated earlier, pausing the world is not an option.
Continued delivery whilst enabling an incremental path to the future is the only way to ensure that we can deliver on our promises.
Contrary to a reboot, this is a solidification of our vision and a commitment to the future. Sure, new features will also appear in time,
such as easier packaging recipe formats, but no decision is being made that will require a rewrite of the project. However, these goals
require stating and explaining up front so that the high level vision is clear and provides the context for any short-term deliverables.
The last thing we need is to be in a position where we’re “stuck” and unable to deliver, due to a lack of foresight.
On behalf of the project, I’d like to thank everyone who has supported us so far. Whether that’s through donations, code contributions,
or even having the time of day to try out the ISO, it’s deeply appreciated. Being the underdog comes with its own set of challenges,
and of course the “indie cost”, but it’s also an opportunity to challenge the status quo and find new, more optimal ways, to do things.
We’re not just building “Serpent OS”, we’re building a set of tools to solve the problem of distributing an OS. Way down the line this
will be powerful enough to support a number of use cases, from appliances to desktops, and even servers. In short, we want to bring high
quality tooling to the masses, and we’re doing it in a way that’s sustainable and reliable.
If a picture tells a thousand words… well then this video .. Yknow what, sod it.
Here’s a video of the offline rollback support in action, as tested in a newly installed
VM using xfs for the root filesystem. We jokingly refer to this as the “LTT” test due
to LinusTechTips’ “interesting encounters” with package management systems in the past.
This has already landed in our volatile repository, so simply sudo moss sync -u and grab
the latest updates. Any subsequent transactions will automatically generate the boot entries
for you, no intervention required. Or mounting. Or anything. Just update and go. Srsly.
We actually saw this as a golden standard for the feature, as it’s a real-world scenario
where you’d want to roll back to a known good state. The video shows the system booting
and recovering in multiple ways, from complete system nuke (via glibc) and simpler scenarios
like removal of the GNOME desktop environment.
The intent is to ensure a user can quickly revert to the last transaction that worked in the
instance an update goes awry, without needing to boot into a rescue environment or live CD.
Developing a project with the scope of Serpent OS is no small feat. In order to maintain our
current cadence, and to land huge features like the offline rollback, or impending system
model work, we need your support. I’m as happy as the next person to return to the job market
once my medical conditions ease up, but the simple matter is this will greatly slow down our
recent progress.
Our aim is to entirely redefine the distribution of Linux, and the years of prior effort
are finally coming together rapidly to make this a reality. If you like what we’re doing,
consider supporting us!
Visit our sponsor page for more information on how you can help us grow and deliver
the future of Linux distributions.
This is all achieved using moss’s internal content addressable storage for deduplication,
where each old transaction is swapped with the live /usr at the time into the archive.
The behaviour is implemented in the initramfs (dracut) by invoking moss state activate $transaction_id -D /sysroot,
ensuring that the activation is performed before the new root is mounted and the system is booted.
We actually shrunk our moss and uutils-coreutils builds to half their usual size so that we can
fit them comfortably into the initramfs.
For now, we’ll automatically generate entries on the ESP (or XBOOTLDR) for the last 5 transactions, and you
can select them during early boot to perform the rollback. It’s not slow, as it’s just doing yet another
renameat2() to atomically exchange the live /usr with the archived transaction.
TLDR: Boot time rollback, no network required, no live CD required, no rescue environment required. Just a working system.
The system model is coming next, which will expose the non-imperative core of the architecture to users.
The usual commands will continue to emulate an imperative OS, by mutating the system model and applying
the internal sync operation. This ensures dependencies are resolved only according to the layered repository
configuration, without special exceptions for “installed” (which.. we spent a lot of effort faking this behaviour).
It’s good to remember that moss is effectively a huge cache, and that each state has no relation to the other. We
simulate upgrades by building a new state with the same selections as the old one, then begin to upgrade those candidates.
The new model (somewhat Gentoo inspired ❤️) will allow moss to build the dependency graph for the finished system state.
As a sneak preview of what we’re enabling, imagine the newly landed transactional reboot code linked with multiple
system models… such that you might decide to moss sync from your existing model to an entirely different one, rebooting
from your GNOME desktop to a KDE desktop, for example. Cleanly, atomically, and without any manual intervention.
Here we are, at the end of 2024, and what a year it’s been! We’ve made significant progress on Serpent OS, and we’re excited to share some of the highlights with you.
Virtually 5 years in the making, we recently attained alpha status. Our tooling and concepts have aligned, allowing us to now rapidly iterate
on the core deliverable itself: Serpent OS. We’ve seen an explosion in cadence, with our tooling enabling us to quickly and
easily deliver updates, new packages and enabling new features.
Since the Alpha 1 ISO (0.24.5), we’ve fixed a number of issues in relation to hardware and booting. We’ve also added
new features to moss (refined boot management) and boulder (our build system). Even now we have multiple PRs open to
tidy up moss, add automatic generation of monitoring.yaml files, and more.
We’ve been working hard to keep the cadence up, and we’re now at a point where we can deliver new ISOs on a regular basis.
Our main focus now is the tooling, in enabling a far more automatic delivery pipeline. The vision is having automated pull
requests generated for package updates, automatically handling changes in dependencies and ABI, and ordered by build tier.
This will significantly reduce the maintainer burden, in conjunction with planned security monitoring.
In the short term we’re going to land the following features:
Offline Rollbacks - We’re going to land offline rollbacks in the boot menu, allowing you to easily revert to a previous
system state.
Versioned Repositories - We’re going to introduce versioned repositories, allowing us to gracefully handle format changes
in moss and boulder, permitting an “update forever” epoch-staggering approach. Additionally, this will allow users to stay on an
older repo version if they’re awaiting a fix to a regression in a newer version.
Improved Documentation - We’re going to improve our documentation, making it easier for new users to get started with Serpent OS.
Tools as a service - We’re adding IPC layers to our tooling, allowing them to be launched as helper services for integration in
other applications. This will allow us to integrate moss with GNOME Software and COSMIC Store, for example. Additionally it will ensure
the latest version of the moss binary is always used by the system, gracefully handling version repo changes.
Chiefly, this will allow moss to cheaply integrate anywhere we need it, including for lichen.
Lichen Improvements - Lichen will also be converted to an IPC based backend, allowing it to be executed via pkexec for integration into
a GUI (or even CLI) frontend. This is a necessary step to allow the frontend to operate without privileges, facilitating live
updates to the NetworkManager configuration, or indeed keyboard layouts. Long term we’re planning a cage based kiosk with a full screen
installer mode, on a far smaller ISO.
Our long term vision is to deliver a system that is easy to use, reliable, and secure. We’re building Serpent OS to be a system that
updates forever, confidently. We’re also shaking things up by being first-adopter of new technologies as default solutions, with a view
to enhancing the robustness, origin-diversity and security of the system through Rust based replacements and alternatives to key components.
You can already see this with our adoption of sudo-rs, coreutils (uutils), ntpd-rs, and not to forget rustls by default for our curl build.
Outside of that, moss, boulder and the supporting crates are also written in Rust, giving us a strong foundation for the future.
Serpent OS is a project that is built to last, and challenge the status quo. Deliver a Linux distribution for use on multiple verticals,
with the feeling of a conventional Linux distribution, but with key management facilities and architecture designed to make a rolling release
distribution that can be trusted for long term use, extensive updates, and the ability to entirely re-engineer the entire OS, delivering in a safe
atomic update without breaking client installations.
In order to give Serpent OS the development time it needs, we’re looking for sponsors to help fund development. If you’re interested in becoming a sponsor
or investor, please do not hesitate to get in touch. We want to secure funding for development and infrastructure for the next 2 years.
While of course we need to iterate on our own tooling, we also need to be able to work more upstream and with kindred projects to drive
the ecosystem forward. In time, we wish to become the incubator for new technologies and solutions, and we need your help to do that.
With your support, we can expand our builder network and enable more hosting, bandwidth, and compute resources. This will in turn enable
our automated rebootstraps, which will of course allow downstreams to extend upon Serpent OS as a kit-distro. Indeed, it’ll allow us to expand
beyond x86_64 when the time is right.
While Serpent OS currently delivers a desktop ISO, this is not the limit of our potential. As indicated, our priorities in the short term
are designed to massively aimplify project maintainer bandwidth and free up more time for feature iteration and development. Once we’re quite
happy with the base (and we’re not far from that point) - we’ll quite happily extend to other desktops, and even server/cloud offerings.
Nothing is bullet proof, but with the architecture and tooling of Serpent OS we can get pretty close. Gotta admit, having a transactional, atomic OS
with rollbacks, and the full granularity of a conventional package manager, is pretty cool. 😎 Especially when things “Just work” out of the box
thanks to the stateless (“hermetic usr”) requirements of the system.
Know what’s even cooler? When we land our system-model implementation, you’ll be able to completely duplicate the setup between local development
and production. When we also land our export/compose functionality in moss, you’ll be able to reap these benefits in containers too. 🐍
Here’s to a great 2025, and we hope you’ll join us on this journey. 🚀
In response to feedback from the community, we’re issuing a refresh of the Alpha 1 release, 0.24.6. This refresh includes a number of key updates and improvements, including:
Now works with etcher
Fractional scaling enabled by default
Prebuild icon theme caches to speed up trigger execution (except for hicolor)
Add new moss boot status command for introspection into blsforme functionality
Fix amdgpu initialisation for older devices, previously leading to black screen on boot
Frequently in Team Serpent we joke that moss is the “systemd of package managers”. It actually does a whole lot more than is easily visible.. for example:
Content addressable storage for the entire OS
Atomic updates of /usr by renameat2() w/ RENAME_EXCHANGE
Executes transactional triggers in a namespace (container) with RW /usr and RO binds of /etc and /var …
Executes system triggers postblit, with dependency ordering..
Via blsforme, manages the ESP, XBOOTLDR, boot entries, sync and promotion of bootloader, kernel and assets, initrds..
Entirely zero configuration. No /etc/default/grub, no remembering your root={}, it’s determined automatically.
Basically does all the work of OS provisioning, barring disk mounting and partitioning. Our installer, lichen, is basically a thin wrapper of moss.
We’ve had no debugging capabilities around the boot management, so we’ve landed moss boot status command. It’s super primitive
but does offer an insight into the introspection capabilities of blsforme. In this simple screenshot, moss/blsforme are supporting the
Boot Loader Protocol, querying the systemd-boot entries in efivars. When found, LoaderDevicePartUUID is used to determine the
boot ESP, but moss/blsforme will quite happily read the GPT directly (relative to / mount) and find the ESP and XBOOTLDR…
Remember - we happily use systemd-boot. We do not use bootctl or kernel-install. Entries are automatically managed and
we’re extending this to support offline rollbacks via boot menu (feel free to extend with /etc/kernel/cmdline.d/*.cmdline drop-in snippets!)
Also note we do not allow systemd to automount the ESP or XBOOTLDR via the GPT autogenerator, instead moss/blsforme will automatically
discover and if necessary, mount these partitions, when dealing with bootloader or kernel updates.
With this explicit control over the boot management, we’ll happily be landing secure boot and fwupd support in the near future,
without the downsides of trying to provide EFI assets to /boot in a package itself. 😬
It must be clearly stated that Serpent OS does not support anything other than UEFI booting on x86_64-v2+ capable hardware.
Please note that GNOME Boxes will default to BIOS, not UEFI, and will need hand-mangling of the XML file. Also note in other
solutions such as VirtualBox you will need to specifically select EFI in the VM settings.
In order to maximise compatibility with other tooling and firmware, we’ve modified the generation of our ISO to include
the isolinux MBR/GPT hybrid components, however we deliberately did not include a functioning bootloader for BIOS boot.
Instead, you will see a boot failure indicating that ldlinux.c32 could not be found, which is a sure-fire way to know your
VM or hardware is incorrectly configured.
We’ve made the decision to pause our offering of COSMIC Desktop ISOs. We’re huge fans of the project, and we
strive to keep it up to date and functional. However, it is very early in alpha, and so are we. It doesn’t make
a lot of sense for us to extend our workload to two alpha codebases!
We still offer COSMIC as an option in the installer for those who wish to try it out, and do encourage testing
and engaging upstream with the developers. For now, we will offer just the GNOME ISO.
In the new year we’ll be focusing heavily on our tooling to facilitate a scale up of our packaging efforts.
We’re quite proud of our tooling, but we’re not oblivious to the warts and issues. The next couple of weeks
will be spent improving our documentation (or making it exist!) and making sure that we have the ideal workflow
in place to permit large stack updates along with the ABI consistency verification we need. This will also
pool work for ent, moss, boulder, by streamlining packaging, and making it trivial to update an entire
stack of packages in one go. Eventually this will be an automatic thing, with successful PRs being verified
and then merged into the volatile repository.
Don’t forget, versioned repositories are also coming your way, and very soon we’re landing offline rollbacks in
the boot menu! blsforme has been significantly restructured for cmdline handling, and understands entries in
the context of a distinct system root (ie moss filesystem transaction) - which is the bulk of the work needed
to facilitate offline rollbacks. The last piece will be running moss at an early stage in the initrd to
swap the /usr pointer to the older transaction, which is instanteous and atomic.
5 years and no release, and now two alpha ISOs before the end of the year. We’re pretty happy with that, and we’re
going to keep surprising you next year with more releases, more features, and more stability. Happy new year from
all of us at Team Serpent! 🐍
If you like what we’re doing, please consider sponsoring us - this will allow us to grow our infrastructure
and deliver builds quicker. Due to health issues in the last few months, I was forced into a position whereby I had to
resign from my job. Any and all contributions to the project are greatly appreciated, and will help us to continue delivering
what folks are frequently now calling “the cleanest Linux implementation they’ve ever seen”.
