So Leap is transitioning to a 16 variation?
It is still possible to make something very much like Leap 15 from the ALP sources if there is enough community interest in helping to support packages. It in many cases may even be migratable from Leap 15, A couple of us worked on a proof of concept during SUSE's last hackweek look forward to a talk on it at this years conference.
-- Simon Lees (Simotek) http://simotek.net
@Dominique Thanks for the detailed response on the question. @Simon Thanks also for your response, it seems like the "something very much like Leap 15" is what a number of posters here, and myself, would be interested in . . . i.e, the logical extension of the current Leap concept/technology. I'm running both TW and Leap 15.5 . . . and somewhere "in between" would be the "sweet spot" for me, the end user on aging hardware. I also run Debian Bookworm and Sid . . . seems like of late Sid is "more stable" than TW, but let's say they are roughly "equivalent" . . . Debian has "unstable," "testing" and "stable" . . . "testing" is the famed "middle way" . . . having newer packages, but which have first have run through the crucible of "unstability" . . . . That's where the "gently rolling" concept of future iterations of Leap would come in, i.e., not a total rewrite of the system, for each new day (or whatever it is) vs . . . rolling in new packages to a generally "stable" base, that doesn't run into massive package upgrades every few months, etc. On the new idea of Leap 16 using "containers" . . . have yet to mess with that concept in linux. It sounds like what Apple did with the last of the OSX variations, where they went to apfs formating and it was possible to set up . . . ??? semi-fluid "containers" that were not "solid" like a "partition" . . . but would be similar, place to install a distro?? Apfs formatting seemed to just mess up the system . . . . So, the point of containers is that they are "easier" to make and/or erase?? Or, this is something to do with SSD technology, where "boundaries" like partitions have less meaning, and all of the data is actually "shared" by the entire disk, so containers just gently sketch in the general area where the data will be stored, but it isn't just there, it's everywhere??
On 3/31/23 05:11, Fritz Hudnut wrote:
It is still possible to make something very much like Leap 15 from the ALP sources if there is enough community interest in helping to support packages. It in many cases may even be migratable from Leap 15, A couple of us worked on a proof of concept during SUSE's last hackweek look forward to a talk on it at this years conference.
-- Simon Lees (Simotek) http://simotek.net
@Dominique
Thanks for the detailed response on the question.
@Simon
Thanks also for your response, it seems like the "something very much like Leap 15" is what a number of posters here, and myself, would be interested in . . . i.e, the logical extension of the current Leap concept/technology. I'm running both TW and Leap 15.5 . . . and somewhere "in between" would be the "sweet spot" for me, the end user on aging hardware.
I also run Debian Bookworm and Sid . . . seems like of late Sid is "more stable" than TW, but let's say they are roughly "equivalent" . . . Debian has "unstable," "testing" and "stable" . . . "testing" is the famed "middle way" . . . having newer packages, but which have first have run through the crucible of "unstability" . . . .
That's where the "gently rolling" concept of future iterations of Leap would come in, i.e., not a total rewrite of the system, for each new day (or whatever it is) vs . . . rolling in new packages to a generally "stable" base, that doesn't run into massive package upgrades every few months, etc.
So at the moment atleast for the base system we will have to work with whatever SUSE is providing us and we don't know what that is quite yet which makes those questions still somewhat hard to answer. Once its more clear on what period of maintenance updates that we will get as the community so it might end up being more of a slowly rolling model or it might have an update channel. SUSE's plan currently is to release different components with different lifecycles at different times. So one month the python component might be updated with a new version then 2-3 months later maybe the perl or one of the webserver components will be updated. Given that python versions will probably have overlapping support there is a chance we can bundle them all together and do a point release every 3-6 months, or whether it will be some form of slowly rolling, but one thing that's certain is it will probably need to be more frequent.
On the new idea of Leap 16 using "containers" . . . have yet to mess with that concept in linux. It sounds like what Apple did with the last of the OSX variations, where they went to apfs formating and it was possible to set up . . . ??? semi-fluid "containers" that were not "solid" like a "partition" . . . but would be similar, place to install a distro?? Apfs formatting seemed to just mess up the system . . . . So, the point of containers is that they are "easier" to make and/or erase?? Or, this is something to do with SSD technology, where "boundaries" like partitions have less meaning, and all of the data is actually "shared" by the entire disk, so containers just gently sketch in the general area where the data will be stored, but it isn't just there, it's everywhere??
I believe it is more something to do with managing support and lifecycles, in the SLE-15 model there was a list of 10,000ish packages that we guarenteed would get security updates and wouldn't change for the 11-13 year lifecycle we offered LTSS customers. In practice there was a number of issues with this approach, for example one customer may have written a specific python app to work with python 3.6 and now that it does its job they are happy to leave it for X number of years which is what was offered with SLE-15. While another (or even the same) customer may now be at the point of wanting to run some other app that only works with python 3.8 or later. What containerization means is rather then depending on the python version in the Host OS we could decide to ship a container containing one version of python for 8-10 years to make the category A customers happy, while then every 2 years we could release a container with a newer version of python that we say we will support for 3 years. Then instead of the customer running there python app on the standard host OS they can just run it in the container with the version that works best for them. Note I have no idea what the actual lifecycles will be that is still being worked on. Another example could be that we release an "Apache Webserver Container" that is just supported for running Apache. Then if we needed to change ABI of a system lib to fix a security issue or need to swap a background library we can do that. Where as currently we don't know what a customer is using any given lib for so we have to maintain abi compatibility and can't easily remove it. Many of the issues that containers are solving for SUSE aren't as big of an issue for openSUSE Leap where the support times are smaller and we don't guarantee strict ABI support between minor versions. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 3/30/23 23:09, Simon Lees wrote:
What containerization means is rather then depending on the python version in the Host OS we could decide to ship a container containing one version of python for 8-10 years to make the category A customers happy, while then every 2 years we could release a container with a newer version of python that we say we will support for 3 years. Then instead of the customer running there python app on the standard host OS they can just run it in the container with the version that works best for them. Note I have no idea what the actual lifecycles will be that is still being worked on.
This is all very interesting, and I'm looking forward to how it all shakes out. Are any other distros doing anything like this? We're actually kind of doing this for Python now. We have a requirement to do coding for machine learning, and there are some Python modules to help, but these modules aren't available in the standard Leap 15.4 build. The quick and safe solution was to install Anaconda, which is sort of like a containerized Python environment. It installs completely in the user's home directory, so it doesn't twaddle any of the operating system bits. Each user can have their own differing versions of Python that are independent from the base operating system. Works nice. I have another concern about security compliance. Big organizations may have requirements to do various kinds of security scanning (Nessus) and may require installation of systems to monitor security status and compliance. McAfee's (now Trellix) Host Based Security System (HBSS) comes to mind. HBSS is kind of like a massive root-kit that has to be tailored for each operating system and distribution. HBSS currently supports up to Leap 15.3, showing that the vendor has a lot of work to do to keep up with versions. They may offer support for 15.4 after it's EOL. The concern is that an organization may outlaw usage of an OS that isn't compatible with their information assurance suite. I'd think that an OS with dancing containers would make security compliance difficult. Please tell me I'm wrong! Another thought: would ALP be compatible with SELinux? Regards, Lew
On 3/31/23 12:28, Joe Salmeri wrote:
MicroOS comes with SELinux in enforcing mode and without AppArmor.
Do you think that TW will transitioin to SELinux and stop using AppArmor ?
I read a study years ago comparing SELinux and AppArmor. It basically said that while SELinux is technically superior, it's very difficult to configure. AppArmor on the other hand was much easier to get right. The net effect was that AppArmor gave superior performance in most cases due to the problems getting SELinux configured correctly. Regards, Lew
On Fri, Mar 31, Joe Salmeri wrote:
MicroOS comes with SELinux in enforcing mode and without AppArmor.
Do you think that TW will transitioin to SELinux and stop using AppArmor ?
SELinux and AppArmor have both Pros and Cons and are for different use cases. Which leads to the situation, that there are setups like MicroOS, where SELinux fits better, and other like Tumbleweed, where AppArmor fits better. Today I don't see a need to move Tumbleweed to SELinux, but as the world in continuously moving, the situation can be a different one tomorrow. Means: today there are no such plans, but nobody knows what will come tomorrow. Before people complain in 10 years, that we wrote that TW will not move to SELinux ;) Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
Today I don't see a need to move Tumbleweed to SELinux, but as the world in continuously moving, the situation can be a different one tomorrow.
Means: today there are no such plans, but nobody knows what will come tomorrow.
Thanks Thorsten for your perspective. I was hoping that the direction was not changing ( at least not right now ) as I have read similar articles which talked about issues like what Andreas pointed out. -- Regards, Joe
On 3/31/23 17:30, Lew Wolfgang wrote:
On 3/30/23 23:09, Simon Lees wrote:
What containerization means is rather then depending on the python version in the Host OS we could decide to ship a container containing one version of python for 8-10 years to make the category A customers happy, while then every 2 years we could release a container with a newer version of python that we say we will support for 3 years. Then instead of the customer running there python app on the standard host OS they can just run it in the container with the version that works best for them. Note I have no idea what the actual lifecycles will be that is still being worked on.
This is all very interesting, and I'm looking forward to how it all shakes out. Are any other distros doing anything like this?
We're actually kind of doing this for Python now. We have a requirement to do coding for machine learning, and there are some Python modules to help, but these modules aren't available in the standard Leap 15.4 build. The quick and safe solution was to install Anaconda, which is sort of like a containerized Python environment. It installs completely in the user's home directory, so it doesn't twaddle any of the operating system bits. Each user can have their own differing versions of Python that are independent from the base operating system. Works nice.
I have another concern about security compliance. Big organizations may have requirements to do various kinds of security scanning (Nessus) and may require installation of systems to monitor security status and compliance. McAfee's (now Trellix) Host Based Security System (HBSS) comes to mind. HBSS is kind of like a massive root-kit that has to be tailored for each operating system and distribution. HBSS currently supports up to Leap 15.3, showing that the vendor has a lot of work to do to keep up with versions. They may offer support for 15.4 after it's EOL.
The concern is that an organization may outlaw usage of an OS that isn't compatible with their information assurance suite. I'd think that an OS with dancing containers would make security compliance difficult. Please tell me I'm wrong!
Personally i'm unsure how this all works, but with the growth in popularity of containers I guess its something they'll have to solve. As a related note as part of certification for certain things the contents of the containers will still be completely built by SUSE.
Another thought: would ALP be compatible with SELinux?
The plan is to have SELinux in enforcing mode by default atleast in all the SUSE products, depending on what we do with openSUSE this might be a bit hard for us unless we get to the point tumbleweed can also do enforcing by default. The core system binaries have been built without apparmor support so apparmor won't be possible at this stage. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hello we have some options :-) I recommend to attend https://events.opensuse.org/conferences/oSC23 to all of those concerned. We'll have session about Leap Next planning as well as updates from ALP. People can ask in person or watch recordings to get more context. The pace of ALP development is quite fast and this is a nice opportunity to get a usable overview of where are we now and upcoming timeline and be able to ask questions. Cheers Lubos On Fri, 2023-03-31 at 18:31 +1030, Simon Lees wrote:
On 3/31/23 17:30, Lew Wolfgang wrote:
On 3/30/23 23:09, Simon Lees wrote:
What containerization means is rather then depending on the python version in the Host OS we could decide to ship a container containing one version of python for 8-10 years to make the category A customers happy, while then every 2 years we could release a container with a newer version of python that we say we will support for 3 years. Then instead of the customer running there python app on the standard host OS they can just run it in the container with the version that works best for them. Note I have no idea what the actual lifecycles will be that is still being worked on.
This is all very interesting, and I'm looking forward to how it all shakes out. Are any other distros doing anything like this?
We're actually kind of doing this for Python now. We have a requirement to do coding for machine learning, and there are some Python modules to help, but these modules aren't available in the standard Leap 15.4 build. The quick and safe solution was to install Anaconda, which is sort of like a containerized Python environment. It installs completely in the user's home directory, so it doesn't twaddle any of the operating system bits. Each user can have their own differing versions of Python that are independent from the base operating system. Works nice.
I have another concern about security compliance. Big organizations may have requirements to do various kinds of security scanning (Nessus) and may require installation of systems to monitor security status and compliance. McAfee's (now Trellix) Host Based Security System (HBSS) comes to mind. HBSS is kind of like a massive root-kit that has to be tailored for each operating system and distribution. HBSS currently supports up to Leap 15.3, showing that the vendor has a lot of work to do to keep up with versions. They may offer support for 15.4 after it's EOL.
The concern is that an organization may outlaw usage of an OS that isn't compatible with their information assurance suite. I'd think that an OS with dancing containers would make security compliance difficult. Please tell me I'm wrong!
Personally i'm unsure how this all works, but with the growth in popularity of containers I guess its something they'll have to solve. As a related note as part of certification for certain things the contents of the containers will still be completely built by SUSE.
Another thought: would ALP be compatible with SELinux?
The plan is to have SELinux in enforcing mode by default atleast in all the SUSE products, depending on what we do with openSUSE this might be a bit hard for us unless we get to the point tumbleweed can also do enforcing by default. The core system binaries have been built without apparmor support so apparmor won't be possible at this stage.
-- Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 4/6/23 01:45, Lubos Kocman via openSUSE Factory wrote:
Hello
we have some options :-)
I recommend to attend https://events.opensuse.org/conferences/oSC23 to all of those concerned.
We'll have session about Leap Next planning as well as updates from ALP.
Would it be worth trying to setup a Hybrid partly virtual session to have an ALP discussion for people who can't join in person, maybe on the last day so we can summarise any of the talks.
People can ask in person or watch recordings to get more context.
The pace of ALP development is quite fast and this is a nice opportunity to get a usable overview of where are we now and upcoming timeline and be able to ask questions.
Cheers
Lubos
On Fri, 2023-03-31 at 18:31 +1030, Simon Lees wrote:
On 3/31/23 17:30, Lew Wolfgang wrote:
On 3/30/23 23:09, Simon Lees wrote:
What containerization means is rather then depending on the python version in the Host OS we could decide to ship a container containing one version of python for 8-10 years to make the category A customers happy, while then every 2 years we could release a container with a newer version of python that we say we will support for 3 years. Then instead of the customer running there python app on the standard host OS they can just run it in the container with the version that works best for them. Note I have no idea what the actual lifecycles will be that is still being worked on.
This is all very interesting, and I'm looking forward to how it all shakes out. Are any other distros doing anything like this?
We're actually kind of doing this for Python now. We have a requirement to do coding for machine learning, and there are some Python modules to help, but these modules aren't available in the standard Leap 15.4 build. The quick and safe solution was to install Anaconda, which is sort of like a containerized Python environment. It installs completely in the user's home directory, so it doesn't twaddle any of the operating system bits. Each user can have their own differing versions of Python that are independent from the base operating system. Works nice.
I have another concern about security compliance. Big organizations may have requirements to do various kinds of security scanning (Nessus) and may require installation of systems to monitor security status and compliance. McAfee's (now Trellix) Host Based Security System (HBSS) comes to mind. HBSS is kind of like a massive root-kit that has to be tailored for each operating system and distribution. HBSS currently supports up to Leap 15.3, showing that the vendor has a lot of work to do to keep up with versions. They may offer support for 15.4 after it's EOL.
The concern is that an organization may outlaw usage of an OS that isn't compatible with their information assurance suite. I'd think that an OS with dancing containers would make security compliance difficult. Please tell me I'm wrong!
Personally i'm unsure how this all works, but with the growth in popularity of containers I guess its something they'll have to solve. As a related note as part of certification for certain things the contents of the containers will still be completely built by SUSE.
Another thought: would ALP be compatible with SELinux?
The plan is to have SELinux in enforcing mode by default atleast in all the SUSE products, depending on what we do with openSUSE this might be a bit hard for us unless we get to the point tumbleweed can also do enforcing by default. The core system binaries have been built without apparmor support so apparmor won't be possible at this stage.
-- Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
participants (7)
-
Andrei Borzenkov -
Fritz Hudnut -
Joe Salmeri -
Lew Wolfgang -
Lubos Kocman -
Simon Lees -
Thorsten Kukuk