I am working (mostly vibecoded) a Git history explorer in Go+modernc.org/Tk9.0: https://github.com/thiagokokada/gitk-go. It is heavily inspired in gitk, this is why the name and usage of Tk for the interface.
The reason for it was because after testing multiple Git history explorers, I still think nothing beats the gitk. Sublime Merge is probably the only alternative that I would seriously consider but I don't really like the UI and the fact that it is proprietary (I am not against proprietary software but I prefer an opensource solution when available). Other alternatives have some bugs or the interface few too slow. gitk itself is mostly fine, but sadly it tries to load the whole repository in memory and this is causing issues every time I try to navigate through nixpkgs (I can see the memory consumption going through the roof while the UI slow down to a crawl).
gitk-go loads a batch of commits (1000 by default) and once you get at the end of the list it loads more. I also add a few features that I miss from gitk, for example if you do any change in the repository (change branches, add files to stash, etc) it will automatically reflect in the UI.
Again, the code is mostly vibecoded since this is the first time I decided to try this from scratch. The code works well for my use cases and it is enough to replace gitk for me, but I can't guarantee there is no bugs and the amount of tests are small. But still, it was fun to see something that I wanted to create for a while (I had this idea for a long time since the issues with gitk that I was having) finally taking form. Probably the program is not useful for anyone but me, but if anything this is a feature, not a bug.
Nix with Flakes never randomly break, I still have projects from 3 or 4 years ago that I can still run `nix build` and getting it running. Yes, if you try to update the `flake.lock` this may introduce breakages, but this is expected if you're pining `nixos-unstable` instead of a stable branch.
I am using purego indirectly in two pet projects of mine. While it has its own issues it definitely solves the issue of cross-compilation.
In this particular case it may be that they will need to write a wrapper to abstract differences between the systemd C API if it is not stable, but at least they still can compile a binary from macOS to Linux without issues.
The other issue as other said is to use journalctl and just parse the JSON format. Very likely that this would be way more stable, but not sure if it is performant enough.
This looks like backwards. I would understand using a LLM to generate a GitHub Actions YAML, but always running your action from a Markdown file seems extremely wasteful in terms of resources.
Edit: ok, looking at example it makes more sense. The idea is to run specific actions that are probably not well automated, like generating and keeping documentation up-to-date. I hope people don't use it to automate things like CI runs though.
I don't think it is only for bragging rights, while in a vacuum the mainline kernel should be good enough for gaming, it is not really good when there are multiple tasks competing for the CPU attention (and this is especially bad for gaming because this can create a frame spike, ruining the game experience especially for multiplayer games). I think fixing this particular issue is one of the reasons Bore scheduler was created.
Try running a long video conversion job that uses up all cores while running a game, no matter how much you fiddle with scheduling priority the performance in the game might drop by 50% and frame times will spike multiple times over. Even if you try reserving some cores for the game, performance will still be much lower.
At least for Bazzite, Nobara and CachyOS, there is the SteamOS desktop option that boots directly to Steam's Big Picture that is quite unconventional in some ways (e.g. this desktop mode kinda also acts as a display manager, so there is the option to boot to your desktop from Big Picture mode and this option is generally broken without specific integration with the session manager).
Sure this could probably be a package in a more "traditional distro", but I'm almost sure most people don't expect their Display Manager to be replaced with Steam when they install a package.
> Sure this could probably be a package in a more "traditional distro", but I'm almost sure most people don't expect their Display Manager to be replaced with Steam when they install a package.
You can add steam big picture mode as a session type which would let you pick it from the login manager (the same as if you had both GNOME & KDE installed, for example). There would be no need to replace anything.
Doesn't work as seamless, NixOS has this option but you can't quit the session unless you go to TTY and type `steam --kill` (the button for `Switch to desktop` exists but doesn't work). For it to work AFAIK you need to give SteamOS kind like a Display Manager permission (and also have some shims that does the actual work for switching sessions).
I don't think they're downplaying. Most users will be perfectly happy with the included KDE application for screenshots/screen capture (it is really fully featured, much better than the default options for Windows or macOS).
And they're not saying that no third party applications will work either, it is just that old screenshot applications that were created for X11 will need to be ported.
In the end that is not really much different from macOS dropping Rosetta in the next release of macOS (yes, I know there is a difference of effort). Old applications will stop working, applications that still get support will eventually support it (if they don't support Wayland already).
The reason for it was because after testing multiple Git history explorers, I still think nothing beats the gitk. Sublime Merge is probably the only alternative that I would seriously consider but I don't really like the UI and the fact that it is proprietary (I am not against proprietary software but I prefer an opensource solution when available). Other alternatives have some bugs or the interface few too slow. gitk itself is mostly fine, but sadly it tries to load the whole repository in memory and this is causing issues every time I try to navigate through nixpkgs (I can see the memory consumption going through the roof while the UI slow down to a crawl).
gitk-go loads a batch of commits (1000 by default) and once you get at the end of the list it loads more. I also add a few features that I miss from gitk, for example if you do any change in the repository (change branches, add files to stash, etc) it will automatically reflect in the UI.
Again, the code is mostly vibecoded since this is the first time I decided to try this from scratch. The code works well for my use cases and it is enough to replace gitk for me, but I can't guarantee there is no bugs and the amount of tests are small. But still, it was fun to see something that I wanted to create for a while (I had this idea for a long time since the issues with gitk that I was having) finally taking form. Probably the program is not useful for anyone but me, but if anything this is a feature, not a bug.
reply