Community Info: Meeting/ALP WG/Board Meeting/Asia Summit CfP&Logo Week 27
Hi all, The ALP Work Group (WG) will take place tomorrow at 14:30 UTC. We plan on having a special guest to ask questions to about ALP. Please be reminded that these WG are opportunities to discuss & help shape ALP. The Community Meeting will be on Thursday at 19:00 UTC. Both meetings will be in https://meet.opensuse.org/meeting You can view the meeting notes from the ALP WG and other notes at https://etherpad.opensuse.org/p/weeklymeeting. BOARD MEETING The biweekly board conference call with the board is today at 13:00 Europe/Berlin time. It about 90 minutes. The meeting will be in the regular Board Meeting Room at https://meet.opensuse.org/OSBoard Current Topics are: https://code.opensuse.org/board/tickets/issues?status=Open&tags=meeting ASIA SUMMIT CFP The Call for Papers for the openSUSE.Asia Summit is now open until July 31. That leaves 27 days to submit your proposal for the online event. Submit your proposal at https://events.opensuse.org. Please find the news at https://news.opensuse.org/2022/07/01/osa-cfp/ LOGO Yes, We need a logo from this year's openSUSE.Asia Summit. Find out how to submit your logo idea at https://news.opensuse.org/2022/07/01/osa-cfl/ v/r Doug
Hey! Not attending today, being sick and having extreme headache so need to relax maybe attending on Thursday, will try to help out at the Asia Summit however On Mon, Jul 4, 2022 at 11:27 AM ddemaio <ddemaio@suse.de> wrote:
Hi all,
The ALP Work Group (WG) will take place tomorrow at 14:30 UTC. We plan on having a special guest to ask questions to about ALP. Please be reminded that these WG are opportunities to discuss & help shape ALP.
The Community Meeting will be on Thursday at 19:00 UTC.
Both meetings will be in https://meet.opensuse.org/meeting
You can view the meeting notes from the ALP WG and other notes at https://etherpad.opensuse.org/p/weeklymeeting.
BOARD MEETING The biweekly board conference call with the board is today at 13:00 Europe/Berlin time. It about 90 minutes. The meeting will be in the regular Board Meeting Room at https://meet.opensuse.org/OSBoard
Current Topics are: https://code.opensuse.org/board/tickets/issues?status=Open&tags=meeting
ASIA SUMMIT
CFP The Call for Papers for the openSUSE.Asia Summit is now open until July 31. That leaves 27 days to submit your proposal for the online event. Submit your proposal at https://events.opensuse.org. Please find the news at https://news.opensuse.org/2022/07/01/osa-cfp/
LOGO Yes, We need a logo from this year's openSUSE.Asia Summit. Find out how to submit your logo idea at https://news.opensuse.org/2022/07/01/osa-cfl/
v/r Doug
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 <dcermak@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
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 <dcermak@suse.de> 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 <dcermak@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
On Tue, 05 Jul 2022 17:46:29 +0200 Dan Čermák wrote: <snip>
- look into building flatpaks on OBS, this will become important very soon, so get started beforehands -> help OBS handling flatpaks & container images
About that. I've been going thru upstream[0] and OBS[1] docs about flatpaks, because I am curious what all the fuss is about :) Required base images for build on OBS are at OBS:Flatpak, but they are, ATM, only for Leap 15.1/15.2 and Tumbleweed? Pedja [0] https://docs.flatpak.org/en/latest/building.html [1] https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.package_for...
Am 5. Juli 2022 15:46:29 UTC schrieb "Dan Čermák" <dcermak@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? 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
Le 06/07/2022 à 11:04, Lars Vogdt a écrit :
Am 5. Juli 2022 15:46:29 UTC schrieb "Dan Čermák" <dcermak@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) thanks jdd -- http://dodin.org http://valeriedodin.com
"jdd@dodin.org" <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" <dcermak@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@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
Le 06/07/2022 à 11:50, Dan Čermák a écrit :
"jdd@dodin.org" <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" <dcermak@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.
ok. I guess it's better if there are more flatpack containers on the same system - my previous tests with one fltpak where not that good :-( 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.
nice, modern machines have a lot of power, much more than needed for most users and since some years laptops are pretty reliable, So I have every day more of old (say more than 10 years old) machines perfectly working... with linux (openSUSE for me), even kde, when none can runs W11 :-) jdd -- http://dodin.org http://valeriedodin.com
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
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? if so it's fro sure more works for devs :-( - one more distro jdd -- http://dodin.org http://valeriedodin.com
"jdd@dodin.org" <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 <dcermak@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
On 7/6/22 22:03, Dan Čermák wrote:
"jdd@dodin.org" <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.
I think this is a bit of an unfair characterization, from the perspective of the community no SLE-16 has ever been mentioned and there has been plenty of talk of not doing Leap from SLE-15-SP6 and on which really leaves the community with only one choice which is building Leap from ALP sources. Now presuming that SUSE still uses rpm's as a basis for building most of its containers it would probably be possible with some amount of effort to create a distro thats more like the current Leap by making sure the rpm's have the appropriate conflicts then putting them all into one repo so it functions more like a traditional linux distro. But frankly claiming the community has any choice about whether the community does or doesn't use ALP as the basis for the next Leap is simply unfair unreasonable and unacceptable unless something else is announced or comes along. So from that perspective the community should be doing everything it can and pushing for everything it can to ensure that it is possible to create a Leap replacement out of the pieces of ALP that its given. At the end of the day its up to SUSE to decide on what the community gets but its still in SUSE's best interest when something isn't hard to do to make life easier for the community to do it. -- 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
Predrag Ivanović <predivan@mts.rs> 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 <dcermak@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
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]? (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 :) IMHO, people that will be able to use openALP should join in and (constructively) help in shaping its future. As for me, I'll try to (finally) figure out the workflow for chipping in future Leap 15.5 (video tutorial/walk-through would be _much_ appreciated :)). Pedja [0]https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-li...
Predrag Ivanović <predivan@mts.rs> 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 <dcermak@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
On 7/7/22 16:57, Dan Čermák wrote:
Predrag Ivanović <predivan@mts.rs> 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. -- 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
Simon Lees <sflees@suse.de> writes:
On 7/7/22 16:57, Dan Čermák wrote:
Predrag Ivanović <predivan@mts.rs> 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 <dcermak@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
Hi Lars, Lars Vogdt <lars@linux-schulserver.de> writes:
Am 5. Juli 2022 15:46:29 UTC schrieb "Dan Čermák" <dcermak@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?
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.
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.
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.
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/
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, ...)?
Yes. This is one of the strict requirements to ALP.
9) Will autoyast still allow automated deployment?
Regards, Lars -- Dan Čermák <dcermak@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
Am Wed, 06 Jul 2022 11:48:07 +0200 schrieb Dan Čermák <dcermak@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 * 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
Lars Vogdt <lars@linux-schulserver.de> writes:
Am Wed, 06 Jul 2022 11:48:07 +0200 schrieb Dan Čermák <dcermak@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@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
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
Lars Vogdt <lars@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@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
On 7/6/22 19:18, Dan Čermák wrote:
Hi Lars,
Lars Vogdt <lars@linux-schulserver.de> writes:
Am 5. Juli 2022 15:46:29 UTC schrieb "Dan Čermák" <dcermak@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.
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
participants (8)
-
Dan Čermák -
Dan Čermák -
ddemaio -
jdd＠dodin.org -
Lars Vogdt -
Luna Jernberg -
Predrag Ivanović -
Simon Lees