Hello, everyone. I'm Daniel Kolesa. I'm the author and primarily developer of Kimmer
Linux. First, in the first half of the talk, I will give you an overview of the project
in case there's somebody there. There's probably many people here who haven't heard of it or
don't know what it's about. And in the second part of the talk, I will sort of give you
an update on what happened during last year. So first, what is Kimmer Linux? It's a general
purpose Linux distribution primarily geared towards client computers such as desktops,
but also others. It's built from scratch, not based on any other existing distribution
with broad focus to it. And it's based on free BSD core tools, the muscle ellipsi and
the LVM tool chain as its system compiler. It's hardened when it comes to tool chain
security more than most distros and it's also very portable. Currently supporting official
binary packages for five architectures, this includes R64, both big and little and in PPC64,
Risk 5 and X86. It's based on binary packaging with APK tools, which is also known from Alpine
Linux, but we use the next generation of APK tools, which is currently under development
and not used by any other distro. It's a rolling release system, so packages are deployed
continuously and there's no fixed releases anywhere. There's custom built source packaging
infrastructure, which was written from scratch specifically for the distro. And it's generally
meant to be lightweight and pragmatic, so not really focusing on one specific thing like
many niche projects, but also overall they're still... I'm not really trying to make it to be
like anything else. We also don't use system D, but we are trying to not to be militant about it
because I kind of really hate doing that, so you won't find anything like that there. Why
make this? Well, I want to make a well-rounded system I would personally enjoy using and also
make proper use of LLVM's features, which they give us over GCC, for example, when it comes to
security hardening. I'd like to improve software I'm unhappy with and overall focus on robustness
and having a deterministic system which will always install the same way and work out of the
box, but still being transparent and simple. And also good to default for things. As for some
core principles of the system, I believe that some sort of technical purity is mostly
counterproductive and makes things in general worse, so we try to not assume too much and sort of
just make a flexible thing. I think that minimalism doesn't really mean anything by itself, so I
try to focus on other things instead. I do believe that the system should be simple and it's better
than being complex, but I also do believe that if complexity is necessary, then it's necessary.
It's better than being complicated and requiring tons of setup. I think that development should be
opinionated, but I also do think that dogmas are mostly bad and what we should actually focus on
is a good software design. In general, we try to be inclusive, open and accessible. Also it's free
software, so it's managed like free software. I think it's important to have fun when it comes to
free software communities, so we try to basically make sure everything goes towards that. I don't
know that mostly anything goes. Now let's get to the system design. I think it's good to always be
strict by default. That is try to make sure that people always do the right thing, make sure that
things are as strict as possible when it comes to, for example, when building software, having
proper lint for everything, having sandboxing and so on. There should always be at least one good
and obvious way to do things. I do believe that portability is extremely important as well as
security and both of these should be preferred over having high benchmark numbers. I'd like to
have self-sustaining tooling which can be retargeted to different environments so that when we need
to switch to something else, it's actually easy to do and we do not get stuck with some
weird old software. I do believe that the system should be atomic if possible when it comes to
package transactions. To this end, I've been working on getting rid of things like post-installation
hooks and so on instead making sure that as much of the transaction is atomic as possible so it
doesn't get interrupted and could be rolled back. I'd like to encourage doing good and if something
is written in a shell, it should usually not be written in a shell. I think there's always room
for improvement and nothing is ever good enough. I also do believe that even though we are not
using system D, it's not the devil so it's fine to get inspired if needed. Now let's get to
packaging infrastructure. We have a custom system called C-Ports and it's implemented in
Python. I started this in 2021 when I was still using Void Linux on my machines and basically
I was unhappy with Xbpssrc being a massive pile of bash scripts. It had many drawbacks such as
being slow, not having sufficient sandbox, being insecure so you couldn't really trust it to do
some tasks. So I sort of redesigned the whole thing in hopefully a better way. It's sandboxed,
it's very fast so you can introspect all the metadata and so on in real time. It's easy to
use and it's optimized to minimize the amount of effort necessary for a small team to maintain
things. So right now we have about 1600 packaging templates and we maintain them for all these
architectures and there's only a few cometers. It's extremely important to actually have a tool
link which will catch many different issues for you because otherwise it just becomes too much. So
we have things like nightly update checks to stay on top of things and heavy linting for
everything, heavy sandboxing, everything is containerized so all the software is built in a
sandbox which has no network access, a read-only file system, sanitized defaults, deterministic
installation of dependencies and so on. At the same time it makes it very easy to add new
packages if necessary. Now let's take, this is how the C ports templates grew during last
year. We started at around 800 and ended at some 1500. This is the comets, like overall
comets in C ports. So we pretty much doubled everything during last year and this is how
offers of templates or comets grew. So we went from around 10 to almost 50. Now let's get to
the updates. During 2023 we released an alpha version which means the project is now ready
to take on some users if they are feeling a little bit adventurous. The repositories are
receiving major expansion constantly with new packages being added pretty much all the
time. The system is usable as a daily driver with some precautions. I'm using it on many
computers, many people are using it. There's still plenty more work to be done in all areas.
Users are currently expected that if they are missing something in the repos they will add
this and maintain it if possible. We have a lot of major software packages, a lot of it being
done during last year including all the big web browsers like container infrastructure,
office suite, Qt6, Java, different big programs. A lot of smaller programs which are still
popular. We gained support for Flatpak which successfully supplements whatever is not
packaged yet at least on the X86 architecture. We are still trying to make sure to package
things if possible because it makes sure that people can actually run this software on all
architecture supported by the distro which is not necessarily guaranteed when you are using
Flatpak. There have been tool changes. We are now based on LVM 17. We default to no cement
interposition. We default to initializing variables to zero. We have the new Lipsy++
hardening flags enabled. We have expanded Fortify source. We also shrunk the executable size a
bit thanks to linker changes. Also since last year there is finally proper infrastructure
which includes build bot which automatically builds all packages as comments come in. Somebody
merges a request or pushes to the repository. Build bot will pick it up. It will deploy the
jobs to all the workers. The workers will build stuff and deploy it back to repos. It is pretty
much real time with only the overhead of actually the build time. The infrastructure is very
simple thanks to C build itself providing pretty much everything it needs to do. That means
it can do all the bulk sorting and so on pretty much by default. Which means what build bot
needs to do is suggest it receives comments. It checks which templates were, well it doesn't
even do that actually. It just tells the worker find all packages which are not yet present
on repos but are present in the C ports. Sort of diff it with the existing state. Then do the sort
to make sure that the bulk is built in correct order. This includes transit if dependencies
which are not even included in the transaction and so on. And things will just automatically
get built and it happens in half a second. We also have a fancy package browser at this
URL now. As for low level user line changes we have an initial API for our session tracker
which has been created from scratch to properly support user services in the system. We utilize
this heavily to, for example, sound server and session bus is run within as a user service
so you no longer have the bus launch or the bus run session nonsense like you had on many
legacy systems. Instead it's done in the same way as on system D systems where you have one
session bus which is started when you log in and then it persists as long as something
needs it. We have user line based on free BSD 14. We switched to system DUDEF in place
of EUDEF because EUDEF has been going out of date and it's pretty much just worse in
all aspects. We have adopted system DETMP files and CIS users in the core to manage all the
temporary state and all the system users to make sure they can be recreated as necessary.
We also have system D compatible support for BINFMT config files so emulators can be set
up in a transparent way and when you install QMU user for an architecture it will install
the configuration file properly reload and you will get your emulation. As for service
management we are preparing for the adoption of debuff broker instead of classic debuff
demon. This will mean fully service driven activation of debuff services which means
nothing will, everything will be supervised, there will be no legacy spawn this demon and
then don't care about it because that sucks. So for this we are currently working on Libdin
CTL which will add an or which already adds an API to interact with DIN from C and as
well as over debuff and we will have a debuff broker controller which will use this API
to generate if needed ephemeral services you know or like if something already has a service
and it will just use that instead of generating anything. As for service management we have
new service targets for example for time thing so services which depend on NTP can use this
or firewalls can make sure they start before other networking demon starts and so on. The
whole early service package got a big overhaul so there's different new helpers for say SW
clock which is used on systems with no real time clock in hardware for swaps with CTL
and so on and so on so to reduce dependencies on other packages. We have improved support
for read only root file system and it should pretty much just work out of the box these
days as well as countless minor quality of life improvements. As for hardware support
this is Kibara running on a Steam Deck OLED for example which works out of the box. We
have LTS kernel 6.6 and stable kernel 6.7. We gain support for Raspberry Pi 5 which is
in the same images as all the other Raspberry Pi so we support 3, 4, 5 in one image as was
shown before Steam Deck support. We introduced support for Big End in PPC64 which runs on
machines as old as PowerMax G5 so that's something people can experiment with. Also we have AMD
CPU working on Ampere Ultra R64 machine-sided box which needed some cursed kernel patches
which were only present in some trees so otherwise you get garbage in the screen which is currently
happening on every other distribution. As for conclusion it's been a very nice productive
year. There's probably going to be a beta release possibly in late spring or early summer.
The upcoming focus is going to be on service management because there's still more things
to improve in there. I'd like to introduce more support for advanced service management
features including better support for capabilities, possibly some name spacing, possibly proper
config file management. Also session tracking is going to be a major focus. I'd like to expand
the turn style API so it can fully replace E-Logindy because E-Logindy has been hugely
insufficient for us. The main issue with E-Logindy is basically with SystemD you have your Logindy
which interacts with SystemD directly so it can spawn the user session and then do it
and it can actually properly interact with E-Logindy. It's mostly geared towards systems
which are legacy so they use legacy style service management with system services only and you
have no way to properly track the lifetime of any E-Logindy session. This is bad for us
because for example we want to be able to ensure that user services can linger beyond
the scope of the user session but if we have E-Logindy managing the runtime directory then
we cannot do that because E-Logindy has no way to tell it to do this so it's kind of bad
and we really need the proper solution. We are already patching E-Logindy to enable some
of these things but I'd like to not patch anything and just get rid of it entirely. Also as a
part of service management focus I would like to introduce proper logging infrastructure
which means something like a journal where you can actually log both legacy log stuff
as well as STD out from different services, have a central daemon which will properly
deal with things like log rotation and so on in a better way than we have now. I would
also like to focus on package management. This will possibly include things like ZSTD
support for package compression and many different enhancements made possibly optional packages.
Right now we only have reverse optional packages which is nice but makes some things clunky
at times and there's a huge amount of work to do but we're going to get to it eventually.
Thank you for listening and now if you have any questions feel free to ask. I will try
my best to answer them.
Yeah?
Thanks for the talk. There are many talks these days of maintainer burnout and you
know the lack of financing in open source. How is Chimera doing at this point?
Sorry can you repeat that?
Is Chimera while financed and are you okay in terms of you know load? You don't suffer
from, do you feel that you may suffer from maintainer burnout if the project grows in
size?
Are you asking about financing?
Yes. Is Chimera okay at this point?
Well currently there's no financing to speak of like it's entirely volunteer driven.
There is five server for example for building these five packages sponsored by a community
member. The X86 dedicated server used for building X86 packages is paid for by me.
I also have my own hardware for PPC64LE. As for other builders for R64 and also for
Big ND and PPC64. These are sponsored by Oregon State University as VMs in their open
source lab so that's really nice of them. I do not really think it needs financing right
now. We are managing quite okay I would say but in the long term sure maybe it's something
to think about.
Now here.
You have the year wrong on your date on the slides.
The year is wrong on the date on your slides.
What?
Oh.
Yeah sure.
Paying attention.
I am curious if you could explain maybe a few words about things like turnstile and
E-log in D and what you feel is significant that system D brings to session management
that you want to reproduce that other system D free Linux's don't do?
Sure. I can explain that. Basically what log in D does in its core is it tracks when
users log in and when they log out so it can actually keep track of the session and other
applications can check this data so they can inspect what sessions exist, what kind
of session type it is, what kind of session class it is, what C group is associated with
that, like what processes belong in a specific session and other applications can make use
of this information. What it also does is manage seats which means it gives you secure
access to devices. Basically since Linux devices do not really have a concept of having multiple
users being connected to them, you can ask log in D for a file descriptor to a GPU device
for instance and it will give you that and it will hold it in place so that nothing else
can ask for it and also nothing else will have physical access to the device node so
only log in D is permitted to give you file descriptors to the device. This is extremely
important for Wayland Compositors for instance and E-log in D basically provides you this
functionality but it doesn't provide you proper session tracking or anything at all and session
tracking is also used by say Wayland Compositors or log in majors or lots of different things.
For session for seats tracking there's a project called Lipset and it also ships with a demon
called CDD which will give you this secure access to the devices but it does not give
you the session tracking so basically turnstile is supposed to complement this and make one
whole thing which will provide the same functionality and it does so in a way which is very important
sort of vendor independent so in addition to having its own solution it will also be
simplified API interface to log in D itself which means different software would be able
to adapt to this API and have support for both log in D itself as well as turnstile
the demon as well as potentially some third party solutions for example for BSD systems
which currently has nothing for this and that's why their Wayland support is very limited
for example.
I think we could take one more, does anyone?
So what is the state about software installer? Is this also planned for the BDG?
State of what?
Of a lacking installer system because of its copy pasting files now?
Well as for installer the problem with installers is that they are very complicated to make
which means it hasn't really been a focus for now instead the manual installation is
extremely simple and you can do it in like three minutes but there is a plan to have
an installer eventually it's just not something which has been you know focused for now because
it's complicated and it's a big project on its own to do properly otherwise if you don't
do that you will end up with bad installer which will have many issues and will be limited
in use so it's better to properly think about it and do it right.
And a quick second question will be like a rolling release strategy or will be like
releases in sync with the BSD user land utilities?
Well the distro itself is rolling release we do update to new the user land utilities
are using free BSD releases currently at 14 and we do update to new releases as they
come out so it does not really sync with free BSD current for example but other than occasional
backpacks when something major happens and we want it earlier but in general we stay
on top of free BSD releases and use that.
Okay thank you.
I think yes we are out of time so thank you Daniel.
Okay thank you.