Happy 918 Day!

Adélie Software has a long and rich history in the Tulsa community, and today is our community’s annual 918 Day celebration!

The Adélie Linux project was started here just about five years ago, when A. Wilcox and Elizabeth Myers were discussing different Linux distributions. They decided to start a few projects aimed at improving the Linux ecosystem on the whole, and what became Adélie was born.

Tulsa has been a wonderful place to run a technology startup. We love holding meetings at Kilkenny’s (and can’t wait to go back after the pandemic!), and relaxing after a long day of programming by taking a walk through LaFortune Park.

However, the true hidden gems – what we would like to highlight this 918 Day – are our local technology shops. We are so lucky to be surrounded by places we can go to buy any sort of hardware we need. Wholesale Computer Supply, OARSpc, RK Computers, Same Day Computer, MegaWatts, Experimac, DISC Surplus… these are just a few of the many names that we are proud to be regular patrons of. Their resilience through the rough times of 2020 is inspiring. They continue to provide Tulsa with the technology we need to live, work, and play digitally and safely.

On behalf of our entire team in Tulsa, we would like to express our deepest gratitude for our friends and neighbours that make this community so great. Thank you, Tulsa!

Looking Towards the Future

Hello all,

You may have noticed that there have not been weekly status reports or blog articles since late March 2020. A lot of notable things have happened in the Adélie Linux project, and other related projects, since then. However, I feel it is important to start with a more personal introspection.

As Project Lead of Adélie Linux, and co-owner of Adélie Software in the Public Benefit, my attention is regularly pulled in many different directions. In April 2020, my mother — the other co-owner of Adélie Software in the Public Benefit — suffered a health malady. Her health is improving now, but combining my existing workload with caring for her caused me to suffer a diabetic emergency. All of this caused financial strain, both regarding the business (from the inability of us to perform work) and personally (for healthcare costs). These issues are also beginning to calm down. These experiences have led me to a few realisations about our community and how to better lead it.

This starts with the Weekly Status Reports. I started writing the Weekly Status Reports to keep interested parties involved with the project even if they could not participate in our IRC or mailing lists. However, the rigidity of posting them weekly has always been a source of contention for me. There are some weeks where nothing much of note happens, and there are other weeks when it seems more appropriate to have had two or three posts because so much happened. Additionally, the Weekly Status Reports were always authored solely by me. My time for writing them is virtually non-existent, and writing them – especially in such detail – takes time away from actually working on the project. In addition, moving forward I would like all members of our team to be able to write about the changes they are responsible for.

It is with this in mind that I am formally announcing the retirement of Weekly Status Reports.

A new initiative, Adélie.Dev, will be launched in the coming days. The Weekly Status Reports provided information about what had already been done; it is my hope that Adélie.Dev will not only provide this to the community, but also provide information about what is still being worked on. This way, newcomers to our community can see tasks being actively developed and join in if they are able. It can also provide cohesion and prevent duplicated effort.

This blog will shift to being more article-driven, providing news and updates from the community in a more traditional blog format. It will also continue to serve as the official Web location for release announcements.

I look forward to watching this community continue to grow into something we can all be proud to be a part of.

In solidarity,
–arw

Official statement on x86_64 architecture security flaws

Many of you that use x86_64 computers are likely concerned with the various security flaws that have been discovered in the silicon of virtually all 64-bit Intel CPUs this year. There have also been a few requests for packaging official microcode updates.

Unfortunately, the EULA required to install, use, and redistribute these microcode updates is non-free. Intel has ensured that providing these updates to you would cause us to violate US and European copyright and contract laws.

As further security flaws are inevitable due to the design of the x86_64 architecture, and we cannot legally provide you with the updates necessary to avoid these flaws, we highly recommend that our users invest in computers using different architectures, such as PowerPC or ARM. While the x86_64 architecture will continue to be a Tier 1 architecture for the foreseeable future, we can no longer guarantee user security or data integrity to users using x86_64 computers with Intel processors due to Intel’s restrictive licensing.

Editor’s note: The original version of this statement included the following statement: Furthermore, Intel has added a stipulation in the EULA for their latest microcode update that renders their CPUs non-free, by forbidding any usage of software that they arbitrarily determine to fall under “benchmarking”. This includes tools such as hdparm. Intel has since removed this clause from their license; however, the microcode itself is still non-free and we cannot distribute it.

Our official stance on the Rust programming language

A few people have asked us about when the Rust programming language will be packaged for Adélie. The short answer is that the Rust programming language fails the requirement that it can be packaged on all tier 1 architectures, and additionally fails to meet our libre source requirements. These issues are not insurmountable, and I hope that Mozilla will continue to work with the community to find answers to them. A more detailed explanation follows.

Issue #1: Rust requires binary Rust to compile

Our guidelines strictly require that all packages must be built from source code, without the requirement to trust upstream binary packages. You can read a few papers on the reason for this; a good starting point is Countering “Trusting Trust” by Bruce Schneier. Put simply, a compiler binary may be malicious, and the only way to prove that it is not is to compile it with a separate compiler. Rust is implemented in Rust, and there is currently only one implementation of it: Mozilla’s. A community effort to create a second implementation is underway, but it is not yet sufficient and supports only x86_64 currently. There is no way to know right now that Mozilla’s binaries do not have malicious code embedded without an independent Rust compiler.

Issue #2: Architecture support

Our guidelines strictly require that all packages support all Tier 1 platforms to be built as a supported package. (Packages that don’t may be maintained by the community at a site like APK Fission.) Rust, as of the time of this writing, does not support any non-x86 architectures; as of 1.8 (the last time triplets were documented), the PowerPC musl platforms were not supported even for custom builds.

Issue #3: Cargo now requires Cargo

As described in issue #1, our guidelines strictly require that all packages must be built from source code. As of the latest release, Cargo now requires itself to build, which again requires us to trust an upstream binary package. With this specific package, it may be possible to bootstrap using an older version of Cargo that still supported source builds without itself. This has not been investigated yet as the other two issues are far more pressing.

In Conclusion

We would truly enjoy the ability to provide the Rust environment to our users, and we hope that Mozilla will continue to improve Rust’s tooling to allow this. Until such a time, the security and integrity of our distribution is paramount. To preserve that security and integrity required to create a truly libre Linux distribution, we are required to delay any packaging efforts for Rust.