Ah, gotcha! Yeah, I know very little about this subject, but perhaps you
can experiment with distri to learn something. Good luck, and let us know
if you need any pointers.
On Sun, Aug 25, 2019 at 9:46 AM Sebastian Lusenti <seb.lusenti@xxxxxxxxx>
wrote:
yes, i know that ..
I'm here for studying too, in particular live kernel patching.
And i think that distri could help me to reach that goal.
Il giorno dom 25 ago 2019 alle ore 09:33 Michael Stapelberg <
michael+distri@xxxxxxxxxxxxx> ha scritto:
Hey Sebastian,
welcome to the list!
distri doesn’t have live kernel patching, and I don’t foresee being
interested in that area anytime soon.
Aside from that, I’m not 100% sure what you’re asking? distri package
images are indeed immutable, and that’s the only question I can find in
your mail.
I will note, though, that distri is a project to research linux
distributions, so it doesn’t have any stability guarantees, security
support, any upper bounds on when new software might be available, etc. I
would NOT recommend to use it in a production environment.
On Sun, Aug 25, 2019 at 9:27 AM Sebastian Lusenti <seb.lusenti@xxxxxxxxx>
wrote:
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
