Speaking with Frank, this week is career week at WPI and a mob scene. There are zero rooms to reserve.

I think it makes the most sense to push the meeting off to the 23rd so we can get a room with proper A/V, etc.

As for a topic, a couple people have asked me about container based distros. I think this would be a great topic.

I've recently gotten heavy involved in k8s deployment stuff and I've had to wrap my brain around this stuff.

Fedora, Container OS, Rancher OS, Blend OS, the list goes on.

I think there's an interesting conversation around how user friendly, secure, etc. this various options are.

Is this something people would be interested in?

Later,
Tim.







On Thu, Feb 9, 2023, 4:08 PM Joel <joelgroup@gmail.com> wrote:

That makes sense with a meeting last week. . 

See everyone on the 16th. . 

Joel 

On February 9, 2023 3:30:18 PM Tim Keller <turbofx@gmail.com> wrote:

We are not having a meeting on the 9th, we'll have a meeting on the 16th.

Thanks,
Tim.

On Wed, Feb 8, 2023 at 9:52 PM Joel via WLUG <wlug@lists.wlug.org> wrote:

Hi, 

Are having a WLUG meeting as tomorrow 2/9  is the second Thursday? 

Thank you, 

Joel 

On February 6, 2023 10:46:54 AM Joshua Stone via WLUG <wlug@lists.wlug.org> wrote:

Hey all,

I thought I'd share a side project I've been working on, which involves building containers with Nvidia kernel modules and userspace components that work as bootable OS images thanks to "container-native" support within Fedora Silverblue.

This approach has several advantages over the traditional package management model for installing out-of-tree drivers, including:

1) Have the install process and QA shift from client side to server side, making a CI/CD model of driver distribution possible.

2) Eliminate the possibility of update failures (i.e., will a , as only container builds with successful runs will be committed to a container registry and updates are delivered with an "immutable" model

3) Modules are signed with one key from a central repo, ensuring that only one key has to be enrolled for all client systems for enabling secure boot support

4) Enable the possibility of supporting multiple driver release streams. i.e., give users the freedom to rebase on 525xx, 520xx, 470xx series drivers, etc, as well as pin to a specific image snapshot in case of a driver regression

5) Have the ability to download a pre-built bootable image from a central repo, or build an image locally with further customizations thanks to the flexibility of the Containerfile format

6) Give maintainers a broader framework for debugging regressions, namely being able to boot into a specific snapshot listed in a bug report

It's true that Nvidia has been the source of many hardware issues. I refuse to own an Nvidia card because of this. But many Linux users use Nvidia, which I thought would be a great motivation for working on a container-native approach to out-of-three driver support.

More info here:




- Josh

_______________________________________________
WLUG mailing list -- wlug@lists.wlug.org
To unsubscribe send an email to wlug-leave@lists.wlug.org


_______________________________________________
WLUG mailing list -- wlug@lists.wlug.org
To unsubscribe send an email to wlug-leave@lists.wlug.org
Create Account: https://wlug.mailman3.com/accounts/signup/
Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/
Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/TRIDUAV2EJ4FFZQOC5ICO4IHVJYDPADR/


--
I am leery of the allegiances of any politician who refers to their constituents as "consumers".