Source
r/openSUSE•
MasterPatricko

Future of Leap, ALP, etc.

As some of you will have noticed I included an entry in the FAQ document I just wrote about Leap future, ALP etc. since that has been a topic of much discussion lately. There was a lot of concern after the initial messaging, and sadly quite a bit of incomplete or wrong information circulating so this is my attempt to help.

This is what I decided to write in the FAQ, I'm reposting it here to have a discussion (keeping the FAQ thread clear).

The Leap release manager recently announced that the Leap 15.x release series will end with Leap 15.5, expected to be released in 2023. The future of the Leap distribution will then shift to be based on "SLE 16" (branding may change). Currently the next-generation SLE is expected to make greater use of containerized applications, a proposal known as "Adaptable Linux Platform". This is still very early in the planning process, and the scope and goals may still change significantly before any release (2024?).

In particular there is no intention to abandon the desktop workflow or current users. This is not "the end of Leap" unless that is what the community decides. If you have strong opinions, you are highly encouraged to join the weekly openSUSE Community meetings and the Desktop workgroups in particular.

Are there questions you still have after reading this? Maybe we can even get an ask-me-anything from Lubos (/u/lkocman) started :) I hope that it is clear there is a lot of room and time to influence the process. That was, I think, the intention behind the emails, not to alarm people.

Note I do not have a leadership role in the openSUSE project, nor do I work for SUSE, I am just a long-time user and maintainer of packages and occasionally join in development, bugfixing, planning, workshops, etc. So this is not an official statement. But it is my best understanding of what has actually been confirmed from listening to Lubos, the Leap release manager directly, as opposed to opinions or second-hand information.

Posted May 14, 2022, 10:52 PM UTC · edited

3627
MasterPatrickoOPMaintainer•

u/bubblymango , I'm replying to your comment here.

If leap is moving towards the ALP proposal, and lets say they choose the flatpak format, does this mean openSUSE will have its own runtimes? Do you know if it will use one big common runtime or that every app will have its own runtime?

This is very much a future decision, I don't know for sure, I don't think anyone does. I doubt openSUSE would recreate all flatpaks from scratch on our own runtime -- that sounds a lot like the packaging work we do already, but starting from scratch -- but this is only my personal opinion.

I do know that both SLE and openSUSE communities currently prefer flatpak by a large margin over other container-app alternatives (snap, appimage).

16
BubblyMango•

My main concern is that flatpaks allow every app to use its own runtime, basically like bundling the shared libraries with the app itself instead of using something like system wide shared libraries. The result is that instead of trusting your distro to update a shared library incase of a security breach, you now need to trust every individual app to update its shared libraries.

So I dont wanna be using flathub, which as i understood it has quite a few popular apps with unupdated SOs that contain known security problems. However is Leap had its own flatpak repo I'd only have to trust the openSUSE maintainers as i do now.

16
MasterPatrickoOPMaintainer•

The result is that instead of trusting your distro to update a shared library incase of a security breach, you now need to trust every individual app to update its shared libraries.

Yes, this is a widely-held concern about containerized apps, I think. To rephrase your question:

"Will it be possible to run Leap Next without any reliance on code not audited by (open)SUSE developers?"

I think it's a reasonable request. Currently Flathub doesn't really have levels of auditing or verification, afaik.

17
BubblyMango•

thank you for your time, you helped a lot.

5
Commercial-Tap-7229•

So would opensuse/suse dev just help flatpak current auditors be the solution here? Or does opensuse/suse want something different?

1
KipShades•

I know Fedora hosts their own Flatpak repo, built from the RPMs in the normal repos for dnf.

would a similar approach work for (open)SUSE?

1
Commercial-Tap-7229•

You can already do it in OBS. Just click create new image and select flatpak manifest.

2
Skyoptica•

I’d like to note that, in the ideal world, the one Flatpak is trying to move towards, this concern is somewhat mitigated (though not entirely resolved) by the sandbox. In that world, you’d only need to worry about an out-of-date app leaking or damaging the data that specific app works with, and not the whole system or other data.

This, of course, is not the case at the moment because there are still many apps that require broad permissions. A problem only further communication, cooperation, and yes, unfortunately, some patience, will resolve.

5
Generic_Commenter-X•

Thanks for this thread. I've read elsewhere that TW is a sort of proving ground? If Opensuse/Suse moves to a somewhat or completely different paradigm like MicrosOS or "Immutable OS" with Flatpaks providing apps, then that sounds like TW won't be needed any longer?

7
MasterPatrickoOPMaintainer•

This is a GREAT question.

Yes, SUSE has had normally a "Factory first" policy, where changes for SLE are to go into openSUSE Factory (which becomes Tumbleweed) first.

So, will this be maintained for SLE 16/ALP? In which case changes are coming to Tumbleweed before Leap.

Or will it be dropped? In which case what is the role of Factory/Tumbleweed?

The SLE release manager has pledged to develop SLE 16/ALP in public, in the OBS. But it's not clear if that means submissions will go to a new project, or still to Factory first.

10
Generic_Commenter-X•

Am I wrong in thinking that a MicroOS Desktop would be, in effect, a rolling release? As long as a MicroOS Desktop were as easy to use/customize for a "normal user" as the current paradigm, I could see no practical reason to avoid it. On the other hand, the more I understand it, the less it seems that ALP offers anything for the end user, since most end users don't need "containerization".

2
MasterPatrickoOPMaintainer•

The current "MicroOS" distro is literally a rolling release -- at its core it is "just" taking Tumbleweed packages and adding an immutable partition layout and necessary tools to deal with that on top of them.

But in general an immutable container-promoting OS does not have to be a rolling release. Leap Micro adds an immutable layer on SLE/Leap packages instead, and so follows the 6-month release cycle of SLE Micro.

What a hypothetical ALP offers for a certain type of end user is -- as is currently used to advertise MicroOS -- scalability (identical setups can be quickly replicated), predictability (same config will always result in the same result), and reliability (if a config doesn't work, easy to revert). These can be a really big deal for certain workflows (single-service containers/VMs being the obvious one).

But I do agree that for a different type of end user who is only running a desktop on one home system, they might see scalability and predictability as irrelevant. Which leaves reliability, I guess?

We have to careful with terms like "normal user" or we will end up talking past each other. (open)SUSE has a lot of different use cases and I personally don't have any statistics of who is "normal".

3
SeedOfTheDog•

Not necessarily. Tumbleweed will still be the "testing ground" running the latest and greatest software. Even if ALP turns out to be MicroOS on steroids, it has to be built on top of something, and it makes sense to keep an bleeding edge "developers oriented" release for the community.

Leap is the black swan here as it is currently piggybacking on SLE. The reason that a lot of people (like me) got worried about openSUSE Leap is combination of:

  1. The fact that openSUSE Leap 15.5 is due to be the last version based on SLE SLE 15 (corrected according to the comment of one of the maintainers bellow)
  2. Richard Brown comments stating that Leap is in a parasitic relationship with SLE and there's zero interest from community maintainers to keep the ball rolling (his option, not mine, but he's both a known community maintainer and a SUSE employee).

Given 1 and 2 there's a lot of justified uncertainty about what Leap will be and even if it will be anything at all once ALP becomes a thing.

Anyway, we are talking about something that will happen a good two years in the future. I'm personally hedging my bets by moving away from openSUSE on my workstations (I could had just as well bought a few personal SLE workstation licenses, but yeah, I don't feel much like giving SUSE my money at the moment). I'm keeping my Tumbleweed box, although it's certainly my least used Linux box at the moment (I mainly use it to build my own packages anyway :)).

6
MasterPatrickoOPMaintainer•

The fact that openSUSE Leap 15.5 is due to be the last version based on SLE.

This is explicitly not true. Leap 15.5 will be the last version based on SLE 15. Big difference.

Richard Brown comments stating that Leap is in a parasitic relationship with SLE and there's zero interest from community maintainers to keep the ball rolling (his option, not mine, but he's both a known community maintainer and a SUSE employee).

For what it's worth I'm a community maintainer and I strongly disagree, he doesn't speak for me or those I work with. I've seen interest both in the community and (in my limited view) within SUSE. And personally I am willing to contribute.

18
SeedOfTheDog•

This is explicitly not true. Leap 15.5 will be the last version based on SLE 15. Big difference.

Hey Pablo, this is great. So are you officially saying that there will be a Leap 16, Leap 15.5+ or whatever people want to call Leap after version 15.5? If so, what will it be based on?

For what it's worth I'm a community maintainer and I strongly disagree. I've seen lots of interest both here and (in my limited view) within SUSE. And personally I am willing to contribute.

Ditto. Plus lots of small time distros based on Leap, specially in Brazil. I would love for everyone to unite around a single, well polished, stable, workstation experience. I would also love to go back to simpler times:

  1. No having to move on whatever direction SLE/ALP is moving to.
  2. End user focus, end user friendly.
  3. No immutable OS, no latest and greatest of everything. If someone wants an Immutable OS, fine use MicroOS. If someone wants the latest and greatest everything install Tumbleweed. Leap is just plain, reliable workstation Linux.

Is there any possibility to make this happen for Leap?

And I could really appreciate a Q&A session with the maintainers. Between the fact that the community knows next to nothing about ALP, the fact that Richard Brown comments are out in the wild and the fact that the answer to everything around Leap future seems to be "TBD" I think that it's more than time to get together and come up with an official statement about the future of Leap.

5
MasterPatrickoOPMaintainer•

Hey Pablo, this is great. So are you officially saying that there will be a Leap 16, Leap 15.5+ or whatever people want to call Leap after version 15.5? If so, what will it be based on?

That is exactly what we are trying to figure out now (and we're not starting from a position of Leap should die). There were two Leap desktop workshops held this week which many (40+) people from inside and outside SUSE attended and spent several hours brainstorming, and Lubos (Leap release manager) is actively collecting feature ideas and user stories.

If you are curious, the notes from the meetings are at https://en.opensuse.org/openSUSE:ALP/Workgroups/Community/Workshops/LeapDesktop We didn't decide anything, just wrote down a whole bunch of ideas/thoughts.

Is there any possibility to make this happen for Leap?

If enough people agree, and are willing to do the resulting work.

I think that it's more than time to get together and come up with an official statement about the future of Leap.

Partly it's just that it's not decided what the future of ALP or Leap is (see above). But yes, I hope that once the workweek starts u/lkocman can join this thread and offer some comments.

4
SeedOfTheDog•

This is explicitly not true. Leap 15.5 will be the last version based on SLE 15. Big difference.

Just adding today's development to this thread as Richard Brown has doubled down on my initial understanding that Leap 15.5 may as well in fact be the last Leap: https://www.reddit.com/r/openSUSE/comments/vb4268/is_opensuse_leap_really_on_its_deathbed/ic7znsw

I’m saying, the Leap release manager has been clear.

There is no Leap planned after 15.5

There's a little bit of semantics here but the conclusion is: Leap 15.5 is likely to be the last version of Leap based on regular SLE (unless SUSE can't make ALP happen before SLE 15 SP6). Otherwise there may or may not be something called Leap based on ALP's codebase, and there may be an upgrade path from 15.5 to it, but for all intents and purposes it will be a completely new thing (immutable OS) based on a new codebase.

1
MasterPatrickoOPMaintainer•

There is no development today. Richard is using the same language he's always used, he means specifically the current codebase of Leap 15 will not continue. This does not mean there will be no stable desktop release called Leap from openSUSE.

As Richard himself says in the discussion thread

Tumbleweed and some form of ALP continues ... Sure, that form of ALP might be called Leap to stop people freaking out

As both he and I both keep saying, what happens after Leap 15.5 is not decided and will only be decided by the contributors. That is all one can say at this point. You are really not helping anyone by trying to nail us down on a public statement locking in stone something that simply hasn't happened yet.

Leap 15.5 is likely to be the last version of Leap based on regular SLE (unless SUSE can't make ALP happen before SLE 15 SP6). Otherwise there may or may not be something called Leap based on ALP's codebase, and there may be an upgrade path from 15.5 to it, but for all intents and purposes it will be a completely new thing (immutable OS) based on a new codebase.

As was the case when we moved from openSUSE 12.x to Leap 13.x. Then to 42.x. and then back to 15.x. If the lack of a 10-year plan is concerning you this much, maybe our community is not the solution for you, because openSUSE has changed code bases and development style quite significantly very regularly every 4-5 years. This is just the next iteration of that process.

There's a little bit of semantics here

If the ALP-based Leap-next distro (whatever it ends up being called) is a stable release which covers the desktop use cases, and there is an upgrade path from current Leap, then what exactly has changed for the users? How is this different to what someone upgrading to a hypothetical Leap 16.x with major new features would have experienced?

1
ok_no_worries•

From the desktop workgroup minutes:

Not much investment in the final UX

I think the wanting to use Linux user base places much importance on the default UX of a distro when forming an opinion on it. The workflows offered and the general look and feel of the distro are key to attracting new users. Existing users are savvy enough to figure out how to customise their desktop exactly how they want and so the concept of desktop layouts is not that appealing to them.

Have a look at Zorrin OS's Appearance App for some ideas on how the UX of ALP could work out to maximise attraction of new users:

Pre-defined Desktop Layouts

To the above, I would have also added features from Pop! OS:

None of the above is revolutionary and savvy Linux users can set all of it up for themselves due to the freedom of Open Source but the above does add value to a distribution in the eyes of a new user and could attact a strong following.

I'm excited about ALP and also anxious that it may turn out to be something I don't like and will be forced to distro hop.

7
dizvyz•

What people want to know is whether Leap will continue to be made after 15.5.

When people think leap is going away they didn't come to that conclusion by themselves without a reason. My opinion is leap will go away and the communication that came out meant exactly that.

Someone has to come out and say what is what since somebody obviously knows more.

2
MilaniumMaintainer •

As containerized applications seem to be the future, I made an attempt to port my essentials and favorites to Flathub. The packaging experience is actually a lot nicer compared to .rpm as the manifests are simpler and the builds are faster and the logs are cleaner. You can also jump into the file system for debugging at any time. It also integrates with language-specific dependencies such as PyPI, which can be resolved and downloaded with a single command. You will see me a lot less on OBS now, I guess.

2
MasterPatrickoOPMaintainer•

Your experience is valid, certain things are easier, but I'll note that some of the "pain points" -- like not being able to just download from pypi during an OBS build -- are intentional. OBS builds are inherently more reproducible and can make stronger guarantees about using only original, not hijacked files than flatpak builds can, afaik.

As for jumping into the file system, that is completely possible on an OBS local build -- osc chroot.

2
MilaniumMaintainer •

I'd argue that Flathub builds are more original as you can pick libraries in versions the developer intended, not the distribution provided. However, in case of updates of dependencies (especially security updates) it creates a lot of duplicated effort. There are indeed downsides.

1
MasterPatrickoOPMaintainer•

This is not a question of argument or opinion, it's a technical point. If you rebuild a correctly specified RPM you are guaranteed to be using the exact same source files and will get the same output, every time. Doesn't matter if PyPI gets hacked or the maintainer has a fight with GitHub or whatever.

This is not true of systems that download files dynamically during the build.

1
MilaniumMaintainer •

It is also an offline build on Flathub, but I don't know if they publish something like .src.rpm files. My guess is not. The cache is probably only local.

1
Kasta4711bort•

I think it os all together confusing and mystifying. These apparently fundamental shifts in what Leap is or is not is communicated in quite terse mailing list announcements. Almost no discussion follows.

2
FreeVariableUnverified Maintainer TBC•

Thank you very much for this post. I've read around this subreddit and also flipped a couple of conversations on the instant messaging platforms. It seems like the main interrogations are:

  • release-model: rolling or not?
  • package build source: from Factory only or Factory + something else?
  • base layer state: immutable or not?

Many people say this is still "to be decided by the community". But let's kid ourselves not: with SUSE not providing SLE binaries anymore, the name of the game here is I think to offer Leap users something that is not already offered by Tumbleweed or a MicroOS flavor while also making the most of the know-how acquired through the tooling and the Kubic-like experiments. So if we squint a bit we can almost see the answers already:

  • release-model: not rolling, or at least much slower than Tumbleweed;
  • package build source: with the difficulties to get non-SUSE employees to contribute, and also for the security and qa-assurance that comes with it, it's likely to be Factory only
  • base layer state: if .rpm come only from Factory it becomes very easy to convert users to transactional-updates, since .rpms will be packages with that workflow in mind, which by the same token makes an immutable base layer very much in order (because if all .rpms are installed via t-u, there is no reason not to go immutable)

So if I am sensing things right, ALP should be like Leap Micro except with no SLE backports and probably using "medium-term" snapshots for easier roll-backs and lesser maintenance. No?

If that's correct, then we're going to a weird place: ALP will get more security/reliability/reproducibility features than Tumbleweed, even though Tumbleweed, being rolling, would need them even more than ALP. So why not just have a single distro that people can run in either of these two modes, rolling or non-rolling?

1