mnahkies

I'm using a cli I wrote to orchestrate per-project VMs for sandboxing using libvirt with COW shared golden images to minimise the disk overhead. The VMs get "rebased" periodically onto new golden images for the rootfs, but keep a persistent home FS for longer. I'm going to clean-up the documentation and open source it at some point soon.

I was using oh-my-pi, but currently playing around with Hermes as an alternative.

Exclusively using open router at the moment, mostly on principle around ZDR, and freedom to experiment with harnesses - but financially I'll probably have to compromise on this soon. GLM, Kimi and DeepSeek are the main models I'm using, with some OpenAI usage.

Tmux for remote access and session durability. I'd prefer to find a setup where I could access the same session through a web interface and seamlessly switch back to TUI, ideally spawning sessions through a web hook or similar. I'm going to take a look at Hedr to see if this can improve this.

Probably the two major things I'm planning to do next are looking at adding a bifrost VM that will hold all API keys, and centralise management of MCP configuration, potentially use it's skill repo stuff as well.

I also want to start controlling egress more - probably iron proxy, though tbh I'd like a solution that was relatively liberal whilst still mitigating exfiltration and prompt injection risks. Maybe I can find a curated allow list to use as a base.

Finally, I make a lot of use of open-webui, but it's disjoint from the agentic setup currently - it'd be nice to find a better way to share information/research from it into the agentic sessions.

I've started hosting most of my private projects on a self hosted gitea, but one roadblock I've found is oidc auth - from GitHub actions I can publish to the Google play store, or npm, without needing to manage any static credentials. I know I'll need to manage some kind of secrets/identity when self hosting, though I'm still looking for nicer solutions than a bunch of static secrets for individual services.

I've seen an agent autonomously upload a jar to a random file host, in an attempt to be helpful as ssh between my host and it's VM wasn't working (which was trivially fixed, but I guess it was in a hurry)

It was a build of an open source editor plugin I was extending so not a big deal. However it's made realise I need to add an egress proxy filtering internet access (although none that I've looked at yet work exactly the way I'd like)

Bitwarden is one of the few subscriptions I have in a patron sense - eg: I've never actually needed any of the premium feature's, but I chose to pay anyway as I felt that was a way to contribute to the long term viability of the project.

I'm not immediately upset about the licensing change - I get the need to protect from low effort/value add reselling and things like that. I do still worry if this is a canary for future changes that run counter to the reasons I migrated to bitwarden in the first place (open, robust, trustworthy).

Counter to many other commenters I personally prefer bitwarden over 1password, and certainly over lastpass and roboform, etc.

My only gripe is having to unlock the desktop app separately from the browser extension, which after adopting the ssh agent functionality became kinda annoying.

I missed out on an event recently because it was full. I got a notification that a spot had become available shortly before it started, but I had an hour travel to get there so wasn't viable.

I think tools to enable better discovery are a good thing, but I'm not sure that I like the idea of splatting RSVPs just in case.

I started with plain wireguard then migrated to tailscale, for my use case:

- I was able to get my partner onto the tailnet by telling her to install an app and login. She doesn't know or care what wireguard is, but she can now access some of my self hosted services on her phone.

- I'm able to easily dynamically register machines to the tailnet, such as CI jobs

- I'm able to self host a DNS resolver and have it just work for devices connected to the tailnet

I'm sure I could achieve these goals with plain wireguard, but I feel like I was able to outsource significant complexity to tailscale instead.

What are people's thoughts/experiences about dual licencing?

Eg: is there a clean way to dual license such that hobbyist, and exploratory work (eg: a proof of concept done in a commercial setting) are allowed, but using it in production requires a fee?

If you've done this, has it been successful? Obviously there's been many projects relicense over recent years (terraform, redis, etc) - but it's less clear to me if this is a viable path for new projects starting out, or if it just kills adoption from the beginning.

Does anyone know what the impact on prompt caching is?

I like the idea of dynamic tool/skill sets, but wonder if it needs to be part of the new session workflow where you would choose a group to activate rather than this dynamic.

It's funny you say that, as one of my weekend projects today is setting up https://www.authelia.com/ to achieve the same.

I probably won't allow everything through it (eg: postgres, clickhouse etc can stay on tailscale), but I've been stumbling into use cases where I want to share things with friends or colleagues, and I don't want to put them on my tailnet.

One of my primary use cases for tailscale/VPN is that I can happily run stuff (grafana, gitea, etc) and not have to be panicked about monitoring for CVEs - I serve it all over HTTPS but I don't want to put it on the public internet if I don't need to.

Through my weekend experiments, I've found I can get way better outcomes, and an order of magnitude less cost with my slapped together sandboxed omp setup plus ZDR openrouter models (DeepSeek, Kimi, etc) than I've ever seen from Claude Code at work.

Everything is version pinned and a deliberate choice to change, and a git revert away from changing back.

TBF the models may change underneath me to some extent still, but the cost benefit of running them myself doesn't pan out yet (for agentic coding at least, don't have enough local vram to get a usable context window and generation speed, self hosting on runpod or similar isn't economically sensible for my current consumption though I have tinkered with it)

I think the key part is about aligning incentives and outcomes - if your security and compliance departments are only judged on "were we breached, did we pass our audits" then there's a risk they won't weigh the tradeoffs associated with the decisions around controls implemented to achieve those outcomes.

To use a ridiculous extreme you can't breach a web app that isn't exposed to the internet, but the users can't access it either.

If you can connect/balance those goals to other metrics around cost and productivity, usability, and a realistic threat model, as guardrails then you incentatize cross-team collaboration to achieve the shared org outcomes.

I'm going to play devil's advocate here.

As a developer, I quite like monorepos to a certain size (eg: until they get big enough that the tooling we typically use outside of big tech starts to fall down).

As an AI, I'm not sure that I care? I'd guess that context management can actually be easier if each microservice has a well documented API (openapi/graphql/grpc/asyncapi/whatever) and you provide the agent harness the ability to drop into each polyrepo as required (and give it the ability to access said documentation).

The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent.

Admittedly the way I'm using agents at the moment is more repo orientated where it's sandboxed to a single repo, but conceptually I think polyrepo microservices could end up being a sweet spot.

Why not both? Driver-less (or even just with drivers) mini buses, without fixed stops and dynamic routes/stops based on demand.

I guess you don't want to stop more times than needed, so maybe you'd want to cluster the demand somehow into "virtual stops", and you may lack some amenities like shelters.. so maybe the traditional bus route is good enough. Though it feels like it's ripe for optimisation (you know the classic no buses come for 30min then 3 arrive at once, or these buses are all full whilst others are roaming empty)

My return on premium bonds this year (so far) is roughly 3.2% annualised - it's not bad considering that it's tax free, and secured by the government

Primary use I have for it is hosting internal services that I don't want on the public internet - do the same at work, it reduces the attack surface hugely

I believe they batch requests so the same weights in vram are shared across many requests https://www.baseten.co/blog/continuous-vs-dynamic-batching-f...

Unfortunately many banks in the UK no longer offer a web portal or physical branches.

I'd love to see legislation that mandated a functioning web experience for critical services like this (banking, utilities, etc) - otherwise it will continue to further entrench the current duopoly.

(I suppose this is also an instance where I should do a better job of voting with my feet and supporting services that do offer this)

I think it's a pretty reasonable split of responsibilities, and not uncommon.

Eg: JDK + maven + junit + tomcat

Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc)

As another commentator said "do nothing" is a decision. There's a distinction between "don't make a decision and hope someone else makes a decision" and "we acknowledge we're deciding to do nothing about X until/unless Y"

The people in leadership positions should be active participants, and not all decisions will be ones they are are able to make locally - but they should feel comfortable to present a POV and recommendation/tradeoffs upwards when that's the case. If the buck stops with them then they should be aware that "do nothing" is a decision that they are making.

In terms of the expert observation, I've seen this happen a number of times in conjunction with "not invented here" (and probably been guilty of it myself at times) - "the commodity solution doesn't do X that we want", "yeah our in house solution doesn't do x,y,z that the commodity solution does but just a little more effort and it'll be perfect"

Spoiler: neither the commodity solution or the in-house solution will ever be perfect, and you should be really self critical of whether you're building something in-house to scratch your own itch.

If you can find a commodity solution with the right extension points that's often the best solution, failing that many times it's worth accepting the limitations, rarely it's worth investing in the totally bespoke thing (outside of your core domain/proposition).

Yeah you could run a single instance with multiple frontends - but the way I'm currently running things the public haproxy instance doesn't have network connectivity to the private services, meaning there is no way I can misconfigure things and expose an internal service to the internet.

Finance somehow accidentally paid me approximately a whole years salary at once when they did the first payroll run after we were acquired.

My first thought was I hope they didn't make this mistake for everyone, and second thought how do I safely return this.

(Turns out it was a one off mistake, and returning the excess was pretty straightforward though probably the largest bank transfer I've ever made)

Personally I think wildcard certs are more secure in many instances - if you're just running one load balancer/reverse proxy then all the private keys are going to the same place anyway. You get the upside of not leaking your subdomains to transparency logs, and having fewer certs to renew.

It also forces you to use DNS challenges, which means you don't require the publicly route able address.

Personally what I do is: - Predominantly use wildcards

- Run a tiny coredns instance with my A records for a internal subdomain of my normal domain

- Configure tailscale to use the coredns resolver

- Run two haproxy instances, one for internal services, one for public facing. The public facing one can't route directly to the internal services.

When even the obscure DNS provider I'm using is supported for DNS challenges, I really don't see much upside to using HTTP challenges anymore

No, I'm not using the gog client (I'm on Linux). It's things like the Witcher 3's launcher.

It's the steam version, but Crusader Kings also hangs for a bit if you block it's network access

I'm aware, and I'm choosing GOG when I can now, though even then I see phoning home (or attempts to) happening (opensnitch is useful for that https://github.com/evilsocket/opensnitch) - I've paid for some titles 2-3x over which is frustrating, admittedly I don't have the physical media from the first time which is on me, but it's frustrating seeing single player games wanting to phone home

When I brought half life 2 there was a lag of about 2-4 years before I could play it for the first time - I didn't read the fine print, and on a dial up connection I couldn't get past the steam client updating in a reasonable amount of time, mind you I was able to download much larger Linux ISOs over time frames of a month+ through resumable downloads.

Not really an issue these days but it certainly was back in the day

They specifically mentioned HFT so I suspect they care a lot about processing speed

The UK tax system also has a bunch of unfortunate cliffs, and tapers that create >60% marginal tax rates and worse. There's a calculator here that illustrates it well https://tax-cliffs.britishprogress.org/calculator

The childcare cliff edge is probably the worst, but the personal allowance taper isn't ideal either as it's compressed over a relatively short income range

And of course all the thresholds remain frozen, creating plenty of fiscal drag on top.

I think the litmus test is roughly "is this obviously AI created" - if it's a well crafted PR that doesn't do the things you mention, and solves a genuine issue in a sensible way then you'd not be able to tell.

The other part of the litmus test is "does the person submitting actually understand what they're submitting and why" - which is arguably not required for PRs that you'd otherwise accept, but since you have to put time and effort into determining whether a given contribution is ok to merge, it's common decency for the submitter to have done a self review first (AI or no AI)