All right. Looks like we can begin. So, welcome. And I will tell you about my project which
is called Chimera Linux. But first, let me introduce myself a bit. I'm a software developer
from the Czech Republic. I've been contributing to open-source software since 2007. And currently,
I'm on a break from work, so I'm kind of working on the distro full-time. When I'm not on a break
for work, I work in the WebKit team in Igalia. Previously, I also used to work for Samsung
in the open-source group, where I worked on the Enlightenment Foundation libraries
and the Window Manager. Since 2009, I've been using FreeBSD, also on desktop for about 10 years.
But I've not been using that on desktop since about 2018, because I've been mostly using
Power Architecture computers these days, which FreeBSD doesn't have the greatest support for.
So, for example, my GPU wouldn't work. I'm also a former developer of the Void Linux distribution,
which has served as a huge inspiration for this project, especially in the design of the packaging
system. And I sort of do all sorts of things. Besides distribution development, I also do,
for example, game development, compiler stuff. I did some kernel bits as well.
But now, what's Chimera Linux? It's a new Linux distribution which I started in 2021. And it's
a general-purpose distribution created from scratch. It utilizes core tools from FreeBSD,
which is one of the big differences from standard distributions, which is GNU tools for this,
or busybox, for example. It uses the LLVM tool chain to compile all the packages. As a matter
of fact, there's currently no GCC in the distribution other than for some variants of
few boot for specific ARM devices. It uses the muscle Lipsy, and it's a rolling release
distribution, so there are no releases. It sort of updates continuously. And it's also highly
portable to many architectures right now. We are supporting Arch64, Power, a little Andean. Soon
there will be Power Big Andean, X8664, as well as complete full support for RISC-5 64-bit.
I started this project in early-mid 2021. And it started with a C-Built, which is sort of a meta-build
system for packages. You create your packaging templates, and these basically describe the
package and how to build it, and C-Built builds it. I was a Void Linux developer to this time,
and I started C-Built as a way to investigate if I can fix many of the shortcomings of Void Linux's
XBPS SRC system. So I've created a quick distribution around C-Built, which consisted of GCC
and GNU user lines, as well as the XBPS package manager, which avoid to use this. And to this point,
it was only about 50 packaging templates. So it was very tiny. It couldn't boot, definitely,
because it had no kernel and no bootloader or init system, even, or anything. So it was just
like a little container, which was capable of building itself when hosted on another distribution.
And as I said, I was trying to fix many of the issues, and main focuses of C-Built have been
performance as well as correctness. This was when I first managed to make Kaimira boot in a VM.
Shortly after those 50 packages switched to LLVM and removal of GCC followed, as well as
switched to 3BSD tools, removal of all the GNU stuff and so on, and as well as gradual expansion
of all the packages. I've been sort of iteratively enhancing the distribution ever since and until
it got to the current state. In late 2021, it was possible to boot the system, and it's capable
of bootstrapping itself. In early 2022, there was a full GNOME desktop already.
This was when I got Wayland Compositor running, and of course, everything needs to be able to
run DOOM, so we got DOOM working. There's a terminal and some other basic stuff, but this was,
I believe, around late 2021. I had a talk about distro at FOSDEM 2022 too, and many things happened
during 2022, so last year I did the talk as a sort of chronological thing. I'm not going to do that
this year because there have been too many things, and I couldn't fit it into a 50-minute slot.
Huge focus has been in last year on security hardening and on development of
different new solutions for things which we've been missing. I'm currently aiming for an alpha
release, which will be sort of early adapter release, where things will mostly work on desktop.
In late February or early March, I plan to make it coincide with one of the
betas of FreeBSD 13.2 in order to be able to rebase the tooling.
Now, for some motivations, why did I create this project? I've been unhappy with existing systems.
There are many great things that existing systems have, but there's always at least one thing which
has been annoying me. I sort of wanted to create a thing which would actually suit me in every single
way. I wanted to make a well-rounded practical operating system that wouldn't be just a toy,
but something people could actually use. At the same time, I would like to improve software in
general, that is mainly in terms of portability as well as security when it comes to things like
usage of sanitizers and so on. I would like to make full use of LLVM, not just replace GCC
compiler, but actually utilize the unique strengths of LLVM, which includes a great sanitizer
infrastructure, things like FINLTO, which GCC still doesn't have and so on. Of course,
proving Linux is not a new Linux is also a major thing. While doing all this, I wanted to have
some fun and some people on the internet said I couldn't do this. Of course, it's important to prove
them wrong. I wanted to build a nice community which would be fun to hang around with and make a
good system for both myself and for other people. Now, for some general principles of the project,
I strongly believe that projects which basically are centered around a single goal
are eventually doomed to fail because once you reach this goal, you have nothing else to do,
but at the same time, it creates dogmatic things which you are not allowed to cross
and it really restricts you with the development. On the other side of the problem, there's scope
creep if you have too many things to do and you keep expanding on it. Eventually, you get to the
point where you never get anything done, so it's important to balance these things. I think opinion
development is overall a good thing because it gives you a sense of direction, which is always
nice to have. I think, obviously, quality of the code matters, but quality of the community matters
even more so. I think fun is good, so I would like to try to keep it that way and not get too
technical in the process. I think free and open source software projects are social spaces and
that's why if you let toxic people into your community, it's eventually going to become a
chore for everybody else. I try hard to keep them out, but at the same time, I try to make sure it
does not get overly elitist because it should be an open, inclusive project for everybody.
As for technical principles, I try to make sure things are strict by default and try to avoid
technical debt at all costs. There should usually be just one way to do things. That doesn't mean
there only has to be one way, but more like a good default that people are supposed to follow and
it's sort of intuitive and easy to follow. Things should remain as simple as possible, but not too
simple. There are many people who overly focus on things like minimalist systems and in the process
they end up forgetting what's actually practical. I think security and hardening is also very important
and in many Linux distributions, it's sort of overlooked. That's another thing. I think portability
is also extremely important. There are many kinds of hardware and people are using many different
kinds of hardware. Of course, most people have their x86 computers, but there's more of it than
you may think and things like risk five are taking off and there's power workstations and
there's arm and so on, so it's good to have all these things. Now, good tooling is also very
important and related to that is self-sustainability. That basically means whatever infrastructure you
have should be self-contained and easy to get going and easy to replicate on any new computer.
Related to that is being able to bootstrap the system from source code. I think that's
sort of a double-edged sword because some people don't care about the bootstrap ability at all
and things are massive binaries downloaded from the internet. On the other side of the coin,
there's people who insist on complete bootstrap ability from source code for everything, even
if it involves doing completely cursed things such as ever seeing how to bootstrap the Haskell
compiler from source completely. It's like if you want to do it and you have to go through
an ancient un-maintained Haskell compiler which only targets 32-bit x86 computers and
like compile some stuff on that and it's from like 2004 and then you have to iterate through
newer versions, eventually you get to GHC and then you can cross-compile a partial distribution
for architecture and then go from that and eventually you reach your goal. I think it's
a means to an end and it's important but not that important. Another thing is that I've seen
over the years many things and I think it's something is written in a shell and it's a
complicated program and it probably shouldn't be. It should be easy to do the right thing
but tooling should also make it difficult to do the bad thing, kind of steer people towards
you know doing what's right and doing so out of the box. Documentation is obviously also important
and many people avoid writing documentation, I understand them because I'm also guilty of this
in many cases but yeah we should strive for a good documentation. There's also the question of
SystemD. I believe SystemD is in many aspects not great but also it brought a necessary change to
Linux and there are basically many people on distributions who just stick their hat into
the sand and just avoid even considering that SystemD might have brought some useful things
and that it might kind of be also their fault that it has become so widely adopted. So we
should develop good solutions to counter whatever SystemD has come up with and basically always
try to improve. Now let's take a look at how a BSD system is developed. Usually you have your
entire system in a single tree and a single repository typically SVN and so on and you have
lots of different components in this repository. It's a complete system capable of boot so if
if you invoke the central make file and compile the system you generalize compile your kernel
and compile your userline and if you put it together you will get a system which is capable
of booting and third-party software is which is not required for the base system is distributed
through some kind of port system. Of course this doesn't mean that there are no third-party components
in a base of the BSD system because I'm not aware of any BSD system which is developing
complete replacement for the tool chain for example. You have your LLVM or whatever in base
and usually it has its own built system integrated with existing make files but it's a single tree.
Now let's contrast it to a Linux distribution. In a Linux distribution it's a collection of
software from many different parties which are separate packages and you have Linux kernel
as the base layer that's always the case otherwise it wouldn't be a Linux distribution.
You have your userline tooling which is often supplied by GNU and you have the libc which is
also often supplied by GNU glipc and you have the tool chain to build all this so it's also
often GNU because while client is used for some distributions not too many of them and you have
the service manager and also some auxiliary tooling around the service manager so that's
often system d nowadays. This is tied together with a package manager which handles installing
and removing and so on and sometimes you have well usually have some of the components always and
then you can install or remove whatever you want and Linux plus gcc plus glipc plus core
utils, find utils, diff utils, and so on. It makes GNU Linux or what is called GNU Linux.
Distributions exist to make sure that all these components work together and they combine well
because many different distributions combine them in different ways and they have different
versions of these components and they all have to play nice. So the Linux kernel has a rule of
never breaking user space if a new version of Linux kernel results in a binary not working
it means it's a bug in the kernel even if it was for example originally an unintended behavior
so this can be kind of a pain. But let's get back to Kaimira so starting out the tool chain.
LLVM in Linux is pretty seamless nowadays most of the time. You have it available on most Linux
systems but on most Linux systems it's sort of a different arrangement because you do not have
LLVM provided the runtime. GCC provides this and it's called libgcc. It's mostly ABI compatible
with lipanwine from LLVM but it also includes some of these built-ins which are provided via
separate library in LLVM. LLVM comes with its own runtime called compiler rt and this is used in
Kaimira instead of libgcc. For the C library we use muscle because it's a proven good
implementation of a C library which is used by several distributions already and you can make
most software work on it just fine with maybe with a few patches but better than other lipsies.
When you have a GNU tool chain you usually have GNU benutils to complement GCC as well as LLVTils
to provide lip health. Benutils provides things like linker because GCC does not come with its
own linker. It also provides different tools which are used together with the compiler things like
archiver and read health and these kind of stuff. In Kaimira this is the LLVM from LLVM is used
as a linker and it's used everywhere. As for the other tooling which is provided by Benutils,
elsetoolchain provides this tooling and this is also used on FreeBSD to provide these tools.
LLVM also provides lip health implementation which replaces the one provided by LLVTils.
Lip health is used in many places but for example the kernel requires it. LLVM also
provides most of these tools which are provided by Libutils. They have a prefix LLVM so for example
LLVM read health. We do not use those in the core system most of the time.
So now to sort out the Coruselant you have many GNU components as well as non-GNU components
like Corutils, FindUtils, DeFutils and so on. You have Util Linux also which is used by
premature distributions and provides sort of a mixture of tools for all sorts of stuff.
In non-GNU distros existing ones such as Alpine you often have busybox which is sort of
a single binary which can be configured to include many different tools which are otherwise
provided by Corutils and so on as well as by Util Linux. The main strength of busybox is that
it's a single binary so you can put it in embedded environments and you can have things
mostly work. But the other side of the coin is that it's very spartan when it comes to
functionality and the code is also not very good. But the other alternatives are usually even worse
in terms of available functionalities. So 3BSD tools are the answer here and that's what we've
done. I found this third-party port of 3BSD's tools called BSDutils. It was a sort of incomplete
experimental thing which was not quite ready for an actual system. So I helped complete it and
reached parity with Corutils. I fixed many bugs which were created during porting in the process.
I also ported many other tools to expand coverage and the result is Karmira Utils which
the distro currently manages and it's sort of a single easy-to-build package which includes
all of the tooling you want. And this replaced not just GNU tooling but also for example a portion
of Util Linux which makes things much easier for the distribution especially in terms of
bootstrapping because for example in Void Linux a NXB-PSSRC which is the build system which is
similar to C-Build. You have a stripped down version of Util Linux in the base build container
and you need this because some of these tools are necessary. But this means bootstrap problem
because when you build a full version of Util Linux you have many dependencies which you do not want
during bootstrapping of your system. Things for example UDef or that kind of stuff which you
really don't want to pull in. So it has a stripped down version of Util Linux for that and then it
has a full version which is built separately and it's kind of a mess. If we have a single package
for the user and all of this can be avoided and then only a partial build of Util Linux can be
built if needed. Karmira Utils is lean enough for very environments things like in-it-RAM-FS or
even embedded things but at the same time it's fully featured enough to be used as interactive
tooling so it's a nice all-in-one thing. And of course it helps break up the current monoculture
of tooling as well as it's easy to harden. For example, Karmira Util utilizes Clang Control
Flow Integrity hardening which can be enabled on Karmira Utils very easily and it just works.
Now to get the kernel sorted out. These two photos one is Karmira running on the MNT reform laptop
and the other is running on Raspberry Pi 3. The kernel is mostly compatible with Clang these days
and some patches are needed to support BSD Utilities as well as the LIP-ELF from ELF Toolchain.
I would like to eventually upstream these things and make sure things work out of box. Until recently
there was an issue with the option to use Clang's internal assembler. It did not work on some
architectures notably 64-bit power because of some legacy debugging for Nonsense. So
GNU Bin Utils was used for that until some time but nowadays it's not a problem and the Clang
assembler just works for every architecture. CKMS, what is CKMS? These photos usually use
DKMS which stands for Dynamic Kernel Module System to build out of three kernel modules and it's a
massive 5k inline bash script and it has functionality which seemed like a good idea at the time and
nobody uses it and it no longer seems like a good idea for example. DKMS can package kernel modules
and you can distribute them and of course this doesn't work because every distro has its own
kernel and it can result in in slight differences in ABI and so on so you cannot really do that.
I created CKMS which stands for Karmira Kernel Module System and it's kind of similar to DKMS but
it's much more lightweight, more robust, it's implemented in Python. It has privileged separation
so when you have your package manager built a kernel module in a hook during installation and
you run your package manager as root it will properly drop privileges so it does not run
the whole compilation of the module as root which happens with the KMS in most setups.
Now for the package manager that's an important thing in a distro. I considered the FreeBSD
package manager at some point but it was not in quite the shape I would like for production. I
did contribute back some patches to fix a bunch of things with muscle because that was the main
thing which was really problematic and I got it working but there are things such as version
expressions and the version string stuff which is a work in progress and it's quite obvious that
it's mainly all geared towards FreeBSD series right now. So eventually I ended up investigating
APK from Alpine Linux which ended up proving to be a great fit. For one it's lightweight but it's
also fairly powerful and I really like its virtual package system. It handles things like shared
libraries very seamlessly where shared libraries in packages are provided basically as virtual
packages and this makes it easily searchable, easy for the solver and so on. I eventually
transitioned to APK Tools version 3 which is the next generation of APK which is currently not
used by Alpine and it does not have a stabilizer yet but it works great. The main difference in
APK 3 is that it no longer uses star balls as packages. It has a new custom sort of structured
format which should help with avoiding vulnerabilities in the package manager.
By summer 2021 it was fully integrated in C-Built and it just worked.
Service management is another big thing you need to boot Linux distribution. So many options were
evaluated in the process, for example Runnit which is used by Void Linux, S6 which is sort of
new kid on the block, OpenRC which is sort of classic and built on the same principles as classic
RC systems. In the end I ended up choosing Dinit which is a new service manager. I chose it because
it's both powerful and lean. It's implemented in modern C++ so it's also safer than most other
service managers. Most importantly it took me about one afternoon to get it fully working and
get to the system from not booting at all to having it completely booting. It's supervising which
means most demons are supervised by the service manager by running on the foreground and being
basically child processes of the service manager but you can have a background processes as well.
It's less robust so this should be avoided most of the time. It's dependency based so it can ensure
that your services start in correct order. It has support for things like one-shots which help immensely
during early boot because most things you need to do during early boot is basically things you
run once and they do not have any sort of persistent process. So the early boot process is full of
one-shots. For example Void Linux with Runnit solves it by making these one-shots a bunch of
sequential shell scripts which are run before the actual services are running and it's not a
great solution because it's not very flexible. In any case it's a good base for a solid service
infrastructure. We have a custom suite of core services for Linux written from scratch. It has
full support for fine-grained targets. Basically a target is a logical service which does not
do anything by itself except act as some sort of sentinel. You can for example have a network
just target and then you can have other things say I want to start before this and then you can
make sure that or I want to start after this. You can make sure that your services start only
after network is up for example. It also has first-class support for user services which is
very important and I'll get to that later. The eventual goal is to have all long-running
processes be services and there's also the matter of session tracking which I'll describe in a bit.
Now this is a new project the distro came up with it's called turnstile and it's an answer to
the login D part of system D. Linux mostly uses system D login D for session tracking. What that
does is basically know when a user has logged in or when a user has logged in on another console
and it also knows when the user has logged out and it can be used by say desktop environments in
many different ways. There's E-Login D which exists as a standalone version which is basically just
ripped off, ripped away from system D and the dependencies are stopped out and it's sort of
dirty and not great. This is done by basically running a daemon which is called login D and a
module in the PAM infrastructure which is obviously used for authentication and the PAM module
basically doesn't even know when a new session has started and it also doesn't know when a session has
ended. This plus seat management which E-Login D also does but this is not widely used because
usually you only have one seat. It's used by desktop environments in especially things like
whale and compositors. With system D most importantly also has login D also spawn a user session of
system D basically which acts as just like normal service manager but it runs as your user and it
runs Caesar services. E-Login D cannot do this because it has no idea what other init system
or what user service manager you might be running. So this functionality is removed and there's no
way to access it. This is one of the reasons why I developed this. It aims to eventually
replace E-Login D and it was originally created just to manage those Caesar instances of
of init. The issue with that when running this in parallel with E-Login D was that
sometimes it needs to know something which E-Login D knows but sometimes E-Login D also
needs to know something the user service manager knows. It especially affects things like lingering
for example you can enable things you can enable specific user to linger which means those user
services will stay up even after you have fully logged out. E-Login D manages your runtime directory
for you which is used by many services and upon log out it removes this runtime directory. If you
have still some user services running and E-Login D has removed your service directory then
things go wrong. So it needs to be integrated and I plan to eventually fully replace login D.
E-Login D turns style does not manage seats because there's already a project called
Lipset and CTD which can do this satisfactorily but Lipset does not do the session tracking so
they can be used together and I plan to provide a library alongside daemon. This library will
provide agnostic API. This API will have multiple backends and it will have a backend for login D
it will have a backend for turn style D as well as potentially other solutions and then
things like desktops will be able to use this and be actually portable because
for example right now to have GNOME on free BSD for example it needs many patches to
replace this functionality and it's just not great. Having an agnostic API which is not
provided by system D would be a much nicer solution. Of course I'll also have to convince
subframes to adopt it. One thing which you do with turn style is managing the bus session
bus as a user service. This has an advantage because you have a single session bus per user
just like it's done when you have system D. Well why have a single session bus? This session bus
has a socket. This socket is somewhere on the file system and this socket is used to identify
other things on the bus. The way to locate this session bus is provided via environment variable
so if you have the environment variable in your environment then things can use this to
read the path and actually locate the socket. Traditionally you had the session bus started
by for example your x11 script xinitrc which would run something like the bus run session
something. That means the session bus was only available within your single graphical TTY.
This is not great because then when you switch console and login there and you want to run
something which needs to access the session bus it doesn't know about it. System D solves this.
We also solve this by running the session bus as a user service so when you first login it
automatically spawns the session bus. When you last log out it stops the session bus and it's
available on every single VT. This has also limitless potential for other user services.
We can do things like debas activation without having debas spawn the services themselves.
It's currently also used for the sound server for example with pipe wire. Now let's move on to
C-Built. C-Built is basically a build system for seaports as I ordered.
C-Built is only on the stand library.
This is what a template might look like. This is the template to build the DOOM game.
As you can see it's mostly metadata. There's one hook in there which runs water recon which
has no other way to do this. There's a build style for configure script which basically strips away
all the non declarative things you would otherwise need. How C-Built works is that it builds all
the software in a simple container called a build root in our terminology. It's a minimized
Chimera system. There's some packages which provide the baseline and your built dependencies
which are specified by the template are also installed into this container. This container is
fully unprivileged so you don't need to run anything as root and it's fully sandboxed. This is
done with Linux namespaces. The container is also read only after the build dependencies are
installed which means no package built can actually change anything in the container otherwise
other than in its own build directory. It also has no network access after all the fetch
stage things are done and it has no access to the outside system. Templates are also declarative
as I said ideal just metadata and it has fully transparent support for cross-compiling with
most build systems which means in most templates you don't need to do anything and it will be
able to cross-compiling without any additional effort. It has a clean handling of common build
systems this includes configure script, mason, cmake and so on and it's strict. It has mandatory
linting hooks for many things and unit tests where possible will run out of box. I strongly
believe that being strict by default is good because you can always make things more loose if
you need it but if you have things loose by default and then you need to strict in them
and you have many hundreds, two thousands of packages and you need to adjust every single one
of them it becomes effort which cannot be done because it's just too much. It has support for
things like bulk builds where it can properly order things in the batch to build without
you know having dependency ordering issues. It can check upstream projects for new versions and
so on. Build flags all the basic stuff for hardening which Linux and service typically use
like fortify, position independent executables, stack and so on are used. On top of that we use
system-wide LTO for practically every package. I think there's only about 30 templates out of
close to a thousand which have LTO disabled for different reasons. In some cases it could be
enabled but it's not worth it. We do utilize a system-wide subset of undefined behavior sanitizer.
It deals with things like trapping signed integer overflows in order to avoid
potential problems. Also CFI or control flow integrity is used for many packages.
It cannot be used for all because it breaks on a lot of stuff. It's very strict when it comes
to typing of functions but it's still used on a couple hundred packages.
The allocator. We now use the Skudo allocator from LLVM which is also used for example on
Google Android. It replaces the allocator in Muscle. This is not because of hardening because
Muscle allocator is already hardened but Skudo is also hardened allocator. But it has significantly
better multi-fraided performance because Muscle Malk NG uses single global lock.
This is a trade-off but it also means that the stock allocator in Muscle performs poorly in many
things and it's something people commonly complain about so we now rely on Skudo. There's also the
advantage of being able to eventually deploy GWP ASAN which is sort of sampling runtime version
of address sanitizers which can catch many memory errors at runtime with minimal performance overhead.
This is not enabled yet but it will be at some point. Other core things for the distro. Some
tooling is taken from Debian. For example we use InitramFS tools to generate InitramFS images
because other solutions were generally found to be unsatisfactory. For example requiring Bash
for the hooks and so on. InitramFS tools is very clean and simple and nice to work with.
If we also use console setup from Debian to do console and keyboard configuration as well as
the script for handling encrypted drives. Eventually I also had to add some other things like
the grab rootloader support for ZFS. We now support root on ZFS very easily and so on.
This is Kymyra desktop on RISC 5. You can see it runs things like Firefox for example
which does not build out of bugs but I made it work. This is on the high-five unmatched board from C5.
When I was starting to add to the desktop first thing I added was the western wayland
combustor as well as GTK. This sort of provided a baseline set of dependencies which are also
used by pretty much everything else. So then I expanded with XoDark stack things like the
enlightenment window manager as well as pegwm for a simple x11 window manager. I added the
multimedia stack including ffmpeg, gstreamer, media players and so on. In spring 2022 I added
the GNOME desktop which is the default choice but of course you can use anything else you want.
I also added web browsers. This includes epiphany which comes with GNOME and is built on webkit
and Firefox which is alternative choice and of course some games.
As I said before I would like to release an alpha version in late February or early March.
I'm not sure if this will happen but I hope it will. Before doing this I would like to perform a
complete world rebuilt of all the packages because I have introduced some things in C-belt which I
would like to propagate it into existing packages and it's not. So just to be clean I would like
to build everything with LVM15 as it is right now and basically then release the alpha. I will need
to launch automatic built infrastructure. I currently have a server in Kolo in my city but it's not
on public network yet so I need to set up the public network and launch things like this and
as well as CI. I would like to clean up the remaining fallout from the recent hardening stuff
as well as update every template to its latest version. And after alpha which is
the alpha cycle is expected to take about half a year to one year. I would like to add a libgcc
compatibility shim so we can run existing binaries because right now you cannot run existing binaries
because the system runtime is different. I would like to add support for D-Bus activation so D-Bus
does not run demons by itself through D-Bus service files but instead do it
instead delegate it to the service manager. I would like to investigate additional hardening
things like LVM save stack and I would like to improve the documentation. Right now there's
the beginning of camera handbook which includes some handy basic information like installation
and how to set up encrypted address and so on but it can always use more documentation.
Local support is also another thing I would like to expand. This is the problem in pretty much all
muscle list rows with the local support being sort of limited and you can have translations but things
like you know formats and so on. So in the conclusion we are currently nearing usability
and it should be suitable for early adopters by March. I would like to get all the major changes
done by beta and continue packaging more software as well as cooperate with upstreams including
the free bsdu upstream on sensing fixes and tooling and so on. In any case thank you for
listening and if you have any questions you can ask them. Of course we also have stickers so come
pick them up.
Yeah as I said it supported. I recently introduced it and I recently tested it. Oh yeah sure. He
was asking if ZFS on root is supported. Yeah it's supported. It uses the upstream script for
NETRMFS tools just patched to support the user line because we don't use busybox and it just
works. We also provide ZFS packages with pre-compiled binary modules so it's not necessarily
compiled from source during installation and CKMS can handle things in a non-conflicting way so if
you have the package installed for the stock kernel which provides the binary ZFS modules
CKMS will not try to build the modules again.
Yeah.
Okay well the question was if what's the target audience basically. Well I would say the primary
audience is basically the same people who would use things like Gen2 and so on basically power users
who can find their way around things because there's no insistence on providing graphical
clickable stuff for everything because it just wouldn't be possible. I just do not have the
main power to do all this so yeah it's for power users who can find their way around a simple system.
Yeah.
He was asking where does the name come from. Well Caimira is basically like a
mythical monster made up of three different animals so it should be fairly obvious like where
it comes from. We have Linux kernel and free bsd stuff and other stuff. Yeah.
Okay. Yeah the question was if I'm working with free bsd. I know the project has taken back some
of the changes. I have some patches in Caimira hotels which I do believe would be useful for
upstream and yes I do want to submit to them upstream. For example I have a fix in the sort tool
which fixes a crash with control flow integrity hardening so this would be nice to include for
example. How did you solve the problem of the PAM service program?
Sorry can you repeat? Those turnstile use C groups. Question is if turnstile is this C groups.
No it doesn't. It does the same thing as login. Basically this is a PAM module to report things
and it keeps a persistent socket connection to the daemon as long as the session is active
and then when the socket is closed and when the daemon receives basically a notification
pulse on the socket and once it knows the connection has been closed then it closes the
session inside of the daemon. So you open a socket from the PAM service module?
The question is if I open the socket from the PAM module. Yes the PAM module opens a connection to
the socket which is provided by the daemon and the daemon basically opens the socket in the system
as a unix domain socket and it's only accessible by root obviously so the PAM module access it.
So if you open a socket from the PAM module that socket obviously ends up appearing as a
file descriptor inside the program that ran the PAM. Does that not interfere with anything?
The question is if the PAM module with the socket actually interferes with anything.
No I found it doesn't interfere with anything and in fact as far as I know login D does basically
the same thing and other solutions for handling for example there are several solutions for handling
the runtime directory which is basically a run user uryd and they basically did the same thing
as far as I know but yeah as far as I can tell it works okay. Yeah. So first of all thanks for
your job it must be like really difficult to maintain all these dependencies. Thank you.
So my question is are you planning to integrate like any specific SSL library like for example
Libre SSL or like OpenSSL? Okay the question was about integrating SSL library we do use OpenSSL
version 3. This was actually a pretty big transition when it happened because many things
do not or did not work well with OpenSSL 3. Fortunately the amount of packages right now
is not that huge there are still some which do not work with OpenSSL 3 and which we do rely on
for example the Heimdall implementation of Kerberos which we use instead of MIT Karbi
does not work with OpenSSL 3 yet but it has its own built-in crypto which can be used instead so
we fall back on that for now. Anybody else?
Looks like that's it man and thank you again.