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