awesome! I'd love to have this in bluefin and kyle says we'll need this in nvidia too?
awesome! I'd love to have this in bluefin and kyle says we'll need this in nvidia too?
KOn nvidia it's useful for loading the driver and unloading nouveau
KLittle more bulletproof
KAlso doesn't need the same huge build time increase since only a file in /etc/ is needed
KAnd not a complete rebuild every update
Jooh!
Jif someone who knows anything about displaylink has a minute ^^^
KCurrently disabled due to it breaking gamemode under f39
KGonna restore it as desktop only here today
Hi will see if i can make something more ublue generic then, is there a specific repo this would fit properly into?
Jnot sure, I'm not familiar with most of this heh
Jlet's see what the others say, I'm sure we can find the best place
Hok, right now this is just some logic i wrote into bazzite-hardware-setup which does a few things based on the users hardware, notably kargs and initramfs argument related things
Hi noticed a while back it would wipe all my initramfs and dracut arguments when the hw version changed 
EI would personally recommend config
EPackage hardware setup as an RPM
Hwell i know nothing about packaging RPMs, but it shouldnt be a problem to decouple the initramfs part of hardware setup and make it its own thing to be used across ublue for things like hardware-setup and other boottime configs
EIf we can get this genericized, I don't mind packaging it. I think that'll ultimately be an easier way to distribute it. Would be cool to consolidate initramfs stuff and possibly other helpers so that people can architect their own hardware setup implementations more easily
JHmaybe the "solution" here is to take a page out of windows book and make a "brew shell" that has brew first in the path and thats the only way to use brew directly (this more a joke and last resort workaround i guess)
(this more a joke and last resort workaround i guess)Hat least i remember that was a thing back when i had to use windows
JI was thinking a container but I'd rather not have to do that
Jor maybe putting the homebrew $PATH statement in one of the other dotfiles but the internet's full of confusing statements so it could be one or any combo of .profile, .bashrc, etc.
Hback when i did a lot of python version dependent development i had aliases to set different paths depending on which python venv i had to use so i would just have 
$REALPATH, $PATH27, $PATH3 and $PATHCUSTOM and the aliases just exported those depending on what i needed. it was messy but i needed a solution fast to just get working Hi dont really think there will be a one solution fits all when it comes to that brew issue just because of how environment variables are handled in all platforms
Jwell we only have to fix it for ourselves
Jlike maybe in a terminal config
Hi know, but most platforms handle envs in the same way, you either have it and whatever is first takes precedence or you dont have it (which is why you would have shells with correct paths applied for things like git bash, visual studio, etc in windows)
also because windows for some reason has i believe a 256 character limit for its $PATH or something weird like that
also because windows for some reason has i believe a 256 character limit for its $PATH or something weird like that
Joh I think we might be past that already lol
Hyeah but i know that was a limitation for windows as i hit that limit very fast when i just tried to make my workflow work on windows back when i did dev work for a company
Hthey got tired of trying to force windows to work for me they just gave me permission to use linux where i just set up my dev environment in less than 5 mins
Hi think the options might be
- brew init command (activate brew $PATH) when needed
- dedicated "brew shell" using whatever shell the user has configured
- container/distrobox (adds more hoops though)
Hneither is a good solution
Mor encourage people to use nix profiles instead, which don't expose binaries of intermediate dependencies to the environment
Jno thanks
Mi don't think you'll get homebrew to fix its broken deployment model
EBrews environment/path would need to precede the hosts. Otherwise it will always take priority. Unfortunately, I think the best way around that is a container
Jyeah I'm always back to the root problem of not having a terminal with container support. 
EI was just thinking about the same thing
Jlet's see what the podmansh folks come back with I guess, dan seemed interested in at least investigating the use case
EWould be awesome
JI posted on the flathub discourse, maybe there's a way to tell flatpak to just ignore that stuff
Jok after work I'll pr it out of the justfile and then just do a brew container
ESounds good!
JJI'll just put this in a container in a distrobox
KCan you add that as part of this PR? Then I can update Bazzite's yafti to point there at the same time
KThe distrobox change I mean
Jit'll take me a while to do it
JI'd like to get this in to prevent people from installing it easily in the meantime while I make a post