
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