Apologies if this doesn't fit here I was curious if any of the system 76 stuff was considered for b

Apologies if this doesn't fit here

I was curious if any of the system 76 stuff was considered for being included:

https://support.system76.com/articles/system76-software/

The power management stuff could be useful though it looks like you'd have to install some drivers for certain hardware. As far as I understand the power management tool works for other hardware.

I have a thelio to setup at some point, not sure if it'll be ublue or not.

I'm am guessing currently this isn't included, but just wanted to point it out.

If this should be posted elsewhere, please let me know where.

System76 Support

System76 Software (Install - Other Operating Systems)

Learn what software is needed to use other OSes and install them

akdev•5/12/23, 1:33 PM

Fedora uses power-profile-daemon

akdev•5/12/23, 1:34 PM

The rest of the stuff there seems very opinionated and not really what we want to do with ublue

That said there’s nothing stopping anyone from creating a custom System76 image with everything loaded

akdev•5/12/23, 1:34 PM

The dkms stuff would need some work

dreamyuki•5/12/23, 1:37 PM

dkms is not supported on ostree fedora anyway

akdev•5/12/23, 1:38 PM

Probably easier to do what the person above did with xone, just build the driver statically from source and ship the drivers in the final image

j0rge•5/12/23, 4:06 PM

is it worth discussing shipping the xone thing that way and then swapping it out later or do we want to err on the side of consistency?

j0rge•5/12/23, 4:07 PM

cuz I can go either way, the user wouldn't notice anything

bsherman•5/12/23, 4:14 PM

the akmods work is basically done in March, the PR was just too big and had extra stuff that caused some heartburn.

I reached out to David last night about it, but if he doesn't respond on it, i'll probably just branch the PR to make corrections

Arcitec•5/12/23, 4:22 PM

@hermmm I am working on the new firstboot system to make the following changes:

Yafti can now be disabled in recipe.ymlrecipe.yml so that it isn't installed and won't auto-run anymore.
Fixing the bug/issue where the autostart script is never updated again after being installed for a user, thus never updating itself in the future. Users currently have stale scripts.
Making sure the autostart script is immutable so that users cannot mess with it (we will use symlinks to immutable locations).
Minimizing the mutable surface, but I cannot think of any ways to get rid of it entirely. So there will still be a mutable file in
```
/etc/profile.d
```
```
/etc/profile.d
```
.

This is the plan so far. I've implemented plenty of it so far, but am interested in hearing if anyone has other ideas.

Arcitec•5/12/23, 4:27 PM

I'm also undecided whether we should install the minimalistic

/etc/profile.d

/etc/profile.d

script even if yafti is disabled.

Pros:

We could make it auto-delete the stale
```
~/.config/autostart
```
```
~/.config/autostart
```
link if yafti is disabled. So if user jumps between ublue versions that disabled yafti, they won't have the leftover link.

Cons:

Someone might not like having a script there at all times even if its only purpose is "if yafti enabled, ensure symlink, else delete symlink".

I think the pros outweigh the cons. Thoughts?

MMichael Apologies if this doesn't fit here I was curious if any of the system 76 stuff ...

bsherman•5/12/23, 4:28 PM

My thoughts are pretty similar to @akdev's ... While it would be great to enable provide all the system76 stuff in ublue-os/main ... I think their choice of distribution/tooling doesn't generally mesh well with ublue / Silverblue.

That said, if there was someone with System76 hardware who really wanted to tackle this, I think it could be a great community image, built downstream, even hosted within the ublue-os org, like a sister to bluefinbluefin...

AArcitec I'm also undecided whether we should install the minimalistic `/etc/profile.d` s...

bsherman•5/12/23, 4:30 PM

this is still scoped to startingpointstartingpoint repo, right?

(btw, did you see my response in discussions?)

Bbsherman My thoughts are pretty similar to @akdev's ... While it would be great to enable...

MichaelOP•5/12/23, 4:30 PM

Completely understand, if I end up getting into ublue, then I'll have to consider it.

Bbsherman this is still scoped to `startingpoint` repo, right? (btw, did you see my resp...

Arcitec•5/12/23, 4:31 PM

Yeah it's the startingpoint repo, which is the only one that auto-starts yafti at the moment. It's super fragile at the moment, so all these changes are necessary. It seems like a solid plan to me but perhaps I'm missing some small change that could make it even better.

Bbsherman this is still scoped to `startingpoint` repo, right? (btw, did you see my resp...

Arcitec•5/12/23, 4:32 PM

Oh you responded to the restructuring discussion? I'll check now

Arcitec•5/12/23, 4:34 PM

I read, that sounds great. And yeah don't burn yourself out. We don't need to move everything at once. One small file at a time is enough.

Arcitec•5/12/23, 4:34 PM

I'll reply there now though

MMichael Completely understand, if I end up getting into ublue, then I'll have to conside...

bsherman•5/12/23, 4:34 PM

I should clarify... when I say "sister to bluefi" I don't even mean as opinionated and stylized as bluefin... though, it could be what you want it to be

I should probably say more like a sister to startingpointstartingpoint or nvidianvidia which are built on

main

main

.

The idea in my head, it ublue-os/system76ublue-os/system76 would be the image for users of that hardware, and other downstream images could in turn use it.

Another thought... if we could work with System76 to adjust how they do this (eg, use akmod instead of kmod) and maybe host a repo of RPM packages instead of requiring a lot of local

make

make

more of this could be potentially brought into

main

main

. Especially after having been proven out semewhere.

AArcitec Yeah it's the startingpoint repo, which is the only one that auto-starts yafti a...

bsherman•5/12/23, 4:35 PM

yeah, nutshell summary of my thoughts... what I see in your proposals is cleanup, standardization, forward looking for automation and subsequent projects to have a good pattern to follow. good stuff.

But also, I'm happy the custom first boot stuff is staying in starting point for the moment.

bsherman•5/12/23, 4:37 PM

If we (community) want to get more opinionated with

main

main

and push a firstboot experience, sure we can, but I am personally very pleased with the approach that was taken. main/nvidiamain/nvidia try to stays "stock-ish" so there's an improved foundation on which all the cool/custom stuff can be built.

Bbsherman I should clarify... when I say "sister to bluefi" I don't even mean as opinionat...

MichaelOP•5/12/23, 4:38 PM

I think I got ya. If I was going to focus on one, I'd want to work on something for my capture PC first. Needs a driver that doesn't belong in main but that I would need to run ublue on a pc I would use for capturing. Maybe a "creator" edition or something. Time will tell. Long ways to go before I'm anywhere ready to try it haha.

MMichael I think I got ya. If I was going to focus on one, I'd want to work on something ...

bsherman•5/12/23, 4:40 PM

if the driver is available as akmod, maybe it could go in main

we do want some hardware enablement there, it's just a bit vague as still only do that via udev rules and nvidia

Bbsherman if the driver is available as akmod, *maybe* it could go in main 😄 we do want ...

MichaelOP•5/12/23, 4:42 PM

I don't think it is haha. But that may be something I have to look at. I have been installing via dkms. Don't think it would ever be a fit for main haha.

Edit: I believe the source is available at least.

Bbsherman If we (community) want to get more opinionated with `main` and push a firstboot ...

Arcitec•5/12/23, 4:43 PM

I totally agree with you on that. Firstboot being the "scriptable/hackable" one, and main + nvidia being the "clean cores" is a great setup.

The way I've been modernizing startingpointstartingpoint is almost at the point where main + nvidia could be refactored to be scripts for it. It's now flexible enough to be able to run a core set of scripts/actions for every image, and then having per-recipe scripts listed for the specific flavors.

The only thing missing is a way to create a recipe.ymlrecipe.yml matrix where there's a "core recipe" and then the per-variant changes such as removing certain packages, adding extras, etc. It could already be implemented if the flavors used scripts for those per-flavor changes though.

Example:
vauxite-recipe.yml: runs scripts/vauxite/*.shvauxite-recipe.yml: runs scripts/vauxite/*.sh in addition to the common scripts.

I dunno if it's worth pursuing such a feature to make it possible to move main + nvidia to the same system as startingpoint though. It'd be nice for users but not sure if there's value for us.

MMichael I don't think it is haha. But that may be something I have to look at. I have be...

bsherman•5/12/23, 4:44 PM

it is in the back of my head to solve the dkms build problem... i started once, but life is busy... there are definitely a few things out there we need...

and I will say, I have built dkms for silverblue OCI, but my roadblock was getting the secure boot signing done... and for ublue specific, we need it to work for all users...

so, priorities... getting akmods done first, then eventually solving the dkms issues.

AArcitec I totally agree with you on that. Firstboot being the "scriptable/hackable" one,...

bsherman•5/12/23, 4:45 PM

for all but the question at the end LOL. i'm not sure what you mean by moving "main+ nvidia" to the same system as starting point?

Bbsherman 💙 for all but the question at the end LOL. i'm not sure what you mean by mov...

Arcitec•5/12/23, 4:47 PM

It was created to be flexible but wasn't made with main+nvidia in mind. It could be improved on that front but it would already be really easy to do. Example:

Every image would run all scripts in scripts/pre/*.shscripts/pre/*.sh and scripts/post/*.shscripts/post/*.sh
vauxite-recipe.ymlvauxite-recipe.yml: Also runs vauxite.shvauxite.sh which in turn runs autostart.sh vauxite/${SCRIPT_MODE}autostart.sh vauxite/${SCRIPT_MODE}, which would cause it to execute every script in scripts/vauxite/pre/*.shscripts/vauxite/pre/*.sh and scripts/vauxite/post/*.shscripts/vauxite/post/*.sh at the appropriate stages.

It's doable. I am not saying it's a good idea though. But it would mean that we work on 1 build system for everything.

Arcitec•5/12/23, 4:48 PM

But it's such a lofty idea that I didn't even plan it! I am not sure I even like it.

Arcitec•5/12/23, 4:49 PM

Everything you've currently automated in main+nvidia could definitely be ported to this.

Arcitec•5/12/23, 4:49 PM

But what's the value of doing that? Beyond having to maintain only 1 system.

Arcitec•5/12/23, 4:50 PM

bsherman•5/12/23, 4:50 PM

I think i'm tracking with you. But I think we definitely just do the cleanup/standardization stuff you've suggested first... and you can make these types of improvements in starting point... and if we then see value after you have it smoothed out there, it could be a discussion/proposal on making the change to main

Arcitec•5/12/23, 4:51 PM

Yeah. I am just asking your thoughts since I am not sure I like the idea at all. Just saying that it's possible.

But yeah, time to focus on smoothing out the standardization first!

AArcitec It was created to be flexible but wasn't made with main+nvidia in mind. It could...

fiftydinar•5/12/23, 4:52 PM

I just want to remind you of this article:

https://ometer.com/preferences.html

fiftydinar•5/12/23, 4:52 PM

I don't think that having tons of variants in 1 ISO is a good idea.

fiftydinar•5/12/23, 4:53 PM

Oh, build system

fiftydinar•5/12/23, 4:53 PM

Nothing, ignore

Arcitec•5/12/23, 4:53 PM

Haha yes it's just the build system.

j0rge•5/12/23, 5:28 PM

@bsherman can you mark your PR as a draft? that way notification filters work instead of doing WIP in the changelog

Jj0rge @bsherman can you mark your PR as a draft? that way notification filters work in...

bsherman•5/12/23, 5:29 PM

yes. good call.

Jj0rge @bsherman can you mark your PR as a draft? that way notification filters work in...

bsherman•5/12/23, 5:30 PM

umm... trying to find where i do that

bsherman•5/12/23, 5:30 PM

ah, found it... sneaky text

Arcitec•5/12/23, 5:33 PM

@bsherman Yes I had the same issue. That draft link is very sneaky!

bsherman•5/12/23, 5:35 PM

i have some kind of RubberDuck

syndrome... often i have to type the thing I can't figure out (like that draft sneaky text) and then i'll immediately find the solution.

it's humbling

AArcitec I'm also undecided whether we should install the minimalistic `/etc/profile.d` s...

xyny•5/12/23, 5:35 PM

Looking good. I wouldn't mind a leftover file in /etc/profile.d/?/etc/profile.d/? or

~/.config/autostart

~/.config/autostart

, but maybe just having one in /etc//etc/ feels better than having one in

~/

~/

. The only con I see in that is the fact that the "yafti toggle" wouldn't disable everything yafti-related in the build.

Xxyny Looking good. I wouldn't mind a leftover file in `/etc/profile.d/?` or `~/.confi...

Arcitec•5/12/23, 5:37 PM

Great to hear.

Yeah the "it won't disable everything" is what I dislike too.

I am also unsure what actually happens when there is a dead symlink in

~/.config/autostart

~/.config/autostart

. If the OS complains or just moves along like nothing.

Either way I am trying to think of ways to make sure the users see zero errors if they move between flavors of ublue. Some that use it and some that don't.

Arcitec•5/12/23, 5:39 PM

I'll do some tests in a VM to see what's the impact of dead autostart symlinks.

xyny•5/12/23, 5:40 PM

I feel like startingpoint is evolving so much (into a way more customizable durection, though), that it's kinda losing my original vision for it; being a lean and thin template where all code is thoroughly documented, easy to grow and stretch, but understandable in it's entirety. It's turned more into a framework-as-a-template, or it's turning. from kickstart.nvim to NvChad.

xyny•5/12/23, 5:40 PM

But maybe I don't mind that. I'd just like to make sure that every bit of it's code is documented well.

Arcitec•5/12/23, 5:40 PM

It's still lean and thin. Thinner than before