The infrastructure layer would have to create the interface for a custom operator to reconcile with. There are a fair bit of bridges out there to enable this. There's now Kubevirt for VM management and Metal3 for baremetal configurations as well. If the operator isn't readily available from the selection of community solutions, the platform team would have to implement it themselves. Kubernetes is really just a glorified etcd store for any manifest schema (CRD) you implement alongside a reconciling controller. It just so happens that the default use case of it was designed for container orchestration. Once you look past Kubernetes as purely a container orchestration tool, you can use its paradigm to implement your own declarative reconciliation logic for anything.
I know that's not a satisfactory answer but the infrastructure models (for VMs or Windows machines) would have to be implemented into the new paradigm bit by bit to make this work. This used to be something that was laborious but you could have Claude Code cook up something for the loop interfaces and have a working controller prototype in a short time.
Not saying the integration is going to be simple though. The team has to actually buy in and prioritise building the controller logic for each platform solution. And that includes reviewing the code slop that Claude creates.
But the downside is that you do get the Cider team constantly messaging and asking for reasons you won't switch. I gave feedback that their Vim bindings were broken (it would sometimes fail on holding down directional hjkl for no reason) but I'm not sure if they've fixed it since I left in 2023.
Spin up one in the US central region instead of an instance near your satellite office. The bottleneck is usually not your shell connection to the instance but the connections from the instance to all the infrastructure that's mainly based in the US.
I'm not familiar with the jargon either, but based on some reading it comes down to how the latest kernel treats process preempts.
Postgres uses spinlocks to hold shared memory for very critical processes. Spinlocks are an infinite loop with no sleep to attempt to hold a lock, thus "spinning". Previous kernels allowed spinlocking processes to run with PREEMPT_NONE. This flag tells the kernel to let the locking process complete their work before doing anything. Now the latest kernel removed this functionality and is interrupting spinlocking processes. So if a process that is holding a lock gets interrupted, all other postgres spinlocks processes that need the same lock spin in place for way longer times, leading to performance degradation.
What I don't understand is that, if coding agents are making coding obsolete, why do these vibe coders not choose a language that doesn't set their users' compute resources on fire? Just vibe rust or golang for their cli tools, no one reviews code slop nowadays anyway /s.
I do not understand the insistence on using JavaScript for command line tools. I don't use rust at all, but if I'm making a vibe coded cli I'm picking rust or golang. Not zig because coding agents can't handle the breaking changes. What better test of agentic coders' conviction in their belief in AI than to vibe a language they can't read.
If this is a skill issue, feel free to let me know. In general Claude Code is decent for tooling. Onduty fullstack tooling features that used to sit ignored in the on-caller ticket queue for months can now be easily built in 20 minutes with unit tests and integration tests. The code quality isn't always the best (although what's good code for humans may not be good code for agents) but that's another specific and directed prompt away to refactor.
However, I can't seem to get Opus 4.6 to wire up proper infrastructure. This is especially so if OSS forks are used. It trips up on arguments from the fork source, invents args that don't exist in either, and has a habit of tearing down entire clusters just to fix a Helm chart for "testing purposes". I've tried modifying the CLAUDE.md and SPEC.md with specific instructions on how to do things but it just goes off on a tangent and starts to negotiate on the specs. "I know you asked for help with figuring out the CNI configurations across 2 clusters but it's too complex. Can we just do single cluster?" The entire repository gets littered with random MD files everywhere for directory specific memories, context, action plans, deprecated action plans, pre-compaction memories etc. I don't quite know which to prune either. It has taken most of the fun out of software engineering and I'm now just an Obsidian janitor for what I can best describe as a "clueless junior engineer that never learns". When the auto compaction kicks in it's like an episode of 50 first dates.
Right now this is where I assume is the limitation because the literature for real-world infrastructure requiring large contexts and integration is very limited. If anyone has any idea if Claude Opus is suitable for such tasks, do give some suggestions.
Thanks HN folks for all the comments. To clarify a bit, the cables are pulled through PVC conduits under the flooring before being buried in cement. Currently the hypotheses for why the cable disintegrated so quickly is hydrolysis and paint solvents. Singapore is extremely humid but this doesn't explain why the exposed cabling on the other end is still healthy and not crumbly.
The second possibility is that I keep the leftover wall paints (Nippon Paint Vinilex 5000) in the same room and have noticed that much of the solvents have evaporated. It is possible that the solvents in the air might have caused the cable to fail in 3 years. It would explain why the other ends that aren't exposed to the air inside the bomb shelter aren't falling apart.
Some other learnings from this. Buried cabling should always be permanently fixed and attached to a patch panel instead of dangling in the open. That was the original plan but I figured it wouldn’t be an issue. I was wrong. Always measure exact length of buried fibre cabling as they aren’t meant to be stored in loops.
Thanks, I really appreciate the SMEs commenting here. I'm learning a lot.
Definitely learnt it the hard way this time. You're right that buried cables should be exact in length and fastened to a patch panel. I'll probably look into better conduit design as well for the next time (in 15 years?). Having shared conduits means I would risk damaging other cables if I tried to pull a new cable through.
Hey actually I didn't know! It's my very first time dealing with fibre networking so I just maxed out the supposed durability specs. I figured I'd rather go overkill than regret not having done so. Ironic I know.
Unfortunately I can't easily dig the cable out and bury it again in this case. I'll have to figure out how to pull a new cable using the existing cable through the PVC conduits as the cable shares a larger conduit with multiple other fibre and Ethernet cables. The whole project was orchestrated remotely in a different timezone with me giving the electricians instructions over WhatsApp photos and audio recordings, so that limited what I could realistically control onsite back then. Often the contractors would proceed with a do first ask questions later approach while I was still asleep. The networking project was holding up the entire home renovation so everything was learnt and planned in a short amount of time.
AFAIK fibre splicing and terminating tools are very expensive. Do point me in the right direction for the $50 tools and I could go get some and DIY.
In theory I can pull a new cable through. But practically it might be tough due to the number of bends (shelter -> wall -> vent -> ceiling -> wall -> floor -> room). In the worst case scenario I can give it a try, but it's probably going to destroy the new fibre cable when I pull it through. For now the connection still works, so I am hoping it doesn't get to the point where I have to give that a try.
It's one of those "just because" moments. The idea was to future proof my home infra for a 25G NAS connection. Most ethernet connections tap out at 10G. While theoretically speaking Cat 8 cables can do 40G, hardware support for full 40G Cat 8 NICs is rare. Fibre is very very flexible with its potential bandwidth and SFP28 transceivers are relatively affordable (if you don't do what I did by using SMF. Home networks should only use MMF if the property isn't a mansion.)
The electricians mentioned that in order to curve the cables along underneath the floor tiling they couldn't use metal trunking which would cause sharp angles, so they used PVC pipes to do curvy trunking for the fibre cables. I could theoretically pull a new cable through by ripping out the wall outlet if this cable actually fails. You can see it in my earlier homelab post. But due to the length of the trunking and the number of bends, I'm not too sure if I can safely drag a new fibre cable through.
But yeah, maybe it's not that bad after all. I hope it won't get to that point.
I'm not sure either. It's not an air tight bomb shelter and it's used like an average storeroom, storing stuff like winter jackets, suitcases and paint. I do use small amounts of Calcium Chloride based dessicants to keep the room dry.
I know that's not a satisfactory answer but the infrastructure models (for VMs or Windows machines) would have to be implemented into the new paradigm bit by bit to make this work. This used to be something that was laborious but you could have Claude Code cook up something for the loop interfaces and have a working controller prototype in a short time.
Not saying the integration is going to be simple though. The team has to actually buy in and prioritise building the controller logic for each platform solution. And that includes reviewing the code slop that Claude creates.