MurphyA/hacker-news huggingface dataset:
Show HN: Enclose Horse – Daily Puzzle Game
by cottomzhang | 2026-01-07 05:13:48+00:00
Enclose Horse is an addictive daily puzzle game where you strategically place walls to trap horses within a grid. Maximize your enclosed area to climb the global leaderboard. A new puzzle awaits every day!
The goal is simple: place walls on the grid to prevent the horse from escaping to the edges. The larger the area you enclose, the higher your score. But choose wisely - you only get one official submission per day!

Place walls by clicking or tapping on grid edges
Block escape routes - horses can't move diagonally or over water
Maximize your score - bigger enclosures mean bigger points
Catch cherries for bonus points when available
by somenameforme | 2026-01-07 05:14:16+00:00
I don't think this is really accurate because the traditional state of society, and one that remains in the 'developing world' which is almost certainly still the wide majority of the world at this point, is families living in multi generational housing with many people contributing. This enables older to generations to comfortably 'retire' when they see fit, and provides financial comfort and security. It's basically like decentralized pensions.

This new world of low fertility, small household size or even people living entirely alone, high external dependence, and the consequent broad insecurity - is still extremely new. And I do not think it will survive the test of time.
by Ericson2314 | 2026-01-07 05:14:47+00:00
I didn't mean to do some snide anticaptialism. Making new Postgreses and blenders is really hard. I don't think the startup ecosystem does a very good job, but I don't assume central planning would do a much better job either.

(The method I have the most confidence in is some sort of mixed system where there is non-profit, state-planned, and startup software development all at once.)

Markets are a tool, a means to the end. I think they're very good, I'm a big fan! But they are not an excuse not to think about the outcome we want.

I'm confident that the outcome I don't want is where most software developers are trying to find demand for their work, pivoting etc. it's very "pushing a string" or "cart before the horse". I want more "pull" where the users/benefiaries of software are better able to dictate or create themselves what they want, rather than being helpless until a pivoting engineer finds it for them.

Basically start-up culture has combined theories of exogenous growth from technology change, and a baseline assumption that most people are and will remain hopelessly computer illiterate, into an ideology that assumes the best software is always "surprising", a paradigm shift, etc.

Startups that make libraries/tools for other software developers are fortunately a good step in undermining these "the customer is an idiot and the product will be better than they expect" assumptions. That gives me hope we're reach a healthier mix of push and pull. Wild successes are always disruptive, but that shouldn't mean that the only success is wild, or trying to "act disruptive before wild success" ("manifest" paradigm shifts!) is always the best means to get there.
by wolrah | 2026-01-07 05:14:53+00:00
> I feel like it's easier to just have Ethernet and a strict HW firewall with the admin interfaces totally disabled (have to full reset to get back in).

Easier? Maybe, for certain values of easy, but as others have noted it's not hard to build a data diode setup using fiber ethernet and from there you just have to hardcode some ARP data and maybe a route entry to allow UDP to flow.

The thing is that with your solution as long as the firewall works properly data shouldn't be able to leak in the wrong direction. With a proper data diode, as long as physics continues to function more or less how we understand it you can prove that data can not leak in the wrong direction. That's a huge difference, especially when it comes to explaining what you're doing to non-technical higher ups, auditors, lawyers, etc.
by stryan | 2026-01-07 05:14:57+00:00
This is starting to sound suspiciously similar to the old lines about all rap being about gangbangers and money/drugs etc. Theres plenty of bands that do traditional clean vocals; I'm listening to Wytch Hazels latest album as I type this. They're very old school/early NWOBHM style metal/hard rock, you may like them.

Other bands with similar[0] vocals off the top of my head: Summerlands, Night Demon, Sonja, Crypt Sermon, Visigoth, Eternal Champion

Halford, Dio,Dickinson, and the other greats are going to be hard to replicate exactly but there's plenty of singers out there that are just as skilled andactively playing music.

[0] in the traditional clean vocals sense
by lovich | 2026-01-07 05:15:08+00:00
@dang, I get what you mean in a vacuum but this article is pretty insulting to the readers intelligence.

The third sentence of the article is

> But one misstep he admitted to might surprise a lot of people who dream of the day they can quit their 9-to-5.

Does anyone really believe the co founder of google retiring after their rise to supremacy in search was the equivalent of someone quitting their 9-5?

They might have well said “Google co-founder shares secrets that stealing bread to eat when you’re hungry and sleeping under bridges is actually illegal”
by csuwldcat | 2026-01-07 05:15:19+00:00
It's not just about the WebAuthn API, you're talking about passkeys as if their key bundles are freely accessible to random userland actors, which is absurd. If that were the case, many assurances the platform makes would be out the window. The reality is that you are obviously already trusting the platform, hardware, its software/firmware, and the implementation's use of core key management APIs, which it doesn't just offer up to random callers. If you think any of those components/actors are not adhering to fundamental boundaries/limitations, like exposure of sensitive credential material to random callers on the device, it's a more far reaching indictment of passkeys in general.
by jackdoe | 2026-01-07 05:15:20+00:00
most of software engineering was rational, now it is becoming empirical

it is quite strange, you have to make it write the code in a way it can reason about it without it reading it, you also have to feel the code without reading all of it. like a blind man feeling the shape of an object; Shape from Darkness

you can ask opus to make a car, it will give you a car, then you ask it for navigation; no problem, it uses google maps works perfect

then you ask it to improve the breaks, and it will give internet to the tires and the break pedal, and the pedal will send a signal via ipv6 to the tires which will enable a very well designed local breaking system, why not, we already have internet for google maps.

i think the new software engineering is 10 times harder than the old one :)
by phire | 2026-01-07 05:15:32+00:00
I also notice that people with lots of experience with computers will automatically reboot when they encounter minor issues (have you tried turning it off and on again?).

When it then completely falls apart on reboot, they spend several hours trying to fix it and completely forget the "early warning signs" that motivated them to reboot in the first place.

I've think the same applies to updates. I know the time I'm most likely to think about installing updates is when my computer is playing up.
by denizkavi | 2026-01-07 05:16:46+00:00
Oh yeah, I've seen this before! Cool stuff

I would say primary concerns were:

dependency issues, needing more than model weights to be able to consume models (Multiple Sequence Alignment needs to be split, has its own always on server, so on), more convenient if the inputs and outputs are hardened interfaces as different envs

Our general findings in the BioML are that the models are not at all standardized especially compared to the diffusion model world for example, so treating each with its own often weird dependencies helped us get out more tools quicker.
by narukeu | 2026-01-07 05:16:47+00:00
[NOTE]

I originally posted this proposal in the GitHub Discussions for Microsoft's TypeScript Native (typescript-go) project. I personally feel it might receive more dicussions on Hacker News, so I've reposted the full text here. Comments and feedback are welcome.

[ORIGINAL]

Title: Proposal: Extract the Parser of TypeScript Native into a standalone Go Module to fill a gap in the Go ecosystem and benefit this project

I suggest extracting the Parser component from typescript-go and publishing it as an independent Go library.

Currently, the Go ecosystem severely lacks a complete, standard-compliant JavaScript/TypeScript/JSX parser. typescript-go actually possesses what is likely the most comprehensive Parser in the current Go ecosystem. If this could be decoupled, it would become a foundational cornerstone for frontend tooling within the Go language.

Rationale:

1. It fills a structural gap in the Go ecosystem.

In the JS ecosystem, TypeScript doesn't need a standalone Parser because tools like Babel are already very mature. However, in the Go ecosystem, there is currently no comparable infrastructure.
As frontend toolchains migrate toward high-performance native languages, Go is highly attractive to the vast community of JS/TS developers due to its ease of learning and concurrency advantages. By filling this void, Microsoft would allow external tools to reuse this core capability without needing to reinvent the wheel.

2. An independent Parser will attract integration from numerous external tools.

This means massive amounts of real-world codebases will be used to test this Parser. Edge cases discovered and fixed by the community can be fed directly back into typescript-go. This is far more efficient than relying solely on internal test cases and will significantly improve the robustness of the Parser.

3. From an engineering perspective, decoupling the Parser helps define project boundaries and improves maintainability.
Implementation-wise, this does not require rewriting core logic; it only involves adjusting the project structure to support Go Module referencing, making the engineering effort manageable.

4. TypeScript has, in a sense, become a de facto standard.

If Microsoft provides an official Go version of the Parser, it ensures that Go-based frontend toolchains maintain high consistency with the native TS compiler in parsing behavior. This prevents the community from creating various incompatible "dialect" parsers due to a lack of standards, thereby avoiding ecosystem fragmentation.
by Nextgrid | 2026-01-07 05:17:09+00:00
Disagreed. You can absolutely do all analytics, personalization and marketing in-house on your properties. You only need data sharing if you want to influence advertising on other properties or if you display others' ads on yours.

Whether you want to do so is a different matter. This obviously requires (potentially custom) software and infrastructure, vs throwing in GTM and calling it a day. If there is no regulatory reason for it (there isn't - this aspect of the GDPR is not enforced), most businesses won't bother and will take the easy option.
by DavidPiper | 2026-01-07 05:17:14+00:00
> However after a while I realized that people just post into the void. Everyone has something to say or promote, yet no one wants to listen. It's like we're all having our booth on a crowded public space, but there are no actual receivers...

> Thus I concluded that people overall are tired of socializing.

I don't think people are tired of socialising. People are tired of the self-centered, propagandized publication that social media companies have addicted us to, both as consumers and providers. This makes people want to socialise less because:

a) They get more immediate satisfaction from consuming or providing content than actually socialising

b) Satisfying this (any) addiction takes a lot of time and emotional effort that might otherwise be used for socialising

Ironically, I think the author discovered exactly what social media ACTUALLY looks like without the addictive algorithms: lots of people yelling and nobody listening.
by deathanatos | 2026-01-07 05:17:14+00:00
No, when Alice and Bob are people whose hardships are actual hardships. It's not just that it's a hardship that's rare, or that "it's just a different hardship", or something — I can read about genuine plight that might affect some small portion of the population and empathize with that, and they with me at the same time – even implicitly, without statement in the article. But this, by virtue of being written, explicitly is unempathetic, whereas "this rare cancer affects 8 people" is not. That's not a problem I wish that I had, vs. this is a problem faced by someone who is well off, to even call this a "hardship" is a stretch.

To do so during a time when tech is also dragging its reputation into the mud by generally harming the rank and file, through large corporations whose actions are not held to account in anti-trust laws, to tech bro oligarchs who wine and dine with power while the rest of us are worst off in a time of unprecedented inequality, to tech laying off hundreds of thousands of employees over the last few years, to LLMs replacing hard working people with slop-generators… is just additional insult to injury.

The article is simply, itself, shallow. "… Is a Lesson for the Rest of Us" — no; barring unforeseen and extremely unlikely circumstances, I'm literally never going to have the "problems" faced by Brin, because I have no expectation of ever retiring with "perpetual wealth" levels of money.
by vander_elst | 2026-01-07 05:17:42+00:00
If I could I'd retire tomorrow, I have so many projects I would like to take on, I have the feeling I could fill 3 lives with them: gardening, learning math, system programming, wine tasting, carpentry, sport, traveling etc... There are *so* many interesting things to do and so little time.
I guess time will tell but at the moment I have a hard time imagining myself getting bored.
by pugworthy | 2026-01-07 05:18:05+00:00
To me, this doesn't show the weakness of current models, it shows the variability of prompts and the influence on responses. Because without the prompt it's hard to tell what influenced the outcome.

I had this long discussion today with a co-worker about the merits of detailed queries with lots of guidance .md documents, vs just asking fairly open ended questions. Spelling out in great detail what you want, vs just generally describing what you want the outcomes to be in general then working from there.

His approach was to write a lot of agent files spelling out all kinds of things like code formatting style, well defined personas, etc. And here's me asking vague questions like, "I'm thinking of splitting off parts of this code base into a separate service, what do you think in general? Are there parts that might benefit from this?"
by devinplatt | 2026-01-07 05:18:21+00:00
In my experience, using LLMs to code encouraged me to write better documentation, because I can get better results when I feed the documentation to the LLM.

Also, I've noticed failure modes in LLM coding agents when there is less clarity and more complexity in abstractions or APIs. It's actually made me consider simplifying APIs so that the LLMs can handle them better.

Though I agree that in specific cases what's helpful for the model and what's helpful for humans won't always overlap. Once I actually added some comments to a markdown file as note to the LLM that most human readers wouldn't see, with some more verbose examples.

I think one of the big problems in general with agents today is that if you run the agent long enough they tend to "go off the rails", so then you need to babysit them and intervene when they go off track.

I guess in modern parlance, maintaining a good codebase can be framed as part of a broader "context engineering" problem.
by cuttothechase | 2026-01-07 05:18:28+00:00
Sergey's challenge looks like is not in retiring early or with non-work.

We had a high performing co-worker who was scared witless after a lay-off episode and this was not because he was worried about lacking money or loss of prestige., but because he could not come to terms with the simple fact of facing the 9 am on a Monday morning with absolutely no expectations. It freaked so much to not feel the hustle and the adrenaline rush of experiencing the blues Monday morning!?

Another colleague used to drive up to the parking lot of their previous employer, post lay-off., so that he could feel normal., and he did this for well over 6 - 8 months. Pack bags, wave to his wife and family, drive up in his Porsche to the parking lot and I guess feel normal !?
by BobbyJo | 2026-01-07 05:18:59+00:00
> Does the corner bakery need a moat to be a business?

Yes, actually. Its hard to open a competing bakery due to location availability, permitting, capex, and the difficulty of converting customers.

To add to that, food establishments generally exist on next to no margin, due to competition, despite all of that working in their favor.

Now imagine what the competitive landscape for that bakery would look like if all of that friction for new competitors disappeared. Margin would tend toward zero.
Show HN: Library for HTML interaction using voice agent
by rajnandan1 | 2026-01-07 05:19:05+00:00
I built Atticus, a framework-agnostic voice agent library that lets users control UI with voice commands.

It is a ts library client side meant to be used in frontend. It can be used to fill complex forms or do multi-step interaction. Built on top of OpenAI realtime agents

Current Limitations
1. Does not handle full redirection
2. Basic events only
by zelon88 | 2026-01-07 05:19:09+00:00
This, 100%.

I'd like to add my reasoning for a similar failure of an HP Proliant server I encountered.

Sometimes hardware can fail during long uptime and not become a problem until the next reboot. Consider a piece of hardware with 100 features. During typical use, the hardware may only use 50 of those features. Imagine one of the unused features has failed. This would not cause a catastrophic failure during typical use, but on startup (which rarely occurs) that feature is necessary and the system will not boot without it. If it could, it could still perform it's task... because the damaged feature is not needed. But it can't get past the boot phase, where the feature is required.

Tl;dr the system actually failed months ago and the user didn't notice because the missing feature was not needed again until the next reboot.
by guywithahat | 2026-01-07 05:19:55+00:00
As far as I remember, Tesla has been talking about full self driving and auto-updates since before 2009, and although cameras weren't placed on the car until years later I would argue these early models were low enough production they were selling the idea more than the product (like how a sports car might be stylized after a jet, even though it doesn't contain a jet engine, but just to capture the feeling of something that's fast). It's also worth noting that car had a lot more buttons, including PRNDL, stock, and I believe AC/heater.

Also my Tesla drives me to work every day just fine without intervention. I don't think you need unsupervised full self driving for the screen to make sense, and while I didn't have a Tesla 11 years ago I think the vision was clear and a screen with minimal/no buttons was still useful. My point is just that if you're trying to make a so-called driver's car, without regular updates or meaningful self driving capabilities, it makes sense to add buttons so people know where things are while driving. The screen was a logical derivation from the other features tesla was building and incorporating, starting with the screen because it's easy is a mistake by companies like VW/benz/etc in my opinion.
by xarope | 2026-01-07 05:20:02+00:00
If you think of the training data, e.g. SO, github etc, then you have a human asking or describing a problem, then the code as the solution. So I suspect current-gen LLMs are still following this model, which means for the forseeable future a human like language prompt will still be the best.

Until such time, of course, when LLMs are eating their own dogfood, in which case they - as has already happened - create their own language, evolve dramatically, and cue skynet.
by coppsilgold | 2026-01-07 05:22:48+00:00
Ultimately what he is suggesting to do is to bind a string of entropy to a website through facilitation of the browser and a Passkey.

A cryptographic seed is one of the most sensitive things. And here you choose to expose it to a website (even though it was specifically generated for that website). This is not something you do for authentication. The only reason to do this is to have javascript/wasm on a website perform sensitive cryptographic operations for you. You should not ever be doing this.

Applications such as password managers can already integrate entropy from a passkey to encrypt their databases using the Challenge-Response protocol: https://docs.yubico.com/yesdk/users-manual/application-otp/c...
by jaden | 2026-01-07 05:23:26+00:00
It's interesting to hear about his experience, but I'm not sure if it's typical. There are millions of people retiring each year, presumably many are happy to be done with the drudgery of work and excited to spend time on hobbies and projects they enjoy.

I'm curious to know how many retirees end up like Sergey and how many you don't hear about because they're too busy enjoying their retirement.
by somenameforme | 2026-01-07 05:23:47+00:00
A peer comment said something similar to which I responded to here: https://news.ycombinator.com/item?id=46522719

However, you brought up the distinction between consumers and producers, but I'd argue that such a thing doesn't inherently exist. YouTube was thriving before Google when it mostly just a site for people to share videos on. Here [1] is one of e.g. Veritasium's oldest videos. What it lacks in flare and production quality, it makes up for in content and authenticity.

You don't need 'creators', you simply need people. And I think a general theme among many of the most successful 'creators', is that they weren't really in it for the money. They simply enjoyed sharing videos with people. Like do you think Veritasium in that video could even begin to imagine what his 'channel' would become?

[1] - https://www.youtube.com/watch?v=U2g1H5wPmUE
by TheTaytay | 2026-01-07 05:24:02+00:00
This was extremely useful to read for many reasons, but my favorite thing I learned is that you can “teleport” a task FROM the local Claude Code to Claude Code on the web by prepending your request with “&”. That makes it a “background” task, which I initially erroneously thought was a local background task. Turns out it sends the task and conversation history up to the web version. This allows you to do work in other branches on Claude Code web, (and then teleport those sessions back down to local later if you wish)
by ej88 | 2026-01-07 05:24:04+00:00
I implemented some of his setup and have been loving it so far.

My current workflow is typically 3-5 Claude Codes in parallel

- Shallow clone, plan mode back and forth until I get the spec down, hand off to subagent to write a plan.md

- Ralph Wiggum Claude using plan.md and skills until PR passes tests, CI/CD, auto-responds to greptile reviews, prepares the PR for me to review

- Back and forth with Claude for any incremental changes or fixes

- Playwright MCP for Claude to view the browser for frontend

I still always comb through the PRs and double check everything including local testing, which is definitely the bottleneck in my dev cycles, but I'll typically have 2-4 PRs lined up ready for me at any moment.