It would appear no one else submitted the posts in question, so the most obvious answer is the account is finding interesting articles that no one else has found. It would be one thing if it won out of many dupe posters, but that doesn't seem to be what's happening.
You aren't serious about high-frequency karma ("HFK") unless you colocate your equipment with the routing for your sources so you can beat your HFK competition to a submission by at least 200ms.
We will have reached HFK-ception when the bots are fighting to be the first to submit "How I used AI to build a High-Frequency Karma Farming Bot on Hacker News."
Noob comes from newb, which comes from newbie. Some argue it comes from "nubile" but I don't personally buy that etymology. I distinctly remember "newb" followed by "noob" but that was eons ago.
They are all valid front page submissions by the looks of them and they appear to be the first ones submitted. It wouldn’t be hard to do if you cared enough to configure notifications for frontier announcements. If someone were using technology to influence submissions or misuse HN, that would be a concern but I don’t see any evidence of that.
To directly answer your question, my guess is they have an alert set up for various places on the internet, and are able to post the links faster than anyone else. Maybe that part is automated.
AI product updates probably tend to rank very well here. If you look at the domains the user is submitting, they’re pretty normal: twitter accounts of tech CEOs, big company blogs, etc.
If I saw a bunch of blogs with affiliate links or landing pages for slop products I’d be more suspicious.
I question all the time what dictates the posts I see on the front page every day, and whether or not it's truly based on organic interest. i wish i could say i up/down vote frequently but i do not and i wonder if that's true for most people.
You can make your post on top in some services by paying 5 dollars on fiver. I asked before about HN, and someone said it is hard to do... Maybe they found a way?
Good question — we'd be happy to submit a PR, but it's not clear to me that they'd be interested. Some background:
- Our approach writes new cache entries all the time. This can get expensive, and is a pretty big change in behavior from how actions/setup-go works today.
- actions/setup-go can basically be considered incredibly critical infrastructure for the public golang ecosystem. Any change in behavior is probably very risky and slow to happen. At this point I'd bet that we see no change, ever, in behavior.
Additionally there are a few relevant issues/prs that have been ignored for years so I'm not optimistic about contributing upstream. Frankly what we've done is write a very small bit of glue code that is likely most effective as a reference for teams writing their own custom caching actions that fit their exact needs:
That said we'd be happy if someone used our code and found it valuable! Lukas put a ton of effort into cleaning up my initial version, added the cache trimming, etc. We depend on this for all of our jobs and use it every day and think it's quite good.
My 2c given that that issue has sat in TODO for several years with no movement is that the maintainers probably aren't going to be pursuing too many big swings like that.
End of the day, implementing an efficient GOCACHE with github's cache primitives is untenable for the general case IMO. It works by shipping around big tarballs, and when your cache actually needs fine grained access to thousands of usually tiny files, only a few of which change, you're likely gonna spend more time on transfer and unpacking than you gain with cache hits.
The other thing is, as mentioned elsewhere, it's really hard to measure cache perf at a granular enough level, and aggregate that across jobs, so I'm willing to bet most people don't (outside of this very good post!) and are going off of vibes or napkin math and don't realize they're wasting time caching garbage.
actions/setup-go maintainer here! Great post, I like the ideas in there. We are always open to improvements, but it's true that low-risk ones are preferred. Feel free to submit your ideas to the GitHub issue tracker. I'll do some due diligence myself.
> - Allowing actions/setup-go users to specify a cache key prefix so that they can have more than one golang CI job, each with its own cache [...]
I'd actually go further: this may be a sensible default behavior.
"Always update the cache" can get expensive, but it's a neat one; "trim the cache" is definitely necessary if you enable this in a moderately active repository in our experience.
If you want really out-there ideas: rather than storing and loading the full cache monolithically, you could use a GitHub-specific GOCACHEPROG and Go-specific cache service to load only the active items. The pruning problem goes away because accretion is cheap. In theory, parallel jobs could actually share this joint cache. (This may not be a realistic initiative at GitHub.)
If you can raise feedback with your colleagues —
- The docs and settings for Actions Cache limits are really hard to navigate; at some pointed we desperately wanted to pay GitHub more money for more cache, but couldn't figure out why we were capped.
- Bulk-data endpoints for Actions performance would be a boon for optimization projects like this. I wind up either scraping `gh run` (slow) or setting up a GitHub App to collect perf data through webhooks (initially tedious, has to be continuously available).
All this aside — actions/setup-go is a pretty well-considered default and an essential part of writing Go on GitHub; ty for your work maintaining it!
- Allowing actions/setup-go users to specify a cache key prefix so that they can have more than one golang CI job, each with its own cache: this is 100% worth upstreaming. I believe there are existing requests and PRs about this. Up to you guys to implement however you see fit.
- Allowing "always update the cache": also a good idea to enable as an option, very important for non-open-source teams that are trying to maximize cache hit rate.
- Allowing "trim the cache": if you're going to allow always updating the cache, probably a good idea.
But the "always update" and "trim" cache changes combine to have a lot of risks regarding cache poisoning that might be bad for open source projects. Lukas may have a different opinion or more to say on this front.
Hey everyone, one of the authors here. This is a "small" improvement that has saved us a LOT of developer time over the last few months. It's actually quite crazy to me that the default actions/setup-go simply does not work well if you want to have more than one golang action running at the same time.
The blogpost has a lot of technical details, but you can also just read the code and try it yourself:
We recently did similar work for our pipelines, heavily based on Better GitHub Actions caching for Go [0]. Were you aware of that article, or did you (re-)discover things like the cache trimming?
What's the best way to contribute? I'd like to expose the "go-version-file" input for the setup-go action instead of setting a Go version directly. Open an issue in the repo?
Also, have you considered this potential optimization: the module cache doesn't care about architecture, it's just downloaded code. Would it make sense to cache module and build cache separately, and use an architecture-free cache key for the module cache?
> That’s also because we didn’t migrate to a Zanzibar-style system like SpiceDB or OpenFGA. Adopting one would mean rewriting every permission check and asking every self-hosted customer to run another stateful service and introduce breaking changes.
This is awesome. Does the demo run fully client-side? This is at least as good as my current solution (Preview.app -> Tools -> Remove Background), I generally pre-crop so it's not too hard to get just the object I care about.
As a Pennsylvanian I think this is idiotic and I completely blame the press, who have breathlesslly amplified baseless negative claims. Such as that datacenters are somehow bad for the environment, have negative impacts on water supply, will raise energy and water rates for residential customers, etc.
I HATE that this is somehow becoming a culture war issue.
I remember the fracking roll out here. The companies involved directly handed checks to local residents, promised to train locals for new jobs, paid to fund schools, and so on.
These companies have a lot of money behind them - if they're not willing to put in the effort to convince local residents that the data center will be good for them, I feel like that's on them. They could easily do some handouts and fix this. Offer to pay extra taxes to the state or whatever, fund a new power plant, pay everyone who lives nearby the DC some thousands of dollars, whatever.
The older I get the more and more convinced I become that the media is the actual real enemy of the country. Their lifeblood is creating controversy and drama about everything so they can show ads. So insane that so few call them out (probably because most people are already "captured" by them).
> As a Pennsylvanian I think this is idiotic and I completely blame the press, who have breathlesslly amplified baseless negative claims.
But have they disproportionately amplified them? I follow some energy experts, and the consensus for AI-focused mega-datacenters seems to be "no". Some interesting reports:
If people were just honest with their objections, then we could be unified, but currently we're fighting misinformation that are trying to stop 5MW computer closets and projects that are trying to be a drop in replacement for a _steel mill_ (which should be an automatic approval)
it certainly seems to be. if it were just a matter of noise, or discharging contaminated water, or waste gasses we're supposed to have rules for these things. any facility that does these things is supposed to adhere to them.
so the issue isn't about data centers at all, but the fact that we've decided to stop enforcing even minimal environmental standards.
water consumption is another one, we just haven't done a very good of realizing that its a limited resource and trying to manage it.
the other is raising electrical rates. it should just be a real problem to raise rates to pay for Capex for other non-residential customers.
those are all real issues. 'people are going to get screwed' is a culture war thing, particularly if their opinion seems to be against environmental regulation as a matter of course. if a data center isn't noisy and polluting, and doesn't impact water or electrical consumption, then there is no sane reason to be against it. there are data centers that use close loop cooling. there are those that don't effect your rates. there are ones that are not really close to residences.
The idea is that it's like Github but it stays up even as your commit/CI frequency increases. As a customer I'm stoked and looking forward to fully switching over as that's exactly what I want.
Can't wait for the Graphite/Cursor alternative (Origin) to become available. Actions being down for an hour in the middle of the US East workday is crazy. It's super frustrating to be an enterprise customer of Github, seems like we don't get any dedicated resources or additional stability. At this point our only option is self-host github enterprise or move away.
I feel stuck on Github until the next generation of forges (I assume Linear is working on one too, and the Pierre guys, and there's probably more) are ready. When it works, I'm actually a huge fan of Github. It just doesn't work reliably and it's a huge operational risk to not be able to freaking deploy. We'll most likely switch to self-hosted GHE in the near-term while continuing to evaluate alternative forges — Forgejo, Gitlab, Gitea, Sourcehut, aren't appealing enough to switch.
We built our first version of our in-app agent with opencode, but we're probably going to switch to Pi. Fundamentally, Pi is the shape of the thing that should exist, and it's awesome to see that it works. Very satisfying to my engineering brain. Been having fun with ohmypi as my personal harness, but going to switch over to pi soon and just mess around with it until it works the way I want. The idea of completely personalized software is so cool and now that it's finally possible I am having so much fun.
Haven't heard of ohmypi, thanks! I feel like this is a good starting point for someone like me who is not ready to configure a harness from zero right now.
Yup! If you keep your laptop on, failing dbs are investigable on tmpfs too — works fine for debugging a few tests in a loop, just can’t run the tests, sleep the computer, have lunch, and come back.
- This post
- The DeepMind Institute https://news.ycombinator.com/item?id=49727659
- Mistral X Mozilla: Private, Multilingual AI Browsing https://news.ycombinator.com/item?id=49723408
based on their account submission history they have a 25% hit rate (!) Seems very, very weird.
reply