Has read now, had to much headache and cold earlier today to attend live, will try to attend the meeting on Thursday On Tue, Jul 5, 2022 at 5:46 PM Dan Čermák wrote:

Hi everyone,

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.

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.

long version:

Desktop in ALP (topic for next official ALP update at news-o-o)

How can we dispell fears of users that we will shove containers & flatpacks down their throats: - we will use flatpak/containers as a distribution format, the packaging model will not change, only the format - the fear is not necessarily flatpaks (probably), but the fear that you'll have to pull everything from flathub/docker hub

=> stress out that you won't have to pull $randomStuff from the internet, you'll get audited software as you were before

Questions that lkocman would ask Yi Fan on the meeting would be:

* Some users are concerned that everything on their desktop will run in a container. Can you address these fears? - flatpak/containers just a distribution mechanism, packaging not going to change - ALP is still in flux, nothing set in stone - aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak) - possible solution for display manager & lower level things: https://github.com/fcrozat/gdm-container - will allow seamless updates with flatpaks installed on the host

* Desktop not being part of PoC, but can we "tentatively" expect it in any snapshot after (Dec, May)? - gdm container makes good progress - good progress with Wayland issues like remote desktop (also upstream involvement) - maybe even have rough prototype in the PoC, will have more info this or next week

* I'd really love to see desktop image that you simply dump to disk e.g. with self-install and first-boot wizzard that lets user to configure system. What's YiFan opinion about this? (SUSE IT wants this approach). - no concrete plans here yet - PoC will not have an installer, just a disk image will be the deliverable -> need to figure out how to run an installer or what to use here - Ancor is driving a workgroup to look into the traditional installation -> https://en.opensuse.org/index.php?title=openSUSE:ALP/Workgroups/Installation

* Any tips, best practices for how to start with Desktop app development (Including things like Desktop Managers like XFce, Elightenment etc) in "openSUSE ALP" (Current reference for community part of ALP based distro, based on top of "base install image of ALP"). - for info, message Yifan directly (yfjiang@suse.com) or the ALP matrix room https://matrix.to/#/#alp:opensuse.org - currently focusing on upstream contributions (-> GNOME upstream) - downstream contributions go into Tumbleweed - for container specific stuff, maybe later, currently too much in flux - look into building flatpaks on OBS, this will become important very soon, so get started beforehands -> help OBS handling flatpaks & container images

* Preferred way to distribute apps we know there will be ALP flathub repo in OBS, I think we could have something like "Community version of it". But we should be really smart about this, as the same app could work on top of (Community) ALP as well as Tumblweed. - would be possible to create

* How many desktop environments will there be for ALP? Just GNOME like with SLED? - first focus on GNOME, might consider alternatives afterwards - will learn from going with GNOME first and apply this to others later on

Maybe publish the Desktop WG results to the openSUSE Wiki as well

And that's it for this week, see you again next week with Luboš back in the driver seat!

Cheers,

Dan

-- Dan Čermák 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

Am 5. Juli 2022 15:46:29 UTC schrieb "Dan Čermák" :

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? 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? 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? 6) Can configuration still be expected at the usual places ($HOME/.config/ : /etc : /usr/etc/)? 7) Are current backups (rsync, Bareos) and configuration management (ansible, Salt) still be supported? 8) Will the whole delivery chain stay secure (signing of flatpaks, SSL, DNSSec, ...)? 9) Will autoyast still allow automated deployment? Regards, Lars

"jdd@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" :

...

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 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

On Wed, 06 Jul 2022 11:20:58 +0200 jdd@dodin.org wrote:

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)

Don't think that will be an issue, if those old computers can't even run openSUSE ALP :) AFAIK, current CPU requirements are 6th generation Intel and later, AMD Ryzen 1st gen and later, and machines having those are unlikely to have *that* low amounts of RAM. Just to be clear, I am in the same boat. My desktop is 2core/8gb RAM, so no oS ALP for me :) But, I am curious how will it end up looking/working, there are some interesting concepts explored with it, IMHO. Pedja

"jdd@dodin.org" writes:

Le 06/07/2022 à 13:44, Predrag Ivanović a écrit :

...

Just to be clear, I am in the same boat. My desktop is 2core/8gb RAM, so no oS ALP for me :)

oh... ok, so ALP is not to be a Leap replacement anytime soon?

ALP is a completely new code stream and *not* the next SLE. Whether the community will build an "openSUSE-ALP" is for us to discuss and decide. Cheers, Dan -- Dan Čermák 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

Predrag Ivanović writes:

On Wed, 06 Jul 2022 11:20:58 +0200 jdd@dodin.org wrote:

...

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)

Don't think that will be an issue, if those old computers can't even run openSUSE ALP :)

AFAIK, current CPU requirements are 6th generation Intel and later, AMD Ryzen 1st gen and later, and machines having those are unlikely to have *that* low amounts of RAM.

Raising the required CPU architecture has been proposed and it has not been decided yet. I am personally torn on this one, because requiring x86_64 v3 gives real world performance benefits (which is why RHEL 9 requires that JFYI) but it also excludes users with older machines. I would actually like to see more usage of function multi-versioning [1] and to rebuild the performance critical subset of our packages with optimizations for x86_64 v3 while providing the base version as a fallback as well. Unfortunately, this is afaik currently block by upstream rpm not supporting something like sub-architectures. But containers or flatpaks wouldn't be stopped by that… Cheers, Dan Footnotes: [1] https://lwn.net/Articles/691932/ -- Dan Čermák 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

Predrag Ivanović writes:

On Wed, 06 Jul 2022 14:30:50 +0200 Dan Čermák wrote:

...

...

AFAIK, current CPU requirements are 6th generation Intel and later, AMD Ryzen 1st gen and later, and machines having those are unlikely to have *that* low amounts of RAM.

Raising the required CPU architecture has been proposed and it has not been decided yet. I am personally torn on this one, because requiring x86_64 v3 gives real world performance benefits (which is why RHEL 9 requires that JFYI) but it also excludes users with older machines.

Ah, so they changed their mind[0]?

No, I simply remembered it wrongly and didn't look it up. That was just a mistake on my side.

(Linked from https://code.opensuse.org/leap/features/issue/81)

Speaking as someone with an (very) old machine, and unlikely to get hardware upgrade any time soon, I think that ALP/openALP is the perfect opportunity to make that break, and I am OK with that. New code-stream, new way(s) of doing things.

I trust that the decision would be made based on technical merit, and after weighting pros and cons. Will I be annoyed because all the fun happens without me? Not really :)

I'd like to add one thing here: only because SUSE decided that ALP is going to require at least x86_64v3 or v2 or whatever else, does not mean that an openSUSE variant will have to follow. We can build our packages with a less restrictive requirement if we wish to continue supporting older hardware (like e.g. Fedora still does, whereas RHEL explicitly dropped them). The decision for ALP was made with the enterprise and datacenter use-case in mind, which is vastly different from a community distro use-case. Thus our decision can be a different one than that of the business.

IMHO, people that will be able to use openALP should join in and (constructively) help in shaping its future.

Thank you! Cheers, Dan -- Dan Čermák 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

Simon Lees writes:

On 7/7/22 16:57, Dan Čermák wrote:

...

Predrag Ivanović writes:

...

On Wed, 06 Jul 2022 14:30:50 +0200 Dan Čermák wrote:

...

...

AFAIK, current CPU requirements are 6th generation Intel and later, AMD Ryzen 1st gen and later, and machines having those are unlikely to have *that* low amounts of RAM.

Raising the required CPU architecture has been proposed and it has not been decided yet. I am personally torn on this one, because requiring x86_64 v3 gives real world performance benefits (which is why RHEL 9 requires that JFYI) but it also excludes users with older machines.

Ah, so they changed their mind[0]?

No, I simply remembered it wrongly and didn't look it up. That was just a mistake on my side.

...

(Linked from https://code.opensuse.org/leap/features/issue/81)

Speaking as someone with an (very) old machine, and unlikely to get hardware upgrade any time soon, I think that ALP/openALP is the perfect opportunity to make that break, and I am OK with that. New code-stream, new way(s) of doing things.

I trust that the decision would be made based on technical merit, and after weighting pros and cons. Will I be annoyed because all the fun happens without me? Not really :)

I'd like to add one thing here: only because SUSE decided that ALP is going to require at least x86_64v3 or v2 or whatever else, does not mean that an openSUSE variant will have to follow. We can build our packages with a less restrictive requirement if we wish to continue supporting older hardware (like e.g. Fedora still does, whereas RHEL explicitly dropped them). The decision for ALP was made with the enterprise and datacenter use-case in mind, which is vastly different from a community distro use-case. Thus our decision can be a different one than that of the business.

We can but that will involve a completely different environment for whats been aimed with Closing the Leap Gap where Leap now uses SUSE packages directly which would loose many of the current benefits we have such as easy migration from Leap to SLE systems unless "V3" became the main product and we also built a "V1" port in the same way we currently build armv7l for Leap.

Certainly. That's why I am really unhappy with any decision to bump the required architecture for ALP so high up. x86_64 v2 would at least only require an Intel Core i CPU or a AMD Jaguar, but that would already exclude my good old Thinkpad x200 (which I could live with, as that thing is increasingly just a dusty paperweight). x86_64 v3 however would exclude many more devices, e.g. every Atom CPU until 2021. If we rebuild openSUSE ALP with a different instruction set, then it will be more work for the community and harder migration paths for SUSE customers moving from openSUSE to SUSE. So imho diverging will have many disadvantages for everyone involved. Cheers, Dan -- Dan Čermák 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

Am Wed, 06 Jul 2022 11:48:07 +0200 schrieb Dan Čermák :

...

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 * 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? * 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?

...

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?

...

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)?

...

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? Are we expecting all our users to manually copy their ~/.config/* into the new ~/.var/app/* place? Are there maybe even internal differences (YAML vs INI-Style)?

...

8) Will the whole delivery chain stay secure (signing of flatpaks, SSL, DNSSec, ...)?

Yes. This is one of the strict requirements to ALP.

Thanks! Lars

...

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?

...

...

...

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. But this brings me to two other questions: 10) Is there something like _multibuild support planned for Flatpak? 11) Will there be a tool to convert spec files into Flatpak files?

...

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? Regards, Lars

On 7/6/22 19:18, Dan Čermák wrote:

Hi Lars,

Lars Vogdt writes:

...

Am 5. Juli 2022 15:46:29 UTC schrieb "Dan Čermák" :

...

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.

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.

Does this mean that an acceptable solution to this problem is to tell all desktop users that they should use Gnome Software rather then zypper up to update there systems? If so do we have plans to ensure that Gnome Software can run with a minimal set of dependencies. For example practically every desktop user is going to have libgtk installed for something (probably also some part of the Qt Stack) so requiring libgtk for desktop users to update there system isn't a huge issue on the other hand plenty of users in the community will be very concerned that using gnome-software would require them also installing all of gnome shell so the wording here would need to be very careful. For a large number of the people I talk to when looking after some of our "lighter" desktops RAM (which has been bought up in this thread) isn't the big issue. The main thing that motivates alot of people to keep smaller lists of installed packages is slow / limited internet speeds and connections which isn't really something we have to think about in Europe the US or Aus anymore but is a significant issue for large number of our users in other parts of the world. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B