yeah same. that's why huh is nice. all the bubbletea bits are wrapped nicely out of the way.
yeah 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
SJFGitHub
... or remove packages that aren't there.
By @EyeCantCU
Took from Bazzite.
Please check if I did changes correctly.
By @EyeCantCU
Took from Bazzite.
Please check if I did changes correctly.
FThanks
Bi'm not aware of an upstream bug for this, it's just "the way it is" and we've had to rehash it a few times because people don't believe me when I say so 
This is exactly why I have made a point to err on the side of keeping our
This is exactly why I have made a point to err on the side of keeping our
-mainYeah I'm just hoping to have one place to point people so we don't have to keep explaining it over and over
Byeah... i'm searing a bit for another explanation online but not finding one
BIt really seems like something which should be covered in this doc: https://coreos.github.io/rpm-ostree/container/#rebasing-a-client-system
BI added a comment to the issue.
Bit is possible to disable but not remove becuase of very basic fact that it is using a OCI IMAGE with some packages disabling works with some it doesnt but from what i have seen not being disabled is mostly function of is it a dependency of something
