On 2/18/23 04:09, Lukáš Krejza wrote:
Thank you Gerard and Robert for appearing and explaining some confusion.
If I may have some additional questions and remarks:
Dne pátek 17. února 2023 16:48:07 CET, Robert Schweikert napsal(a):
Hi,
On 2/17/23 10:07, Gerald Pfeifer wrote:
[ Moving board@ to Bcc: ]
On Fri 2023-02-17, Lukáš Krejza wrote:
2) Did Board itself decided this? If yes, is there a Board meeting
record available publicly, where proposal and / or final decision was
done? I am mainly interested about which board member proposed it and
how were the votes.
The openSUSE Board has not been involved in this topic, and it generally
is outside of the scope of the board as usually agreed upon.
How is it possible, that community discussion happens _after_
announcement of Leap -> ALP and not _before_?
Leap is currently based on SUSE Linux Enterprise. Since ALP (or "ALP",
I'm
not sure the name is final) is going to succeed SUSE Linux Enterprise 15,
This is where the confusion starts, ALP will not replace SUSE Linux
Enterprise 15. Something built from ALP will replace SUSE Linux
Enterprise 15. ALP is a PLATFORM from which we build other things. ALP
itself does not dictate a read-only filesystem with
transactional-updates and btrfs. One of the things that we will build
form ALP will be *-Micro, in that incarnation there will be a read-only
root filesystem based on btrfs that uses snapshots. But *-Micro will not
be the only thing that gets built from AL-PLATFORM.
Ultimately this is like talking about Concrete and people basically
decreeing that when you have Concrete you can only make one thing from
it, a foundation. That of course is completely incorrect. Concrete is a
material, people us it to build houses, walls, roads, secure fence
posts, make sculptures, ......
This is exactly my point. "Everyone" just assumes, that:
1) ALP-based distro means heavy focus on containers + transaction updates for root FS, exclusively
2) SLE going for ALP means Leap will go ALP without doubt and there is no other option
Both are then wrong?
Lets say Yes, No and Maybe, Certainly with regards to 1, SUSE is currently putting a heavy focus on Containers and Transactional Updates including in there media so its reasonable that this is how its being reported. However Fundamentally ALP is built from the same sources as Tumbleweed so if you build it the right way its still possible to have a solution that acts like Leap and Tumbleweed without the container focus. Recently we created an ALP workgroup during SUSE's Hackweek to prove that this is possible see [1]. With regards to 2, unless we somehow find a huge number of extra volunteers it does likely mean atleast using the ALP sources but we are able to use them to create something that resembles current Leap pretty closely.
These 2 points IMHO make public and more importantly Leap users (which i see im my eyes - please take no offense - as our little kids we need to take care for, even when it's sometimes exhausting) into believing (and fearing), that they are forced into a change by an enterprise. Change that they didn't called for, for whatever reasons. They think that they will have to use flatpaks, that have bundled libraries they laugh at Other OS (c) since they have linux. They think they will lose beloved zypper and yast2 sw_single ;) Typical Leap user IMHO does not want change. And changing the way they install software, with "cool" addition of the containerized desktop app problems we do not talk about, is the worst change possible for them.
I think that number of articles getting this wrong is spreading like a plague, so it already suffices something like openSUSE news post, what ALP-based means and what it doesn't mean in comparison to current Leap. I don't think the new "containers are the future" paradigma, but actual architecture change of the system. Is read-only root an option? Is using containers an option? Etc... That would clarify much confusion.
This confusion is also an actual reason why this thread exists.
We can talk about how useful is heavy containerization for desktops, but this is completely out of scope of this discussion IMHO.
What is IMHO important are these questions:
1) Does ALP-based distribution mean and requires/expect heavy containerization?
No again see [1], but for example its possible to build MicroOS from tumbleweed that does require this while tumbleweed itself doesn't.
2) Is it expected to be fewer RPMs available in favour of flatpaks/whatever in an ALP-based distribution?
On SUSE products most likely, but for openSUSE it will depend on what people contribute. For example SUSE may decide to only ship and support apache as a containerized workflow, which will almost certainly run fine under openSUSE's Leap replacement / next version. But at the same time if someone in the community is willing to maintain it then there is no reason why openSUSE Couldn't continue to ship apache as an RPM it might just take someone to do some work or depending on how the container images are built it maybe automatic then it might just require someone willing to fix bugs related to not running in a container. Similarly for flatpaks I expect that Gnome atleast will probably favor having its applications as flatpaks but these will have to be created and distributed by SUSE rather then on flathub so I would presume they will use obs for this and if so it might still be possible to just rebuild those source as rpm's or it might take someone willing to do whatever effort is required to make that happen. I know the desktop apps I still maintain will be available as rpm's though.
3) Current very simplified code packaging (for packages also available in SLE) path for Leap is (correct me if wrong, please):
Upstream -> Packager -> Factory /Tumbleweed -> SLE -> Leap
That is correct for packages in SLE, for non SLE packages it is just Upstream -> Packager -> Factory /Tumbleweed -> Leap
How would the packaging path (according to current proposals) in ALP-based Leap look? I guess here is the main advantage of ALP-based?
It would look the same except in the SLE and possible Leap part (if the community feel like it) Rather then just having rpm's there would be a mix of rpm's container images and flatpaks, hopefully all will be buildable from rpm spec files so if users want they can still mostly use rpm's
4) Does majority of Leap users prefer ALP-based or non-ALP-based distro :) ?
This is the wrong question, the right question is do enough people care enough about Leap to contribute enough to make it a viable distro into the future. Realistically Leap is a community open source project and as always if people aren't willing to contribute to it, then it will die. SUSE currently contributes by providing a Release Engineer, access to there binaries and sources for SLE and a bunch of hosting building and other infrastructure. From there it has always been up to the community to take that and create whatever distros we feel like we want we are lucky that SUSE provides the community with a good base to do such and even with ALP there seems to be a good enough base to atleast do something but feature parity with the current Leap will probably require more effort from the community if we want to keep it the way it was as SUSE has some different focuses and Goals. Fortunately this doesn't make creating Leap impossible. As with all open source projects users really only get to use whatever developers decide to create that they find useful for themselves but many developers try to make there code as useful as possible for end users. But that doesn't mean there is a magic black hole of resources where by if 100 users request X suddenly we have enough time and effort to make it happen.
5) Does majority of Leap community packagers prefer ALP-based or non-ALP-bysed distro?
I guess we will find out based on whether they choose to contribute rpm's, flatpaks or container images. Personally I have reasons why I'd like an as Leap like system as possible in some cases which Is why I created a prototype one that is ALP-Based because I know thats what i'll have access to in the future. The only exception to this would be if enough users banded together and started paying developers to create something that meets there needs.
6) What is the Board opinion? Is 100% of the Board ALP-positive? If no, what do opponents say? If yes, convince us too, please!
At the end of the day I can say as someone who was previously on the Board that the Board's position doesn't really matter because the board has no power to tell contributors that they need to do something, at most in very rare circumstances all they can do is tell a contributor not to do something. Again openSUSE as an organisation isn't paying any contributors to implement the things they deem most important to the community all contributions are voluntary either by people or by people acting on behalf of there employer.
What will a browsing PC gain and lose? What problem it will solve for them?
What will sysadmin laptop gain and lose? What problem it will solve for them?
What will gaming/multimedia PC gain and lose? What problem it will solve for them?
What will enterprise work desktop gain and lose? What problem it will solve for them?
What wil a server gain and lose? What problem it will solve for them?
In all these cases systems should theoretically be more secure and if something does go wrong it should be slightly easier to recover. But the main benefits SUSE is looking at is more about lifecycle management. Due to SLE's ABI compatibility guarantees all of Leap 15.4 and 15.5 will still have to use python 3.6 as default. With ALP's containerisation approach different components such as the desktop wont be bound to using the same versions as other components which means for openSUSE users they are more likely to end up with newer versions and less of the limitations Leap currently has which makes some software feel quite dated. 1. https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll -- 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