i think they mean more of what commands have actually been run and which of the just commands are ac
i think they mean more of what commands have actually been run and which of the just commands are actually active, kind of like
ESo more for checking the state. There'd need to be separation between scripts ran as a user and by the system but it's doable
Hthats what i gathered, which would help in cleaning up and reorging the just files
MThat would be helpful to easily get the status.
Hheck a cool thing it would let us do is even make a template to just 
well it would be cool for things that can do it without needing to do extra steps after a reboot
ujust set-states "file.conf" and it would just apply all the selected states well it would be cool for things that can do it without needing to do extra steps after a rebootMyou could ship a set-states default, source it, and then iterate through. The ujust commands are mostly bash scripts now.
AIt sounds like reinventing configuration management
Bcheckout "huh" too, if you're looking for a similar thing in Go by the same people.
Hthe funny thing is that i did try to use bubbletea for my project but it was way overkill for what i needed 
Byeah same. that's why huh is nice. all the bubbletea bits are wrapped nicely out of the way.
Hstarting to get tired of rewriting the tui at this point, gone from pure bash to golang with bubbletea to my own choice dialogs and now youre saying i didnt need to do that
Hhaha
BI feel your pain. I've rewritten blincus in go, go + web, wails, and now bash.
Hhttps://github.com/HikariKnight/quickpassthrough/tree/dev
thats what i have been working on when i had the time
thats what i have been working on when i had the time
GitHub
A project to remove the complexity of setting up GPU passthrough for qemu - GitHub - HikariKnight/quickpassthrough at dev
Bwow that's awesome!
Hwhole goal is to make it easier to setup, and a lot faster to setup.
sadly its mostly just been a vacation project for the most part
sadly its mostly just been a vacation project for the most part
FThe thing why I made an issue is that I don't like I forget things which I modify. I like when I type rpm-ostree initramfs-etc & see which files are tracked.
but some interesting observations are made which I didn't think of. Like I forgot that just scripts are also run by system, so there needs to be a clear separation. States is something I don't understand fully. Is it like you make multiple just scripts into ` preset or something?
but some interesting observations are made which I didn't think of. Like I forgot that just scripts are also run by system, so there needs to be a clear separation. States is something I don't understand fully. Is it like you make multiple just scripts into ` preset or something?
MThat's a pretty cool project. VFIO is such a rabit hole.
Hthink of states as a list telling you which switches are flipped and which are set to off on a dashboard
Hits something i have wanted to simplify for a long while, the original bash version (which is in the main branch) was a proof of concept in simplifying it
J@KyleGospo one more day until our terminal!
Hoh? is prompt going to become standard
KGitHub
Adds the new Logo Menu GNOME extension
Adds Prompt Integration via user-flatpak-manager, nautilus-open-any-terminal, and xdg-terminal-exec.
DO NOT SHIP UNTIL STABLE ORG.GNOME.PROMPT
Adds Prompt Integration via user-flatpak-manager, nautilus-open-any-terminal, and xdg-terminal-exec.
DO NOT SHIP UNTIL STABLE ORG.GNOME.PROMPT
Kon bazzite too
Hnice
Hi want to try it out, didnt manage to get it working when i tried it (but im also not that familiar with the gitlab web ui so i probably downloaded the wrong thing) so i figured to wait until stable
Jyeah he's close to a stable release.
Jthis was the final piece we needed. everything else we need is already being worked on upstream.
Jbut no one was fixing the terminal ux, so having this show up and be mostly feature complete really helps.
Jand it's performant af, you won't need to use a 3rd party terminal to get all the performance goodies
FWhat is performance of the terminal? How fast it executes commands?
Jgpu rendering, etc.
JJGNOME developer Christian Hergert recently demonstrated how Linux terminal emulators have the potential of running much faster
FI just run normal commands without TUI apps like nvtop, htop etc., so I guess I won't see a difference
FBut I will try Prompt for container integration
TDefinitely want to try out Prompt, but it seems like waiting for stable is a good call given the devel flatpak seems a little broken for me
MAre you on nvidia?
TYes
MGitLab
OS: Arch Linux GNOME 45.1, Wayland session HW: NVIDIA 3060, proprietary driver 545.29.02 gtk4 1:4.13.3+r44+g
TWell that'd do it
TProbably because prompt pulls in a newer gtk with this bug than what the rest of the system is using
Kwhich is also likely because it's in the nightly gnome repo
TYep
JWill Nvidia users have this problem with a stable release in flathub?
TMy other flatpaks seem to be fine, but I'm guessing yes whenever the gtk4 in the runtime gets updated (unless they push a fix before then)
TSeems like
GDK_DEBUG=gl-prefer-glA stable release of prompt against the current runtime will probably be fine
MYeah this appears to be a bigger issue for gtk to solve.
TActually I'm not sure. Looks like the current runtime would need to be updated before a stable release would work since prompt depends on things not in the current one
S