> /bin and /sbin, needed for system boot. /usr/bin and /usr/sbin for normal runtime.
Nowadays most Linux systems boot with initramfs, that is a compressed image that includes everything the system needs to boot, so you're basically saying /bin and /sbin is useless.
Yes of course it can break. The point is that the stuff needs to be in initramfs. "includes everything" has an implicit "when working".
What seems bad about it to you? Initrd means you only need /boot (or equivalent) to be working at boot time, which seems nice to me. And looking at mine, the image is smaller than the kernel, so it's not wasting a ton of space.
More than once I've run into weird issues with missing filesystem drivers and other important things that caused me major grief during an emergency.
Sure it could be blamed on shitty distro maintenance and development but a better architecture would be putting essential things like filesystem drivers in /boot without this extra kludge of rebuilding an initrd (that you hopefully didn't forget to do before typing reboot) which depends on a pile of config files set just right (and oh by the way different in literally every distro).
A folder in boot could still be missing drivers, though.
Rebuilding an image isn't a big factor there, it's a tradeoff between making setup a bit more annoying versus making it a bit easier to manage your boot files.
> initrd seems like an enormous kludge that was thrown together temporarily and became the permanent solution.
Eh, kinda. That's where "essential" .ko modules are packed into - those that system would fail to boot without.
Alternative is to compile them into kernel as built-ins, but from distro maintainers' perspective, that means including way too many modules, most of which will remain unused.
If you're compiling your own kernel, that's a different story, often you can do without initrd just fine.
The issue I have with `nix-shell` is that the evaluation time is long, so if you need to run the script repeatedly it may take a long time. `nix shell` at least fix this issue by caching evaluations, but I think uv is still faster.
Years of experience working in Enterprise and complex systems.
And that is all on point with the criticism: while an AI can design a new language based in an existing language like Clojure, we need actual experienced people to design new interesting languages that add new constraints and make Software Engineering as a whole better. And we are also killing with AI the possibility of new people getting up to speed and becoming a future Rich Hickey.
> And we are also killing with AI the possibility of new people getting up to speed and becoming a future Rich Hickey.
Not sure I am on board with this part... I find LLMs in particular to be great teachers specifically for getting up to speed to becoming future Rich Hickey.
it is indeed a great teacher but there are times where it hallucinates and sticks to the hallucinated content even after several iteration unless human in the loop breaks it. i've wasted hours believing what LLM hallucinated.
my learnings are a lot of microdoses of things that I usually don't work on in a day to day so i don't want to spend time reading about it but yes this sort of learning would be otherwise impossible so gotta thank LLM for that.
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.
Nowadays most Linux systems boot with initramfs, that is a compressed image that includes everything the system needs to boot, so you're basically saying /bin and /sbin is useless.
reply