Update on next generation of SLE
(Sending to both openuse-project as well as opensuse-factory. Please keep discussions on the -project list to make life easier for all.) Moin, In the last months many people have brought up the topic of "When will the next SLE major version come out?". Today we would like to give you a first update on the plans. Since 2018, when SLE 15 was initially released a lot of things have changed, including requirements from users and customers, technologies, the speed of new versions of applications, languages and their libraries appearing. Also the connection between Leap and SLE has changed. And while some bits and pieces got better, we firmly believe we can do better. SLE 15 is a great general purpose operating system, yet challenges with some use cases, now places of deployment, and the type of enhancement requests show that it's time for a successor. With the next generation of Enterprise releases we want to tackle the above. Intending to do radical changes (regarding technology- but also design-wise) we choose "Adaptable Linux Platform" or short "ALP" as codename for that next generation. This indicates already that some things will be quite different than a "mere "SLE 15++ would be ;) First and foremost, ALP will be developed in the open. We are not going to put the pieces together internally and then share outside, as in the past. No, we are creating and building in the openSUSE Build Service - in a project next to you :). You get to directly see to see what is going on and participate more easaily. Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of "host OS", and the and the layer providing and supporting applications, which will be container (and VM) based. You might say "This is very generic, can you tell us more?" - of course. In the upcoming weeks more and more will crystalize, and we will share as quickly and regularly as possible. This is just a first heads-up to inform you that we are in the process of setting everything up - from project to feedback channels, from documentation to testing. Of course, you will have lots of other questions - how will contribution work, what impacts this has on LEAP and get-o-o, how migration could work, and many more. We kindly ask you for a little bit of patience. We promise we will share as soon as possible more details. ciao, Stefan -- Stefan Behlert, SUSE Software Solutions Product Management SUSE Linux Enterprise Maxfeldstr. 5, D-90409 Nuernberg, Germany SUSE Software Solutions Germany GmbH, GF: Ivo Totev (HRB 36809, AG Nuernberg)
On 2022-04-13 10:21, Stefan Behlert wrote:
(Sending to both openuse-project as well as opensuse-factory. Please keep discussions on the -project list to make life easier for all.)
...
First and foremost, ALP will be developed in the open. We are not going to put the pieces together internally and then share outside, as in the past. No, we are creating and building in the openSUSE Build Service - in a project next to you :). You get to directly see to see what is going on and participate more easaily.
Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of "host OS", and the and the layer providing and supporting applications, which will be container (and VM) based.
You mean that we users will have to run our openSUSE Linux in a virtualized machine, instead of our real hardware machine? This is nuts. Please explain. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On 4/13/22 12:00, Carlos E. R. wrote:
On 2022-04-13 10:21, Stefan Behlert wrote:
(Sending to both openuse-project as well as opensuse-factory. Please keep discussions on the -project list to make life easier for all.)
...
Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of "host OS", and the and the layer providing and supporting applications, which will be container (and VM) based.
You mean that we users will have to run our openSUSE Linux in a virtualized machine, instead of our real hardware machine?
That's not at all what I understood from the paragraph you quoted. To my eyes, it says the operating system will be separated into two parts: 1) a small core including only what is needed to interact with the hardware and to manage it, no matter whether that's real or virtual hardware (somehow similar to MicroOS[1]) 2) all the applications and user-space tools that will run as containers or virtual machines on top of that minimal core, way more isolated from each other and from the core compared to a current Leap in which all pieces are interconnected.
This is nuts.
Please explain.
Better now? Cheers. [1] https://en.opensuse.org/Portal:MicroOS -- Ancor González Sosa YaST Team at SUSE Software Solutions
On 2022-04-13 12:19, Ancor Gonzalez Sosa wrote:
On 4/13/22 12:00, Carlos E. R. wrote:
On 2022-04-13 10:21, Stefan Behlert wrote:
(Sending to both openuse-project as well as opensuse-factory. Please keep discussions on the -project list to make life easier for all.)
...
Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of "host OS", and the and the layer providing and supporting applications, which will be container (and VM) based.
You mean that we users will have to run our openSUSE Linux in a virtualized machine, instead of our real hardware machine?
That's not at all what I understood from the paragraph you quoted.
To my eyes, it says the operating system will be separated into two parts:
1) a small core including only what is needed to interact with the hardware and to manage it, no matter whether that's real or virtual hardware (somehow similar to MicroOS[1]) 2) all the applications and user-space tools that will run as containers or virtual machines on top of that minimal core, way more isolated from each other and from the core compared to a current Leap in which all pieces are interconnected.
This is nuts.
Please explain.
Better now?
No, you are saying that in a year or two I will have to reinstall my desktop machine as small core system that runs a virtual machine inside having the all real things I use. I don't see any advantage and a lot of complexity. For us plain users.
Cheers.
-- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
Hello Carlos, please see my comments inline. On Wed, 2022-04-13 at 12:27 +0200, Carlos E. R. wrote:
On 2022-04-13 12:19, Ancor Gonzalez Sosa wrote:
On 4/13/22 12:00, Carlos E. R. wrote:
On 2022-04-13 10:21, Stefan Behlert wrote:
(Sending to both openuse-project as well as opensuse-factory. Please keep discussions on the -project list to make life easier for all.)
...
Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of "host OS", and the and the layer providing and supporting applications, which will be container (and VM) based.
You mean that we users will have to run our openSUSE Linux in a virtualized machine, instead of our real hardware machine?
That's not at all what I understood from the paragraph you quoted.
To my eyes, it says the operating system will be separated into two parts:
1) a small core including only what is needed to interact with the hardware and to manage it, no matter whether that's real or virtual hardware (somehow similar to MicroOS[1]) 2) all the applications and user-space tools that will run as containers or virtual machines on top of that minimal core, way more isolated from each other and from the core compared to a current Leap in which all pieces are interconnected.
This is nuts.
Please explain.
Better now?
No, you are saying that in a year or two I will have to reinstall my desktop machine as small core system that runs a virtual machine inside having the all real things I use.
I don't see any advantage and a lot of complexity. For us plain users.
To my understanding workload focus that you seem to be worried about is for the server (such approach can be already seen on Leap Micro). I already had a conversation at the *weekly community meeting on the Workstation topic and I also touched it on Monday's meeting with Board. We'd like to collect community feedback on nowadays Leap workstation experience and ensure that we protect values that users like in general on Enterprise-y desktop/workstation. To my understanding plan is to have a workstation and community can participate on shaping it (Stefan B. mentioned on a Board a year of Linux desktop). Long story short idea was a blogpost related to the direction of Enterprise desktop linked with a high level survey for what people appreciate on Leap/SLE Wokrstation and make sure that we preserve the values. That idea seeemed to be accepted well on both sides. I believe it will be super useful to the newly forming Desktop workgroup within SUSE. We were just waiting for the official announcement and perhaps +two days to let the information sink in :-) There is another round of weekly meeting today in the evening. Feel free to join. [0] https://etherpad.opensuse.org/p/weeklymeeting
Cheers.
-- Cheers / Saludos,
Carlos E. R. (from 15.3 x86_64 at Telcontar)
-- Best regards Lubos Kocman openSUSE Leap Release Manager
Le mercredi 13 avril 2022 à 12:27 +0200, Carlos E. R. a écrit :
On 2022-04-13 12:19, Ancor Gonzalez Sosa wrote:
On 4/13/22 12:00, Carlos E. R. wrote:
On 2022-04-13 10:21, Stefan Behlert wrote:
(Sending to both openuse-project as well as opensuse-factory. Please keep discussions on the -project list to make life easier for all.)
...
Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of "host OS", and the and the layer providing and supporting applications, which will be container (and VM) based.
You mean that we users will have to run our openSUSE Linux in a virtualized machine, instead of our real hardware machine?
That's not at all what I understood from the paragraph you quoted.
To my eyes, it says the operating system will be separated into two parts:
1) a small core including only what is needed to interact with the hardware and to manage it, no matter whether that's real or virtual hardware (somehow similar to MicroOS[1]) 2) all the applications and user-space tools that will run as containers or virtual machines on top of that minimal core, way more isolated from each other and from the core compared to a current Leap in which all pieces are interconnected.
This is nuts.
Please explain.
Better now?
No, you are saying that in a year or two I will have to reinstall my desktop machine as small core system that runs a virtual machine inside having the all real things I use.
No, Ancor didn't write that either. ALP concepts are indeed focused on Server Workloads (since this is what mostly interest SUSE as a company), where we will focus on containers and virtual machines. For desktop like system, something similar to MicroOS Desktop / Silverblue is more aligned with the concepts around ALP. -- Frederic CROZAT Enterprise Linux OS and Containers Architect SUSE
On Wed, Apr 13, 2022 at 7:35 AM Frederic Crozat <FCrozat@suse.com> wrote:
Le mercredi 13 avril 2022 à 12:27 +0200, Carlos E. R. a écrit :
On 2022-04-13 12:19, Ancor Gonzalez Sosa wrote:
On 4/13/22 12:00, Carlos E. R. wrote:
On 2022-04-13 10:21, Stefan Behlert wrote:
(Sending to both openuse-project as well as opensuse-factory. Please keep discussions on the -project list to make life easier for all.)
...
Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of "host OS", and the and the layer providing and supporting applications, which will be container (and VM) based.
You mean that we users will have to run our openSUSE Linux in a virtualized machine, instead of our real hardware machine?
That's not at all what I understood from the paragraph you quoted.
To my eyes, it says the operating system will be separated into two parts:
1) a small core including only what is needed to interact with the hardware and to manage it, no matter whether that's real or virtual hardware (somehow similar to MicroOS[1]) 2) all the applications and user-space tools that will run as containers or virtual machines on top of that minimal core, way more isolated from each other and from the core compared to a current Leap in which all pieces are interconnected.
This is nuts.
Please explain.
Better now?
No, you are saying that in a year or two I will have to reinstall my desktop machine as small core system that runs a virtual machine inside having the all real things I use.
No, Ancor didn't write that either.
ALP concepts are indeed focused on Server Workloads (since this is what mostly interest SUSE as a company), where we will focus on containers and virtual machines.
For desktop like system, something similar to MicroOS Desktop / Silverblue is more aligned with the concepts around ALP.
And note, there is *no* technical reason we have to *require* that model for openSUSE ALP (in absence of a better name here...). We already have a layered repository model for Leap, that will probably continue and will allow us to do the traditional composition model that regular desktop Linux users generally prefer. That said, supporting a model that resists hysteresis (I refuse to call it immutable, because immutable it ain't) and makes it easier to do things like factory resets and such is very useful for offering the Linux desktop to a wider audience. -- 真実はいつも一つ！/ Always, there's only one truth!
Am 13.04.22 um 13:44 schrieb Neal Gompa:
That said, supporting a model that resists hysteresis (I refuse to call it immutable, because immutable it ain't) and makes it easier to do things like factory resets and such is very useful for offering the Linux desktop to a wider audience.
I find deleting my $HOME always proved to reset all misconfigurations. So I don't see how decoupling my home configuration files from the application from the OS helps that use case. Even AppImages tend to mess with $HOME freely :( Greetings, Stephan
On Wed, Apr 13, 2022 at 7:49 AM Stephan Kulow <coolo@suse.de> wrote:
Am 13.04.22 um 13:44 schrieb Neal Gompa:
That said, supporting a model that resists hysteresis (I refuse to call it immutable, because immutable it ain't) and makes it easier to do things like factory resets and such is very useful for offering the Linux desktop to a wider audience.
I find deleting my $HOME always proved to reset all misconfigurations. So I don't see how decoupling my home configuration files from the application from the OS helps that use case. Even AppImages tend to mess with $HOME freely :(
I'm not speaking to the value of virtualized applications. Indeed, in most cases that's totally overkill for desktops. I'm speaking more to what Frederic said about a Silverblue-like model. There are also some configuration files in /etc and /var which may be worth being able to reset, but for most desktop stuff, indeed it's mostly in $HOME. But we can apply this principle to home configuration too: we could use subvolumes for home directories and set up a snapshot regime and allow users to flow back and forth through them (like Time Machine). -- 真実はいつも一つ！/ Always, there's only one truth!
Le mercredi 13 avril 2022 à 07:54 -0400, Neal Gompa a écrit :
On Wed, Apr 13, 2022 at 7:49 AM Stephan Kulow <coolo@suse.de> wrote:
Am 13.04.22 um 13:44 schrieb Neal Gompa:
That said, supporting a model that resists hysteresis (I refuse to call it immutable, because immutable it ain't) and makes it easier to do things like factory resets and such is very useful for offering the Linux desktop to a wider audience.
I find deleting my $HOME always proved to reset all misconfigurations. So I don't see how decoupling my home configuration files from the application from the OS helps that use case. Even AppImages tend to mess with $HOME freely :(
I'm not speaking to the value of virtualized applications. Indeed, in most cases that's totally overkill for desktops. I'm speaking more to what Frederic said about a Silverblue-like model.
There are also some configuration files in /etc and /var which may be worth being able to reset, but for most desktop stuff, indeed it's mostly in $HOME. But we can apply this principle to home configuration
Agreed
too: we could use subvolumes for home directories and set up a snapshot regime and allow users to flow back and forth through them (like Time Machine).
Heh, you obviously looked at my desktop systems which have been running this for some years ;) -- Frederic CROZAT Enterprise Linux OS and Containers Architect SUSE
On Wed, Apr 13, 2022 at 7:58 AM Frederic Crozat <FCrozat@suse.com> wrote:
Le mercredi 13 avril 2022 à 07:54 -0400, Neal Gompa a écrit :
On Wed, Apr 13, 2022 at 7:49 AM Stephan Kulow <coolo@suse.de> wrote:
Am 13.04.22 um 13:44 schrieb Neal Gompa:
That said, supporting a model that resists hysteresis (I refuse to call it immutable, because immutable it ain't) and makes it easier to do things like factory resets and such is very useful for offering the Linux desktop to a wider audience.
I find deleting my $HOME always proved to reset all misconfigurations. So I don't see how decoupling my home configuration files from the application from the OS helps that use case. Even AppImages tend to mess with $HOME freely :(
I'm not speaking to the value of virtualized applications. Indeed, in most cases that's totally overkill for desktops. I'm speaking more to what Frederic said about a Silverblue-like model.
There are also some configuration files in /etc and /var which may be worth being able to reset, but for most desktop stuff, indeed it's mostly in $HOME. But we can apply this principle to home configuration
Agreed
too: we could use subvolumes for home directories and set up a snapshot regime and allow users to flow back and forth through them (like Time Machine).
Heh, you obviously looked at my desktop systems which have been running this for some years ;)
I was mostly speaking of my own experimental setup, but hey, nice to see someone else doing it too! :) -- 真実はいつも一つ！/ Always, there's only one truth!
Am 13.04.22 um 13:54 schrieb Neal Gompa:
There are also some configuration files in /etc and /var which may be worth being able to reset, but for most desktop stuff, indeed it's mostly in $HOME. But we can apply this principle to home configuration too: we could use subvolumes for home directories and set up a snapshot regime and allow users to flow back and forth through them (like Time Machine).
I feel like this should exist already - but let me ask anyway: under what condititions can you control subvolumes for home directories as user? I'm mostly interested in snapshotting dot directories - unless they are caches. Greetings, Stephan
On Wed, Apr 13, 2022 at 7:58 AM Stephan Kulow <coolo@suse.de> wrote:
Am 13.04.22 um 13:54 schrieb Neal Gompa:
There are also some configuration files in /etc and /var which may be worth being able to reset, but for most desktop stuff, indeed it's mostly in $HOME. But we can apply this principle to home configuration too: we could use subvolumes for home directories and set up a snapshot regime and allow users to flow back and forth through them (like Time Machine).
I feel like this should exist already - but let me ask anyway: under what condititions can you control subvolumes for home directories as user? I'm mostly interested in snapshotting dot directories - unless they are caches.
With a little elbow grease, I suppose we could do that too. The challenge is that you have to pre-determine which ones to create. We can kind of cheat and do that for .config, .mozilla, and a few others up front. -- 真実はいつも一つ！/ Always, there's only one truth!
Am 13.04.22 um 14:08 schrieb Neal Gompa:
On Wed, Apr 13, 2022 at 7:58 AM Stephan Kulow <coolo@suse.de> wrote:
Am 13.04.22 um 13:54 schrieb Neal Gompa:
There are also some configuration files in /etc and /var which may be worth being able to reset, but for most desktop stuff, indeed it's mostly in $HOME. But we can apply this principle to home configuration too: we could use subvolumes for home directories and set up a snapshot regime and allow users to flow back and forth through them (like Time Machine). I feel like this should exist already - but let me ask anyway: under what condititions can you control subvolumes for home directories as user? I'm mostly interested in snapshotting dot directories - unless they are caches.
With a little elbow grease, I suppose we could do that too. The challenge is that you have to pre-determine which ones to create. We can kind of cheat and do that for .config, .mozilla, and a few others up front. If just applications would behave:
coolo@nerissa#~>find .config/ -type d | grep Cache | wc -l 1327 It's insane 11GB below Greetings, Stephan
Le mercredi 13 avril 2022 à 14:11 +0200, Stephan Kulow a écrit :
Am 13.04.22 um 14:08 schrieb Neal Gompa:
On Wed, Apr 13, 2022 at 7:58 AM Stephan Kulow <coolo@suse.de> wrote:
Am 13.04.22 um 13:54 schrieb Neal Gompa:
There are also some configuration files in /etc and /var which may be worth being able to reset, but for most desktop stuff, indeed it's mostly in $HOME. But we can apply this principle to home configuration too: we could use subvolumes for home directories and set up a snapshot regime and allow users to flow back and forth through them (like Time Machine). I feel like this should exist already - but let me ask anyway: under what condititions can you control subvolumes for home directories as user? I'm mostly interested in snapshotting dot directories - unless they are caches.
With a little elbow grease, I suppose we could do that too. The challenge is that you have to pre-determine which ones to create. We can kind of cheat and do that for .config, .mozilla, and a few others up front. If just applications would behave:
coolo@nerissa#~>find .config/ -type d | grep Cache | wc -l 1327
It's insane 11GB below
Indeed. Just look at what kind of ugly workaround is needed to avoid backing those: https://github.com/fcrozat/rclone-container/blob/master/backup-to-restic :( We would need upstream to really follow XDG convention for storing cache.. -- Frederic CROZAT Enterprise Linux OS and Containers Architect SUSE
Dne středa 13. dubna 2022 14:13:27 CEST, Frederic Crozat napsal(a):
Le mercredi 13 avril 2022 à 14:11 +0200, Stephan Kulow a écrit :
Am 13.04.22 um 14:08 schrieb Neal Gompa:
On Wed, Apr 13, 2022 at 7:58 AM Stephan Kulow wrote:
Am 13.04.22 um 13:54 schrieb Neal Gompa:
There are also some configuration files in /etc and /var which may be worth being able to reset, but for most desktop stuff, indeed it's mostly in $HOME. But we can apply this principle to home configuration too: we could use subvolumes for home directories and set up a snapshot regime and allow users to flow back and forth through them (like Time Machine).
I feel like this should exist already - but let me ask anyway: under what condititions can you control subvolumes for home directories as user? I'm mostly interested in snapshotting dot directories - unless they are caches.
With a little elbow grease, I suppose we could do that too. The challenge is that you have to pre-determine which ones to create. We can kind of cheat and do that for .config, .mozilla, and a few others up front.
If just applications would behave: coolo@nerissa#~>find .config/ -type d | grep Cache | wc -l 1327 It's insane 11GB below
Indeed. Just look at what kind of ugly workaround is needed to avoid backing those: https://github.com/fcrozat/rclone-container/blob/master/backup-to-restic :( We would need upstream to really follow XDG convention for storing cache..
Well... I have there LibreOffice, Skype, Falkon, Chromium, Vivaldi, YakYak, Edge and Teams. 3 out of 8 related to MS. ;-) Followed by web rendering kernel from Chrome. LO is really shame, thought. -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
Am 13.04.22 um 13:34 schrieb Frederic Crozat:
No, Ancor didn't write that either.
ALP concepts are indeed focused on Server Workloads (since this is what mostly interest SUSE as a company), where we will focus on containers and virtual machines. I wonder how these virtual machines are deployed then? You might need less hardware support in the kernel for these, but the rest of the operating system for those is pretty much like what Carlos imagines for his Leap system, no?
So if we use the "host os" kernel together with the operating system meant for virtual machines we can still have what we need to have for the containerless OS, right? Greetings, Stephan
Le mercredi 13 avril 2022 à 13:53 +0200, Stephan Kulow a écrit :
Am 13.04.22 um 13:34 schrieb Frederic Crozat:
No, Ancor didn't write that either.
ALP concepts are indeed focused on Server Workloads (since this is what mostly interest SUSE as a company), where we will focus on containers and virtual machines. I wonder how these virtual machines are deployed then? You might need less hardware support in the kernel for these, but the rest of the operating system for those is pretty much like what Carlos imagines for his Leap system, no?
When you say "deployed", I assume you mean "created". In that case, there is several ways, either with an image-creation tool (kiwi, packer, suse studio express) or using a minimal VM as base and run some config management tool or use an installer. This part is not set in stone yet on ALP.
So if we use the "host os" kernel together with the operating system meant for virtual machines we can still have what we need to have for the containerless OS, right?
Yes, of course. But at least for ALP, this is not something we are focusing. If people in openSUSE community wants to still continue on this path, nobody will stop them. -- Frederic CROZAT Enterprise Linux OS and Containers Architect SUSE
------- Original Message ------- On Wednesday, April 13th, 2022 at 3:21 PM, Stefan Behlert <behlert@suse.com> wrote:
(Sending to both openuse-project as well as opensuse-factory. Please keep discussions on the -project list to make life easier for all.)
Moin,
In the last months many people have brought up the topic of "When will the next SLE major version come out?". Today we would like to give you a first update on the plans.
Since 2018, when SLE 15 was initially released a lot of things have changed, including requirements from users and customers, technologies, the speed of new versions of applications, languages and their libraries appearing.
Also the connection between Leap and SLE has changed. And while some bits and pieces got better, we firmly believe we can do better. SLE 15 is a great general purpose operating system, yet challenges with some use cases, now places of deployment, and the type of enhancement requests show that it's time for a successor.
With the next generation of Enterprise releases we want to tackle the above. Intending to do radical changes (regarding technology- but also design-wise) we choose "Adaptable Linux Platform" or short "ALP" as codename for that next generation. This indicates already that some things will be quite different than a "mere "SLE 15++ would be ;)
First and foremost, ALP will be developed in the open. We are not going to put the pieces together internally and then share outside, as in the past. No, we are creating and building in the openSUSE Build Service - in a project next to you :). You get to directly see to see what is going on and participate more easaily.
Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of "host OS", and the and the layer providing and supporting applications, which will be container (and VM) based.
You might say "This is very generic, can you tell us more?" - of course. In the upcoming weeks more and more will crystalize, and we will share as quickly and regularly as possible. This is just a first heads-up to inform you that we are in the process of setting everything up - from project to feedback channels, from documentation to testing.
Of course, you will have lots of other questions - how will contribution work, what impacts this has on LEAP and get-o-o, how migration could work, and many more. We kindly ask you for a little bit of patience. We promise we will share as soon as possible more details.
ciao, Stefan
-- Stefan Behlert, SUSE Software Solutions Product Management SUSE Linux Enterprise
Maxfeldstr. 5, D-90409 Nuernberg, Germany SUSE Software Solutions Germany GmbH, GF: Ivo Totev (HRB 36809, AG Nuernberg)
Hi, All this sounds pretty cool! Would ALP be considered as a "Leap Micro Desktop" then? -- Br, A.
On Fri, 2022-04-15 at 09:26 +0000, Attila Pinter wrote:
------- Original Message ------- On Wednesday, April 13th, 2022 at 3:21 PM, Stefan Behlert <behlert@suse.com> wrote:
(Sending to both openuse-project as well as opensuse-factory. Please keep discussions on the -project list to make life easier for all.)
Moin,
In the last months many people have brought up the topic of "When will the next SLE major version come out?". Today we would like to give you a first update on the plans.
Since 2018, when SLE 15 was initially released a lot of things have changed, including requirements from users and customers, technologies, the speed of new versions of applications, languages and their libraries appearing.
Also the connection between Leap and SLE has changed. And while some bits and pieces got better, we firmly believe we can do better. SLE 15 is a great general purpose operating system, yet challenges with some use cases, now places of deployment, and the type of enhancement requests show that it's time for a successor.
With the next generation of Enterprise releases we want to tackle the above. Intending to do radical changes (regarding technology- but also design-wise) we choose "Adaptable Linux Platform" or short "ALP" as codename for that next generation. This indicates already that some things will be quite different than a "mere "SLE 15++ would be ;)
First and foremost, ALP will be developed in the open. We are not going to put the pieces together internally and then share outside, as in the past. No, we are creating and building in the openSUSE Build Service - in a project next to you :). You get to directly see to see what is going on and participate more easaily.
Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of "host OS", and the and the layer providing and supporting applications, which will be container (and VM) based.
You might say "This is very generic, can you tell us more?" - of course. In the upcoming weeks more and more will crystalize, and we will share as quickly and regularly as possible. This is just a first heads-up to inform you that we are in the process of setting everything up - from project to feedback channels, from documentation to testing.
Of course, you will have lots of other questions - how will contribution work, what impacts this has on LEAP and get-o-o, how migration could work, and many more. We kindly ask you for a little bit of patience. We promise we will share as soon as possible more details.
ciao, Stefan
-- Stefan Behlert, SUSE Software Solutions Product Management SUSE Linux Enterprise
Maxfeldstr. 5, D-90409 Nuernberg, Germany SUSE Software Solutions Germany GmbH, GF: Ivo Totev (HRB 36809, AG Nuernberg)
Hi,
All this sounds pretty cool! Would ALP be considered as a "Leap Micro Desktop" then? I think the scope and all deliverables are still in progress.
-- Br, A.
-- Best regards Lubos Kocman openSUSE Leap Release Manager
Project,
With the next generation of Enterprise releases we want to tackle the above. Intending to do radical changes (regarding technology- but also design-wise) we choose "Adaptable Linux Platform" or short "ALP" as codename for that next generation. This indicates already that some things will be quite different than a "mere "SLE 15++ would be ;)
been digging around about ALP and next level suse and container or virtualised and abstraction stuff and all and now I am personally wondering how much longer opensuse will be the distro I can make use of. I tend to run on dated and aged hardware, leftover stuff and such. Smallish servers, routers and firewalls and pretty basic stuff, all with opensuse. Then I found and read about some hardware stuff here, I have never actually heard about, various levels of x64 ABI, e.g. x86-84-v3 for example. <https://code.opensuse.org/leap/features/issue/72> Of course such stuff must exist, as the x64 world came a long way. <https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex> Every now and then I did worry how long kernels would support my aged x86-64 processors of different vendors. Mostly old amd based stuff though, very few intel. So I ran some script extracting the "version" of the supported ABI, as of course ;) opensuse glibc would not support some fancy parameter just yet it turns out. Stephen Kitt's script at: <https://unix.stackexchange.com/questions/631217/how-do-i-check-if-my-cpu-supports-x86-64-v2> long story short, all my systems here support mostly -v1 only, two of them support v2, thats all. No -v3 let alone -v4 or such neat stuff How much longer will opensuse (leap or whatever it get called) support for kind of basic linux use, also for desktop but on dated hardware. I strongly dislike e-waste and all. I kind of remember the switch over to -x64 when opensuse became 64bit only ;p even though thats also some years back now. Still, I am kinda scared that almost all my hardware is essentially x86-64-v1 only, at most -v2 only. What to make of that issue 72 on code opensuse? comment of lkocman <https://code.opensuse.org/leap/features/issue/72#comment-1048> Thanks for insight. Is opensuse leap still the distro to go for these days with these major changes on the horizon? Back in the days many years ago I kind of thought in an idealistic open source software world everbody would grab the distributions and software in their source shape and form and compile and build it to their hardware themselves and everbody running ist happily on whatever hardware they had at ones disposal. ty.
On Sat, 2022-04-16 at 21:51 +0200, cagsm wrote:
Project,
With the next generation of Enterprise releases we want to tackle the above. Intending to do radical changes (regarding technology- but also design-wise) we choose "Adaptable Linux Platform" or short "ALP" as codename for that next generation. This indicates already that some things will be quite different than a "mere "SLE 15++ would be ;)
been digging around about ALP and next level suse and container or virtualised and abstraction stuff and all and now I am personally wondering how much longer opensuse will be the distro I can make use of. I tend to run on dated and aged hardware, leftover stuff and such. Smallish servers, routers and firewalls and pretty basic stuff, all with opensuse. Then I found and read about some hardware stuff here, I have never actually heard about, various levels of x64 ABI, e.g. x86-84-v3 for example. <https://code.opensuse.org/leap/features/issue/72>
Of course such stuff must exist, as the x64 world came a long way. < https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low- level-sys-info.tex>
Every now and then I did worry how long kernels would support my aged x86-64 processors of different vendors. Mostly old amd based stuff though, very few intel. So I ran some script extracting the "version" of the supported ABI, as of course ;) opensuse glibc would not support some fancy parameter just yet it turns out.
Stephen Kitt's script at: < https://unix.stackexchange.com/questions/631217/how-do-i-check-if-my- cpu-supports-x86-64-v2>
long story short, all my systems here support mostly -v1 only, two of them support v2, thats all. No -v3 let alone -v4 or such neat stuff How much longer will opensuse (leap or whatever it get called) support for kind of basic linux use, also for desktop but on dated hardware. I strongly dislike e-waste and all. I kind of remember the switch over to -x64 when opensuse became 64bit only ;p even though thats also some years back now. Still, I am kinda scared that almost all my hardware is essentially x86-64-v1 only, at most -v2 only.
What to make of that issue 72 on code opensuse? comment of lkocman <https://code.opensuse.org/leap/features/issue/72#comment-1048>
Regarding the x86_64-v3 that was a brand new information for me as well. So I just tracked it in the jira for migration. I think your feedback is exactly what we need. E.g. in a way that one of values that user like is the support for older hardware that sits under my desk. I'd like to publish the survey for feedback about Leap values that users appreciate soon. Stay tuned.
Thanks for insight. Is opensuse leap still the distro to go for these days with these major changes on the horizon?
Back in the days many years ago I kind of thought in an idealistic open source software world everbody would grab the distributions and software in their source shape and form and compile and build it to their hardware themselves and everbody running ist happily on whatever hardware they had at ones disposal.
ty.
-- Best regards Lubos Kocman openSUSE Leap Release Manager
On Wed, Apr 20, 2022 at 4:06 PM Lubos Kocman <lubos.kocman@suse.com> wrote:
Regarding the x86_64-v3 that was a brand new information for me as
I am starting to getting worried about the future of some? many? of my opensuse leap systems. For example I was didding into this stuff i found on code opensuse org <https://code.opensuse.org/leap/features/issue/79> and now I am kind of confused with for example just looking at one of my cpu/apu system here. That code feature article talking mainly about SSE3 and when taking into considering the cat /proc/cpuinfo output where there are no SSE3 given, but SSE4A (amd hw here) but then again reading about my cpu/core/tech that it supposedly does have SSE3 and that SSE4A is always at least based on previous SSE versions and added ontop (SSE4, SSE4.1 SSE4.2 being different stuff to SSE4A though). and this ABI check only putputs -v1 here for this cpu/apu. my stuff being: cpu/apu: AMD A8-3870 APU with Radeon(tm) HD Graphics cat /proc/cpuinfo | grep -i sse flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall arat npt lbrv svm_lock nrip_save pausefilter this site telling me that it ought to have SSE3 <https://www.cpu-world.com/CPUs/K10/AMD-A8-Series%20A8-3870%20AD3870WNZ43GX.html> and this as well: <https://en.wikipedia.org/wiki/List_of_AMD_accelerated_processing_units#Lynx:_%22Llano%22_(2011)> Please dont abandon us -v1 ABI hardware owners and I read about falling back or reverting to Tumbleweed 32bit again(!) for non-SSE3 owners and stuff? please no? Then again, I have some few intel based hw as well, that are mayb even older, core2 quad stuff, which lists its features support with SSE2, SSE3, SSE4_1 in the flags of proc/cpuinfo but lists this still as ABI -v1 only. I wonder where opensuse will end up going for what ABI version exactly of x86_64 and what features? also why doesnt the current leap 15.4 kernel and its proc/cpuinfo doesnt list the SSE3 flag for the AMD cpu above when it ought to have this according to those websites and according to some articles that higher SSEx versions are supposed to be based on lower SSE versions? Anyone care about ewaste? thanks lots.
Hi, -yes. Scaring. It's supposed to be what the market/customers want. Ordinary users? I don't know enough yet but,., Developers in the free run and promises. Regards
participants (11)
-
Ancor Gonzalez Sosa -
Attila Pinter -
cagsm -
Carlos E. R. -
Frederic Crozat -
Johan Dot -
Lubos Kocman -
Neal Gompa -
Stefan Behlert -
Stephan Kulow -
Vojtěch Zeisek