This hackweek a group of us have been looking at using the ALP binaries provided by SUSE to create a functional successor to openSUSE Leap.
**Goals:** * Creating and maintaining it should be manageable by a small number of community volunteer maintainers, but at the same time should be scalable to grow with additional contributors. * It should be possible for community members to easily contribute additions in their preferred form whether rpm, container or something else. * Use ALP Sources wherever possible (In some cases this may require building them in a different format). * Make it possible to support smaller desktops including supporting X11, Wayland and xwayland. * Support upgrading systems from Leap 15.5 in most cases. This will likely mean alongside supporting transactional updates so that SUSE:ALP -> openSUSE:ALP is possible, it also needs to be possible to still support traditional RW filesystems with zypper up and dup. * Support running ALP containerised workloads but aim to avoid using containers in core operating system components. * Provide a lightweight environment for embedded usecases including Raspberry Pi's.
To test that these goals are realistic, our main goal for this hackweek was to get Xfce running on a combination of ALP and backports packages. It seemed like a good choice as the package set is small enough to be handled by a couple of people and it's popular in the openSUSE community. We have made good progress and have achieved a lot, but more on that later.
**Design:** The basic concept is to follow what we have done with Leap and create a "Backports" repository containing community packages from Tumbleweed to fill the gaps, one of the differences here is SUSE's repos for SLE contain around 10,000 packages while ALP contains around 2,000, despite this, we only had to add around another 350 packages to reach our initial goals. This includes yast and many gnome build dependencies that hopefully we will be able to take from ALP Sources once they are there. But even at this number it is probably manageable for a small team especially while the packages are present in Tumbleweed.
Once we had the packages we needed, we could use our existing tooling such as kiwi to create images for testing including livecds. The biggest benefit to SUSE's Factory first policy is with the right packages everything that works in Tumbleweed also works here. Hopefully once we know how SUSE plans to build their container images, we will also be able to use the same approach partnered with the backports repo to build openSUSE community images if people are interested in maintaining them. We didn't investigate that this hackweek though.
Lubos also spent a significant portion of his hackweek working with d-installer to see if it is currently suitable for working with the additional features that we require.
**Design Limitations:** While it is possible to work around many of ALP's restrictions via simply building images differently, some other design decisions are hard to avoid due to the fact ALP binaries are built without certain features such as AppArmor and NIS.
**Results:** Firstly we have a backports repository here[1] containing all the additional packages we required so far, we also have a wiki page documenting why many of these packages are required [2]. Secondly we built several KVM Images available for downloading and testing [3], that include Xfce, Enlightenment and a generic console environment. These are very limited images - really only designed as a proof of concept, so beyond very basic functionalities and basic desktop options, don't expect too much. Third we built live cds also for testing and available to download [4]. Initially we worked on Xfce and Enlightenment due to my personal interest but at that point Valentin discovered that we were only about 30 packages away from a usable Gnome system and decided to give it a shot. However, what Gnome ends up looking like in the future will depend a fair bit on what SUSE does with it for their ALP products. We also have a D-Installer image availiable as a proof of concept for installation.
**Unanswered Questions:** * Desktop apps - SUSE's ALP will likely use Flatpaks, if these are built on OBS, it may be possible to build rpm versions from the same source. It is also likely that some openSUSE contributors will prefer to ship their applications as rpms. So Ideally we want to support both. * Maintenance / Release schedule - Ideally during the year at scheduled periods, we will bundle up changes from SUSE's ALP and the community and bundle them into some form of point release. I.e. it seems likely that SUSE will release the python3.11 stack at a point when the python3.10 stack is still supported so it would be ideal to pick one point to do regular migrations rather then them happening at random times. Currently we still don't have enough detail in this area to really assess what will be possible though. * There is a chance that SUSE will use less repositories than in the past and we may need to add repository- based filtering to zypper / yast so that they only show still supported packages for install. But again we are very much waiting for more detail here.
**What Next:** We now know that this concept A works and B would be maintainable, so if there is broad community interest in this concept, the next step would be probably after the Leap 15.5 release, creating a backports package repo similar to the way the Leap ones have existed with bots etc. Then getting maintainers to contribute any other packages they wish to maintain. At the same time, setting up image building and openqa tests. In the meantime the packages in the backports repo under my namespace are mostly linked from Factory (i'll fix the rest) so i'll keep an eye on them and check they stay building. If you maintain a package and are interested in the list of dependencies, you'd also need to maintain to get it working, let me know and I can link it in from Factory. However, be aware that significant parts of the perl, python and ruby language stacks etc aren't packaged yet. Also in the spirit of lighter desktops i'd like to get sway packaged as well as it will give a good indication of whats needed for the other smaller wayland desktops.
The name is something else to consider, should we just use Leap for the open source builds of SUSEs ALP products, should we do something else entirely? Given that SUSE is using names of alps as release code names I chose to do something similar but different, This project is meant to be less extreme then a trip up into the alps, more like a relaxing picnic or stroll through the hills so this prototypes codename is Grassy Knoll because it sounds cool and maybe I've been playing too much dwarf fortress. Either way, it may not be the best name for the project long term.
**FAQ:** * Why didn't we look at KDE? - KDE has a much larger packet set, Also part of my initial goal was to create something small enough that if I needed to maintain it with a couple of people mostly for our own personal usecases we'd be able to. KDE doesn't fit within that scope, however from the testing we have done this week if someone wanted to maintain KDE, it shouldn't require too many changes from the packages in Tumbleweed and may provide a good way to do KDE going forward with ALP but i'll leave that decision with the KDE Maintainers
Finally a massive thanks to the other members of this hackweek team: Maurizio Galli, Lubos Kocman and Valentin Lefebvre. They took a concept I had in my head and helped transform it into a functioning prototype. Also a big thanks to Fabian Vogt for answering all my "why won't kiwi build this"-questions.
If you have questions thoughts or suggestions feel free to reach out to us via email or in the openSUSE-ALP channels on Discord / IRC / Matrix. we will also work on getting this information into the wiki.
1. https://build.opensuse.org/project/show/home:simotek:GrassyKnoll:Backports 2. https://en.opensuse.org/User:Simotek:GrassyKnoll 3. https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll:... 4. https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll:...
On 2/2/23 20:06, Simon Lees wrote:
The name is something else to consider, should we just use Leap for the open source builds of SUSEs ALP products, should we do something else entirely? Given that SUSE is using names of alps as release code names I chose to do something similar but different, This project is meant to be less extreme then a trip up into the alps, more like a relaxing picnic or stroll through the hills so this prototypes codename is Grassy Knoll because it sounds cool and maybe I've been playing too much dwarf fortress. Either way, it may not be the best name for the project long term.
Thanks for the update! This really sounds interesting and I'm looking forward to trying it and putting it to work.
But one comment about "Grassy Knoll". In the US context, the Grassy Knoll is important to the assassination of President John F. Kennedy. Just mentioning the phrase to older Americans will bring back many bad memories and associations. Perhaps a name without such negative baggage might be in order? Try googling "grassy knoll" to see what I mean. There's even a memorial park with that name, on the Grassy Knoll in Dallas Texas.
Regards, Lew
On 2/3/23 15:21, Lew Wolfgang wrote:
On 2/2/23 20:06, Simon Lees wrote:
The name is something else to consider, should we just use Leap for the open source builds of SUSEs ALP products, should we do something else entirely? Given that SUSE is using names of alps as release code names I chose to do something similar but different, This project is meant to be less extreme then a trip up into the alps, more like a relaxing picnic or stroll through the hills so this prototypes codename is Grassy Knoll because it sounds cool and maybe I've been playing too much dwarf fortress. Either way, it may not be the best name for the project long term.
Thanks for the update! This really sounds interesting and I'm looking forward to trying it and putting it to work.
But one comment about "Grassy Knoll". In the US context, the Grassy Knoll is important to the assassination of President John F. Kennedy. Just mentioning the phrase to older Americans will bring back many bad memories and associations. Perhaps a name without such negative baggage might be in order? Try googling "grassy knoll" to see what I mean. There's even a memorial park with that name, on the Grassy Knoll in Dallas Texas.
Yeah, obviously i'm Australian and none of that showed up in my quick search for alternate words for hill and I remember it from Fantasy / Video Game context. We will use a different hill related name (or maybe something else for the next prototype. Suggestions welcome :-)
Fri, 3 Feb 2023 14:36:53 +1030 Simon Lees sflees@suse.de:
This project is meant to be less extreme then a trip up into the alps
In this case it needs to be named Harz, because sometimes will be Brocken for a while...
Olaf
Simon Lees wrote:
Yeah, obviously i'm Australian and none of that showed up in my quick search for alternate words for hill and I remember it from Fantasy / Video Game context. We will use a different hill related name (or maybe something else for the next prototype. Suggestions welcome :-)
How about "Sisyphus" ? :-)
On Fri, Feb 3, 2023 at 11:33 AM Per Jessen per@opensuse.org wrote:
Simon Lees wrote:
Yeah, obviously i'm Australian and none of that showed up in my quick search for alternate words for hill and I remember it from Fantasy / Video Game context. We will use a different hill related name (or maybe something else for the next prototype. Suggestions welcome :-)
How about "Sisyphus" ? :-)
"Jolly Green Giant" is probably more fun :)
On Friday 2023-02-03 11:32, Olaf Hering wrote:
Fri, 3 Feb 2023 14:36:53 +1030 Simon Lees sflees@suse.de:
This project is meant to be less extreme then a trip up into the alps
In this case it needs to be named Harz, because sometimes will be Brocken for a while...
If it ain't baroque, don't fix it.
On 2/2/23 22:06, Simon Lees wrote:
If you have questions thoughts or suggestions feel free to reach out to us via email or in the openSUSE-ALP channels on Discord / IRC / Matrix. we will also work on getting this information into the wiki.
- https://build.opensuse.org/project/show/home:simotek:GrassyKnoll:Backports
- https://en.opensuse.org/User:Simotek:GrassyKnoll
https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll:... 4. https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll:...
Simon,
I hate that we jump around in naming the stable releases, but if Leap has to go, then a the name of a small mountain chain such as Hartz is a lot better than Grassy Knoll for the reasons stated in other responses. Choosing a German name makes sense for openSUSE.
I tried to download your XFCE live iso, and got the following error message: https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll:... is unreachable.
Larry
Am Freitag, 3. Februar 2023, 16:22:16 CET schrieb Larry Finger:
On 2/2/23 22:06, Simon Lees wrote:
If you have questions thoughts or suggestions feel free to reach out to us via email or in the openSUSE-ALP channels on Discord / IRC / Matrix. we will also work on getting this information into the wiki.
https://build.opensuse.org/project/show/home:simotek:GrassyKnoll:Backport s 2. https://en.opensuse.org/User:Simotek:GrassyKnoll 3. https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnol l:/Images/images/ 4. https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnol l:/Images/images/iso/
Simon,
I hate that we jump around in naming the stable releases, but if Leap has to go, then a the name of a small mountain chain such as Hartz is a lot better than Grassy Knoll for the reasons stated in other responses. Choosing a German name makes sense for openSUSE.
How about single mountains IN the harz (no T in there) range instead? And maybe just not have anything between openSUSE and the version number itself?
Lets start with A: "Achtermann" which is a nice little hike to get up onto :) - https://w3w.co/findet.dortige.wieso
So that would be: openSUSE 16.0 "Achtermann" followed by openSUSE 16.1 "Brocken" etc etc.
that being said, I can see the Brocken top from my roof window on a clear day.
Cheers MH
On 2/3/23 09:47, Mathias Homann wrote:
How about single mountains IN the harz (no T in there) range instead? And maybe just not have anything between openSUSE and the version number itself?
Lets start with A: "Achtermann" which is a nice little hike to get up onto 😄 -https://w3w.co/findet.dortige.wieso
So that would be: openSUSE 16.0 "Achtermann" followed by openSUSE 16.1 "Brocken" etc etc.
I like that idea very much.
Larry
* Larry Finger Larry.Finger@lwfinger.net [02-03-23 11:16]:
On 2/3/23 09:47, Mathias Homann wrote:
How about single mountains IN the harz (no T in there) range instead? And maybe just not have anything between openSUSE and the version number itself?
Lets start with A: "Achtermann" which is a nice little hike to get up onto 😄 -https://w3w.co/findet.dortige.wieso
So that would be: openSUSE 16.0 "Achtermann" followed by openSUSE 16.1 "Brocken" etc etc.
I like that idea very much.
yes, sounds like a plan.
On Friday 2023-02-03 16:47, Mathias Homann wrote:
How about single mountains IN the harz (no T in there) range instead? And maybe just not have anything between openSUSE and the version number itself?
Lets start with A: "Achtermann" which is a nice little hike to get up onto :)
Nobody cares about codenames, and they are hard to translate from and to the actual version. I hate Debian for it. In OBS, the targets are Debian_10, Debian_11, same for Ubuntu_22.04, 22.10, etc. Utterly simple.
But whenever I have to operate in real Debian space, I have to lookup what some silly codename means. « What is "xenial"? Is that more recent than "bionic"? And how old even _is_ "bionic"? »
Am 03.02.23 um 18:12 schrieb Jan Engelhardt:
Nobody cares about codenames, and they are hard to translate from and to the actual version. .....
"nobody" is a hard word. i don't care as you. so +1 from me.
use a static name + a number. every thing else is only fancy stuff who will complicate everything.
simoN
On 2/3/23 07:22, Larry Finger wrote:
I hate that we jump around in naming the stable releases, but if Leap has to go, then a the name of a small mountain chain such as Hartz is a lot better than Grassy Knoll for the reasons stated in other responses. Choosing a German name makes sense for openSUSE.
But when I think of "Hartz" it brings to mind dog food and cat diapers:
How about a word that brings to mind power and authority, and excitement?
I just asked ChatGPT what she though and she suggested:
NebulaOS
Not too bad, I kind of like Nebula. New, emerging, spectacular, mighty, etc.
openSUSE Nebula
Regards, Lew
On Friday 2023-02-03 18:47, Lew Wolfgang wrote:
On 2/3/23 07:22, Larry Finger wrote:
I hate that we jump around in naming the stable releases, but if Leap has to go, then a the name of a small mountain chain such as Hartz is a lot better than Grassy Knoll for the reasons stated in other responses. Choosing a German name makes sense for openSUSE.
But when I think of "Hartz" it brings to mind dog food and cat diapers:
How about a word that brings to mind power and authority, and excitement?
Hartz (IV) is a name for (part of) the German social welfare system. Yes, that certainly brings to mind the power and authority of the German state, but needless to say, brings few people excitement.
NebulaOS Not too bad, I kind of like Nebula. New, emerging, spectacular, mighty, etc.
Nebulous. And possibly conflicting with a trademark of Standard Broadcast LLC (Nebula).
On Fr, Feb 3 2023 at 09:22:16 -0600, Larry Finger Larry.Finger@lwfinger.net wrote:
Simon,
I hate that we jump around in naming the stable releases, but if Leap has to go, then a the name of a small mountain chain such as Hartz is a lot better than Grassy Knoll for the reasons stated in other responses. Choosing a German name makes sense for openSUSE.
As far as I understand this is more or less seen as a leaplacement :D for Leap, so I would hope it would inherit Leap name as well, don't give up on it yet, that's what happened with previous projects like Step. Grassy Knoll is very much a prototype name, and not a product name, Tumbleweed is too long of a name already, that ends up being even longer whenever people mistype it as Thumbleweed or TumbleWeed for whatever reason (I guess TumbleWeed happens because TW is a fairly common acronym for it, but it would be nice if there was a name that didn't require shortening every time). I do like some of the proposals for names here, they could be a fun added flavour in a form of codenames for releases that may end up being useful for marketing material.
LCP [Jake] https://lcp.world/
On Fri, 3 Feb 2023 11:35:22 +0100, Neal Gompa ngompa13@gmail.com wrote:
On Fri, Feb 3, 2023 at 11:33 AM Per Jessen per@opensuse.org wrote:
Simon Lees wrote:
Yeah, obviously i'm Australian and none of that showed up in my quick search for alternate words for hill and I remember it from Fantasy / Video Game context. We will use a different hill related name (or maybe something else for the next prototype. Suggestions welcome :-)
How about "Sisyphus" ? :-)
"Jolly Green Giant" is probably more fun :)
"Montreal" ? It's not the Alps, but ...
Or, "Boaty McBoatface" ?
-- Robert Webb
On 2023-02-03 19:17, Jacob Michalskie wrote:
On Fr, Feb 3 2023 at 09:22:16 -0600, Larry Finger Larry.Finger@lwfinger.net wrote:
Simon,
I hate that we jump around in naming the stable releases, but if Leap has to go, then a the name of a small mountain chain such as Hartz is a lot better than Grassy Knoll for the reasons stated in other responses. Choosing a German name makes sense for openSUSE.
As far as I understand this is more or less seen as a leaplacement :D for Leap, so I would hope it would inherit Leap name as well, don't give up on it yet, that's what happened with previous projects like Step.
No, if it is based on Alp, it is not "Leap".
On Fri, 3 Feb 2023 20:25:06 +0100, "Carlos E. R." carlos.e.r@opensuse.org wrote:
On 2023-02-03 19:17, Jacob Michalskie wrote:
As far as I understand this is more or less seen as a leaplacement :D for Leap, so I would hope it would inherit Leap name as well, don't give up on it yet, that's what happened with previous projects like Step.
No, if it is based on Alp, it is not "Leap".
Simon wrote, "[...] it also needs to be possible to still * support traditional RW filesystems with zypper up and dup. * Support running ALP containerised workloads but aim to avoid using containers in core operating system components. [...]"
If it is also distributed as RPMs, do you think it would still be Leap-like enough to keep the name? -- Robert Webb
On 2023-02-03 20:52, Robert Webb wrote:
On Fri, 3 Feb 2023 20:25:06 +0100, "Carlos E. R." carlos.e.r@opensuse.org wrote:
On 2023-02-03 19:17, Jacob Michalskie wrote:
As far as I understand this is more or less seen as a leaplacement :D for Leap, so I would hope it would inherit Leap name as well, don't give up on it yet, that's what happened with previous projects like Step.
No, if it is based on Alp, it is not "Leap".
Simon wrote, "[...] it also needs to be possible to still * support traditional RW filesystems with zypper up and dup. * Support running ALP containerised workloads but aim to avoid using containers in core operating system components. [...]"
If it is also distributed as RPMs, do you think it would still be Leap-like enough to keep the name?
It is not done as in Leap. It is not the same development and maintenance model. It is not Leap, if Alp is there.
Please avoid breaking expectations and change the name.
A naming discussion, how fun
On 2/3/23 14:25, Carlos E. R. wrote:
On 2023-02-03 19:17, Jacob Michalskie wrote:
On Fr, Feb 3 2023 at 09:22:16 -0600, Larry Finger Larry.Finger@lwfinger.net wrote:
Simon,
I hate that we jump around in naming the stable releases, but if Leap has to go, then a the name of a small mountain chain such as Hartz is a lot better than Grassy Knoll for the reasons stated in other responses. Choosing a German name makes sense for openSUSE.
As far as I understand this is more or less seen as a leaplacement :D for Leap, so I would hope it would inherit Leap name as well, don't give up on it yet, that's what happened with previous projects like Step.
No, if it is based on Alp, it is not "Leap".
Why not? "Leap" was created when we started consuming more packages from the enterprise build of SUSE. That concept still applies with the work that was done here. Whether that enterprise build is called SLE, timbuktu, or ALP should not matter.
Later, Robert
On 2/3/23 15:32, Carlos E. R. wrote:
On 2023-02-03 20:52, Robert Webb wrote:
On Fri, 3 Feb 2023 20:25:06 +0100, "Carlos E. R." carlos.e.r@opensuse.org wrote:
On 2023-02-03 19:17, Jacob Michalskie wrote:
As far as I understand this is more or less seen as a leaplacement :D for Leap, so I would hope it would inherit Leap name as well, don't give up on it yet, that's what happened with previous projects like Step.
No, if it is based on Alp, it is not "Leap".
Simon wrote, "[...] it also needs to be possible to still * support traditional RW filesystems with zypper up and dup. * Support running ALP containerised workloads but aim to avoid using containers in core operating system components. [...]"
If it is also distributed as RPMs, do you think it would still be Leap-like enough to keep the name?
It is not done as in Leap. It is not the same development and maintenance model.
Au contraire, it is the same maintenance model. Take bits built for a SUSE enterprise thing and sprinkle some community pixie dust on top.
It is not Leap, if Alp is there.
Please avoid breaking expectations and change the name.
On 2/4/23 07:08, Robert Schweikert wrote:
A naming discussion, how fun
On 2/3/23 14:25, Carlos E. R. wrote:
On 2023-02-03 19:17, Jacob Michalskie wrote:
On Fr, Feb 3 2023 at 09:22:16 -0600, Larry Finger Larry.Finger@lwfinger.net wrote:
Simon,
I hate that we jump around in naming the stable releases, but if Leap has to go, then a the name of a small mountain chain such as Hartz is a lot better than Grassy Knoll for the reasons stated in other responses. Choosing a German name makes sense for openSUSE.
As far as I understand this is more or less seen as a leaplacement :D for Leap, so I would hope it would inherit Leap name as well, don't give up on it yet, that's what happened with previous projects like Step.
No, if it is based on Alp, it is not "Leap".
Why not? "Leap" was created when we started consuming more packages from the enterprise build of SUSE. That concept still applies with the work that was done here. Whether that enterprise build is called SLE, timbuktu, or ALP should not matter.
So While I agree with you and LCP, for me this somewhat depends. For example if we are unable to provide Gnome or KDE with this model I might feel uncomfortable calling it Leap. Technically so far I don't see a reason why we couldn't have Gnome and KDE. However what we are doing here is significantly enough different from what SUSE is doing that I have no idea what buy in and how much involvement we will get from SUSE (Beyond providing 4 engineers a hackweek to get a prototype up and running).
Unlike current Leap where we can basically take SLED and have complete Gnome support out of the box the model we worked on including our Gnome livecd is completely different from what SUSE is planning with its ALP desktop. This combined with the fact we currently have an approximate 2000 package set to work with rather then 10,000 i'm sure this will grow as language stacks turn up.
What all this means is with just a few volunteers we can probably support the smaller desktops and a few other usecases. My needs are pretty straight forward, from this work its pretty clear that I could make and maintain something that meets my needs and gives other people a base to work off. If we are going to reach close to feature parity with Leap it'll take alot of extra help from the community and maybe we won't know if that level of help and support is there until people get a chance to provide it which is why I haven't just started calling it Leap 16 which if we get the community support would probably be a sensible name but if not probably isn't and maybe retiring it or using it for the open version of SUSE:ALP's next desktop is a better idea.
* Robert Schweikert rjschwei@suse.com [02-03-23 15:39]:
A naming discussion, how fun
On 2/3/23 14:25, Carlos E. R. wrote:
On 2023-02-03 19:17, Jacob Michalskie wrote:
On Fr, Feb 3 2023 at 09:22:16 -0600, Larry Finger Larry.Finger@lwfinger.net wrote:
Simon,
I hate that we jump around in naming the stable releases, but if Leap has to go, then a the name of a small mountain chain such as Hartz is a lot better than Grassy Knoll for the reasons stated in other responses. Choosing a German name makes sense for openSUSE.
As far as I understand this is more or less seen as a leaplacement :D for Leap, so I would hope it would inherit Leap name as well, don't give up on it yet, that's what happened with previous projects like Step.
No, if it is based on Alp, it is not "Leap".
Why not? "Leap" was created when we started consuming more packages from the enterprise build of SUSE. That concept still applies with the work that was done here. Whether that enterprise build is called SLE, timbuktu, or ALP should not matter.
yes, +1
Hi,
On 2/3/23 20:58, Simon Lees wrote:
On 2/4/23 07:08, Robert Schweikert wrote:
A naming discussion, how fun
On 2/3/23 14:25, Carlos E. R. wrote:
On 2023-02-03 19:17, Jacob Michalskie wrote:
On Fr, Feb 3 2023 at 09:22:16 -0600, Larry Finger Larry.Finger@lwfinger.net wrote:
Simon,
I hate that we jump around in naming the stable releases, but if Leap has to go, then a the name of a small mountain chain such as Hartz is a lot better than Grassy Knoll for the reasons stated in other responses. Choosing a German name makes sense for openSUSE.
As far as I understand this is more or less seen as a leaplacement :D for Leap, so I would hope it would inherit Leap name as well, don't give up on it yet, that's what happened with previous projects like Step.
No, if it is based on Alp, it is not "Leap".
Why not? "Leap" was created when we started consuming more packages from the enterprise build of SUSE. That concept still applies with the work that was done here. Whether that enterprise build is called SLE, timbuktu, or ALP should not matter.
So While I agree with you and LCP, for me this somewhat depends. For example if we are unable to provide Gnome or KDE with this model I might feel uncomfortable calling it Leap. Technically so far I don't see a reason why we couldn't have Gnome and KDE. However what we are doing here is significantly enough different from what SUSE is doing that I have no idea what buy in and how much involvement we will get from SUSE (Beyond providing 4 engineers a hackweek to get a prototype up and running).
Well, SUSE will still maintain packages, that for product that get created from ALP those packages might end up in a container should be immaterial. The important part should be that security issues get fixed and the we get to mirror those builds as packages to OBS, rather than being forced to consume the containers.
I think the later will be the key question and that may be something we can ask already and get answered without waiting for the product definitions of ALP based products.
Unlike current Leap where we can basically take SLED and have complete Gnome support out of the box the model we worked on including our Gnome livecd is completely different from what SUSE is planning with its ALP desktop. This combined with the fact we currently have an approximate 2000 package set to work with rather then 10,000 i'm sure this will grow as language stacks turn up.
Yep, once we actually know what ALP looks like I suspect the package count will go up by quite a bit. On the other hand one of the goals of ALP is to have fewer packages.
What all this means is with just a few volunteers we can probably support the smaller desktops and a few other usecases. My needs are pretty straight forward, from this work its pretty clear that I could make and maintain something that meets my needs and gives other people a base to work off. If we are going to reach close to feature parity with Leap it'll take alot of extra help from the community and maybe we won't know if that level of help and support is there until people get a chance to provide it which is why I haven't just started calling it Leap 16 which if we get the community support would probably be a sensible name but if not probably isn't and maybe retiring it or using it for the open version of SUSE:ALP's next desktop is a better idea.
I was not dismissing a re-naming. I was objecting to the absolute of "anything from ALP cannot be Leap", when we really don't know yet. As you state this can go either way.
I think there is a reasonably good chance that we'll get to mirror the SUSE package builds into OBS in the same way we mirror the SLE package builds, in that case I don't see why we should care if the project inside of SUSE that builds those packages has an ALP name instead of a SLE name.
Later, Robert
On 2/3/23 14:36, Simon Lees wrote:
This hackweek a group of us have been looking at using the ALP binaries provided by SUSE to create a functional successor to openSUSE Leap.
For reference this is all now documented on the wiki at https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll
**Goals:** * Creating and maintaining it should be manageable by a small number of community volunteer maintainers, but at the same time should be scalable to grow with additional contributors. * It should be possible for community members to easily contribute additions in their preferred form whether rpm, container or something else. * Use ALP Sources wherever possible (In some cases this may require building them in a different format). * Make it possible to support smaller desktops including supporting X11, Wayland and xwayland. * Support upgrading systems from Leap 15.5 in most cases. This will likely mean alongside supporting transactional updates so that SUSE:ALP -> openSUSE:ALP is possible, it also needs to be possible to still support traditional RW filesystems with zypper up and dup. * Support running ALP containerised workloads but aim to avoid using containers in core operating system components. * Provide a lightweight environment for embedded usecases including Raspberry Pi's.
To test that these goals are realistic, our main goal for this hackweek was to get Xfce running on a combination of ALP and backports packages. It seemed like a good choice as the package set is small enough to be handled by a couple of people and it's popular in the openSUSE community. We have made good progress and have achieved a lot, but more on that later.
**Design:** The basic concept is to follow what we have done with Leap and create a "Backports" repository containing community packages from Tumbleweed to fill the gaps, one of the differences here is SUSE's repos for SLE contain around 10,000 packages while ALP contains around 2,000, despite this, we only had to add around another 350 packages to reach our initial goals. This includes yast and many gnome build dependencies that hopefully we will be able to take from ALP Sources once they are there. But even at this number it is probably manageable for a small team especially while the packages are present in Tumbleweed.
Once we had the packages we needed, we could use our existing tooling such as kiwi to create images for testing including livecds. The biggest benefit to SUSE's Factory first policy is with the right packages everything that works in Tumbleweed also works here. Hopefully once we know how SUSE plans to build their container images, we will also be able to use the same approach partnered with the backports repo to build openSUSE community images if people are interested in maintaining them. We didn't investigate that this hackweek though.
Lubos also spent a significant portion of his hackweek working with d-installer to see if it is currently suitable for working with the additional features that we require.
**Design Limitations:** While it is possible to work around many of ALP's restrictions via simply building images differently, some other design decisions are hard to avoid due to the fact ALP binaries are built without certain features such as AppArmor and NIS.
**Results:** Firstly we have a backports repository here[1] containing all the additional packages we required so far, we also have a wiki page documenting why many of these packages are required [2]. Secondly we built several KVM Images available for downloading and testing [3], that include Xfce, Enlightenment and a generic console environment. These are very limited images - really only designed as a proof of concept, so beyond very basic functionalities and basic desktop options, don't expect too much. Third we built live cds also for testing and available to download [4]. Initially we worked on Xfce and Enlightenment due to my personal interest but at that point Valentin discovered that we were only about 30 packages away from a usable Gnome system and decided to give it a shot. However, what Gnome ends up looking like in the future will depend a fair bit on what SUSE does with it for their ALP products. We also have a D-Installer image availiable as a proof of concept for installation.
**Unanswered Questions:** * Desktop apps - SUSE's ALP will likely use Flatpaks, if these are built on OBS, it may be possible to build rpm versions from the same source. It is also likely that some openSUSE contributors will prefer to ship their applications as rpms. So Ideally we want to support both. * Maintenance / Release schedule - Ideally during the year at scheduled periods, we will bundle up changes from SUSE's ALP and the community and bundle them into some form of point release. I.e. it seems likely that SUSE will release the python3.11 stack at a point when the python3.10 stack is still supported so it would be ideal to pick one point to do regular migrations rather then them happening at random times. Currently we still don't have enough detail in this area to really assess what will be possible though. * There is a chance that SUSE will use less repositories than in the past and we may need to add repository- based filtering to zypper / yast so that they only show still supported packages for install. But again we are very much waiting for more detail here.
**What Next:** We now know that this concept A works and B would be maintainable, so if there is broad community interest in this concept, the next step would be probably after the Leap 15.5 release, creating a backports package repo similar to the way the Leap ones have existed with bots etc. Then getting maintainers to contribute any other packages they wish to maintain. At the same time, setting up image building and openqa tests. In the meantime the packages in the backports repo under my namespace are mostly linked from Factory (i'll fix the rest) so i'll keep an eye on them and check they stay building. If you maintain a package and are interested in the list of dependencies, you'd also need to maintain to get it working, let me know and I can link it in from Factory. However, be aware that significant parts of the perl, python and ruby language stacks etc aren't packaged yet. Also in the spirit of lighter desktops i'd like to get sway packaged as well as it will give a good indication of whats needed for the other smaller wayland desktops.
The name is something else to consider, should we just use Leap for the open source builds of SUSEs ALP products, should we do something else entirely? Given that SUSE is using names of alps as release code names I chose to do something similar but different, This project is meant to be less extreme then a trip up into the alps, more like a relaxing picnic or stroll through the hills so this prototypes codename is Grassy Knoll because it sounds cool and maybe I've been playing too much dwarf fortress. Either way, it may not be the best name for the project long term.
**FAQ:** * Why didn't we look at KDE? - KDE has a much larger packet set, Also part of my initial goal was to create something small enough that if I needed to maintain it with a couple of people mostly for our own personal usecases we'd be able to. KDE doesn't fit within that scope, however from the testing we have done this week if someone wanted to maintain KDE, it shouldn't require too many changes from the packages in Tumbleweed and may provide a good way to do KDE going forward with ALP but i'll leave that decision with the KDE Maintainers
Finally a massive thanks to the other members of this hackweek team: Maurizio Galli, Lubos Kocman and Valentin Lefebvre. They took a concept I had in my head and helped transform it into a functioning prototype. Also a big thanks to Fabian Vogt for answering all my "why won't kiwi build this"-questions.
If you have questions thoughts or suggestions feel free to reach out to us via email or in the openSUSE-ALP channels on Discord / IRC / Matrix. we will also work on getting this information into the wiki.
https://build.opensuse.org/project/show/home:simotek:GrassyKnoll:Backports 2. https://en.opensuse.org/User:Simotek:GrassyKnoll 3. https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll:... 4. https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll:...
Am Mittwoch, 8. Februar 2023, 01:31:24 CET schrieb Simon Lees:
On 2/3/23 14:36, Simon Lees wrote:
This hackweek a group of us have been looking at using the ALP binaries provided by SUSE to create a functional successor to openSUSE Leap.
For reference this is all now documented on the wiki at https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll
and none of the discussion held here made it onto the page. Especially nothing about "Grassy Knoll" and why its a bad name made it.
:eyeroll:
On 2/8/23 16:45, Mathias Homann wrote:
Am Mittwoch, 8. Februar 2023, 01:31:24 CET schrieb Simon Lees:
On 2/3/23 14:36, Simon Lees wrote:
This hackweek a group of us have been looking at using the ALP binaries provided by SUSE to create a functional successor to openSUSE Leap.
For reference this is all now documented on the wiki at https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll
and none of the discussion held here made it onto the page. Especially nothing about "Grassy Knoll" and why its a bad name made it.
Yes, the wiki page captures the technical information and details from our weeks work that is intentional. Consider it this way, we had an "ALP Workgroup" that ran for a week using the project name Grassy Knoll because we needed to call it something it was created to research a topic and create a proposal which it did.
Whatever we create post the Leap 15.5 that may use some of the information we gathered as part of this workgroups research will be done in the openSUSE namespace under a different name and will be recreated mostly from scratch, maybe with some scripting using the info from this workgroup as a basic guide. The point of this workgroup was a technical excersize to prove a concept could be done not a branding exercise.
and none of the discussion held here made it onto the page. Especially nothing
about "Grassy Knoll" and why its a bad name made it. :eyeroll:
It's a wiki and anyone can contribute content to it.
That said, please let's stop talking about the name on this list. As one of the people who contributed to this initiative, I am not pleased that a good chunk of the discussion in this thread is so focused on the name and not on the technology and how to improve it. The bad name is just a codename we used during hackweek, not the name of the product.
Best, Maurizio
Hello,
On 2023-02-08 07:39, Maurizio Galli wrote:
... a good chunk of the discussion in this thread is so focused on the name and not on the technology ...
don't worry.
Everyone can comment on the naming of something. Only few can contribute to the technology of something.
See https://en.wikipedia.org/wiki/Law_of_triviality
There is nothing bad (as long as comments are polite). This is just normal human behaviour.
What would be bad is excluding humans who (politely) comment.
Kind Regards Johannes Meixner
As one of those older Americans who has family in the DFW area, I don't find it to be a bad name; it's just a name people will associate it with that part of history. It's still labeled a conspiracy theory and the declassified redacted documents from 2022 still don't support the theory. Nevertheless, it would be nice to find some new meaning associated with the phrase. Grassy Knoll is rather generic and probably shouldn't be overshadowed by this historical event.
Wife just reminded me. I forgot to mention that we (I many times) were on the Grassy Knoll in September with people taking selfies toward where JFK was shot. That was rather unexpected, but I guess things change over time and we should move forward. v/r Doug
On Wed, 2023-02-08 at 07:55 +0100, Johannes Meixner wrote:
See https://en.wikipedia.org/wiki/Law_of_triviality
There is nothing bad (as long as comments are polite). This is just normal human behaviour.
What would be bad is excluding humans who (politely) comment.
Does ":eyeroll:" qualify as "polite"?
IMO the naming discussion does not belong on the Wiki page. Perhaps the best idea would be to just remove the controversial code name from the page.
Martin
On 2/8/23 18:17, Martin Wilck wrote:
On Wed, 2023-02-08 at 07:55 +0100, Johannes Meixner wrote:
See https://en.wikipedia.org/wiki/Law_of_triviality
There is nothing bad (as long as comments are polite). This is just normal human behaviour.
What would be bad is excluding humans who (politely) comment.
Does ":eyeroll:" qualify as "polite"?
IMO the naming discussion does not belong on the Wiki page. Perhaps the best idea would be to just remove the controversial code name from the page.
Which would only go so far, for example hackweek is over so I don't really have time to go through and recreate all the obs stuff in a different namespace and update various repository definitions etc at the moment, I have several other projects I am working on.
Hello
You might want to check the latest release engineering meeting minutes l. We're in discussion of continuing with simple Leap 16.X. https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/D...
I think we'll want to be identifiable as an ALP "compatible" system. So less differences in various identification attributes the better.
TBH, the ALP version scheme is still bit cloudy to me. A good example is SLE Micro released based on ALP will go from 5.X (based on SLES 15) to 6.X based on (ALP). But internally version wise matches 15 SPX.
The current plan that we're suggesting is to use 16 both internally and externally for Leap based on ALP.
Hope it Helps
Lubos
On Fri, 2023-02-03 at 21:28 -0500, Patrick Shanahan wrote:
- Robert Schweikert rjschwei@suse.com [02-03-23 15:39]:
A naming discussion, how fun
On 2/3/23 14:25, Carlos E. R. wrote:
On 2023-02-03 19:17, Jacob Michalskie wrote:
On Fr, Feb 3 2023 at 09:22:16 -0600, Larry Finger Larry.Finger@lwfinger.net wrote:
Simon,
I hate that we jump around in naming the stable releases, but if Leap has to go, then a the name of a small mountain chain such as Hartz is a lot better than Grassy Knoll for the reasons stated in other responses. Choosing a German name makes sense for openSUSE.
As far as I understand this is more or less seen as a leaplacement :D for Leap, so I would hope it would inherit Leap name as well, don't give up on it yet, that's what happened with previous projects like Step.
No, if it is based on Alp, it is not "Leap".
Why not? "Leap" was created when we started consuming more packages from the enterprise build of SUSE. That concept still applies with the work that was done here. Whether that enterprise build is called SLE, timbuktu, or ALP should not matter.
yes, +1
On Wed, Feb 15, 2023 at 7:18 AM Lubos Kocman Lubos.Kocman@suse.com wrote:
Hello
You might want to check the latest release engineering meeting minutes l. We're in discussion of continuing with simple Leap 16.X. https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/D...
I think we'll want to be identifiable as an ALP "compatible" system. So less differences in various identification attributes the better.
TBH, the ALP version scheme is still bit cloudy to me. A good example is SLE Micro released based on ALP will go from 5.X (based on SLES 15) to 6.X based on (ALP). But internally version wise matches 15 SPX.
The current plan that we're suggesting is to use 16 both internally and externally for Leap based on ALP.
I would prefer this. It makes things neat and simple.
-
Carlos E. R. -
doug demaio -
Jacob Michalskie -
Jan Engelhardt -
Johannes Meixner -
Larry Finger -
Lew Wolfgang -
Lubos Kocman -
Martin Wilck -
Mathias Homann -
Maurizio Galli -
Neal Gompa -
Olaf Hering -
Patrick Shanahan -
Per Jessen -
Robert Schweikert -
Robert Webb -
Simon Becherer -
Simon Lees