I suspect this might be helpful for minor integration challenges or library upgrades like others have mentioned, but in my experience, the vast majority of Rust compilation issues fall into one of two buckets:
1. Typos, oversights (like when adding new enum variants), etc. All things which in most cases are solved with a single keystroke using non-LLM LSPs.
2. Wrong assumptions (on my part) about lifetimes, ownership, or overall architecture. All problems which I very much doubt an LLM will be able to reason about, because the problems usually lie in my understanding or modelling of the problem domain, not anything to do with the code itself.
I tried the same about a month ago and was unable to get anywhere, probably due to being very new to the custom keyboard scene and having only a very vague understanding of how qmk/rmk/vial/keymaps fit together. Thanks for writing this up, I might give it another go now!
The custom keyboard bubble is really deep and filled with many, many different kind of setups which makes research not really easy.
To get you started:
- QMK is probably the most mature firmware for non-wireless devices and widely used. Probably the best starting point to get in touch with all the different concepts of keymap layers, one-shot modifiers, hold-tap-mechanics, ...
- Via/Vial is based on QMK and simply tries to provide a GUI for instant and live configuration of the keyboard, instead of doing it by code.
- ZMK is also very stable and designed for wireless usage (battery consumption) but also REALLY complex because of the toolchain (at least in my opinion)
- RMK, KMK, ... are all different kind of firmwares trying to do something different or better or just in a different language like rust or python. Most of the time these kind of firmware expect some kind of "basic knowledge". So I would start with the classics QMK or ZMK.
Thanks for writing all this down! I've written a lot of Rust, which was why I was drawn to RMK initially, but ran into a lot of the same headaches as the author, but without the perseverance to resolve any of them.
I did manage to get QMK working eventually, but without VIA/L the prospect of having to flash the two parts of my Ferris Sweep every single time I wanted to fine tune it, and having already spent a lot of time just getting that far, completely burned me out on the project.
I think impact can have a big influence on mechanical hard drive longevity, so it could be that the way the ServerPartDeals drives were sourced, handled or shipped compromised them.
Postgres upgrades were actually annoying the last time I did, where I had to explicitly import data from a previous version into the new one, instead of the software just automatically detecting that the data was a version behind and doing whatever to upgrade the format.
This would probably not have been as big of a headache, if it wasn't because it was running in a container, and was deployed as part of a separate project, meaning CloudNativePG (which probably handles this for you) was not an option.
I think it is a reference to the Chernobyl mini-series, where the Dyatlov character responds to the news of the level of radioactive contamination as "Not great, not terrible", unaware that their measuring equipment is actually maxed out, hiding the true scale of the problem.
The Chernobyl mini-series is highly recommended. It is a classic example of how arrogance and stupidity are closely related. (Where stupidity is defines as knowing the correct thing to do, but ignoring the facts or available infomation.)
If anyone watches a TV show with the assumption that they are getting an accurate view of history, then I wish them luck in life, since they will probably need it.
Tell that to the people who were displaced because of the accident, which of course, is proven truth. The last part of your statement is petty, based on ignorance of how life itself is extremely difficult to report after the fact when facts are so easily denied.
That particular series was presented with very heavy emphasis on how "accurate" it was to real events, though, and many, many people thought it a documentary.
I set up a Talos bare metal cluster about a year ago, and documented the whole process on my website. Feel free to reach out if you have any questions!
I've only used Bottlerocket in relation to EKS, and even then my interaction with it was pretty limited so I have no idea how it fares as a standalone operating system.
My one big experience with it was the recent bug which (as I recall) attempted to harden the system by marking memory pages as no-execute, which caused virtual runtime languages like Java to basically break entirely when running on a node using this version of Bottlerocket.
It was fixed pretty quickly, but it did feel like a weird thing to slip through...
It is precisely the large impact on GDP that poses a threat to the host nation. When companies like Novo Nordisk are such a huge part of the economy, they can exert disproportionate influence on society itself.
Our economy is absolutely benefiting from Novo Nordisk's size right now, but if/when their demand weakens or they're out-competed, we're going to end up with a lot of unemployed biotechnicians and massive roads to Kalundborg which will need to be maintained.
I'd be very interested to know as well. Although the last time I attempted to run kanidm in a containerized fashion it left a lot to be desired.
The software is (perhaps expectedly) not really built to support semi-ephemeral lifetimes, so it took quite a few hacks to get it running in Kubernetes the last time I tried.
As I recall, the primary issue I had was with exposing the certman-provided Let's Encrypt certificates to the kanidm process inside the container in a reasonable fashion. I don't think I found an elegant way of signalling to the kanidm process that the certificates had been renewed and should be reloaded.
This is actually great. I maintain a library[1] for interacting with the Robot interface using Rust, but testing is heavily gated because of the potential costs it might incur, which is why a lot of the purchasing/cancellation APIs haven't been thoroughly tested.
With this billing, I'll be able to do thorough integration testing without breaking the bank.
And of course with hourly billing, horizontal scaling becomes much more feasible.
I haven't actually. I believe they do offer modest amounts of credit for creating useful libraries, documentation and such targeting their platform, but I never really looked into it.
> At the moment there is still a one-time order fee for dedicated servers
For (some) dedicated servers, I think. Last time I checked the lowest tiered dedicated servers didn't have any setup fees. If it's not mentioned, assumed it'll remain.
As diggan said, there's usually at least one of their dedicated server offerings for which setup fees are waived, so I figure my tests would use the API to find out which one and use it :)
1. Typos, oversights (like when adding new enum variants), etc. All things which in most cases are solved with a single keystroke using non-LLM LSPs.
2. Wrong assumptions (on my part) about lifetimes, ownership, or overall architecture. All problems which I very much doubt an LLM will be able to reason about, because the problems usually lie in my understanding or modelling of the problem domain, not anything to do with the code itself.