So, next we have Krishna Brown, and it will discuss about it, it's really not a slide,
so I don't have to say it, but I don't want to give it a try.
Being different takes ails at this of the endless RC.
Thank you very much.
So, yes, first who the heck am I?
Well, I'm Richard, I've been doing open-source stuff for like 20 years now.
This is like my 13th first, then I build a distro, and I'm going to be talking about the latest one that I've built.
After you've got a little introduction about what the heck is this A-on thing?
Anyway, I'm going to be talking about the long roads that it's traveled, it's five years old now.
Some of the sort of pain points we've had as we've been putting it together.
Some little sort of inside baseball stories of what's gone on behind the scenes in the community and stuff as well.
And then talking about what we ever actually released the dumb thing and some kind of points to share and maybe discuss when it comes to your own projects.
Or just like any open source project generally, I think some of this stuff actually can be applied quite generically.
So, what the heck is A on anyway?
Well first, like way back when I suddenly woke up on morning and realized all this stuff that Susan was paying me to do in my day job with enterprise Linux
isn't actually good enough.
You know, traditional Linux, we've been building it for years and we've built it like it's a Swiss army knife.
It's great, it's flexible, you can change all the bits and pieces, it's wonderful.
But it's great, it's flexible, you can change all the bits and pieces.
So everybody does and they all end up with something different and it breaks and it breaks inside itself and it breaks when you start looking at other bits, just massively complicated.
And the funny thing is, like as this has been done more and more people have been adopting Linux around the world anyway, you kind of see people realizing these inherent problems with that open source to the next flexibility anyway.
Because what do users do when they start running Linux?
Well, they take this wonderfully complicated, do everything mega flexible platform and then they tear it down into some tiny little VM image that only does one thing.
Because, you know, they don't want all that change, they don't want all that complexity, making it all VMs, putting everything in containers, you know, ignoring the fact that we spend all our time in traditional digital and coming up with my life's life cycles and then they just don't patch the dumb thing and then replace it with the next version eventually, you know, you know, spending tons and tons of effort on automation and configuration management and yeah.
So, you know, people know these weaknesses in Linux but we've all kind of just trained ourselves into, you know, avoiding them rather than actually really fixing the distribution at the heart.
So, my view, you know, the perfect Linux should just work.
It shouldn't need these sort of complicated steps of taking it and then ripping it down and making it smaller.
Shouldn't need complicated policies, shouldn't need complicated configuration management.
All of this stuff should just be baked in so out of the box, your Linux does the thing that it's meant to be doing.
So, it should be optimized for basically what everybody's doing these days anyway, you know, it should be optimized for single purpose installations.
Small amount of services on their as possible have the updates automatically happen have recovery when the updates go wrong automatically happen.
Use it at scale because especially on the server side of things, you know, everyone's deploying more than one instance these days and have the whole thing ready to be orchestrated.
And, you know, maybe centrally administered, but not necessarily need it because, in fact, you don't need it off the stuff that ends up working anyway.
And in addition to doing all of that thing, it should be avoiding needing any manual maintenance ever being in a inconsistent state.
I mean, you heard about reproduciable builds for early like, you know, whatever state it's in, you should know that's what you wanted to be and how you wanted to be.
And you shouldn't need to have any of that complicated orchestration tooling even if you do support it.
And I would say for servers that perfect Linux already exists.
Micro OS from the Opensus project is that OS already, you know, it's a rolling release which may surprise some people when I talk about a rolling release for a server.
But, you know, because it does all of that stuff I just talked about, you know, it does the automatic updates.
It does the automatic repair.
The fact is that we don't have a lifecycle where you have to worry about what made a version of running.
Yeah, you don't need to, you just deploy it, it runs, it patches itself, it fixes itself.
You contain us all run, your services all run.
The footprint is nice and small.
I mean, mine Micro OS servers now.
I think the oldest one is, well, the oldest one is actually older than Micro OS.
But, yeah, so it's seven years, it's been running on its own.
I never need to touch the dumb thing.
But it's still running, it's still a big thing, it's still a good.
But I don't just want to serve it.
I mean, you know, I'm a desktop user too, and desktop's a special.
You know, they're not something that you can just hide away in a data center.
You're physically touching the thing.
You know, if anything goes wrong with your desktop, I'd actually argue it's worse than if anything goes wrong with your stuff.
If anything goes wrong with your server, because you were going to use that desktop to fix the server.
You know, you can't, you're not going to run around with two laptops and be able to roll over to the other side of the cluster.
You know, it's got to be more reliable than your service would be.
And yeah, if you don't think does it go wrong, you really need to be get back to a working state incredibly quickly.
And that's why I made A on.
So today, it is just like microS, reliable, predictable, and mutable.
We're opinionated, you know, it's known only.
I mean, very much more of a Chromebook like experience.
I'm a lazy developer than I was 10 years ago.
You know, I just want my laptop to work.
I don't want to be spending my time messing around with it.
Deploying it is an image, so I know I'm running exactly what I built and what I should be running.
Keeping the footprint on the machine as small as possible, but not so small that it's actually a pain.
You know, so printing, gaming, multimedia stuff, all of that's baked in.
And all of it just working straight after the box.
But that's today.
Wasn't where we began at all.
So the history lesson now.
Started this first five years, almost five years ago now, which is really weird.
As a user how quick projects, user gives employees a week, giving down again to mess around or whatever they want.
So we already had microS.
And I was like, okay, I want to have a desktop on top of microS.
It's going to be awesome.
And that's basically what I built.
So the microS desktop did it as a system role.
So basically alternative installation option when you're installing microS.
Which meant it was basically a nice simple RPM pattern that would sit on
top of all the other RPM patterns, which microS was already building.
Which meant it was dependent on all the stuff that microS was already building.
And we shared the same installer, we shared the same ISO.
I thought I was saving myself time and effort to didn't really work out that way.
Because that's where the initial technical problems were.
Because microS is a very server-oriented operating system.
I ended up with a very server operated desktop.
You know, I was having to work around all the issues of having extra drivers for the M's.
I didn't care about in cloud tooling that I didn't care about.
And embedded tooling that I didn't care about.
And then not being able to run any of my graphics stuff.
Because I wasn't on the microS image.
You know, having to really have a hard time with the core configuration.
You know, things like SE Linux policies.
You know, that's your one policy for your entire system.
And if that's written with a server in mind, it's going to bump up against a lot of desktop use cases.
Really, really, really common.
And you go to your security maintainers.
And they're like, yeah, it could fix that.
But then that's going to be way too much of a hole for everyone who's actually using microS as a server.
Like it's meant to be, right?
And also then we would have weird and wonderful interactions because microS has some of these additional patterns for things like cockpit and remote attestation.
People will try and mix and match and play around with wood and wonderful combinations, which I guess is quite fun.
But it just always broke and I was never in a position to really fix either because, you know, I'm not going to go fix cockpit to one on a desktop.
It doesn't really make sense.
And yeah, sticking with the same ISO and the same RPM installer, you know, we were stuck with some very basic common workflow.
You know, on the server it makes perfect sense to always have a router count.
I wanted to just have a user account with pseudo privileges.
Could I tell the installer to not do that?
No.
You know, for a different product, maybe, but for the same product with the different pattern,
it doesn't magically know that you press that one button to install that one pattern.
So completely stuck there, completely stuck when it comes to deploying images.
And then when I got the old thing installed, I couldn't actually tell if you've installed microS, the desktop or microS, the server.
Which also then started causing weird and wonderful confusion.
There's people started actually adopting this and talking about on forums and it's like, okay, I'm running microS or which one.
Where does this book report actually go?
And also we had sort of applied from the technical stuff, you know, community problems.
Because it was a system role, which is an installation option in the asked.
We had community members that kind of went, yeah, cool, I'm going to, you know, I don't like known.
So I'm going to contribute my favorite desktop environment instead.
And, in fact, what I kind of really did was I'm going to make Richard maintain the desktop environment because I'm going to disappear immediately afterwards.
Which, yeah.
And that's how microS desktop KDE was born.
And where had to rename microS desktop to microS desktop, no.
And that bought tons of problems.
There was the technical ones.
We, because, you know, there's a lot of stuff that's common between desktop, so you thought, okay, fine.
Instead of having microS desktop as one pattern,
you have a common pattern and a KDE, you want to know one.
So suddenly, there's an argument of which package goes in which pattern.
And, you know, where's the right place to actually put it, which was always pointless.
Because it always ended up being being the same team, maintaining all three package patterns at one point.
But, yeah.
And then, you know, you put it in the wrong one and half the desktop's break.
We ended up with lots of attention from the KDE user based in OpenSuser, which was great.
But one extra contributor in several years doesn't actually help.
And kind of muddied the water of what we're trying to do here.
You know, meant to be this nice, simple, you know, we provide, you know, provide you a desktop.
And suddenly, like, which one now, and, you know, you put instead of this nice vision of a perfect polish desktop,
you would certainly do a more questions and more options in front of our users,
which can't undermine the whole point of what we're trying to do.
But I didn't just drop it. Well, I tried.
The contributor, who originally made it, then suddenly appeared after disappearing for several years,
and went to the OpenSuser Board and made a big stank.
And even though the OpenSuser Board technically shouldn't be directing developers,
we were directed to keep it in the project.
So, we did.
But it was unmaintained.
We kind of hung around for years.
We steadily went along with the known side of things, doing an alpha and a beta.
And everybody scanned it a 12 KDE sort of, just stayed there where it is.
So, yes, talking about alpha's and beta's and stuff.
I realize it's a loaded terms.
So, when I come to using them, these are my nice helpful,
hopefully human understandable definitions of what I mean when I say an alpha.
You know, when the microS desktop was an alpha, it kind of worked.
It was mostly broken most of the time.
When I started calling it a beta, it was almost complete.
There was a few things I knew were missing,
and it mostly worked, but they could occasionally be issues.
And release candidates, which is where we are now.
You know, it's complete, at least,
complete as far as I believe it to be at that day,
because definitions changes that you're going to see.
But whatever it worked, it's reliable, but may have some rough edges.
So, release really is just a complete sort of,
it works, it's very, it's done.
So, the first release in microS desktop known land was,
well first, yeah, release candidate was early 2023.
Pretty good state of things.
You know, we had a very minimized no installation.
No RBM applications in the base of OS,
apart from software, stack, and terminal.
Everything being flat-packed from flat-up,
out of the box for GUI applications,
distra box being out of the box for command line applications,
desktop notifications for the background updates,
and whatever possible we started avoiding the need
for the shared microS installed.
So, whatever possible we'd have in no initial setup do the work
and try and kind of get ourselves away from being stuck in that workflow.
MicroS desktop at the time is, you know, for, and still is today.
But was it really an RC by my own definition?
Well, kind of, those rough edges were a bit rough,
than they should have made them maybe.
You know, we were still dependent on the patterns
and the policy kits and the system D presets and all that stuff.
Thank you very much.
So, we had a fair bit of croft in there.
You couldn't run every flat-packed properly, especially like steam,
because I see them as we get in the way and moan about it.
You know, you had to still have a separate route password.
Studio policy wasn't right, and all kit was constantly asking you
to enter the route password when you wanted to change a printer
and know which is fully annoying.
You couldn't actually turn off automatic reboots,
so, you know, you left your laptop running,
it would magically reboot in the middle of the night,
just like a microS server, which really was not fun.
Still couldn't distinguish between microS server and microS desktop,
which was hard for me when I wanted to put a patch or a fixed adjust.
One of them couldn't stop users from going into gas
to the open-suset installer and completely messing with the potitions
and making an installation that was completely nonsensical.
Couldn't stop them from trying to install KDE and gnome
and 20 other things at the same time,
and then wondering why they didn't work.
Yes, and we still had the sort of community confusion of,
you know, why aren't you supporting KDE more,
because none of us were working on it.
So I decided to kind of throw the baby out with the birth order
and the microS desktop project officially renamed in May 2023
to A1 as it's now good.
Partly an excuse just to have a nice reset
and a clearer definition of, you know, this is a gnome
only desktop only, you know,
we're doing this and just this and this is the name for that.
And if you want to do something else and take our code,
you can do whatever you want with our code,
but you know, call it something else, please.
We started addressing the technical deaths that we'd build up
with all of our previous choices
and pursuing the kind of freedoms we had about,
okay, this is a new thing and you start, you know,
what do we do if we kind of,
not starting from zero because we're still going to inherit
everything we had previously,
but we had not be tied to any previous decision we made.
And so we kind of retroactively now call
microS desktop as A1, but yeah,
we then started working on our C2.
And it took pretty much 366 days
before we did A on our C2,
where we have now a brand new installer
that we wrote from scratch,
using basically, it's a very fancy
Zenity wrapper around systemly rebut,
but, you know, it looks pretty.
It takes an image,
deployed to the disk,
it's wonderful, it's modular
because it's just a lot of bashing the installer really.
So you can add your own install steps
or repap the bits you don't want,
which obviously I was having a lot of pain with.
Complete support for ignition and combustion,
because we've talked, you know,
we're one of these affordable districts of nice having
a tool chain where stuff takes care of itself on first boot.
And it's a really nice party piece,
I wrote a module in tick,
which analyzes the operating system
it's about to annihilate when it images.
And if you happen to have a BTRFS home
subvolume on there, like we do on all of our districts,
then it copies that to the USB stick,
because I made the USB stick rewrite
and back up your Wi-Fi passwords,
and your SSH keys,
and everything that's remotely interesting,
and then,
you can see the image in them,
but, like now, again,
which is a nice factory reset,
that can be really quite extreme,
so I can totally change the layout on the disk
without stopping my life,
which is really quite nice.
In A on itself,
outside the installer,
we got rid of the root password,
we got the pseudo permissions all changed,
like Paul Keaton, Essie Linux, all tuned up,
all with tons of views
and help from the Caesar security team,
because the fact that we were doing this under a new name,
as a new thing, with a clear focus,
was suddenly all the things they were worried about,
like, it's a desktop,
but, okay, we get it, we're fine, do it,
it's like, hey, cool!
I mean, okay,
also, maybe we could package it separately too,
so you're not going to accidentally get those policies
on an open-suza installation,
it worked out really nice, actually.
We got rid of the automatic rebooting,
and yes,
like I said,
identifiable as A on,
not as much for us.
And then,
because feature creep is a thing,
we also took care of a whole bunch of stuff,
which we hadn't cared about a year before,
so,
using system D-boot as our bootloader,
tidying up the boot process,
so it's completely silent,
there's no flickering,
it just boots up,
doing Z-RAM by default,
and B-T-R-F-S compression by default,
turning off SSH,
being really fancy with X-864 B-3 libraries,
and also updating D-Tboot's automatic.
And life is good for a couple of months,
and one of the things we wanted at the time,
it took a little bit longer,
was doing for this description by default.
I talked more about this earlier today,
where now A on offers two separate modes.
One,
if your hardware is good enough,
TPM backed automatically and logging,
so,
yeah,
it just works pretty quite nice.
Make sure you're booting the system that you meant to be booting,
and then, actually,
means you can rely on stuff like your password,
in Linux to be secure,
because no one's accidentally booting you into a different shell.
Or,
if you have a really old laptop,
you get lugs for the passphrase,
yeah, just like every other district.
It worked really really well,
but that has basically been the rest of the store for 2024,
because the technical part was easy,
and then we realized there's lots of really different laptops out there,
with lots of really different UEFI,
and people mess around with different configurations.
So it's taken as a little bit of the rest of the year
to kind of bed that down,
change exactly which bits were measuring into the TPM,
and get it working,
but it's kind of,
it's actually,
it's really kind of there,
and ready now.
Oh, I thought it was getting FW update
to actually handle the fact that we used the system reboot,
because FW update was completely confused by the fact
we were a distro that didn't identify ourselves
as a distro in our own bootloader,
because we used system debugging.
So it got very confused about where to do firmware updates,
which,
yeah,
was a bit of a problem.
So will we ever actually release A on?
Yes,
but there's one thing that I've got left
that I've really mastered rest is,
you know,
it does work technically speaking,
but we can't prove that
because I haven't got ran to write in the open QA test yet.
So,
if you want to contribute anything to A on right now,
that's the number one burning issue.
As soon as we have open QA tests,
that we will throw into the open user pipeline for releases,
then I'll probably be able to say,
I'm released,
because we can prove then,
you know,
it's always working,
it's always building job done.
However,
that feature creep things still happening.
You know,
I mean,
the first time this list has already got even longer.
You know,
so meanwhile,
you know,
I'm almost certainly going to start using UKI's
for booting,
because literally all the problems I was
moaning about last week
have been fixed in conversations in the court
or this weekend.
This self-healing improvements.
I want to get rid of the TTY consoles,
because the booting flick of three,
but you do still like to see the TTY form
for a split second before GDM kicks in,
and I just want to get rid of that.
And,
ignases added a new feature into
transactional updates,
where we can deploy OCI images,
and I kind of just want to use that as another way
of reinstalling A on,
because it just seems like fun.
So,
but to be honest,
if we get the European QA testing first,
I'll probably just call it A on release,
and we can do all that stuff.
I don't really think any of that's blocking the final release.
So,
lessons learned.
I would say,
you know,
any project these days,
in this day,
and it really needs to be aware of,
like,
how well defined are your project goals?
This was the mistake we made
in the Minecraft desktop at first, right?
Like, a great idea.
Door wide open for anyone to contribute,
anything they want,
and then we literally end up spinning our wheels
for two to three years,
because other people dive in
and kind of start mangling with that scope of the project.
So,
you know,
know the scope of what you want to do,
what you're prepared to work on,
and,
or,
be prepared for,
like,
some way of redefining it,
or aesthetically,
if you really,
really have to.
It doesn't have to be so painful,
we did it.
Along with that lesson,
you know,
a one thing I really took away from this story,
is don't always listen to your community.
You know,
it's great to have lots of people
giving lots of really good ideas,
but the ideas are great,
the contributions,
matter more.
Yeah,
you know,
and if you've already got enough on your plates
to get what you want done,
focus on what you've already decided,
you don't always need to add everything.
All the time,
because otherwise,
you'll just spend all your time
coming,
and commenting all these cool new ideas,
like I've been doing,
it's a year five,
and I'm still in a release candidate stage.
You know,
this future creep thing is a blessing,
because my laptop's awesome,
and I'm really enjoying the OS on there,
but it's still not quite released yet.
So,
yeah,
just,
it's kind of,
keep worth keeping in mind at some point,
I guess you need to say no.
But also,
like,
there's no absolute tennis,
like we've gone from being really strict
to then constantly redefining it.
Yeah,
this district development stuff
is always a little bit nebulous and fun.
And I have shot through that perfectly time for five minutes.
So,
any questions,
open discussion?
I've got a couple of prompts.
There's one in the corner.
Perfect.
I think the guy that's responsible for that now,
where there's just some people,
and obviously there's some more.
Okay.
So,
so,
you're the guy who's responsible for
system D-booting.
So,
before I put in solid,
but it wasn't really complicated.
So, what was the question?
Could you just say it in the microphone?
I don't say it.
Sorry.
I said,
are you responsible for that system D-boot
works on obscenity?
There are almost just there.
There are more people than me
who have made that magical thing happen.
I'm one of the heavier consumers of their work.
Yeah.
But yeah,
because there's various,
depending on the scope of what you want with system D-boot,
in open-suser,
there's various different options.
You can have a very vanilla installation,
or you can have one with FD-boot-U-Tool,
where it does all the funky ploughing
with all of the open-suser B-T-R-Fest snapshots.
Yeah.
All that cool stuff.
Anyway,
I'm not a criminal.
If you want me to tell you about your talk,
it was great.
It was a lightning.
Thank you.
Some phrase.
Anyway.
Anything from anybody else?
Anyone have any thoughts on these topics?
Anyone think I'm completely wrong
when saying you should ignore your community?
No.
Yeah.
And that's part of it too, actually.
Someone just said,
depends on how many you're working on the project.
Yeah.
This started as a passion project.
Yeah.
Okay.
We have 300 people in the telegram group.
So we're not a tiny project anymore.
But yeah, it's still,
we have a still only a limited number of people working on this sort of stuff.
Well, okay.
And so, thank you very much.