Hi all,
I'm Sebastian and I'm new in distri.
A customer of mine has a big problem with patching and maintaining their
environment.
Because they have few SysAdmin and had to maintain more than 1000 host with
complex softwares and dependencies.
now, this would be much better if software were immutable (we config the
software just one time than build imagines and than patch all the
environment) and, more important, kernel patch doesn't need reboot to take
effect.
Now, just wondering: could it be possible realize it with distri?
that's would be a great feature.
Thanks.
Il giorno sab 24 ago 2019 alle ore 21:08 Michael Stapelberg <
michael+distri@xxxxxxxxxxxxx> ha scritto:
Thanks for the thoughtful questions, answers inline:
On Sat, Aug 24, 2019 at 8:25 PM Jose Miguel Parrella <
joseparrella@xxxxxxxxx> wrote:
Tangentially on the topic of images...
On a freshly booted distri system, there are 175 packages in /ro. I
notice that a few packages are loaded after the system is open for
interactive use. For example, shadow, git, etc., all start "mounting" as
they're first accessed. Running a find or a du -chs in /ro triggers
mounting for all the packages. It doesn't seem to be actual mounting as
mount doesn't yield any changes.
Yeah, the term mount is just used to convey what the fuse daemon is doing
conceptually here, no kernel mounts are involved.
I started tracking it down to here [1] but I got a bit lost - what is
this behavior? What is actually being "lazy loaded" here, and what's the
benefit? Is it maybe that the distri FUSE knows all packages need to be
there, but the squashfs haven't been loaded and exposed in the FUSE until
the files are accessed? I do see a significant increase in memory usage
before/after doing a find in /ro on a fresh system.
Yes, you’re spot on: the squashfs images are not even opened until they
are required. Lazy loading avoids unnecessary work (perhaps you never
access files in the kicad image until your next boot) and, as you noticed,
keeps memory usage proportional to the working set, not all installed
packages.
...and coming back to the topic of "images", I find it confusing at times
with other distros to differentiate when we're talking about the "product
image" (USB, ISO, VDI, etc.), the "package image" (AppImage, Snap, etc.) or
the "instance/system image" (as in ostree/Silverblue)
Is it correct to say that in distri: distri-disk.img or similar is the
product image/artifact, the squashfs are the package images, /roimg is the
"system image" as represented on disk and /ro is the running system (even
if immutable)? Looks like /roimg is what docs [2] call the "store"
Yes, that seems correct to me. Definitely the first two (product image and
package image). I’m not too familiar with ostree/silverblue, so I’m not too
sure about what the term “system image” entails.
What I'm trying to wrap my head around is how distri is upgraded. (BTW, I
really like how ostree talks about many "competing" approaches to this. [3])
In a nutshell: “distri update” is roughly equivalent to: ls
/roimg/*.squashfs, strip versions, install all these packages. This makes
the new versions available. To clean up no longer needed packages, use
“distri gc”.
[1]
https://github.com/distr1/distri/blob/b65d2791e0195a49862a3ccdbbfd6b3a24715582/cmd/distri/internal/fuse/fuse.go#L785
[2]
https://github.com/distr1/distri/blob/b65d2791e0195a49862a3ccdbbfd6b3a24715582/cmd/distri/pack.go#L272
[3]
https://ostree.readthedocs.io/en/latest/manual/related-projects/#related-projects
________________________________________
From: distri-bounce@xxxxxxxxxxxxx <distri-bounce@xxxxxxxxxxxxx> on
behalf of Michael Stapelberg <michael+distri@xxxxxxxxxxxxx>
Sent: Saturday, August 24, 2019 3:45 AM
To: distri@xxxxxxxxxxxxx
Subject: [distri] Re: new to the list
Hey spence, welcome to the list!
I agree regarding the sentiment wrt flat/snap/appimage—for me, appimage
seems like the most appealing approach, too. Not having to set up anything
is definitely a great property to have!
Come to think of it, not much is missing to make distri export
self-contained executables. Maybe I’ll experiment with that.
As for the reasons why I chose Go, see
https://michael.stapelberg.ch/posts/2017-08-19-golang_favorite/ for why
it’s my favorite. For this project in particular, Go provides a lot of what
we need in the standard library, and using a language in which I have years
of experience allows me to focus on exploring the distribution research
aspects of the project, not getting sidetracked by issues with my tools :)
On Sat, Aug 24, 2019 at 5:42 AM spencer davey <
dmarc-noreply@xxxxxxxxxxxxx<mailto:dmarc-noreply@xxxxxxxxxxxxx>> wrote:
Hi Michael and everyone,
I just signed up for the list and just testing if I got it working. I
think this project is very cool. I'm a debian/ubuntu user and get along
just fine with apt. I've experimented with flatpacks and snaps. I hate
them. Its bloated and complicated to me for trying to simplify things. I do
like appimages though. From what I've read with your blog posts your
package style seems to follow that approach more. I'm not a linux expert or
dev expert so excuse me if I don't make sense sometimes. I'm still learning
a lot. I feel like this could or should be a next generation linux
standard. Much better integration than snaps and flatpacks which distros
seem to be moving towards and away maybe from LHS? - though a long way off.
Anyway I'm going to follow this closely and maybe might be able to
contribute somehow to the project.
One question I have more as a curiosity because I'm not super familiar
with it, is there a reason you chose to use golang for development?
Thanks, this is awesome
spence
