MurphyA/hacker-news huggingface dataset:
by reilly3000 | 2025-09-08 00:49:02+00:00
There may be an interesting opportunity to gather data on the accuracy of guesses per image. You could use something like Google analytics, but simple server-side logging is more private and keeps the page light.

The question could be: What images are most often mistaken? What characteristics do they share? Knowing the highest false negative images would be really valuable people to know what not to ignore.
by istjohn | 2025-09-08 00:49:34+00:00
There are already cheaper, better vehicles being produced in China that American consumers cannot buy due to exhorbitant tariffs. These vehicles will only improve as battery tech continues to rapidly advance and Chinese manufacturers climb the learning curve.

Meanwhile, American manufacturers will lazily enjoy comfortable margins guaranteed by the protectionist tariffs without needing to make meaningful investments in new technology. They will fall even further behind and become even less competitive. But the American people will be told--truthfully--that if they do not continue buying overpriced, technically inferior vehicles, the entire domestic auto industry will fall, with dire consequences for thousands of American workers.

We bailed out the auto industry in 2008. The bipartisan tariffs on Chinese EVs is effectively another giant domestic auto industry bailout at great cost to American consumers, though they by and large are oblivious to this. But an argument could have been made that these tariffs were a necessary and temporary measure to give the US auto industry time and space to catch up to their foreign competition. With this change, these tariffs will need to be a permanent ball and chain on the American consumer. The US auto industry will never be able to exist without them.
by xrd | 2025-09-08 00:51:13+00:00
I installed my nest, and it was indeed very simple. And, it appeared to work with Home Assistant, but like I said, the devil is in the details. It was a very frustrating experience.

The problem is that if I look here I cannot tell the first thing about which device is supported and how well. HA does not have a great filtering system.

https://www.home-assistant.io/integrations/#climate
by Panzer04 | 2025-09-08 00:51:33+00:00
Intel CPUs are decidedly better value when multicore performance is a concern. At the top end they trade blows.

If your workload is pointer-chasing intel's new CPUs aren't great though, and the X3D chips are possibly a good pick (if the workload fits in cache) which is why they get a lot of hype from reviewers who benchmark games and judge the score 90% based on that performance.
by SixFeetUp | 2025-09-08 00:52:15+00:00
Six Feet Up is seeking a Data Engineer with 12+ years of experience designing, building, and maintaining robust and scalable data pipelines. In this role, you will have the opportunity to work on a variety of challenging projects across different industries, delivering high-quality solutions that drive business value.

If you are a motivated Data Engineer seeking a challenging and rewarding role, we encourage you to apply.
by Nathan2055 | 2025-09-08 00:52:32+00:00
Okay so here's the argument I've heard: if arbitrary replacements of the lid sensor were possible, it would be feasible to create a tampered sensor that failed to detect the MacBook closing, thus preventing it from entering sleep mode.

This could then be combined with some software on the machine to turn a MacBook into a difficult to detect recording device, bypassing protections such as the microphone and camera privacy alerts, since the MacBook would be closed but not sleeping.

Additionally, since the auto-locking is also tied to triggering sleep mode, it would be possible to gain access to a powered off device, switch the sensors, wait for the user to attempt to sleep mode the device, and then steal it back, completely unlocked with full access to the drive.

Are these absolutely ridiculous, James Bond-tier threat assessments? Yes, absolutely. But they're both totally feasible (and not too far off from exploits I've heard about in real life), and both are completely negated by simply serializing the lid sensor.

Should Apple include an option, buried in recoveryOS behind authentication and disk unlock steps like the option to allow downgrades and allow kernel extensions, that enables arbitrary and "unauthorized" hardware replacements like this? Yes, they really should. If implemented correctly, it would not harm the security profile of the system while still preventing the aforementioned exploits.

There are good security reasons for a lot of what Apple does. They just tend to push a little too far beyond mitigating those security issues into doing things which start to qualify as vendor lock-in.

I really wish people would start to recognize where the line should be drawn, rather than organizing into "security of the walled garden" versus "freedom of choice" groups whenever these things get brought up. You can have both! The dichotomy itself is a fiction perpetuated to defend the status quo.
by mccoyb | 2025-09-08 00:52:35+00:00
Does Clojure solve this to a satisfying degree? One gives up static typing to embrace Clojure’s solutions.

On the other hand, Rust / Haskell provide partial solutions with static typing — but run into annoying boilerplate related to the orphan rule.

I’m not sure if there’s a true solution, given the level of thinking which has gone into these two forks in the road.
by s1artibartfast | 2025-09-08 00:52:43+00:00
It's not really that ironic. The native Americans fought and lost. If they had their way there would be no USA or settlers. Where is the irony in this?

It seems the lesson is that if foreign people want to come and live here, they better come with an army and be prepared to fight. Another lesson is that if you let them in they will displace you and diminish your autonomy.
Ask HN: How much can we trust open-source projects or our hardware?
by solosquad | 2025-09-08 00:52:52+00:00
For large open-source security-focused projects like Kali Linux, we’re told there are no backdoors but with millions of lines of code, how can we actually verify that? Full manual auditing isn’t feasible for most individuals.

Some thoughts/questions:

Are reproducible builds and supply-chain audits enough to trust the binaries?

What strategies exist for spotting subtle backdoors in such large codebases?

For hardware, how do you approach the risk of compromised firmware, microcode, or hidden subsystems (e.g. Intel ME, AMD PSP)?

Do projects like Coreboot, Heads, or formally verified kernels meaningfully reduce this risk in practice?

Beyond reading every line yourself, what’s the best way to build confidence?

How much trust (percentage-wise) do you personally put in OSS security projects or commodity hardware, and what technical mitigations do you use to minimize blind trust?
by crq-yml | 2025-09-08 00:52:53+00:00
I think the problem can be defined equally as: we can't invest in something more abstract than "plain text" at this time. When we try, it gets downgraded to a plain text projection of the syntax.

The plain text encoding itself exists in a process of incremental, path-dependent development from Morse Code signals to Unicode resulting in a "Gigantic Lookup Table" (GLUT, my coining) approach to symbolic comprehension. The assumption is useful - lots of features can "just work" by knowing that a particular bit pattern is always a particular symbol.

If we push up the abstraction level, we get a different set of symbols that are better suited to the app, but not equivalent GLUT tooling. Instead we usually get parsing of plain text as a transport. For example, CSV parsing. It is sloppy; it is also good enough.

Edit: XML is also a key example. It goes out of its way to respect the text transport approach. There are dedicated XML editors. But people want to edit it as plain text and they can't quite get there because funny-business with character encodings gets in the way, adding a bunch of ampersands and semicolons onto the symbols they want to edit. Thus we have ended up with "the CSV of hypertext documents", Markdown.
by Uptrenda | 2025-09-08 00:53:06+00:00
Biggest irony of the thread is the OP and the ones commenting celebrating the tech putting themselves out of the job while contributing it. Eg. a dermatologist who looks at skin conditions -- a very visual skill. They use their skills at that to build an app that people can use to check for skin cancer, rashes, whatever. Now, people have less incentive to see a dermatologist and might miss the zebras (and in fact: people are lazy and tend to hate doctors already so they won't.) Then there's the software engineers here who (even if you're a high level senior engineer) are further moved down the chopping board the better AI gets.

YAY, three cheers for all the soy boys building AI. See you on unemployment soon.
by rogerrogerr | 2025-09-08 00:54:57+00:00
Cameras can clearly discern the broadside of a firetruck. Whether some earlier build didn't detect one doesn't change that firetrucks reflect plenty of photons to be detectable.

I'm consistently surprised by how immune to sun-blindness my car is. It regularly reads traffic lights that have the sun right next to them; I've never seen any discernible degradation due to too much light, too little light, or bad contrast of any kind.

You're just bringing up a never-ending stream of but-what-abouts, so I'm done refuting them after this. It's not a good use of my time.
by to11mtm | 2025-09-08 00:55:25+00:00
Good ramble though :)

Yeah, Apple definitely realized that they should do something and for as much as I don't care for their ecosystem I think they were very smart in how they handled the need for memory bandwidth, e.x. having more 16 bit channels vs fewer 64 bit channels probably allows for better power management characteristics as far as being able to relocating data on 'sleep'/'wake' and thus being able to leave more of the ram powered off.

That plus the good UMA impl has left the rest of the industry 'not playing catchup' i.e.

- Intel failing to capitalize on the opportunity of a 'VRAM heavy' low end card to gain market share,

- AMD failing to bite the bullet and meaningfully try to fight Nvidia on memory/bandwidth margin...

- Nvidia just raking that margin in...

- By this point you'd think Qualcomm would just do an 'AI Accelerator' reference platform just to try....

- I'm guessing whatever efforts are happening in China, they are too busy trying to fill internal needs to bother boasting and tipping their hat; better to let outside companies continue to overspend on the current paradigm.
by danpalmer | 2025-09-08 00:55:55+00:00
I'm a bit biased, but I find the AI overviews to be basically great. All I want from a search engine is the correct answer, Google's knowledge graph has done that for many queries for a long time, and AI overviews seems like a good next step in that process.

I've not seen many hallucinations, fact checking is fairly straightforward with the onward links, and it's not like I can take any linked content at face value anyway, I'd still want to fact check when it makes sense even if it wasn't AI written.
by ropable | 2025-09-08 00:56:00+00:00
I got my start in professional software development by building an multi-user Access shadow-IT database application that made heavy use of VBA. It only worked because it had a couple of active users at any time, and I left that workplace with documentation consisting of a half-page of bullet points. I know for certain that it was still in usage four years after I left, though God know how long it kept operating in the end.

Notwithstanding that shadow IT is the bane of my existence these days, I sometimes need to be reminded of how far a motivated individual can come when they have access to adequate tools and information.
by motorest | 2025-09-08 00:56:41+00:00
> The problem with the current move semantics is that, compared to e.g. Rust: 1) the compiler generates unnecessary code and 2) instead of just implementing class T you must implement a kind of optional<T>.

I don't know what you mean by "compiler generates unnecessary code" or why you see that as a problem. I also have no idea what you mean by "a kind of optional". The only requirement on moved-from objects is that they must be left in a valid state. Why do you see that as a problem?
by colechristensen | 2025-09-08 00:56:50+00:00
The BBC said they were all subcontractors and as you suggest, mechanics involved in setting up the factory in some way. Seems like it's exactly that, a contract house not wanting to go through the process of getting proper visas and getting folks in in any way.

As with a lot of things, I'm not so opposed to enforcing visa rules for something like this but maybe the shackles and method of detention weren't all that necessary. Also worth looking at fixing the reasons why companies are skipping the proper visa process, because nobody at all should be (or is?) opposed to LG/Hyundai setting up a factory in the US. Things we should be doing with a helping hand are being done with guns drawn instead.

But we all know they're doing it this way for the populist theater, there's folks out there that want to watch fascist police state theater on the evening news.
by thaumasiotes | 2025-09-08 00:57:34+00:00
Yes, I'm talking about kunyomi; I don't see how that affects the point.

> If I'm Japanese and I see an obscure kanji, its phonetic (component) only gives me information about its onyomi, which is almost certainly some wildly obscure loanword from late medieval Chinese that isn't even in my recognition vocabulary

I was highly amused when one of the "obscure" kanji presented was 論. It doesn't get much less obscure than that.

On the other hand, none of the interviewees recognized it. All of them got 檸檬. (Another one I wouldn't have expected to be obscure, but in that case I would have been right.)

It's possible that there's some selection for interviewees who provide entertaining responses, but the effect seems weak to me for two reasons:

(1) Of the people featured in a video, you see all of them respond to every prompt. So selection has to be limited to "which people are going to appear", and even then if an entertaining person is boring on some prompts you'll still see that.

(2) Getting things wrong almost always consists of making one or two wrong guesses and saying "I don't know". It's much more entertaining when people get them right, unless they turn out to be obvious and everyone gets them right.

> (I was right about "spicious" but wrong about "sus": it's actually "uplookish".)

You'd need super, not sub, for "up" or "over". Traditionally it's "over"; I'm not sure if there's another Latin prefix that gets used for "up". There is one for "down", de (as in "depend", "descend", or even "defenestrate"), but nothing comes to mind for "up". The opposite of "descend" is "ascend", where the prefix just means "toward".
by to11mtm | 2025-09-08 00:58:36+00:00
Some of it is about maximizing their balance sheet.

The factories that existing ICE engines are made in, both their build and every retooling has a cost; being able to maximize the saleable product from that cost is in the best interests of the balance sheet.

This is a challenge for both the US as well as Japan which is why you see each doing different weird things to try and kick the can down the road or ignore it. But that's a deeper part of the rabbit hole.
by yojo | 2025-09-08 00:59:02+00:00
I can confirm that Google was using Perforce for version control extensively, at least through 2008. I think it was somehow customized, but I definitely have lingering muscle memory around “p4 sync” and “p4 submit”.

I was on an internal tools team doing distinctly unsexy LAMP-stack work, but all the documentation I ever saw talked about perforce/p4.
by motorest | 2025-09-08 00:59:55+00:00
> When you say you must, do you mean that it’s best practice, that or that this is UB or similar?

I'm not OP, but the only requirements that C++ imposed on moved-from objects is that they remain valid objects. Meaning, they can be safely destroyed or reused by reassigning or even moving other objects into them. I have no idea what OP could be possibly referring to.
Show HN: GoSocket – A Simple WebSocket Framework for Go
by filipejohansson | 2025-09-08 01:00:59+00:00
Hi HN,

I built GoSocket, a small library that helps you set up WebSocket servers in Go with almost no boilerplate.

It lets you start a server in a few lines of code, handle connections, broadcast to rooms or clients, and add middleware. JSON is supported now, Protobuf and MessagePack are planned.

Example:

ws := gosocket.NewServer() ws.WithPort(8080). WithPath("/ws"). OnMessage(func(c gosocket.Client, m gosocket.Message, ctx *gosocket.HandlerContext) error { c.Send(m.RawData) // echo return nil }) log.Fatal(ws.Start())

Repo: https://github.com/FilipeJohansson/gosocket

It’s still pre-1.0, so I’d love feedback, testing, and contributions.
by exidy | 2025-09-08 01:01:27+00:00
I love BuildKite. It might seem obvious now but I feel like BK had two key ideas -- fully declarative pipelines and a hybrid SaaS control plane / customer-managed workers concept that made it so much easier to deploy into large enterprises. That combined with a UI that was clear and a pleasure to work with.

I do wonder how BK will continue in a world that's increasingly dominated by GitHub and and other integrated solutions, but I hope as long as there's a market for quality tools, BK will survive and thrive.
by colechristensen | 2025-09-08 01:01:30+00:00
>Doing a raid publicly and loudly puts a lot of current and future investment at risk for very little gain.

The "gain" is the armchair nazis' watching it on the news approval rating and the rest of the population getting acclimatized to the environment. These things are being done for show, to systematically test the boundaries and build consent for future actions by normalizing this kind of activity.
by n4bz0r | 2025-09-08 01:01:49+00:00
> I'm also tired of remembering ports, if there's a way of mapping those. Should I run a local proxy?

If we're talking web-services - absolutely. I put Caddy in front of everything just to be able to simply use domains. You can also use it to map ports to either standard or more convenient ones if that suffices. Configuring reverse-proxy with Caddy [0] takes just a few lines:

http://some-service.internal { reverse-proxy localhost:12345 }

After setting up a reverse-proxy or two you might want to expand your infrustructure with the following to to neaten thing up even more:

- DNS-server: most routers can be that; another easy option would be PiHole.

- DHCP-server: same as above (PiHole does DHCP too).

- Reverse-proxie(s): you can have either just one for the entire network or a number closer to the amount of services if you choose to have HTTPS between everything. Wouldn't bother with Nginx for that unless there is a strong incentive.

- ACME-server: provides the certs for the local reverse-proxies if you choose to have HTTPS between everything. Caddy can also act as a very easy to set up ACME-server [1].

If you have all that set up, you can access all the local services securely and via readable URLs. Given all the services get their certs from the ACME-server, the consumers only need to trust (install) one root cert in order to consider all the local connections secure.

Might seem like a lot at first, but the configuration is fairly straightforward and I found it's worth the effort.

[0]: https://caddyserver.com/docs/caddyfile/directives/reverse_pr...

[1]: https://caddyserver.com/docs/caddyfile/directives/acme_serve...
by RezaSi | 2025-09-08 01:01:55+00:00
Really solid write-up, thanks for putting this together. The bit about GOPROXY=a,b vs a|b was new to me — I’ve run into weird issues before with private modules and now it makes a lot more sense.

Dependabot supporting private proxies is huge too. I remember just giving up on it for Go projects with private deps because it would always break. Excited to try this out.

Curious though — for smaller teams that don’t want to run their own proxy, do you think sticking with public + direct is “good enough,” or is that still risky in terms of leaking private module names?
by blargey | 2025-09-08 01:02:31+00:00
It's stated clearly that the factory in question is under construction. There are multiple such factories being constructed by Hyundai in Georgia, each under an agreement with the state to employ several thousand locals once they get it running, in exchange for incentives to build on US soil in the first place. (ex/ 8,100 local jobs under this plan, for example https://georgia.org/sites/default/files/2023-09/hyundai_moto... )

These people were brought there for one-off, short-term, specialized work to get the factory ready, to start employing those thousands of locals, as per Hyundai's agreement with Georgia's state govt. They abused temporary / non-work visas to do so, but not to displace local labor (which wouldn't know how to do the job) - rather, to help build a new source of local labor.

As such, it's likely that there isn't a single person in the world who "wins" because of this deportation, except maybe some harangued ICE official with quotas to fill. Maybe that's why "the white house hasn't yet made a huge fuss about it and why hyundai isn't being held to account."
by bigyabai | 2025-09-08 01:02:58+00:00
Kali Linux is a pentesting distro. It's not claimed to be secure and AFAIK it makes deliberately insecure design decisions to enable spoofing/SDR attacks.

Are reproducible builds and supply-chain audits enough to trust the binaries?

No. But for most applications trust isn't really required.

What strategies exist for spotting subtle backdoors in such large codebases?

It's not hard. For big projects, contributors are usually a tight-knit group that heavily scrutinize any outsider PRs. By creating a rigorous system of code review (and implementing reminders for bad dependencies) you can deter backdoors decently well.

For hardware, how do you approach the risk of compromised firmware, microcode, or hidden subsystems

You cannot.

Do projects like Coreboot, Heads, or formally verified kernels meaningfully reduce this risk in practice?

No, but if properly configured they can reduce attack surface as-advertised.

Beyond reading every line yourself, what’s the best way to build confidence?

I know this is a dumb answer, but "be smart" will get you a really long ways. Stick to the main roads, don't use software developed by 2 or 3 people if your personal security is paramount. Keep your systems slim and minimally networked, route any home servers through a VPN or proxy to prevent it from being harassed on the open internet.
by ccheshirecat | 2025-09-08 01:02:58+00:00
For clarity: Hypr Pte. Ltd. (UEN 202520273N), AS211747 HYPR-NET, is an infra-focused startup working on microVMs, virtualization, and novel approaches to infrastructure. We are independently managed and only active in the infrastructure space; other accounts or projects are unrelated.

Infuze was ours but has since been shut down so we can focus fully on our own architecture. There has never been any scam, nor anything remotely related to one.

The Show HN post about the lightweight VM manager is unrelated to any cloud business. It started as a quick personal tool and unexpectedly resonated with people, so I iterated on it the same day. It’s just a minimal Go wrapper around libvirt, not connected to our core work.
by tedk-42 | 2025-09-08 01:03:28+00:00
Really is an exciting future ahead. So many lost arts that don't need a dedicated human to relearn deep knowledge required to make an update.

A reminder though these LLM calls cost energy and we need reliable power generation to iterate through this next tech cycle.

Hopefully all that useless crypto wasted clock cycle burn is going to LLM clock cycle burn :)