- Alp-community-wg

A Noob's MicroOS Experience (aka, Toolbox tutorial wen?)
by Gordon Leung 22 Jul '22

22 Jul '22

Hi, I saw the announcement about sending MicroOS reviews here so since I tried it out a month or two ago so I guess I will share my thoughts here. I think MicroOS could benefit a lot from a toolbox tutorial in a new user welcome pop up, because when I tried out MicroOS I had only heard of the name "toolbox", but never knew what it could do at all. Toolbox makes doing "normal" Linux distro things such as installing devel packages or something else temporarily pretty painless, but because I had no idea it could do that, I was just restarting my computer every time I was trying to figure out what devel packages I needed to build a C program. Also, some other tutorials such as how to use Distrobox to simulate entire other Linux distributions could be a neat bonus. People unfamiliar with immutable distros such as myself don't know what we need, so by the time I looked up how those tools worked, I was already back to using plain vanilla Tumbleweed. Gordon Leung

3 3

Re: High-Impact ALP workgroups
by Dan Čermák 14 Jul '22

14 Jul '22

Hi Dirk, Dirk Müller <dmueller(a)suse.de> writes: > On Dienstag, 12. Juli 2022 17:40:17 CEST Dan Čermák wrote: > >> we have identified your workgroups [1] to have a potential high impact >> on the community of ALP and would thus like to encourage you to start >> publishing your workgroup reports on the factory[2] and alp[3] mailinglists >> as well as to the openSUSE wiki[4]. > > Hi Dan, > > are you looking for that being published as unstructured meeting minutes or do > you plan to setup a more targetted process like for example > > https://en.opensuse.org/openSUSE:OSEP_0001 We don't have a specific template in mind and I don't think that a formal template is really in place here, because it goes against how the openSUSE community works. I think it would be valuable to start posting your minutes to the wiki after a general introduction to the community so that interested contributors can follow your progress and provide feedback. > where we could have a more targetted proposal discussion? > > I think for some of the more controversial changes it would be good to > document rationale, chosen option and alternatives to structure potential > feedback or discussion accordingly. I'll think of a template that can be used for communicating change proposals and will find a way how you can ask for feedback that will be (hopefully) useful and will not overwhelm the workgroup. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

High-Impact ALP workgroups
by Dan Čermák 12 Jul '22

12 Jul '22

Dear ALP workgroup leads, we have identified your workgroups [1] to have a potential high impact on the community of ALP and would thus like to encourage you to start publishing your workgroup reports on the factory[2] and alp[3] mailinglists as well as to the openSUSE wiki[4]. It would be very nice if we could start involving community feedback in the development of ALP, so that the whole does not feel like SUSE is throwing stuff over the wall. If you would like help with publishing and involving the community, then feel free to ask us for help, as this is what we are here for ;-) Thanks, Dan Footnotes: [1] https://en.opensuse.org/openSUSE:ALP/Workgroups/Community#Workgroup_impact [2] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/ [3] https://lists.opensuse.org/archives/list/alp-community-wg@lists.opensuse.or… [4] https://en.opensuse.org/openSUSE:ALP/Workgroups -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 07 Jul '22

07 Jul '22

Lars Vogdt <lars(a)linux-schulserver.de> writes: > Hi > > On Wed, 06 Jul 2022 12:50:18 +0200 Dan Čermák wrote: >> >>> 1) What are the advantages of flatpak/container vs RPM? >> >> That's what will happen. Currently we distribute software for every >> code stream and with flatpaks we hope to reduce the burden on our >> maintainers and allow them to distribute it only once. > > For me this kind of means we retire from the current way to deliver well > tested (but maybe older) software to Leap users and deliver the latest > and greatest stuff to Tumbleweed users. > > 13) How can someone decide to use an older, but known to be stable > version of a package (say: Libreoffice 7.2.7 instead of Libreoffice > 7.3.4) in ALP? We haven't made any decisions in this regard (like with a lot of other stuff), but with flatpaks we could deliver a org.opensuse.libreoffice-stable, org.opensuse.libreoffice-beta, org.opensuse.libreoffice-nightly, etc. co running "streams". With containers we could go the already established tag route, i.e. registry.opensuse.org/opensuse/libreoffice:stable registry.opensuse.org/opensuse/libreoffice:beta registry.opensuse.org/opensuse/libreoffice:nightly Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 07 Jul '22

07 Jul '22

Jiri Slaby <jslaby(a)suse.cz> writes: > On 05. 07. 22, 17:46, Dan Čermák wrote: >> we have mostly focused this week's meeting on how the ALP Desktop is >> going to look like and how we can dispel fears around flatpaks and >> containers when it comes to the ALP desktop. > > I have never looked into this container stuff in more detail. But one of > the concerns I was always afraid of was how this behaves WRT shared > libraries and their memory footprint? IOW, containers kill the purpose > of shlibs completely and one has to hold all of the versions (per each > container on the top of ones from the base system) in memory, right? > This sounds as if using static libraries. A lot of the containerized software is written in Go and that is already statically linked, so my guess is that no one really looked at this so far. However with flatpaks the situation is different and it would be theoretically possible to deduplicate shared runtimes of flatpaks. Unfortunately I don't know whether that is actually done in practice or even feasible. > And what about userspace live patching? Would we provide it for SLE for > all the containers? Or don't you expect these continaers to be available > on SLE (which would be against the advertised purpose, it seems)? This would be a question for Libor, who is driving the Kernel and Live Patching WG. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Lubos Kocman 07 Jul '22

07 Jul '22

Hello openSUSE! I'm happy to see these discussions, and this is precisely why we need to plan in an open way! I have an understanding of many concerns which are being raised here. Just an idea that I discussed with Dominique a few days ago. My first-time personal experience with our current "Immutable Desktop" was quite good, but not perfect. I definitely would have some RFEs, which seem to be relatively low-hanging fruits that would improve my day-to-day experience by a lot (mostly default configuration) I can see how the entry barrier may appear too high to people meeting such a concept for the first time. I'm thinking of an idea to make a "workshop" where users would install MicroOS Desktop and try to use it for a week, and then we'd meet to talk about the user experience, both good and bad). I think people liked our last *workshop. We've had around 50 visitors in total. We could start putting together known issues (FAQ), try to propose some changes, and make sure they're being tracked for ALP GA. Thoughts? [0]https://en.opensuse.org/openSUSE:ALP/Workgroups/Community/Workshops/LeapD…

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 06 Jul '22

06 Jul '22

Lars Vogdt <lars(a)linux-schulserver.de> writes: >> > Please correct me, if my assumptions are wrong: >> > * A Flatpak will include all needed libraries, which will blow up >> > the needed (installation and mirror) space >> >> No, flatpaks support runtimes which would contain the required >> libraries and these are shared between different flatpaks. E.g. on >> flathub you already have a GNOME runtime and a KDE runtime. We could >> create our own openSUSE Tumbleweed runtime and base our flatpaks on >> that. > > This sounds to me like: "Flatpak is just another packaging format. But > instead to rely on packagers to provide Apparmor/SeLinux profiles, > Flatpaks are using cgroups from the beginning, which makes them more > secure." - Is that description close enough to the truth? As far as I know flatpak utilizes seccomp to achieve the isolation and not cgroups. Iirc cgroups are more for limiting resource usage and not security sandboxing, but this is really far outside of my knowledge. >> >> > 2) Will ALP still allow one 'zypper up' call to update all >> >> > software (container, flatpak, rpm) on a system? >> >> > >> >> > 3) Will OBS auto-convert current rpms to flatpaks? >> >> >> >> Theoretically that could be done, but I think that's at the moment >> >> out of scope. >> > >> > For 2, does this mean we loose the current benefit of updating a >> > whole system with just one single tool? >> > >> > So for 3, this currently means that packagers have more work, >> > because they need to provide the needed Flatpak build configuration >> > as well? >> >> Not really. Currently a packager has to provide a spec file for every >> code stream and maintain those independently and make them build. With >> flatpaks in the mix, you'd have to maintain a single code stream and a >> flatpak build description. > > IMHO this answer is wrong. Most packages in OBS are not using spec files > for every code stream, but include macros in one single spec file to > build for multiple code streams. In devel projects yes, but the actual package sources of the released code streams are separated and have often significantly diverged from the state in the devel project. > But this brings me to two other questions: > > 10) Is there something like _multibuild support planned for Flatpak? I cannot answer that, as I do not know what the Build Service team has planned here. > 11) Will there be a tool to convert spec files into Flatpak files? No, and that should really not be required. The idea is that you combine multiple rpms into a flatpak and not that you convert a rpm into a flatpak. > >> > How is a migration from RPM to Flatpak expected in this case? >> >> Afaik there are no plans to support a migration from SLE to ALP. > > Are there plans to support a migration from openSUSE to ALP? I don't think there are and imho the technical complexity of that would make such a migration next to impossible to pull of cleanly. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 06 Jul '22

06 Jul '22

Jan Engelhardt <jengelh(a)inai.de> writes: > On Wednesday 2022-07-06 11:48, Dan Čermák wrote: >>> >>> 1) What are the advantages of flatpak/container vs RPM? >> >>Flatpaks support sandboxing when configured properly giving you greater >>security benefits in comparison to traditional rpms. > > But that is not inherent to the flatpaks themselves. As you say, > flatpaks are but a different method of _distributing_ software. And > so the critique becomes: stop distributing software twice. That's what will happen. Currently we distribute software for every code stream and with flatpaks we hope to reduce the burden on our maintainers and allow them to distribute it only once. > To make flatpaks (or, at this point: sandboxes) more widely accepted, > generate them on the fly from an existing system, i.e. from {an rpmdb > and loose files} rather than from a set of .rpm files. Sure, that would be nice to have. But creating such a system is a lot of work which is really hard to justify if there is already a perfectly functioning and widely adopted system in place. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 06 Jul '22

06 Jul '22

Lars Vogdt <lars(a)linux-schulserver.de> writes: > Am Wed, 06 Jul 2022 11:48:07 +0200 > schrieb Dan Čermák <dcermak(a)suse.com>: >> > 1) What are the advantages of flatpak/container vs RPM? >> >> Flatpaks support sandboxing when configured properly giving you >> greater security benefits in comparison to traditional rpms. >> >> The main benefit however is that we would be able to build certain >> desktop applications (e.g. Firefox, Thunderbird, LibreOffice, etc.) >> only on top of Tumbleweed, put them into a flatpak and distribute >> them to Tumbleweed, Leap and ALP users. This is something that is >> impossible to achieve with RPMs unless you bundle *everything* into a >> single RPM and even then it will probably not work. So this will save >> our packagers a tremendous amount of work. > > While I understand that this makes the live of a packager easier (at > least in the future, when we got rid of all the old-school > distributions), I think that we loose a big benefit of the current > way to do it. > > Please correct me, if my assumptions are wrong: > * A Flatpak will include all needed libraries, which will blow up the > needed (installation and mirror) space No, flatpaks support runtimes which would contain the required libraries and these are shared between different flatpaks. E.g. on flathub you already have a GNOME runtime and a KDE runtime. We could create our own openSUSE Tumbleweed runtime and base our flatpaks on that. > * We need to find a way to track, if a Flatpak contains a vulnerable > library and push out security updates for all involved Flatpak > (containers). I think/hope, that OBS can help us here? The plan is to build *everything* inside OBS. So updates will be distributed the same way as they are currently, only the artifact at the end will change. > * For any library update, we increase the needed space on all mirror > servers and also require much more bandwidth from all endusers - as > they need to download a whole copy of all Flatpaks with all their > in-tree libraries. > -> Is there already a project like "deltarpm", which might help to > reduce the amount of 'need to be transferred' Flatpak content for > any update? Again, this would go into the runtime, which would be shared by all flatpaks. I must admit that I am not familiar with the flatpak distribution method enough, thus I cannot answer whether there is something like deltarpm. >> > 2) Will ALP still allow one 'zypper up' call to update all software >> > (container, flatpak, rpm) on a system? >> > >> > 3) Will OBS auto-convert current rpms to flatpaks? >> >> Theoretically that could be done, but I think that's at the moment out >> of scope. > > For 2, does this mean we loose the current benefit of updating a whole > system with just one single tool? > > So for 3, this currently means that packagers have more work, because > they need to provide the needed Flatpak build configuration as well? Not really. Currently a packager has to provide a spec file for every code stream and maintain those independently and make them build. With flatpaks in the mix, you'd have to maintain a single code stream and a flatpak build description. > >> > 4) Will there still be some kind of repo (incl. package >> > informations like version-release, changelog, etc.) for flatpaks? >> > >> > 5) Will Yast-Software manage all these different kind of formats >> > (container, flatpak, rpm) transparently for the enduser? >> >> I don't know what the plans of the Yast team wrt flatpaks are, but >> GNOME Software center supports flatpaks and rpms seamlessly. > > So this means more work for the Yast team. > Are they aware of this? > Did they maybe even already agreed to implement this in the near future > (before the first official release of ALP)? I have CC'd the Yast ML to get their take on this. >> > 6) Can configuration still be expected at the usual places >> > ($HOME/.config/ : /etc : /usr/etc/)? >> >> That depends on the flatpak, but generally flatpaks put their >> configuration into ~/.var/app/ > > How is a migration from RPM to Flatpak expected in this case? Afaik there are no plans to support a migration from SLE to ALP. > Are we expecting all our users to manually copy their ~/.config/* into > the new ~/.var/app/* place? As you'd have to reinstall the system anyway, you'd have to move your configs into different places. > Are there maybe even internal differences (YAML vs INI-Style)? Any internal differences would be caused by the packaged application itself. Flatpaks do not mandate any type of configuration format, as at the end of the day they are just archives that get unpacked on your file system (just like rpms…). Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 06 Jul '22

06 Jul '22

"jdd(a)dodin.org" <jdd(a)dodin.org> writes: > Le 06/07/2022 à 11:04, Lars Vogdt a écrit : >> Am 5. Juli 2022 15:46:29 UTC schrieb "Dan Čermák" <dcermak(a)suse.de>: >>> tl;dr; Fear not, you will not be forced to download random flatpaks or >>> containers from dockerhub/flathub. We (probably) just change the deliver >>> method, but the packaging workflow will stay the same. >> >> 1) What are the advantages of flatpak/container vs RPM? >> > > and the disadvantages :-( > > for example: will we have to load in ram all the libraries for each > application launched? What about old computers with 2Gb or even 4Gb ram > and 256Go disk/ssd? (that works without problem with 15.3) Flatpaks are very good when it comes to deduplication, at least of libraries on the disk. I would expect that they perform similarly when loading them to RAM, but I have not verified that. This sounds like something that we definitely have to take into account and potentially fix upstream. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0