mnahkies

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.

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