Daniel Kolesa

Chimera Linux is a new Linux distribution started in mid-2021. It's a general-purpose operating system based on binary packages that aims to be practical and clean, while addressing various shortcomings of an average Linux distro. One of the things making it unique is that it's a non-GNU distribution, utilizing a combination of userland utilities originating from FreeBSD, the LLVM/Clang toolchain and musl libc, besides other things. On top of that, it is not based on any existing distribution and comes with its own packaging infrastructure and various custom software that was needed to fill in the gaps. It's also highly portable, already supporting x86_64, POWER, AArch64 and RISC-V, with more possibly coming. In the presentation I will cover the progress made in the last year, as well as give a general overview of the system and what it takes to create a distro from scratch.

The distribution follows a rolling release model and by default uses the GNOME desktop with Wayland. The custom package building infrastructure was created after having learned from the shortcomings of equivalent systems in other distros, aiming to be flexible and fast, while emphasizing correctness and allowing for fully sandboxed, unprivileged builds. The result is binary packages/repositories for apk-tools, which Chimera uses as a frontend package manager. The build tooling can also bring the system up from source using a foreign musl-based distribution as a base, making it easily bootstrappable. The resulting repositories utilize LLVM's ThinLTO for nearly all packages, and special emphasis is also placed on security hardening (including CFI and others). Service management is based on the Dinit suite with a custom set of core services and is fully supervising, dependency-based and aims to provide practical parity with systemd, while remaining lean and grokkable (and most importantly, portable). A major aspect of the project is to also improve software portability across the stack, improving the state of matters for both Linux and the BSDs. We also aim to contribute code improvements back to FreeBSD.

Most importantly, this is not any kind of dogmatic, niche effort. It's a system that tries to be pragmatic, providing a complete package that is polished and has well-defined defaults, while establishing its own identity and not being like something else. We also want to establish a community that is open and welcoming, without pointless elitism, and most importantly have fun doing all of this.

This is a follow-up presentation to last year's FOSDEM, but I will try my best to make it standalone and as easy to understand as possible for the general audience. Some basic Linux administration knowledge may be necessary for some of the information.

Chimera Linux is a new distribution I started in the middle of 2021, after years of thinking and vague planning. After getting a bunch of real world maintenance experience managing the POWER architecture support in Void Linux, I have decided to make those ideas a reality - a distribution with the Linux kernel, but FreeBSD userland, LLVM/Clang system toolchain and core runtime, musl libc and a fair amount of custom tooling. Right now, it is a bootable system targeting a variety of CPU architectures (aarch64, ppc64le, riscv64, x86_64...) that is easily bootstrappable (and capable of building itself), testable, lightweight and fast (but still in heavy development). It uses the apk package manager (of Alpine Linux) and a completely custom source packages collection and build system written in Python, allowing for sandboxed, fully unprivileged package builds.

The distribution follows a rolling release model for its simplicity and ease of release management, but without insisting on bleeding edge versions. The build tooling is capable of bringing the system up from scratch using any other musl-based distribution as a base (and without requiring any GNU components beyond currently their make implementation) - the system rebuilds itself 3 times for that purpose. Link-time optimization (specifically Clang's thin LTO) is enabled for nearly all packages. The lightweight, dependency-based, supervising 'dinit' service manager takes care of boot, and Wayland is the preferred display server. The system aims to be general purpose, not niche; a primary goal is breaking up some status quos in the Linux ecosystem and provide a truly viable alternative. It should be community driven, open, welcoming and unorthodox, without any pointless dogmatism.

In the talk I will cover my journey towards having a system capable of boot, what it took to bring up a distribution from scratch and how I dealt with various obstacles, and what I learned on the way, as well as the future of the project. Some basic Linux administration knowledge will be required from the audience, but any somewhat tech-savvy person should be able to follow.

Void's POWER architecture port has been progressing steadily since the last OpenPOWER Summit EU talk in 2019. Recently we introduced a completely new 32-bit little endian port, which will be a big part of this talk's focus, and is a first among Linux distributions. I will not stay there though - we have more to cover, including stuff like Chromium and Electron applications in repos, faster POWER crypto in LibreSSL, reworked crosstoolchains, stable support for newest AMD GPUs, and our big endian variants are also receiving attention, including properly clearing up the 64-bit ABI situation.

Void Linux is an independent, rolling release, general purpose Linux distribution (leaning towards desktop/workstation focus) originally created in 2008 on the x86_64 architecture as a testbed for its own XBPS package manager. Over time, it has received a variety of ports, including 32-bit and 64-bit ARM, MIPS, and eventually POWER and PowerPC. It has variants for 64 and 32 bits, little and big endian, and glibc and musl C standard libraries. Most recently it has received an experimental 32-bit little endian port, which is a first among Linux distributions.

I will be focusing partially on the new port, and partially on other news in the distribution since my last talk I gave at OpenPOWER Summit EU 2019. I will explain our goals with the new port, as well as our plans. Additionally, the future of the distribution will also be covered, as well as currently remaining issues and blockers that prevent us from achieving that.

I will describe how we use the Eolian Domain Specific Language to handle automatic generation of EFL bindings for different languages

The EFL is a suite of libraries for cross platform application development written in C. However, most people prefer using higher level languages for application development, which makes bindings necessary. Writing bindings by hand is not an easy task; their later maintenance is even worse, which in the past resulted in our bindings getting obsolete fairly quickly.

A while ago EFL got its own object system called Eo. This object system forms the basis of our API infrastructure; as one of the advantages, it allows for potential automatic language bindings. While Eo provides an appropriate runtime, it's not enough - which is why we also came up with a declarative interface description language in which the EFL APIs are described, allowing for all sorts of processing and analysis.

In this talk I will describe how we use this language (called Eolian) to handle automatic generation of EFL bindings for different languages. I'm going to show examples of different generator types (for dynamic languages, particularly Lua, as well as statically typed compiled languages such as C++) as well as provide examples of Eolian usage for different tasks.

OctaForge is a permissively licensed open source cross-platform (Linux, FreeBSD, Windows and OS X, and possibly other platforms) 3D game engine based on the well known Cube 2/Tesseract engines, While Cube 2 and Tesseract engines were created mainly for the games they power, OctaForge aims to provide a framework for game development.

In my talk I will cover the design of the engines OctaForge is based on as well as design of OctaForge itself, the challenges I faced during its development and the challenges I'm still facing as well as the future direction of the project.

And to make things more interesting, I'll show some demos as well.

OctaForge is a permissively licensed open source cross-platform (Linux, FreeBSD, Windows and OS X, and possibly other platforms) 3D game engine based on the well known Cube 2/Tesseract engines, While Cube 2 and Tesseract engines were created mainly for the games they power, OctaForge aims to provide a framework for game development.

In my talk I will cover the design of the engines OctaForge is based on as well as design of OctaForge itself, the challenges I faced during its development and the challenges I'm still facing as well as the future direction of the project.

And to make things more interesting, I'll show some demos as well.

The EFL is a toolkit for writing cross-platform applications. Enlightenment is a desktop shell built using this toolkit. Both the EFL and Enlightenment are fast and light on resources (which made them the toolkit of choice in places such as the Tizen operating system and embedded environments) while remaining scalable, but their low level approach complicates portability. In this talk I'd like to summarize our past portability issues and tackle current ones, as well as talk about our future direction. The talk will be focused on FreeBSD, using it as an example, but will also cover our general issues and portability to other operating systems including Windows and OS X.

The EFL (Enlightenment Foundation Libraries) is a toolkit for writing applications (desktop and mobile alike), notably used by the Tizen operating system as well as other places. Enlightenment itself is a desktop shell built upon this toolkit. It's clean, lightweight and written entirely in C. However, its low-level implementation approach has, besides small size and high performance, a flaw, which is portability, an issue I have to deal with very often as part of my work at Samsung.

Enlightenment/EFL developers have always tried to write relatively portable code, but there are still quite a few issues (major and minor) that remain. As a FreeBSD user I think that portability is a very important topic that should not be overlooked, and that's why I would like to cover these issues in this talk as well as propose some solutions. The problems we're currently facing include dependency on certain very Linux specific things, such as udev, Wayland etc. as well as differences between APIs provided by those operating systems and differences in tooling (build systems...).

By coming up with solutions to these issues, we can make the EFL and E work better on non-Linux operating systems (including but not limited to the BSD family, Mac OS X or even Windows) as well as make it work better in those places where it already runs, making it more accessible to more developers.

In this talk I will introduce the EFL and Enlightenment, cover portability problems across different operating systems with a focus on *BSD (and lesser coverage of OS X and Windows) and present our future plans as far as platform coverage is concerned.