WEBVTT

00:00.000 --> 00:14.000
I'm going to talk to you about system manager, I'm really interested to hear about this and

00:14.000 --> 00:16.000
I want to talk to you about this.

00:22.000 --> 00:25.000
Hi, so I'm Ramsis.

00:25.000 --> 00:29.000
The title of the talk is a niche in Nixon, almost any distro.

00:29.000 --> 00:31.000
That's a very...

00:31.000 --> 00:33.000
Yeah, we'll see.

00:33.000 --> 00:38.000
We're not very young, but that's the goal that we would eventually like to reach.

00:38.000 --> 00:43.000
So who am I? Ramsis, RVDP, most places online.

00:43.000 --> 00:48.000
In this and past, I used to be a theoretical high energy physicist,

00:48.000 --> 00:53.000
but then I kind of figured out that's not really much of a job market for that.

00:53.000 --> 00:59.000
So I went going to IT, worked as a fertilizer, like a full-steck Java scholar, developer.

00:59.000 --> 01:07.000
Then I took a bit of a detour and worked as a tech lead security engineer for international NGO.

01:07.000 --> 01:12.000
After that, I went back to more hardcore engineering,

01:12.000 --> 01:15.000
and I became like an independent software engineer.

01:15.000 --> 01:21.000
I'm currently working mainly with a lot of mixed related consulting.

01:21.000 --> 01:27.000
I've been using Nixon's maybe 2017, so quite a while.

01:27.000 --> 01:32.000
And in general, I just love working on all kinds of open source projects.

01:32.000 --> 01:35.000
I think it's just really rewarding.

01:36.000 --> 01:40.000
Yeah, you can find me on Matrix.

01:40.000 --> 01:44.000
So I'm just going to quickly introduce system manager,

01:44.000 --> 01:49.000
project that I've been working on a little bit, started maybe a year ago.

01:49.000 --> 01:52.000
So that's a problem that we're trying to solve.

01:52.000 --> 01:53.000
What did we come up with?

01:53.000 --> 01:58.000
What are the hopefully current limitations and what's next?

01:58.000 --> 02:03.000
So the problem we all know next was we love it, it's great.

02:03.000 --> 02:06.000
But the problem is it's kind of all or nothing solution.

02:06.000 --> 02:10.000
So if you want to use Nixon's, you kind of have to do everything with Nixon's.

02:10.000 --> 02:12.000
Your whole system is running the distro.

02:12.000 --> 02:15.000
And you kind of have to immediately dive into the deep ends,

02:15.000 --> 02:19.000
like just no way to like start with another distro,

02:19.000 --> 02:24.000
and kind of start using Nixon without needing the whole package.

02:24.000 --> 02:29.000
There is a whole manager that's usually done the next best thing,

02:29.000 --> 02:31.000
which you can use on a distro,

02:31.000 --> 02:33.000
because you can manage your home profiles and such,

02:33.000 --> 02:35.000
but you cannot do anything on the system level.

02:35.000 --> 02:39.000
So you cannot manage system level, system g services,

02:39.000 --> 02:41.000
and these kind of things.

02:41.000 --> 02:44.000
And that's kind of what we try to solve.

02:44.000 --> 02:49.000
So can we have next manage system level configuration,

02:49.000 --> 02:56.000
but not necessarily have it managed the whole system?

02:56.000 --> 02:59.000
There's a couple of potential solutions that you can think of.

02:59.000 --> 03:01.000
One of them is system depotable services.

03:01.000 --> 03:04.000
It's something that system the introduced,

03:04.000 --> 03:06.000
I think now a couple of years ago.

03:06.000 --> 03:09.000
The idea there is that you take one or multiple services.

03:09.000 --> 03:11.000
You package it up into a kind of image.

03:11.000 --> 03:13.000
You can send it on another machine,

03:13.000 --> 03:16.000
and you can kind of have system restart those services.

03:16.000 --> 03:18.000
That's one thing that works,

03:18.000 --> 03:21.000
but it was not really ideal.

03:21.000 --> 03:23.000
There's also Nixon's containers,

03:23.000 --> 03:25.000
that I haven't really looked into it too deep,

03:25.000 --> 03:28.000
but I heard that some people do similar things

03:28.000 --> 03:31.000
as what we're trying to achieve using Nixon's containers,

03:31.000 --> 03:34.000
unlike other distros.

03:34.000 --> 03:37.000
I'm not exactly sure how they do it.

03:37.000 --> 03:39.000
In the end, just system the end spawn.

03:39.000 --> 03:43.000
So I guess I take kind of wrap up the directory and then move it to another system,

03:43.000 --> 03:47.000
and run system the end spawn directly.

03:47.000 --> 03:51.000
The other option is to kind of do what home energy it did,

03:51.000 --> 03:55.000
and you write like a custom switch to configuration,

03:55.000 --> 03:58.000
that takes some kind of top level directory,

03:58.000 --> 04:01.000
that links to all the things that you want,

04:01.000 --> 04:03.000
and you put that in place.

04:03.000 --> 04:05.000
So that's what we want with.

04:05.000 --> 04:07.000
It's like the most straightforward option

04:07.000 --> 04:10.000
and we have kind of knowledge of how it works.

04:10.000 --> 04:13.000
The advantage is so it's a well understood system.

04:13.000 --> 04:16.000
We've been there, we do it on Nixon's,

04:16.000 --> 04:17.000
we do it with home energy,

04:17.000 --> 04:20.000
so we kind of understand the trade-offs.

04:20.000 --> 04:24.000
Also we get native system B services,

04:24.000 --> 04:29.000
so the idea that we will actually populate ETC with a bunch of sim links,

04:29.000 --> 04:33.000
and then you just run like you use the host system

04:33.000 --> 04:35.000
to run those services.

04:35.000 --> 04:38.000
So we don't have containers, we don't have images,

04:38.000 --> 04:40.000
we don't have not working stuff.

04:40.000 --> 04:43.000
We don't have to deal with any of that thing,

04:43.000 --> 04:46.000
of those things that can be the complicated stuff.

04:46.000 --> 04:49.000
And it turns out it's actually a very small number of

04:49.000 --> 04:52.000
fundamental operations that you have to support

04:52.000 --> 04:55.000
for Nixon's style modules to work.

04:55.000 --> 04:58.000
So mainly you need to be able to create fast and ETC.

04:58.000 --> 05:02.000
You need some way to run system the temp files,

05:02.000 --> 05:06.000
since all of stuff depends on that to put stuff in place.

05:06.000 --> 05:09.000
And you need to have some kind of reconciliation loop

05:09.000 --> 05:11.000
to look at the current system,

05:11.000 --> 05:14.000
the state look at what changed,

05:14.000 --> 05:17.000
and what you have to do like start,

05:17.000 --> 05:19.000
start restart, reload, services,

05:19.000 --> 05:23.000
start, that timer, sockets, these kind of things.

05:23.000 --> 05:26.000
Some things are missing in what we have right now.

05:26.000 --> 05:29.000
Some notable things are uses and groups,

05:29.000 --> 05:32.000
mainly because I couldn't really figure out

05:32.000 --> 05:35.000
yet a way to do that without, like,

05:35.000 --> 05:37.000
crashing too much with embedding disorder,

05:37.000 --> 05:40.000
or working on things like file systems,

05:40.000 --> 05:41.000
probably never going to work,

05:41.000 --> 05:43.000
because there are some things that are just,

05:43.000 --> 05:46.000
yeah, you cannot kind of co-exist and manage it from two sites.

05:47.000 --> 05:50.000
Same with not working, maybe there's a way,

05:50.000 --> 05:52.000
but we didn't really invest in that yet.

05:52.000 --> 05:54.000
Also things like global system D settings,

05:54.000 --> 05:57.000
so you have, like, your ETC system,

05:57.000 --> 06:00.000
the system.conf style of things.

06:00.000 --> 06:03.000
Also there are the main question is,

06:03.000 --> 06:05.000
how are you going to deal with embedding

06:05.000 --> 06:06.000
destroy doing something,

06:06.000 --> 06:07.000
you want to do something,

06:07.000 --> 06:11.000
it's not really a clear way of how to combine that.

06:11.000 --> 06:13.000
At some point you have to make, like,

06:14.000 --> 06:18.000
a limit to the things that we are willing to manage.

06:18.000 --> 06:21.000
The disadvantages of this approach,

06:21.000 --> 06:25.000
we actually need to write that custom switch to configuration thing.

06:25.000 --> 06:28.000
We need to write it, we need to maintain it,

06:28.000 --> 06:31.000
so that's a bit of work.

06:31.000 --> 06:35.000
We would like to be able to reuse as much as possible,

06:35.000 --> 06:37.000
existing mix of modules.

06:37.000 --> 06:40.000
But when you try that, it turns out that they actually have

06:40.000 --> 06:43.000
a lot of interdependencies between each other,

06:43.000 --> 06:45.000
because, like, we didn't mix packages.

06:45.000 --> 06:46.000
They all live in the same manner,

06:46.000 --> 06:50.000
and so they're kind of free to depend on a lot of stuff from each other.

06:50.000 --> 06:55.000
So just taking a couple of them out is actually not easy at all.

06:55.000 --> 06:58.000
And a lot of them are also just written for a mix of us,

06:58.000 --> 07:01.000
and were only intended to have a work on mix of us.

07:01.000 --> 07:03.000
So as soon as you take them out,

07:03.000 --> 07:07.000
you notice there's a lot of hidden assumptions in these modules.

07:07.000 --> 07:12.000
So that turned out to be actually not that easy.

07:12.000 --> 07:15.000
Especially coupled with the fact that there's things that we cannot support,

07:15.000 --> 07:18.000
like users and such.

07:18.000 --> 07:20.000
And we also with this approach,

07:20.000 --> 07:21.000
we have to be really careful,

07:21.000 --> 07:23.000
but because we're literally sharing this space with you and

07:23.000 --> 07:25.000
but in this row, so you have to be a bit careful

07:25.000 --> 07:28.000
that you don't screw things up by starting to override stuff

07:28.000 --> 07:30.000
that and but in this row is actually managing.

07:30.000 --> 07:32.000
So that's a bit tricky.

07:32.000 --> 07:34.000
We try to be very conservative in this,

07:34.000 --> 07:38.000
so that if you kind of deactivate your system manager config,

07:38.000 --> 07:42.000
ideally you should be back where you started off.

07:42.000 --> 07:45.000
If it doesn't work, it's basically a work.

07:45.000 --> 07:49.000
So what does it do currently?

07:49.000 --> 07:53.000
So one thing is you need to have mix available,

07:53.000 --> 07:58.000
which may or may not be an easy thing depending on your current set up,

07:58.000 --> 08:01.000
but that's not something that we as the system manager provide.

08:01.000 --> 08:05.000
So that's kind of the prerequisite.

08:05.000 --> 08:07.000
Apparently it has to be running in demon mode,

08:07.000 --> 08:10.000
where a couple of people that try to using it in single user mode,

08:10.000 --> 08:11.000
apparently that they don't work.

08:11.000 --> 08:15.000
I didn't really investigate much further.

08:15.000 --> 08:18.000
There might be weird things if you're running in single user mode.

08:18.000 --> 08:22.000
If you have mix available, then you can just mix from the binary,

08:22.000 --> 08:26.000
pass it off like a system manager config,

08:26.000 --> 08:29.000
and that should be it.

08:30.000 --> 08:33.000
If you do that, what do you get?

08:33.000 --> 08:36.000
So we run system V10 files,

08:36.000 --> 08:40.000
scripted only the time file rules that were defined by system manager,

08:40.000 --> 08:42.000
because of course them, but in this row can also have

08:42.000 --> 08:46.000
time file rules that you don't necessarily want to re-evaluate.

08:46.000 --> 08:49.000
We create a run system manager,

08:49.000 --> 08:53.000
as well you follow pretty much like mix was this,

08:53.000 --> 08:56.000
containing all the installed packages.

08:56.000 --> 08:59.000
We create a drop-in in ETC profile,

08:59.000 --> 09:01.000
that will populate your path,

09:01.000 --> 09:05.000
so that actually the packages that are in run system manager software,

09:05.000 --> 09:07.000
you can actually run them on the shell,

09:07.000 --> 09:10.000
if you just refresh your session.

09:10.000 --> 09:14.000
We create a system manager target that gets pulled in by the default target,

09:14.000 --> 09:17.000
so whatever them, but in this rows default target,

09:17.000 --> 09:20.000
that one will pull in the system manager target,

09:20.000 --> 09:23.000
so that then we can have a bunch of system manager,

09:23.000 --> 09:25.000
merge services that sit on the meat there.

09:25.000 --> 09:27.000
So basically you're expected to have

09:27.000 --> 09:29.000
every service that you want to run

09:29.000 --> 09:33.000
a dependent system manager to target.

09:33.000 --> 09:36.000
And then we register a profile and

09:36.000 --> 09:39.000
an ETC route just so that mix doesn't delete your stuff

09:39.000 --> 09:43.000
from underneath you while you're running.

09:43.000 --> 09:46.000
So it's pretty close to what you would expect

09:46.000 --> 09:48.000
from such a system.

09:48.000 --> 09:51.000
It should be if you're used to mix

09:51.000 --> 09:55.000
or home manager, this should sound like pretty standard.

09:55.000 --> 09:59.000
This is not really any surprises there.

09:59.000 --> 10:02.000
So what you found up with under-actual system,

10:02.000 --> 10:04.000
you will have an EXTOR.

10:04.000 --> 10:06.000
That was already there when EXTOR installed,

10:06.000 --> 10:08.000
but so you will have a bunch of stuff

10:08.000 --> 10:11.000
in that EXTOR that you built for you.

10:11.000 --> 10:14.000
You will end up with a bunch of siblings in ETC,

10:14.000 --> 10:19.000
very similar to what you would expect in EXTORs.

10:20.000 --> 10:22.000
You will have your system B services,

10:22.000 --> 10:25.000
that will also just be siblings.

10:25.000 --> 10:30.000
You will get the mix kind of static linking

10:30.000 --> 10:33.000
as I like to call it in the services.

10:33.000 --> 10:37.000
So all stuff can refer to each other.

10:37.000 --> 10:40.000
And you kind of get the thing that we like on EXTORs

10:40.000 --> 10:42.000
where stuff doesn't just break,

10:42.000 --> 10:44.000
because as far as I move the rounder,

10:44.000 --> 10:45.000
search with everything,

10:45.000 --> 10:47.000
it's kind of like statically assembled through all the

10:47.000 --> 10:50.000
singleings in your next door.

10:50.000 --> 10:53.000
And most importantly, one writing your config,

10:53.000 --> 10:55.000
you can use a normal mix into relation

10:55.000 --> 10:58.000
to just template all this stuff.

10:58.000 --> 11:02.000
And you get a bunch of packages in path.

11:02.000 --> 11:04.000
So all of these events should feel really familiar

11:04.000 --> 11:06.000
if you used to mix with us,

11:06.000 --> 11:08.000
because it's basically what we get on EXTORs.

11:08.000 --> 11:09.000
So we need to go to this,

11:09.000 --> 11:11.000
like if you know how mix us works,

11:11.000 --> 11:14.000
you should be getting more as the same thing

11:14.000 --> 11:18.000
within the constraints that we discussed earlier.

11:18.000 --> 11:21.000
Can we use this today?

11:21.000 --> 11:26.000
Yes, but it's a little bit of a working progress.

11:26.000 --> 11:28.000
So it's, yeah,

11:28.000 --> 11:31.000
we got it to work for the things that like

11:31.000 --> 11:35.000
I wanted to use it for can be a working on this.

11:35.000 --> 11:39.000
Basically anything that I didn't need

11:39.000 --> 11:41.000
is pretty much not there.

11:41.000 --> 11:43.000
There's no lot of documentation.

11:43.000 --> 11:46.000
So that's something that we need to improve on.

11:46.000 --> 11:48.000
And then the main theme for this,

11:48.000 --> 11:50.000
we need more modules.

11:50.000 --> 11:54.000
Which is kind of a chicken and acting.

11:54.000 --> 11:57.000
Like ideally, we have people that want to use it

11:57.000 --> 11:59.000
and that put over modules.

11:59.000 --> 12:01.000
We try to have a bit of a compatibility layer

12:01.000 --> 12:02.000
with mixed packages.

12:02.000 --> 12:05.000
So we try to make it such that you can,

12:05.000 --> 12:07.000
in large, take an mixed-packed,

12:07.000 --> 12:08.000
just module,

12:09.000 --> 12:12.000
copy it into your, your flake or whatever.

12:12.000 --> 12:14.000
And have it work.

12:14.000 --> 12:15.000
That sometimes works.

12:15.000 --> 12:17.000
Sometimes it doesn't.

12:17.000 --> 12:18.000
If it doesn't,

12:18.000 --> 12:20.000
you can open a back report.

12:20.000 --> 12:22.000
We can see maybe we should add some extra things

12:22.000 --> 12:24.000
to the compatibility layer.

12:24.000 --> 12:26.000
Maybe we just have to rewrite the module

12:26.000 --> 12:28.000
because it assumes the way the one thing is in the

12:28.000 --> 12:29.000
packages.

12:29.000 --> 12:32.000
I think what would be really cool

12:32.000 --> 12:34.000
is if this kind of,

12:34.000 --> 12:37.000
if many people like this idea,

12:37.000 --> 12:40.000
maybe there's a way to work with mixed packages

12:40.000 --> 12:41.000
upstream and see like,

12:41.000 --> 12:43.000
can we,

12:43.000 --> 12:46.000
can we see if modules need to be

12:46.000 --> 12:48.000
so mixed packages specific or not.

12:48.000 --> 12:50.000
We can also go to home manager

12:50.000 --> 12:52.000
route where they basically,

12:52.000 --> 12:53.000
they have their own set of modules

12:53.000 --> 12:55.000
completely independent.

12:55.000 --> 12:56.000
But of course, it's a lot of maintenance.

12:56.000 --> 12:58.000
So that would require quite a lot of people

12:58.000 --> 13:02.000
to spend time on maintaining these modules.

13:02.000 --> 13:04.000
Better works.

13:04.000 --> 13:07.000
So if you just write the module for it,

13:07.000 --> 13:09.000
it works.

13:09.000 --> 13:12.000
There's a couple of potential improvements

13:12.000 --> 13:13.000
that I see.

13:13.000 --> 13:15.000
One thing that wasn't around yet when we started this is

13:15.000 --> 13:18.000
the whole ETC overlay thing that was introduced

13:18.000 --> 13:19.000
in the packages,

13:19.000 --> 13:20.000
which is really cool.

13:20.000 --> 13:22.000
If you're not familiar with it,

13:22.000 --> 13:23.000
check it out.

13:23.000 --> 13:24.000
It's really nice.

13:24.000 --> 13:26.000
So the idea is that instead of like,

13:26.000 --> 13:28.000
kind of incredibly creating

13:28.000 --> 13:31.000
whole bunch of siblings in ETC,

13:31.000 --> 13:33.000
you create like a,

13:33.000 --> 13:35.000
an immutable far system image,

13:35.000 --> 13:37.000
like an ERAVS image.

13:37.000 --> 13:39.000
And then you create an overlay of that

13:39.000 --> 13:42.000
and like a mutable part of your ETC.

13:42.000 --> 13:44.000
And that's the real ETC that you see.

13:44.000 --> 13:46.000
One idea that I had,

13:46.000 --> 13:47.000
but I've not played with the ETC,

13:47.000 --> 13:49.000
is that we could do the same on like,

13:49.000 --> 13:50.000
this kind of,

13:50.000 --> 13:51.000
but in this struggle,

13:51.000 --> 13:52.000
we kind of mount,

13:52.000 --> 13:54.000
like we make an overlay of us

13:54.000 --> 13:55.000
of the actual,

13:55.000 --> 13:57.000
the real ETC,

13:57.000 --> 13:58.000
unlike the,

13:58.000 --> 14:00.000
our static image underneath.

14:01.000 --> 14:03.000
And then we kind of like the,

14:03.000 --> 14:04.000
embedding this row ETC

14:04.000 --> 14:06.000
remains like the mutable layer on top

14:06.000 --> 14:09.000
and we just like put all stuff underneath.

14:09.000 --> 14:11.000
Which could be a pretty nice way to,

14:11.000 --> 14:12.000
not like,

14:12.000 --> 14:14.000
clash too much with a distro.

14:14.000 --> 14:15.000
If they already have a file

14:15.000 --> 14:16.000
that we are supervision,

14:16.000 --> 14:17.000
basically we'll see theirs.

14:17.000 --> 14:19.000
And so if you don't see the file

14:19.000 --> 14:20.000
that you're expecting,

14:20.000 --> 14:22.000
it basically means you're clashing

14:22.000 --> 14:23.000
with the embedding distro,

14:23.000 --> 14:26.000
which may be a pretty nice,

14:26.000 --> 14:28.000
like way to degrade.

14:29.000 --> 14:31.000
You've as groups is something

14:31.000 --> 14:33.000
that I think have already several issues

14:33.000 --> 14:35.000
have been opened for that.

14:35.000 --> 14:37.000
Yeah,

14:37.000 --> 14:38.000
I think it,

14:38.000 --> 14:40.000
we have to look into what's possible.

14:40.000 --> 14:41.000
I'm not sure if it's even like,

14:41.000 --> 14:42.000
theoretically possible.

14:42.000 --> 14:43.000
Can we do this without like,

14:43.000 --> 14:44.000
completely messing up here

14:44.000 --> 14:45.000
or embedding distro?

14:45.000 --> 14:47.000
I'm not sure,

14:47.000 --> 14:48.000
maybe.

14:48.000 --> 14:49.000
And then as I said,

14:49.000 --> 14:51.000
figure out how to reuse

14:51.000 --> 14:52.000
more just from mixed packages,

14:52.000 --> 14:53.000
much as possible.

14:53.000 --> 14:54.000
Just to like,

14:54.000 --> 14:55.000
reduce the amount of wood

14:55.000 --> 14:56.000
that's required to,

14:57.000 --> 14:59.000
to boot shop a project like this.

15:01.000 --> 15:03.000
One thing also that we,

15:03.000 --> 15:04.000
that's interesting that we worked on,

15:04.000 --> 15:06.000
is how do we test this?

15:06.000 --> 15:07.000
Because in mixed packages,

15:07.000 --> 15:10.000
we have of course the whole VM testing framework,

15:10.000 --> 15:12.000
which is really amazing

15:12.000 --> 15:13.000
and really enjoyed the work with

15:13.000 --> 15:15.000
if you want to test these kind of things.

15:15.000 --> 15:17.000
So what I kind of wanted is

15:17.000 --> 15:19.000
be able to reuse that

15:19.000 --> 15:21.000
but on different distros.

15:21.000 --> 15:23.000
Turns out,

15:23.000 --> 15:25.000
it's actually not that hard at all.

15:26.000 --> 15:28.000
So I worked on,

15:28.000 --> 15:30.000
kind of taking the task driver

15:30.000 --> 15:32.000
and then just instead of a mixed image,

15:32.000 --> 15:33.000
you take,

15:33.000 --> 15:34.000
you've been to cloud image,

15:34.000 --> 15:35.000
you take a fedora image,

15:35.000 --> 15:36.000
that being image,

15:36.000 --> 15:38.000
whatever you boot it up

15:38.000 --> 15:40.000
and you get exactly the same test

15:40.000 --> 15:41.000
instrumentation.

15:41.000 --> 15:43.000
And actually that works pretty well.

15:43.000 --> 15:48.000
And so this is one example.

15:48.000 --> 15:49.000
It's very pretty small,

15:49.000 --> 15:51.000
but you see the normal,

15:51.000 --> 15:53.000
all put that you would expect from mixed stress,

15:53.000 --> 15:54.000
even though it's actually booting,

15:54.000 --> 15:55.000
you're going to kernel.

15:55.000 --> 15:57.000
So this is like you're going to cloud image

15:57.000 --> 16:00.000
that you just load with the same test driver.

16:00.000 --> 16:03.000
And because we really like this so much,

16:03.000 --> 16:06.000
we don't pull it out into a separate project

16:06.000 --> 16:08.000
called mixed VM test.

16:08.000 --> 16:12.000
Many PICMA Felix work a lot on there.

16:12.000 --> 16:14.000
So this is a separate project

16:14.000 --> 16:17.000
that came out of system manager,

16:17.000 --> 16:19.000
but it's very interesting that you can also use for all the things.

16:19.000 --> 16:22.000
So if you work a lot with different distributions,

16:22.000 --> 16:25.000
and you like the mixed packages testing framework,

16:25.000 --> 16:26.000
this is really cool.

16:26.000 --> 16:29.000
I think now we have Ubuntu fedora,

16:29.000 --> 16:32.000
and there will be only if I'm not mistaken,

16:32.000 --> 16:36.000
but it's really not at all too at different distros.

16:36.000 --> 16:39.000
And that if you're on a different distro,

16:39.000 --> 16:40.000
make a pull request,

16:40.000 --> 16:43.000
we would be very happy to merge it.

16:43.000 --> 16:46.000
Yeah, if you want to try it out,

16:46.000 --> 16:50.000
numtide system manager is there.

16:51.000 --> 16:52.000
Yeah, that's it. Thank you.

17:00.000 --> 17:01.000
Thank you very much.

17:01.000 --> 17:03.000
This was a great talk.

17:03.000 --> 17:04.000
Really interesting.

17:04.000 --> 17:07.000
I'm going to have to check out those projects.

17:07.000 --> 17:12.000
We have more time available for Q&A now.

17:12.000 --> 17:15.000
So are there any questions in the audience?

17:15.000 --> 17:17.000
And please repeat the question, right?

17:17.000 --> 17:19.000
Yeah.

17:19.000 --> 17:22.000
Will you work with, let's say,

17:22.000 --> 17:25.000
the read on the Prec system distribution like fedora,

17:25.000 --> 17:28.000
she's a group, or is it like that?

17:28.000 --> 17:30.000
Please repeat the question.

17:30.000 --> 17:32.000
Yeah, the question is whether we do work with,

17:32.000 --> 17:35.000
like a read-only distribution like fedora silver blue.

17:35.000 --> 17:38.000
I never worked with,

17:38.000 --> 17:41.000
it's a little blue actually, so I don't know.

17:41.000 --> 17:43.000
We assume that we can write,

17:43.000 --> 17:45.000
but I think on this, this was probably,

17:45.000 --> 17:48.000
I also write it just not persisted, right?

17:48.000 --> 17:50.000
I think it was probably,

17:50.000 --> 17:54.000
you will have to bake some parts into the original image.

17:54.000 --> 17:57.000
Or you would have to have some way to at least

17:57.000 --> 18:01.000
run like your system manager activate every time you boot.

18:01.000 --> 18:04.000
But besides that, as long as you can actually still write

18:04.000 --> 18:07.000
even in non-presistent,

18:07.000 --> 18:10.000
it's kind of over-nade, that's what persistors such.

18:10.000 --> 18:14.000
I would expect that you could get it to work, yes?

18:14.000 --> 18:18.000
Do you use a work around,

18:18.000 --> 18:21.000
do we add users or services?

18:21.000 --> 18:23.000
No, they have to be there.

18:23.000 --> 18:27.000
Yeah, the question is whether we use any workaround for use the groups,

18:27.000 --> 18:29.000
basically we'll have to provision them in the,

18:29.000 --> 18:31.000
abiding this draw.

18:31.000 --> 18:34.000
And yeah, the whole issue is that you have only one,

18:34.000 --> 18:37.000
like ETC password or ETC group,

18:37.000 --> 18:40.000
so it's hard if two sources are writing in it at the same time.

18:40.000 --> 18:43.000
Maybe we could, I'm not super familiar,

18:43.000 --> 18:45.000
but I know that on modern systems,

18:45.000 --> 18:49.000
that's actually not the real source of truth for users and groups,

18:49.000 --> 18:51.000
and it's kind of, I think,

18:51.000 --> 18:53.000
some kind of other database behind

18:53.000 --> 18:56.000
that also system behaviors for this kind of dynamic users,

18:56.000 --> 18:57.000
stuff and such.

18:57.000 --> 19:01.000
So maybe there's a way there to kind of interact with that,

19:01.000 --> 19:04.000
and not actually persist anything on the file system,

19:04.000 --> 19:06.000
but I've not looked at it in detail,

19:06.000 --> 19:09.000
but I think there might be ways to improve the situation,

19:09.000 --> 19:12.000
but probably we just do nothing for them.

19:12.000 --> 19:13.000
Okay.

19:13.000 --> 19:19.000
Is Josh Lee here who's going to be giving you a talk after the next one?

19:19.000 --> 19:22.000
Josh Lee?

19:22.000 --> 19:25.000
Okay, I'm not seeing anyone.

19:25.000 --> 19:27.000
Oh, I have a question.

19:27.000 --> 19:28.000
You have a question?

19:28.000 --> 19:30.000
All right, there's time for more questions.

19:30.000 --> 19:34.000
And how do you, or how could you combine this with remote deployment?

19:34.000 --> 19:38.000
How would I combine this with remote deployment?

19:38.000 --> 19:47.000
Well, basically, you just have to copy closure over the store path, right?

19:47.000 --> 19:51.000
So we don't have anything written up for that,

19:51.000 --> 19:54.000
but I think it's only a couple of lines of bash if you want to do that.

19:54.000 --> 19:58.000
You basically, so it would be the same way as other needs.

19:58.000 --> 20:00.000
Yeah, because you have a particular closure in the closure,

20:00.000 --> 20:03.000
you will have a deactivation script.

20:03.000 --> 20:05.000
So basically, you can copy over the closure,

20:05.000 --> 20:08.000
if you want the right script, and it will do everything.

20:08.000 --> 20:11.000
So I think it's not really two commands.

20:11.000 --> 20:14.000
All right, we have time for another question.

20:14.000 --> 20:17.000
Have you actually tested using system manager on NICS?

20:17.000 --> 20:20.000
Or have some, you know, how would you then try to see it?

20:20.000 --> 20:24.000
So the question is if I tried using system manager on NICSOS?

20:24.000 --> 20:26.000
Yes, I did, because actually I only used NICSOS,

20:26.000 --> 20:32.000
so when I was developing this, I actually run on NICSOS.

20:32.000 --> 20:37.000
So it's funny, and you have to be, yeah, there's a lot of, like, footprints.

20:37.000 --> 20:40.000
But you can, yeah.

20:40.000 --> 20:44.000
As long as you know, actually it's pretty much the same constraint as another destroyer.

20:44.000 --> 20:46.000
You just don't want to ride the same thing as the already there,

20:46.000 --> 20:50.000
and also we kind of cross deactivation if you try to do that.

20:50.000 --> 20:55.000
So you can ride just new services into your ETC that also linked to the NICSOS,

20:55.000 --> 20:57.000
and not much fun is going to happen.

20:58.000 --> 21:03.000
You're going to get, like, next to your current system software.

21:03.000 --> 21:06.000
You're going to get, like, a system manager software on the run,

21:06.000 --> 21:09.000
and both will be added to the path, which is also fine.

21:09.000 --> 21:13.000
So there's not that many surprises, yeah.

21:13.000 --> 21:15.000
I'm actually works.

21:15.000 --> 21:20.000
But I don't think it's pretty useful besides testing, basically.

21:20.000 --> 21:22.000
I have a quick follow-up to that.

21:22.000 --> 21:26.000
Can you basically reuse the same service definition for NICSOS and your system?

21:27.000 --> 21:30.000
So can you reuse the same system services?

21:30.000 --> 21:34.000
Yes, we have exactly the same NICS code,

21:34.000 --> 21:36.000
like, to define the system resources.

21:36.000 --> 21:37.000
Yeah.

21:37.000 --> 21:38.000
Thank you very much.

21:38.000 --> 21:39.000
Last question.

21:39.000 --> 21:40.000
Okay.

21:40.000 --> 21:41.000
You know that.

21:41.000 --> 21:44.000
I think the chances of that extending to the NICS started right now.

21:44.000 --> 21:45.000
Sorry.

21:45.000 --> 21:46.000
Can we get?

21:46.000 --> 21:49.000
I think that, again, to the experiment, the half services.

21:49.000 --> 21:53.000
Oh, so what do we can extend this to NICS Darwin?

21:54.000 --> 22:00.000
Oh, I think I've never run Darwin, so I'm not super familiar,

22:00.000 --> 22:04.000
but I think NICS Darwin is already more or less this.

22:04.000 --> 22:05.000
No.

22:05.000 --> 22:08.000
Like, yeah, it's older than the last two,

22:08.000 --> 22:11.000
great, like, background services and so on.

22:11.000 --> 22:12.000
Yeah.

22:12.000 --> 22:13.000
Thank you.

22:17.000 --> 22:20.000
Yeah, I think the implementation of how you create a service

22:20.000 --> 22:23.000
and such a sport is probably quite different, because then I think it

22:23.000 --> 22:28.000
beyond the use of the launch, these stuff and such.

22:28.000 --> 22:29.000
I think, like, I would.

22:29.000 --> 22:32.000
You can really service definitions.

22:32.000 --> 22:35.000
Yeah, except I probably don't have the same sort of option that they

22:35.000 --> 22:36.000
supports.

22:36.000 --> 22:41.000
My gut feeling is that NICS Darwin is basically this on Darwin,

22:41.000 --> 22:45.000
but I'm very Darwin specific where this is really focused on Linux.

22:45.000 --> 22:49.000
I'm not sure how much is in the intersection of, like, how much can we actually

22:49.000 --> 22:50.000
utilize between the two?

22:50.000 --> 22:53.000
I'm not familiar with NICS Darwin to be able to say.

22:53.000 --> 22:57.000
Maybe there's a way to neutralize certain parts.

22:57.000 --> 22:58.000
Yeah.

22:58.000 --> 23:01.000
I think we have to conclude the Q&A at this point, please.

23:01.000 --> 23:03.000
Another round of applause for NICS Darwin.