AUSTIN (December 24, 2024) — The Adélie Linux distribution recently celebrated its sixth beta release and is making steady progress toward a 1.0 general release. In the 12 months since the 2023 status update, we’ve released several BETA5 updates and landed BETA6.

Press coverage has been notable. We’ve been featured by The Register and DistroWatch, and we’re happy to see retrocomputing enthusiasts and smaller outlets diving in as well.

This status update is ambitious. I cannot overstate how significant BETA6 was to unblocking some of our more interesting goals, namely to do with C++20 and overall modernization.

We had originally targeted August for our GCC update, but decided to hold off and roll a subsequent LLVM update, Rust update, ICU update, and Mozilla update into one release.

With those tasks out of the way, we are excited to share with you some of our latest progress and future plans, which include new ports, improved security, more packages, focus on GPU support, better accessibility, and new partnerships. But first, BETA6 news.

New Release: 1.0-BETA6

Highlights include some BETA8 goals as we’ve adjusted priorities: Linux 6.6, GCC 13 with sanitizer support, Rust 1.80, Firefox 128, and LLVM 18 ahead of schedule. Java bootstrap has been rolled into a broader bootstrap effort, which we’ll cover a bit later in this article.

We’ve added experimental Wayland support, paving the–Way–for a more competitive Linux desktop experience. Desktop remains one of our core competencies and priorities.

Please see the BETA6 release announcement for more information.

This release also includes a bleeding-edge development version of Spack, in preparation for Spack 1.0 as it becomes a Linux Foundation project, which brings improved support for modeling more aspects of its supported computing environments, such as libc itself.

Major Project News

Our infrastructure is entirely self-hosted, and since May it’s entirely sustained by donations!

This is a major breakthrough because we are no longer dependent on personal financing by individual contributors. We are grateful for all of our supporters. Thank you, sincerely.

To better meet our community’s needs, we’ve opened up a Discord server (“Adéliecord”), which supplements–but does not replace–our IRC development and support network. We are still evaluating whether a Discord-IRC bridge should be set up. For now, it’s separate.

What’s Next?

Quality of life improvements are trickling out regularly, and we are grateful for everyone who is reporting issues to us. For example, installer improvements, better performance, and security-related items. We know many are following our progress with anticipation.

We just pushed Xfce 4.20 to the public (thanks, Sheila!).

We are continuing to find and report significant bugs to upstream software projects.

Active development includes JDK through 1.21 on musl 1.2.5. With GCC 13 out of the way, we can focus on polishing these updates and then release them to the public.

Here is what we hope to accomplish in the next 1-1.5 years, in no particular order. Several of these topics are deserving of their own blog posts or even full-length articles.

For BETA7:

• Java source bootstrap
• Rust source bootstrap
• Full survey and tools/integration for popular hypervisors
• Improved X11 automated testing (“checkx11”)
• Introduction of Qt 6
• Qt 5 and Qt 6 coexistence (transition period)
• KDE 5 and KDE 6 updates
• musl 1.2.5 (or newer; a release is expected soon)
• Improved Repology scores
• Formal APKBUILD modeling infrastructure (more on this later)
• Possible new port(s)

For BETA8:

• OpenSSL 3
• Boot time improvements
• Packaging of nginx + top industry server software with robust default configurations
• Possible new port(s)

We believe BETA8 may coincide with an RC3 release, which would not be too far off from the fabled 1.0 general release. Criteria for 1.0 proper include an external source bootstrap, at which point our toolchain vendor identifier will switch from -foxkit- to -adelie-, as in aarch64-adelie-linux-musl, and full Spack support.

Concurrently, with no specific target milestone:

• Support for multiple init systems, including systemd
• OpenRC user services support

The points listed above are only a subset of the work that we have planned. As with any community project, contributor interest and availability can fluctuate so we cannot make any promises except to reaffirm our commitment to doing things The Right Way ™.

Infrastructure

Necessary for more advanced network configurations that our Cisco router could not handle, we were able to replace the Cisco router with an “open” alternative, and purchase a second unit for use in our colocation project with OSUOSL¹, also using donated funds.

The old router has not been phased out yet but this should happen in the next few weeks. We do not anticipate any service disruptions however stability remains to be evaluated.

While our current website design introduced many necessary changes and improvements to aid in administrative goals, due to limited time we had to rely on an excessive amount of JavaScript. This does not live up to the spirit and standards of our project.

We hope to (silently) replace the current website with a script-free implementation soon.

A Texas non-profit has donated approximately 20 Dell XPS 10 tablet computers. These are being used to test our 32-bit ARM port. While they are not powerful by any measure, we view this as a feature, as Adélie is lightweight and intended to be usable on such devices.

New Ports

While SPARC and RISC-V are on our official roadmap, they will not be “Tier 1” targets before the 1.0 general release, meaning they will not be required to meet our strict standards for completeness. It is currently too early to predict what these ports will look like.

This will depend on available time and resources, particularly if unexpected issues arise.

The sparc64 port will be the more challenging of the two, since it requires porting musl libc to a new architecture first. The SPARC architecture is particularly sensitive to alignment issues, so we are quite excited to throw software at it and hope to find legitimate bugs.

The riscv64 port is in progress but is currently in need of a fix for a segmentation fault.

Porting a distribution to a new architecture is not a straightforward endeavor. Some distributions handle this better than others. Debian describes one approach to porting.

In general, this involves cross-compiling software from one architecture to another and building it piece by piece until the system can stand on its own. Some software will only run on one or two architectures. Components are often created “by hand” (not automatically).

Our last status updated alluded to a new development tool to bootstrap our distribution for any target supported by musl. The theory behind this tool is to allow any unprivileged user to build subsequent rootfs environments, starting with a cross-compilation toolchain, and ending with a native environment that is capable of building Adélie from scratch.

Given some of the early success we’ve had with this tool, if we can maintain momentum, we may also offer experimental m68k, ppc64le, riscv32, and mips64 ports for further testing.

Bootstrapping

The term “bootstrap” is a bit misguided but conveys the spirit of the task appropriately: to become self-sufficient with minimal starting inputs. We use the term at several levels.

In the most practical sense, we wish to have a script that can convert our project’s source code into binary form, without depending on existing Adélie-specific binaries. That is, one should not need to be running Adélie in order to build Adélie, even if you trust Adélie.

Such a script has existed and “worked” (to varying degrees) exactly once in 2017 using Gentoo on a G5 with cross toolchains, and has always required manual intervention.

Java and Rust present substantial challenges to our porting efforts, currently requiring further manual involvement. Ada and eventual GHC support are even more difficult.

(This introduces a chicken-and-egg issue when it comes to porting to new architectures).

We are currently removing our dependence on Java and Rust binaries so that we can bootstrap these packages purely from source (given a C++ compiler).

(But wait, isn’t it sexy to “self host” your compiler toolchain, such that you depend on a previous version of itself, so you can show off that your language works well?)

Of course, our assumption is that we are starting with a feature-rich C++ compiler.

The “Holy Grail” of bootstrapping is a “full source” bootstrap, where all binaries are derived from a simple, auditable codebase. There are some practical limitations, such as when software like GNAT does not have its full source code available and requires previous versions to build. Putting that (and GHC) aside for a moment…

Adélie has been making significant progress towards a “generic Linux to Adélie Linux” bootstrap tool that is able to first cross, then natively, build a minimal environment in which an “Adélie-like to Adélie-proper” bootstrap can be performed.

The crucial detail here is that the target architecture need only be one that musl supports, and either QEMU or native hardware (if available) can be used to complete the port.

We are calling the “Adélie-like” environment “preimage”, and then when a minimal Adélie is built inside it, this will be a “newstrap image” that is fed into our autobuilder infrastructure to build the full world from source. We also seek to work backwards from near-nothing.

In the interest of auditability and provenance, especially as we pursue HPC environments that could run potentially sensitive workloads, one selling point for our distro will be that all executable code will be fully and practically traceable back to, perhaps, an index card.

At this moment, we are fairly close to proving out the following three bootstrap processes:

1. “Bring your own CC, AS, AR, LD, MAKE, and SHELL, and you’ll get a usable Linux development environment”
2. “Bring your own usable Linux development environment, and you’ll get an Adélie-like cross/native preimage environment”
3. “Bring your own Adélie-like cross/native preimage environment, and you’ll get the full native Adélie world”

The steps before (“seed rootfs”), otherwise analogous to Stage 0, remain to be started, and all three of the above steps need some work to iron out target-specific kinks.

One added benefit of our approach is that steps 1 and 2 (and technically 3) can be performed by an unprivileged user, never needing to drop into a chroot(8) environment.

This is accomplished at the expense of performance but remains an optional requirement.

Due to a QEMU limitation, cross-endian ports are not fully supported, so we are porting PRoot to big-endian ppc64 so that we can correctly bootstrap sparc64 and mips64 in the absence of real hardware. (Though we have real hardware as well).

Java

In the beginning, our Java build procedure was not reproducible or particularly elegant. We relied on a number of arcane tricks to get OpenJDK to work that are no longer available to us, especially as we have moved away from the GCC version 6 that we once used.

In our quest to support as many architectures as possible, and to truly support these architectures instead of paying mere lip-service, we have been forced to rethink how we are to package a number of tools that the average user will want or need in their life. Of these, Java is one of the more complex, due to reasons that are largely historic in nature.

You may be aware that Adoptium and the Eclipse Foundation, under their AdoptOpenJDK initiative, provide Linux binaries for Java. You may also be aware of Oracle’s binaries, and IBM’s Semeru distribution. Why should we not simply trust these?

We can’t trust these vendors because Horst wants to play Minecraft on a Quadra 950 and wants you to join him from your Wii U. The firms that produce Java binaries “for Linux” in fact produce it for Linux on one or two architectures, the ones they consider most relevant to their business–mostly for glibc. At Adélie, we want to give you Java on all architectures.

Oracle occasionally publishes experimental musl-linked binaries, but randomly deletes them without warning and does not replace/update them. So we can’t trust them, either.

Using existing work by Andrius Stikonas, we’ve been able to piece together a Java bootstrap–from a very early set of tools, barely recognizable as Java by today’s standards, through newer and more capable tools, until we reach OpenJDK 7 and 8–where we have the foundations of the modern Java toolchain, and the ability to simply incrementally compile newer and newer JDKs.

While translating this work to Adélie, we’ve uncovered a number of bugs–some old enough to drink–that have needed fixing. Some were case-sensitive #defines which simply eluded the attention of developers at the time, such as documented by Gentoo Bug 168736, others were issues with architectures that didn’t exist at the time of these tools being developed, and still more were related to recent changes in the musl C library that underpins our work.

The work that remains is inglorious and unexciting. It is the translation of our bootstrap to mechanisms that can be automated, so that builds can be made for every architecture.

Along the way, we’ll find more bugs, and we’ll fix them. And we will bring you a Java that is more than just another JDK–we will bring you a Java that is refined, reliable, and ready.

And if you’d like to help us get there a little faster, we invite you to join in.

Rust

Rust is one of those toolchains that requires (nearly) precisely the previous version to build, all the way back to prehistoric versions of the compiler. Each version used new features introduced in the preceding version. And for technical reasons we won’t get into, the Rust bootstrap process is slow. It might take 1-1.5 hours to build a single version.

Multiply this by 20 or more, and it could take a full day to bootstrap Rust on any given architecture that it supports. We can build the entire rest of our tree in less time!

Fortunately, an enthusiastic wizard has created mrustc, an alternate Rust compiler that itself is written in C++. This can help us reduce the number of Rust toolchains that we need to build, and bridge us to source on all targets.

New Repositories

In addition to system/ and user/, we are introducing several new package repositories to assist with several key areas of our project. Some of them will have public binaries, such as kernels/ and compilers/ repositories, while bootstrap/ will not, for internal use only.

Fun fact: BETA6 already used the new bootstrap/ repository, which builds but does not publish intermediate binaries. We retain them to save time during future builds if we can.

For kernels/, the following broad objectives are planned:

• embedded: for Raspberry Pi, ODROID, Beagleboard, SunXi (including matching images)
• Asahi: for use on Apple Silicon hardware
• performance: kernels tuned for performance (in various contexts)
• hardened: security-hardened kernels (including to support SELinux)
• mainline: bleeding edge (primarily for testing)

For compilers/, the following broad objectives are planned:

• GCC trunk
• LLVM trunk
• Benchmarking and writing documentation for parallel code execution
• Investigate whether NVIDIA HPC SDK (formerly PGI) can be integrated, and how
• Investigate whether Intel HPC Toolkit can be integrated, and how

Note: Adélie does not currently have the capacity to support all of these initiatives equally (for now, many of these are led by passionate individuals), but we believe it is worth the time and effort to strengthen our platform and ecosystem and to attract project interest.

Security

In addition to the kernel and SELinux hardening discussed above, the GCC and LLVM updates in BETA6 provide several enhancements over BETA5, such as better static analysis, sanitizer improvements, and other toolchain hardening features.

One of our contributors is currently onboarding to help us better organize our CVE response efforts. We hope that the improved APKBUILD modeling work will allow us to more effectively parse, correlate, and manage security-related issues in packages.

However, much work remains toward making Adélie the secure platform that we intend.

gcompat

(A new gcompat release is imminent; please check back soon and thanks for your patience).

Pre-compiled Spack binaries and, for example, the Anaconda distribution offer us a massive corpus of complex glibc-linked software that will aid in determining how to evolve the gcompat project. We hope to create a dedicated website for the gcompat project.

Ridley Combs has contributed a new loader that will help accelerate our GPU experiments. It is currently pending review, testing, merging, and release.

The new gcompat website will provide documentation and software compatibility matrices.

Package Tooling

We currently maintain “soft” forks of apk-tools and abuild, which are our package manager and package build utility, respectively. However as upstream continues to change APK (itself a “hard” fork of pacman) and our needs for robustness become more apparent, we will be “hard” forking both of these projects. (N.B. to support formal APKBUILD modeling).

Pipelines & Automation

Our last status update mentioned some developer-facing initiatives:

• Formalization of project roadmap and issue tracking/management
• Formalization of CI, development and release pipelines, and internal automation

These are still in progress. We have dedicated scheduled assistance to help with this effort and hope to write about it in the coming months.

Accessibility

Modos, the company creating an e-ink paper monitor (and other open hardware products such as a laptop), recently published an update worth watching. We’re hoping they’ll consider Adélie as their supported distribution and wish them continued success.

We would love to collaborate on accessibility matters, possibly involving AccessKit.

Documentation

Documentation remains a sore spot.

For example, manual installation on Macintosh computers requires model-specific nuance and the documentation presently written has become outdated with our recent releases. Writing and correcting our documentation is a high priority, high importance item for us.

There are several ongoing initiatives for user-facing, developer-facing, and administrator-facing documentation that we will share in a future update. That is, we’re working on it.

If you would like to help out with technical documentation, we may be able to pay you for it.

Final Thoughts

The remainder of the 2023 projects and initiatives remain accurate and on-track, except for LibreOffice which has not seen any activity since our last status update.

Thanks, team, for another great year. Y’all are killing it.

Footnotes

¹ This transition is still in progress. In brief, core infrastructure will remain untouched, but we will expand some of our development capacity to OSUOSL for cost and redundancy.