HNHacker News
TopNewBestAskShowJobs

Groxx

21,070 karma · joined December 16, 2009

Basically your average geek.

Contact me: hn@username.is . The "hn" helps me organize; it's unnecessary, but appreciated.

I'm also currently @groxx@hachyderm.io

submissionscomments
Groxx··on Hacking with Claude on a $27 smart watch
fwiw I pretty much only like the metal "mesh" bands, if you haven't tried those - all other kinds make me sweat (or get uncomfortably juicy when I sweat) and/or collect crud that eventually irritates my skin if I don't wash it frequently. the mesh breathes extremely well in comparison, and essentially doesn't build up gunk at all.

also many watches are incredibly thick and I apparently routinely get my wrist within millimeters of darn near everything. a thin one (pebble time round) solved that, and being light also means it doesn't slide around or require a very tight strap.

Groxx··on Go 1.27
I like to alternate. or use constructions that make it ambiguous.
Groxx··on Amazon's Drones Will Soon Deliver to Nearly 500 US Cities and Towns
The main noise savings I can see are likely to come from "use a much larger drone and lower the package down on a crane". Larger blades help, but the biggest effect is simply not having it nearby.
Groxx··on Meta's blockbuster trial draws parallels to big tobacco
That seems inevitable for laws that try to address private behavior, yes. It'll waffle around and strike randomly as it gets tested more and more in court to narrow the definition, and that gradually causes a chilling effect around the whole concept. The only real consideration worth having is "will things be better after", not "will my life be unchanged".
Groxx··on Meta's blockbuster trial draws parallels to big tobacco
Seems like you don't have to rule it out completely? "You might also like this show" is rather different than YouTube's "OMFG SHORTS WATCH THEM NOW" experience. Even if the line is fuzzy, I think many can agree some things are closer than others, and that's enough for some laws (there are plenty of other not-perfectly-testable laws out there as counterexamples).
Groxx··on Cursor launches Origin, GitHub alternative
Plus a rather clear lack of investment into improving it / retaining their talent / etc, yeah: https://damrnelson.github.io/github-historical-uptime/

Anecdotally: at work I saw quite a lot of github-uptime-related issues, and because they're the central host for everything they become *cough* load bearing for a huge amount of the company. Stability and performance has been dramatically worse than the self-hosted phabricator+gitolite before it.

Groxx··on Cursor launches Origin, GitHub alternative
They've already separated the wiki's version control, why not CI? And the issues/discussions are just vendor lock-in wrapped in a shiny UI.
Groxx··on Field measurements of neighborhood-scale air temperature impacts of data centers
>You are quoting my passage for you to do something, not solve it.

Which is claiming I'm doing nothing because you haven't seen it. The implication is that you're disregarding "my ideals" unless I do something so impactful that you would have passively noticed.

I fully believe that's not what you intended, but that is a rather straightforward read of what you typed out, so I pointed it out.

Groxx··on Field measurements of neighborhood-scale air temperature impacts of data centers
>No one can live your ideals for you, if you think something should be done, you should do it, and quickly at that. If it is that urgent, why are you not doing anything?

This is the world-hunger-equivalent bit fwiw. It's rather explicitly "if you care about this, why haven't you solved it", an over-the-top bad-faith argument.

Groxx··on Field measurements of neighborhood-scale air temperature impacts of data centers
You've been complaining that people blocking datacenters (which is partly succeeding) is worse than fixing the EPA.

Something is being done, urgently (vastly faster than the larger legal system), and public outrage is loud and annoying and widely visible, which is indeed what I want. Beyond that it isn't especially fair to say "if you like to eat, why haven't you solved world hunger", particularly when those EPA/zoning laws aren't in place yet, so I'll just ignore that part.

Groxx··on Linux 7.3 improves performance when running out of vRAM
Freeze as many applications as necessary to reserve room for the DE so I can choose what to do?

Surely that's obvious to other people aside from me. It's an attended system, not a headless server in a rack hundreds of miles away that must not ever alert someone.

Groxx··on Field measurements of neighborhood-scale air temperature impacts of data centers
Honestly, anything that gets people paying attention to stuff that has been building for decades is good in my book.

I agree that'll be a much better end-state to be in, but is it the best right now? ... idk. We're in an increasingly blatant "smash and grab" phase for major corporations right now, and they need to be stopped quickly.

Groxx··on Field measurements of neighborhood-scale air temperature impacts of data centers
By then it is too late, plus they never pay enough in damages. And the EPA does not have teeth currently, and damage will be done while fixing that too.

So people fight by pattern recognition: abnormally incentivized and extremely large? Kill it with fire immediately. It's mostly reasonable and more effective than anything else at the moment.

Groxx··on Field measurements of neighborhood-scale air temperature impacts of data centers
It can be an issue for the community in the same watershed, as well as being affected by what they do with any waste water. There have been quite a lot of extremely-drawn-out lawsuits about them drawing more than claimed, dumping hot water into streams and damaging the ecosystem, and polluting other water sources by dumping dirty water into drinking water affecting areas.

I agree the total usage isn't particularly large, and any "they'll use up all the fresh water everywhere" FUD is flat out wrong. But it can be a large jump for an area, and they've broadly shown themselves to be incredibly amoral and willing to fight legal battles with infinite money just because they can. They are not good neighbors.

Groxx··on Evolve: An incremental game about evolving a civilization
To anyone visiting on mobile: if you don't see any buttons, switch to the desktop version in your browser.

Evolve is one of a relative few that have been around and growing for a long time, and easily have months of (gradual) content. Worth a try if these appeal to you and you haven't tried it yet.

Groxx··on Field measurements of neighborhood-scale air temperature impacts of data centers
Noise pollution is definitely being discussed: https://www.usnews.com/news/national-news/articles/2026-04-2...

There are many reasons to not like these things nearby (anywhere it affects power or water too). And on top of that they've been "somehow" getting massive incentives and tax cuts, despite bringing in very little money or employment, which costs the area even more in future years.

It's everything combined, and pushback has been somewhat successful. Success in a protest tends to help bring more success to the same protest elsewhere.

Groxx··on Composable Tests
Ehhh... when it truly is two tests bodged into one, then sure.

But sometimes you do this kind of thing to avoid useless test brittleness: does your test check that `doSomething()` does what you expect, or do you have another test for that and this test only checks that `nowSomethingElse()` changes the object in a predictable way, e.g. updates a calculated field?

If it's the former, then it might be two tests masquerading as one, and this might make sense.

If it's the latter, you've changed a test that only checks what it cares about, and now you have a test that depends on unrelated implementation detail and will probably break unnecessarily in the future. Plus you've removed the assert that was documenting what it expects, so it's harder to tell if fixing it should mean updating both checks, or only the second one.

Groxx··on A simple fix for LLM tail latency
This sounds like a job for Fast Fallback instead: https://en.wikipedia.org/wiki/Happy_Eyeballs
Groxx··on Will you have spent more of your life with computers than your family?
Yeah, this has always been my take too. Assuming an even 8h split on weekdays, the awake-not-working time is heavily eaten up by commuting and general upkeep. Family squeezes into shared upkeep and any remaining time at best.

The two weekend days don't seem enough to catch up to the accumulated work-time, especially if your commute is relatively long (which is true for a large chunk of the USA), so you're just constantly in a deficit until you retire... which is more of an "if" than a "when" in many cases.

Which is clearly a problem, but I don't think computers are the cause.

Groxx··on Incident with Github.com [resolved]
All three: their own quite aggressive pushing of LLM coding as a whole.
Groxx··on Qwen3.8 27B at 256K: 50 TPS on a 24 GB GPU
I think it's fair to say they're better at a paragraph or so than most humans. And have been for quite some time, which is probably why their use in writing has exploded.

Long form though? Still pretty bad. Probably getting worse in practice, as people have them write larger and larger chunks of text without paying any more attention to the result.

Groxx··on How Go detects struct copies with sync.noCopy
Yeah, I really don't see much of a reason for Go to get a first-party linked list type. In most cases in non-list-oriented languages the performance and ergonomics are awful compared to a competent growable array type, the mechanical sympathy of "real" linked lists is generally terrible.

Plus they're extremely easy to build if you truly have a good use for one, particularly with generics.

Groxx··on A quick look at zero-knowledge proofs
> Alice sends out

Alice can send anything in any cryptographic scheme involving two parties, the only real safety in any of it is "are the odds of an accepted different value low enough to be impractical for an attacker". Does that apply here too?

Groxx··on Models Are Getting Dumber on Purpose
Not sure what you're trying to claim here tbh - Oct 23, 2018 is what the answer checker is looking for, it correctly judged "April 22, 2019." as incorrect: https://logs.epoch.ai/inspect-viewer/c79c08da/viewer.html?lo... (row 10, I don't see a way to link directly) and the correct answer matches the Wikipedia article's claim: https://en.wikipedia.org/wiki/Cry_Pretty and the RIAA's site it uses as a citation: https://www.riaa.com/gold-platinum/?reload=1786913260239&tab...
Groxx··on Go is an ideal language for AI-assisted software engineering
No, they're not mutually exclusive and tons of go code uses both to implement some kind of semantic. They serve moderately different purposes because their semantics are quite different.

Select, however, is encouraged very widely, and is used very widely, because it's very useful to be able to wait on any of multiple things efficiently. Select is great, you quickly grow to miss it in languages that don't have it. But select only works with channels, and often that means you're essentially forced to use channels where a mutex is much simpler and more natural. It also means tons of APIs are channel-centric because it's kinda the only non-blocking option (atomics exist, but that's a very different kind of non-blocking, and dramatically more error-prone for normal humans to write).

Once you go channel-centric for things like streams or concurrent RX style stuff, it does work, and some libraries do exactly that. But then you run into the historical limitations on generics, which makes for sometimes unnatural code, and channel performance is usually significantly worse than mutexes (it's still very fast, but you don't want to use it for extremely small things). And you are pretty much required to use those channels directly with select by hand because wrapping channels changes some semantics. And the semantics of those libraries are not mutex-y and are different from what most are already used to, because few other languages are channel-centric.

So you end up with high-level channel-oriented concurrency libraries that people only want to use for large expensive operations, thus are only designed for large expensive operations, which means it's not very common over all, and few develop the habit. E.g. there are quite a lot of goroutine-pool-helping libraries for ~seconds of work, but few functional-flavored generic parallelizing ones for opportunistic use.

It's part ecosystem, part language design, and part language history. You can do most of the Java stuff in Go with enough effort, but it just isn't done in practice very much, and it'll look and feel quite different.

Groxx··on Go is an ideal language for AI-assisted software engineering
Broadly agreed, the concurrent Go code I've gotten out of them has been absolutely riddled with issues, and they're even worse at writing tests for it. They can get tutorial-level code on the first shot almost always... but tutorial-level Go code is often rather unusable in production due to missing error handling or observability.

Go's generics are getting a fairly important improvement soon though! Generic methods, finally! It should help open up some more ergonomic patterns: https://tip.golang.org/doc/go1.27

Groxx··on Go is an ideal language for AI-assisted software engineering
No thread/goroutine handles for fork/join handling from "outside", and no generics for many formative years that influenced tons of habits, then significantly weaker generics (improving very soon[1]), have all led to most concurrent code to be very "intrusive" - you create bare threads and add bare synchronization primitives (or nearly) by hand inside the threaded code to make it concurrent. `errgroup` is as far as a lot of code goes, in terms of sophistication.

Java leans heavily in the other direction: a lot of concurrency is added externally, without changing existing code, often in very declarative-flavored ways.

E.g. Future<T> serves as a foundation for a ridiculous amount of stuff, while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics.

There are very obviously lots of counter-examples for both langs (`synchronized`, rill in Go, etc), and I expect Go to become more Java-flavored in time (it already has moved this direction somewhat, and 1.27 will enable a lot more). But I think it's a fair summary of broad ecosystem habits.

1: https://tip.golang.org/doc/go1.27 (not yet released)

Groxx··on How Claude marks AI-generated content
>Content generated by Claude may not carry a detectable mark if, for example: ...

>A file’s metadata was stripped through format conversion, re-saving, screenshots, or other means

Ah. So what essentially every single consumer-oriented media host does. Gotcha.

I fully recognise this is a hard problem, but hopefully metadata isn't the only method for media. Standard procedure is to shrink files for storage and privacy reasons, and non-visual metadata goes out the window by default.

Groxx··on How Claude marks AI-generated content
Since they do have the input, they could probably just store checksums at each step...

... though I'm not sure why that would be preferable over a coarse rolling checksum over all of the output. Seems like that wouldn't influence output, would be equally imperceptible, and probably easier to calculate (compared to "hash seed times running all LLMs supported times number of RNG algorithms, to see if output matches").

Presumably there's some other trick, or it's a red herring / failed experiment and not what they actually do in practice.

Groxx··on Stealing Reasoning Traces from Proprietary LLM APIs
It's rather common for posters to make a very small summary in a comment. It can help fight the floods of comments working off the title alone (though it's not particularly needed here for that purpose, imo)
← PreviousPage 4 of 34Next →