paffdragon

It's not possible for a human to do what an LLM does at scale, for sure. But that's the difference, humans are not robots, so they will turn the the problem around and will try to find ways on how to not have to do this in the first place. E.g. minimizing pending changes left around by making small frequent commits. A lot of invention comes from people being annoyed doing something all over again manually. LLM stirs up things a little bit as it provides a completely different way of doing such tasks. You don't have to invent a better process if the LLM can do it repeatedly for a reasonable price. The new pressure then comes from minimizing LLM costs, I guess.

Interesting approach. I'm a bit old-school, when I make a change I already have all the context and beyond in my head, plus all the expectations from colleagues, historical context etc that might be useful to remind people about. At least for me, it is easier to formulate the commit based on that, than trying to formulate a prompt to formulate what I want to have in the commit. But I have the same with code. When it is born in my head, it's usually easier for me to write what I want, than trying to explain it to an LLM. I find the LLM a bit lacking precision when it comes to comprehension, a little like trying to explain something to a child (with superpowers, but still need step by step directions).

But I find it very interesting how others find prompting more productive for their use cases. It's definitely a new skill. Over years I also built my skill to write commits, so it comes natural to me as opposed to prompting, which requires extra effort and thinking in a different way and context and it doesn't work well for something that I do basically automatically already.

I find the commits written by AI often inadequate, as they mostly just describe what is already in the diff, but miss the background on why was the change needed, why this approach was chosen, etc, the important stuff...

I think, if you work with logging long enough this becomes common sense at some point. Consider when logging backend performance or subscription gets hit by bursts - e.g. an unlikely code path gets repeatedly hit that logs an error or in the worse case an exception trace. With logging every X occurrence you reduce the total amount, but don't have control about the overall rate. With logging every X seconds, you can manage the rate better, which is useful depending on the logging backend performance or subscription.

Or at least they don't cover business logic if they pass while breaking it.

This is very familiar. Rough draft, some manual execution often wrapped in a unit test executor, or even written in a different scripting language just to verify the idea. This often helped me to show that we don't even want to build the thing, because it won't work the way people want it to.

The part about distraction in code feels also very real. I am really prone to "clean up things", then realize I'm getting into a rabbit hole and my change grows to a size that my mates won't be happy reviewing. These endeavors often end with complete discard to get back on track and keep the main thing small and focused - frequent small local commits help a lot here. Sometimes I manage to salvage something and publish in a different PR when time allows it.

Business mostly wants the result fast and does not understand tradeoffs in code until the debt hits the size of a mountain that makes even trivial changes painfully slow. But it's about balance, which might be different on different projects.

Small, focused, simple changes definitely help. Although, people are not always good at slicing a larger solution into smaller chunks. I sometimes see commits that ship completely unused code unrelated to anything with a comment that this will be part of some future work...then prio shifts, people come and go, and a year later we have to throw out all of that, because it does not apply to the current state and no one knows anymore what was the plan with that.

Is this on Linux? Do you have an example of a website where Yubikey does not work? I'm curious, because I use Firefox on Linux for years, also for work, and never hit a site where my Yubikeys would not work. (I'm also using Google Meet regularly for work from Firefox without problems)

EDIT: Sorry, I misread, Newt is the WireGuard client and is based on wireguard-go if I'm correct.

This looks really nice.

I have set up something similar just recently with an OPNSense box running DNS, the WireGuard instance and getting a wildcard Let's Encrypt cert that it pushes to my Synology reverse proxy (Nginx). So from my clients I can enable the WG tunnel only on my internal IP range, setting the internal DNS, so I don't have to have my public cert pointing to my IP. It works once setup for my home net. But for multi-site, Pangolin looks very polished and probably easier to set up.

Is Newt a custom implementation of a WireGuard server? Has it been security audited in some way?

Check the notes.rewrite config options in https://git-scm.com/docs/git-notes#Documentation/git-notes.t... Also notes.rewriteRef. You can use these to configure git to carry your notes across amend/rebase.

I wrote a little tool for versioning based on conventional commits that uses git note for a version override. In case you want to force a specific version instead of the one autodetected, you can add a git note with the version you want.

This was useful when migrating a piece of functionality into its own repo and you want to preserve history. Adding these forced version tags into commits would be quite messy in the new repo where you switch to a new versioning scheme.

It's very likely that it has been already scraped by AI bots.

I imagine it like this. Juniors will be taught by LLMs on some things, but seniors will still be there, they will still assist, pair program, code review, etc. but they will have another party, the LLM, like a smarter calculator.

Oh. Yes. Little Bobby "show me your private repos" we call him.

Most of my family was using FB Messenger, but now it's WhatsApp, unfortunately still Meta, and I hate it, but at least it's encrypted and old messages are autodeleted. I couldn't convince them yet to use Signal or Matrix. Signal might work, I used to use it with my brother, but he was the only one, so wasn't really effective. I had hopes that I can move everyone to my own Matrix instance, but that looks unachievable right now. Edit: I forgot to mention calls, if something is very personal (not secret, just personal) we usually make call.

I think, I need to buy new HW maybe. My 12 core 32GRAM laptop is running these local models so slowly, it's unusable (I do have an Nvidia card in it as well, but I ended up disabling due to issues under Wayland/wlroots and didn't have time to fix that yet). And most of my phone's advanced AI features won't work when only on-device processing is allowed.

Oh, totally, I am very well aware that most people don't care much about this, which also makes my outbound emails less private in turn. And the irony, I don't use Google myself, but my wife does, and even when I set up a new mailbox on a custom domain for her, she asked me to redirect it to her Gmail...but that's why we don't use plain text email for private stuff anymore.

Indeed. What I meant was that it's cheaper to drop than to generate a reply. But you are right, and I also mentioned in the other reply, that my router wouldn't stand a chance dropping or replying to a DDoS anyway, so probably this concern is not relevant in the home router context.

Fair enough. For me personally it's not that big of a concern. I just remember from a previous network monitoring gig that using ICMP had a few problems with rate limiting. But that wasn't my cheap router at stake. It's probably just something that stuck with me and not that relevant in my context anymore.

Nice. One thing that I am concerned about is giving my emails to Gemini (or any other third party). The article mentioned that they wrote a new MCP server because they didn't trust existing third party tools. For me it is the same, but including third party LLMs. Someone told once that if optimizing your algorithm is to much work, just wait until computers get faster. Maybe I'll wait until I can do this on-device.

I am not a network engineer, but when I hear ICMP, I associate it with consuming CPU on my shitty router and DDos potential. I only block ICMP for unknown external traffic (response to packets not otherwise blocked by firewall, then aggressively rate limit that) and allow it internally. I used to go overboard in the past and learned how annoying it is to not being able to do a simple ping...

Indeed, that's my experience too. We used partitions like others mentioned below, but Postgres had issues with moving rows across tables atomically and had to implement our custom complex queries to overcome it. Plus job expiration was dynamic and had to use background cleaning. The bigger problem was with the planner not able to pick up sudden changes in volume and had to use a cron to run analyze on it. Managing retries with backoffs, etc.. At some point we stopped fighting it and just moved to SQS, we have zero problems since, no maintenence needed, and it's still free so we saved storage cost, time and developer effort for ongoing maintenance.

We still use Postgres for simple queues, but those don't really require a library as it's quite simple usually, with some advisory locks we can handle the crashed job unlocking fairly well too.