News for hackers. Stuff that matters.

linsomniac

Re:Bidirectional Charging During Grid Outages on Sunday November 01, 2026 @12:39PM (#50327767)
Maybe. I did the math and in our area a Powerwall would roughly pay for itself over the speced lifespan of the device, IIRC that was just the cost of the device not the cost of installation. I did that calculation ~4 years ago, so maybe it has changed, but definitely do the math, I was surprised.
I'm in the US, but:

>Non-commercial use only. You agree not to use our Services for any commercial or business purposes and we (and our Providers) have no liability to you for any loss of profit, loss of business, business interruption, or loss of business opportunity."

that sounds similar to what I'm seeing, but in my case that restriction is limited to their "evaluation-level" services. It says in full:

>Evaluation and Additional Services. In some cases, we may permit you to evaluate our Services for a limited time or with limited functionality. Use of our Services for evaluation purposes are for your personal, non-commercial use only.

Thanks again for pointing this out. I think we're in the clear in the US.

Re:TCP Use-After-Free: CVE-2026-98432 / CVSS 9.8 on Saturday October 31, 2026 @09:34PM (#50321963)
I'd be seriously considering Debian or, hear me out, NixOS. We run all our work servers on Ubuntu, but ~6 months ago I switched my workstation to NixOS and I couldn't be happier. I've been following "latest" or whatever they call it, being able to treat the OS package versions like the rest of our software (update the flake.lock file and then burn it in in dev+stg for ~2 weeks before rolling to prod) is pretty attractive.
>Productivity went down because an engineer spent 2 weeks

Yes, that is something you have to be careful of. In this case, as I mentioned I believe, it was done in spare time, not full time, and it was mostly the AI that spent 2 weeks, I'd guess he probably spent a day or two, and the testers probably spent another day (however, I think this ended up coinciding with our quarterly "full site" test, so it would have happened anyway).

Agreed, but remember this was a reply under an article about modernizing existing code.
In this case the situation was that we had other higher priorities for the last decade so we were walking around with this technical debt.
I know a lot of people think that the AI tools level the playing-field, but we aren't experiencing that. The guy that did this translation is doing more tickets than the other 4 software devs combined. And it's not because they are low-effort tickets. That's also on top of the 6 hours a week of meetings he has that the other devs don't.
Does it change it that we are an organization of 8 people? As far as I know our use is permitted, but LMK if that isn't the case.
We just recently use Claude Code to port an old Coldfusion site to Java Spring and it went amazingly well. It's around 50K lines of Java, one of our engineers did it in his spare time over about a week, using the $200/mo Claude plan. We had been talking about doing it for at least the last dozen years but never found the time. It would have taken around 12-18 engineer-months to do this manually.

He had the translation use browser integration to compare the new site to the old site automatically. The result was so good that he had to change background color on the new site because he couldn't be sure that he was testing the new site; it was so close to the original he was paranoid about accidentally being on the old site and not knowing it. The whole thing was done in under 2 weeks, including coding, developer testing, tester testing, and deployment. It's been in production 4-6 weeks now and we've had no reports of problems.

Re:Eulogy for the Software Engineer [video] on Friday October 30, 2026 @06:08PM (#50310784)
"I keep hearing that coding was never the hard part but you're not going to hear that from me. Coding was hard. If it'd been easy, none of us would be grieving."
That seems very plausible, thanks!

Looks like it's available in The Year’s Best Science Fiction: Twenty-First Annual Collection and at the time I read _Toast_ I was also reading a bunch of these "Years Best Sci Fi" collections. I've snagged this and will give it a read, but I'm almost 100% certain that you nailed it!

Re:OpenAI's agents talked to each other through the CPU Cache on Thursday October 29, 2026 @08:43AM (#50288033)
These covert communications are reminding me of a short story I read a few decades ago but haven't been able to track back down. I thought it was a Charles Stross story in the _Toast_ collection, but I re-read it and it isn't there.

In the story some University students take part in a trial that involves a brain scan and then them spending the rest of the day answering a customer support message. They can spend the whole day working on researching and writing a really good customer support reply to a user request. While doing this they notice something odd and realize through some sort of back-channel that this isn't the first time they've spent the day writing a customer support message; they are stuck in a simulation.

I'd really love to go back and re-read it, but I've not been able to find it again.

In _Toast_ is another story that's also relevant: A fairly innocuous news story pops up and our hero calls his partner at work to tell them that it's time to get their go bag and get off planet. This news story indicates the Earth is in the beginning stages of reaching an AI singularity, and this isn't the first time our hero has gone through this on a planet.

Re:Ghostty 1.4.0 on Tuesday October 27, 2026 @06:37PM (#50266851)
>I still don't understand the point of Ghostty, Kitty, Wezterm...

WezTerm can run on my Mac but give me a native GUI experience of a Wezterm session on my Linux workstation. It's like tmux, but with a native GUI experience including mouse click-drag selection that doesn't pick up "window" borders.

That alone is what is keeping me on Wezterm, since I get a native experience on some terminal sessions I access remotely on my macbook but then can switch to on my 30" screen when I'm at my desk.

FWIW: This is NOT what "balcony solar" is. See my top level comment clarifying it.
Nevada has started allowing it, and other states are starting to allow it in Jan 2027. However, these all rely on equipment that meets standards that equipment is not yet certified for (UL 3700). It's a bit of a waiting game in the US right now.
Clarifying "Balcony Solar"

I'm seeing a lot of comments mis-representing "balcony solar". This is a phrase that specifically means "small-scale solar panels that directly feed the grid". It is NOT about solar cells feeding a "cooler sized battery+inverter".

This is what makes it so attractive; no battery is required. But this is also why it is waiting in the US on legislation (back-feeding the grid). Germany has already passed this legislation. In particular, the equipment needs to be UL3700 certified.

See https://en.wikipedia.org/wiki/Balcony_solar_power

Re:Pharo 14 on Monday October 26, 2026 @12:50PM (#50246905)
>One thing that AI programming has done is made me care much less what programming language is being used

I'm right there with you. I really like programming in Python, the language. Now that I'm not writing much if any code, the rough edges in building and deployment have come to the forefront. Even "uvx run" has become a sticky wicket (I have some machines that don't have Internet access).

Re:We should be more ambitious with the software we build on Monday October 26, 2026 @08:45AM (#50242686)
Ok, I'll take the bait.

apt-cacher-ng, the hand-written C++ version, is 16K LOC for the core. apt-cacher-ultra does a lot more. Seems like a pretty reasonable LOC count to me.

What are you basing your assertion above on?

Re:We should be more ambitious with the software we build on Sunday October 25, 2026 @12:35PM (#50233396)
>Exactly what you are optimizing for here?

Let's call it "Joy".

I've done hard things. Many of them have a significant amount of time that is a slog. A tapestry is going to have a lot of days of just slog work. And that's fine. Doing hard things can be very rewarding. I've reupholstered a couch by taking it down to the sticks, repairing and reinforcing the frame ("hey kids, the couch isn't designed for walking and jumping on"), enhancing the design, re-springing it, redesigning the cushions so that they didn't need readjusting every time you sat down, making new foam cushions, and then sewing a upholstery. Took 3-4 months.

But, I'm in the last half of my 50s. The project you're commenting on, apt-cacher-ultra, probably would have taken 2 full time developer years to get to where it is now, and I'm doing some pretty big changes for the next version. I literally probably have a handful of that sort of project I can do left in my life, assuming I quit my job now and work full time on it.

Let me tell you, it's pretty sobering to be faced with: "I may only be doing this once, maybe twice more in my career."

So yes, building experiments where I get to try out my ideas without 2 developer-years of coding required is going to give me an opportunity for a lot of creation that I otherwise wouldn't have had. I've spent decades hand-crafting code, I fully understand the joy of doing so.

Re:We should be more ambitious with the software we build on Sunday October 25, 2026 @12:23PM (#50233252)
>You only have to implement the very small set of requests that an apt client can make

Why even write one of those? Just set up an nginx proxy cache and call it done.

But that doesn't even scratch the surface of what this project does. We already have a few simple approaches to this problem: apt-cacher and apt-cacher-ng. Neither of which were any help when Canonical was under DDoS. Both of which have proven unreliable.

As I said elsewhere, apt-cacher-ultra is a pretty subtle piece of software, it doesn't just do a naive cache, it fully understands the apt repo structure, validates the repo, and snapshots it, understands what packages your clients frequently request and preemptively downloads updates to them as part of the snapshot promotion, etc. A DDoS of the package sources, even in the middle of an upstream releasing updates, is something a-c-u will handle no problem. I've simulated this by firewall rules blocking upstream traffic. It's also proven much more reliable than apt-cacher-ng.

I've been in the software game ~40 years, I've seen it time and time again: "How hard could it be" and then when you get into it you realize there are a lot of devils in the details.

Re:We should be more ambitious with the software we build on Sunday October 25, 2026 @12:09PM (#50233101)
>uncomplicated thing

That's pretty naive.

This isn't just a simple http proxy and checking if the requested URL exists on disc. It's a pretty subtle snapshotting system that fully understands and vets apt repos, detecting when the repo changes, proactively downloading "interesting" packages that have updated, verifying and validating all packages, and then promoting the repo to active when it is healthy. Plus a web-based admin interface.

The core of it is around 20K LOC, with another 40K in tests. The COCOMO model gives that an estimate of around 2 developer years of effort assuming full time work.

Re:We should be more ambitious with the software we build on Saturday October 24, 2026 @08:45PM (#50227048)
>my problem is with enjoyment

I get it, I've gotten a lot of joy over the decades from the specific act of programming. But I also get a lot of joy from making something. I'm old enough now that I don't have a lot of my time left to "hand stitch an amazing tapestry". But with AI tooling, I do have time to try out a bunch of ideas and see how they work, scratch little itches and also just run a mad scientist library of experiments, without each experiment taking tens or hundreds of hours of coding to see how that experiment pans out.

Re:We should be more ambitious with the software we build on Saturday October 24, 2026 @08:40PM (#50227024)
>In the spirit of the latter, here's mine!

To pile on, here's mine: https://github.com/linsomniac/apt-cacher-ultra

It is a robust, reliable cache of apt packages, with the additional goal of still being able to serve packages from the cache even when the upstream is down. This was started shortly after that DDoS of Canonical this past year. We've run apt-cacher-ng and apt-cacher over the last dozen years, but (a) it requires hand-holding about once a month and (b) it did absolutely nothing for us when Canonical was under DDoS.

I've put well over 100 hours of my time into it. Still running into a lot of people knee-jerk calling it "slop", but I've had 200-ish machines pulling from it for 6 months and it has worked way better than apt-cacher-ng.

I'm not really sure what to do with people who dismiss AI-assisted projects, while dehumanizing the 100 hours of my time I've put into it. I fear we're running the very real risk of both sides losing: the people trying to thoughtfully create with AI losing because of the AI, and the people avoiding AI losing because they can't keep pace.

Re:Show HN: Corgi, a helpful {agent, terminal} multiplexer on Saturday October 24, 2026 @11:15AM (#50222090)
When I first saw this I though "Meh, I'm happy with Herdr", but then I saw "paste images, even over SSH" and I've gotta try it. I also REALLY like the website where you can interact with the example screenshot, that's <chefs kiss>.

However (and I know connecting is on the road map), is it possible to have multiple local connections? That's core functionality for me, I run Herdr in one terminal on my workstation, and on my laptop I ssh in (actually "wezterm connect") and run a "herdr attach" so I can access it both from my Mac and my desk. I've never gotten around to trying the herdr native connect from my Mac because that works so well.

I believe you are talking about Hyperball: https://www.ipdb.org/machine.cgi?gid=3169

I've been fortunate enough to come across it a couple times, it's pretty cool.

>it becomes de facto free shelter

So? Let it.

If people need shelter, it's a shame we are building a ballroom instead of shelter.

Re:Canary Tokens on Wednesday October 21, 2026 @05:45PM (#50188121)
>Claude knows how to make fake credit cards now

If by "fake" you mean ones that pass number validation on web sites, that's easy. I wrote python code to check and generate valid numbers back in the '90s; it's a simple, well known check digit algorithm appended at the end. https://en.wikipedia.org/wiki/Luhn_algorithm.

Just going to remind you all that https://canarytokens.org/ exists.
Maybe what makes me more comfortable with it is that I'm in Operations. 95% of what I ship to production is not code I've written, and a huge part of what I ship to production is not code I even understand. Day in and day out I'm responsible for tens of millions of lines of code involved in running a service: Linux kernels, userspace, application servers, databases, monitoring. I'm responsible for reliably running this whole stack.

So, for me, end of the day, it's all about testing, monitoring, soaking in staging and promoting to production.

This might be why I'm fairly comfortable shipping AI generated code.

Older »