MurphyA/hacker-news huggingface dataset:
by kolbe | 2026-01-29 19:40:26+00:00
I have a Model Y with AI hardware version 4. It is phenomenal at self-driving, and if your impression of FSD is a year old or older, then you are woefully out of date in understanding where the tech is today. If I could, I would send my own grade school child off to her friend's houses and extracurricular activities in my car unaccompanied. It is safer than buses, taxis, and me. Not since Tesla created the first economically viable EV for the American public have I been as excited about a revolution in automotive technology. Other than the fact that Tesla still needs people out there manually driving to generate training data, I don't think Tesla should be selling cars at all. I fully support this move, and all I have to say is thank God for Waymo, so we can have good competition in the Robotaxi market.

I'm done listening to pundits doubt Elon. I haven't seen Wall Street forecast future economic and technological trends well at all. Elon has created an EV market, caught falling rocket boosters, created the leading AI "nonprofit", and launched a worldwide satellite internet service, mostly in the face of rent seeking financial professionals and hacker news SSEs calling him dumb. I'm not sure what else a man needs to do to prove he deserves a little deference in his strategic decisions.
by 5gkhn2 | 2026-01-29 19:40:33+00:00
Hi HN,

I built o2go to solve a few pain points I kept hitting with existing OAuth2
libraries in Go:

- I wanted explicit control over auth code and refresh flows

- I needed to see raw HTTP errors when debugging OAuth issues

- I didn’t want to pull provider-specific code unless I needed it

The core is intentionally small and boring, and providers live in separate
modules.

Happy to answer questions or discuss design decisions.
by benlivengood | 2026-01-29 19:40:34+00:00
Agreed; everyone complained that LLMs have no world model, so here we go. Next logical step is to backfill the weights with encoded video from the real world at some reasonable frame rate to ground the imagination and then branch the inference on possible interventions (actions) in the near future of the simulation, throw the results into a goal evaluator and then send the winning action-predictions to motors. Getting timing right will probably require a bit more work than literally gluing them together, but probably not much more.
by Tuna-Fish | 2026-01-29 19:41:04+00:00
The lawyers are the ones talking, and they have to come up with a fair valuation.

If SpaceX pays too much for it, other SpaceX shareholders have a case against SpaceX leadership. If xAI accepts an offer that is too low, other xAI shareholders have a case against xAI leadership. Given that the leadership is basically the same people, they are very well incentivized to come up with a valuation that is as fair as possible.

And this is not just theoretical, Musk has already been sued successfully once on a similar case, when his companies gave out too much free support to the boring company.
by insane_dreamer | 2026-01-29 19:41:12+00:00
Who is liable when FSD is used? In Waymo's case, they own and operate the vehicle so obviously they are fully liable.

But in a human driver with FSD on, are they liable if FSD fails? My understanding is yes, they are. Tesla doesn't want that liability. And to me this helps explain why FSD adoption is difficult. I don't want to hand control over to a probabilistic system that might fail but I would be at fault. In other words, I trust my own driving more than the FSD (I could be right or wrong, but I think most people will feel the same way).
by lifetimerubyist | 2026-01-29 19:41:25+00:00
I use the built-in TokyoNight Day theme as my light theme in GhosTTY and I think it's almost perfect. Then I use TokyoNightMoon for dark. Works great. Hard to use anything else now.

If you're CLI application doesn't play nice with it (i haven't seen many) I don't use it.
by manuelabeledo | 2026-01-29 19:41:42+00:00
I'll just copy & paste this bit:

> The whole claim that Qualcomm is on par with Apple predicates upon results from benchmarking tools, which stress CPU and GPU and thus induce peak power consumption.

If you are saying that Qualcomm and Mediatek are on par with Apple because they perform the same in Geekbench, then we have to talk about peak power consumption and TDP. But regardless, even if we were to look at average power consumption over time, Elite Gen 5 still tops the A19 Pro by more than *20%*.

> No, that is looking at the actual experience of using the phone. Peak consumption is a useless metric. Nobody cares. People care about their phone feeling smooth and how often they have to charge. From this point of view, Apple has no lead whatsoever provided by their SoC while they used to which is the point I have been making from the start.

Speaking of moving goalposts...

This whole paragraph makes no sense. First you said that Qualcomm is on par with Apple based off benchmarks. Now, if peak consumption doesn't matter, therefore benchmarks don't either, so we have to compare the "experience" of using a phone? How do you quantify that? Which phone would you compare an iPhone with? Does every single phone with an Elite Gen 5 perform exactly the same? Do we choose the Poco F8 Ultra, which seems to throttle and stutter quite frequently, or the OnePlus 15, which reaches external temperatures of 50C?

Anyway, pick a lane, or at least make a good point, because this ain't one.

Unrelated, but this whole thing reminds me of how, back in the day, some manufacturers would put a desktop CPU and GPU inside a laptop as thick as a brick, fed the 10Kg monstrosity with a 400W power adapter, and call it "the fastest laptop ever", which could be technically true, but was very, very wrong.
by themanmaran | 2026-01-29 19:42:10+00:00
We build "long running" email agents. But it's not really long running in the sense of an agent taking 1000's of actions in a giant loop.

It's more "long running" because the agent takes 4 steps, then waits a week for the user to email it back. We might have a successful client exchange that takes a month, but for the Agent it's 99% just waiting for the next user reply.
by Veserv | 2026-01-29 19:42:12+00:00
Absent more precise information, this is a statistical negative mark for Waymo putting their child pedestrian injury rate at ~2-4x higher than the US human average.

US human drivers average ~3.3 trillion miles per year [1]. US human drivers cause ~7,000 child pedestrian injurys per year [2]. That amounts to a average of 1 child pedestrian injury per ~470 million miles. Waymo has done ~100-200 million fully autonomous miles [3][4]. That means they average 1 child pedestrian injury per ~100-200 million miles. That is a injury rate ~2-4x higher than the human average.

However, the child pedestrian injury rate is only a official estimate (likely undercounting relative to highly scrutinized Waymo miles) and is a whole US average (operational domain might not be comparable, though this could easily swing either way), but absent more precise and better information, we should default to the calculated 2-4x higher injury rate; it is up to Waymo to robustly demonstrate otherwise.

Furthermore, Waymo has published reasonably robust claims arguing they achieve ~90% crash reduction [5] in total. The most likely new hypotheses in light of this crash are:

A. Their systems are not actually robustly 10x better than human drivers. Waymos claims are incorrect or non-comparable.

B. There are child-specific risk factors that humans account for that Waymo does not that cause a 20-40x differential risk around children relative to normal Waymo driving.

C. This is a fluke child pedestrian injury. Time will tell. Given their relatively robustly claimed 90% crash reduction, it is likely prudent to allow further operation in general, though possibly not in certain contexts.

[1] https://afdc.energy.gov/data/10315

[2] https://crashstats.nhtsa.dot.gov/Api/Public/Publication/8137...

[3] https://www.therobotreport.com/waymo-reaches-100m-fully-auto...

[4] https://waymo.com/blog/2025/12/demonstrably-safe-ai-for-auto...

[5] https://waymo.com/safety/impact/
by NewUser76312 | 2026-01-29 19:42:27+00:00
I don't understand, doesn't the market solve these issues? Here's what I figure would happen:

1. App creators will pass the extra cost over to the iPhone users.

2. Android (and other platforms that can host smartphone apps) will be more competitive and start to look better for both app creators and consumers.

Sure, there's a bit of a context switching cost. Not everyone will just be able to automatically change over to an Android phone tomorrow. But it doesn't need to happen all at once. These phones get updated and replaced every 1-2 years. If iOS users see their app store prices rising too high, and they aren't OK with this, then they will switch to Android eventually, once it's worth it.

Otherwise, I don't see any problem with Apple reaping the benefit of their powerful and well-built walled garden ecosystem.
by lysace | 2026-01-29 19:42:41+00:00
I am so happy that my embarrassing lack of geographical knowledge of the US states' internal geographies amused you. A good laugh is great for your health, I've heard. ;)

At least I know where your country is located.

Now, let me quiz you on the geographical locations of French regions? Or perhaps Finnish regions, if that's something you work closer with, day-to-day?
by philipwhiuk | 2026-01-29 19:42:42+00:00
This almost certainly isn't only a China problem. I've observed UK users asking questions about diabetes and other health advice. We also have an inexpensive (free-at-point of use for most stuff) but stretched healthcare system. Doubtless there are US users looking at the cost of their healthcare and resorting to ChatGPT instead too.

In companies people talk about Shadow-IT happening when IT doesn't cover the user needs. We should probably label this stuff Shadow-Health.

To some extent, the deployment of a publicly funded AI health chat bot, where the responses can be analysed by healthcare professionals to at least prevent future harm is probably significantly less bad than telling people not to ask AI questions and consult the existing stretched infrastructure. Because people will ask the questions regardless.
by bobbob1921 | 2026-01-29 19:42:52+00:00
Amazing, perfect app! I use it frequently, and I love the response I get from customers or friends whom I turn onto it (or install it for).
I also encourage others to donate to this developer. The sad thing is casual users would not even think of donating as they assume this type of feature should be (properly) built into the OS; so I’ve made sure to donate on behalf of users I’ve turned on to Everything. Great app!
by echelon | 2026-01-29 19:42:54+00:00
Tim is awesome.

Ironically, he covered PixVerse's world model last week and it came close to your ask: https://youtu.be/SAjKSRRJstQ?si=dqybCnaPvMmhpOnV&t=371

(Earlier in the video it shows him live prompting.)

World models are popping up everywhere, from almost every frontier lab.
by ulrikrasmussen | 2026-01-29 19:42:58+00:00
I run GrapheneOS, but I can't use the national digital identity app because it requires Google Play Integrity. I very much cannot do what I want without it having severe consequences because the duopoly is starting to shape the basic digital infrastructure, and critical services start requiring that I use one of the two ecosystems.

I think the principle of digital autonomy should be front and center. Surely we can figure out security models that don't imply that two American tech companies get to call the shots on what people can or cannot do on hardware that they supposedly own.
by Spivak | 2026-01-29 19:42:59+00:00
People's standards for when they're willing to cede control over their lives both as the passenger and the pedestrian in the situation to a machine are higher than a human.

And for not totally irrational reasons like machine follows programming and does not fear death, or with 100% certainty machine has bugs which will eventually end up killing someone for a really stupid reason—and nobody wants that to be them. Then there's just the general https://xkcd.com/2030/ problem of people rightfully not trusting technology because we are really bad at it, and our systems are set up in such a way that once you reach critical mass of money consequences become other people's problem.

Washington banned automatic subway train operation for 15 years after one incident that wasn't the computer's fault, and they still make a human sit in the cab. That's the bar. In that light it's hard not to see these cars as playing fast and loose with people's safety by comparison.
by azarai | 2026-01-29 19:43:25+00:00
Where is the issue?

I worked around 7 years on the smallest 11 Zoll MacBook Air from 2015, on my lap sitting in an armchair in my living room and all was fine. Party even developing in Java. The only pain was the SSD was too tiny once I got into audio stuff.

Now, it's a 2022 MacBook Pro M1 Pro with 16GB and it's enough for most stuff I do. Only the 1Tb SSD got too small again.

If you want to work and get results, just get it done with whatever you got. Everything else are excuses.

On a side note, every dev should be forced to code on average consumer computers.
by mystifyingpoi | 2026-01-29 19:43:38+00:00
The example given in "The WhatsApp Insider Threat" is just plain stupid. An AI agent always runs as the user. All agent actions are under responsibility of the user. We are stepping into age of "it's not me, AI did that" and I don't want to be a part of it.

Also:

> completely bypassing DLP controls, email security, and any corporate audit trail.

That doesn't mean anything. If I can log in to work email on my personal machine, that's the decision of the company to allow this, it has pros and cons. There is a solution to this: do not allow any access to work stuff outside of strictly controlled work hardware.
by eitally | 2026-01-29 19:43:50+00:00
There are exceptions to what I'm about to say, but it is largely the rule.

The thing a lot of people who haven't lived it don't seem to recognize is that enterprise software is usually buggy and brittle, and that's both expected and accepted because most IT organizations have never paid for top technical talent. If you're creating apps for back office use, or even supply chain and sometimes customer facing stuff, frequently 95% availability is good enough, and things that only work about 90-95% of the time without bugs is also good enough. There's such an ingrained mentality in big business that "internal tools suck" that even if AI-generated tools also suck similarly it's still going to be good enough for most use cases.

It's important for readers in a place like HN to realize that the majority of software in the world is not created in our tech bubble, and most apps only have an audience ranging from dozens to several thousands of users.
by samrus | 2026-01-29 19:44:07+00:00
I mean problems not worth solving, because theyve already been solved. If you need to just do the grunt work of retrieving the solution to a trite and worn out problem from the models training data, then they work great

But if you want to do interesting things, like all the shills keep trying to claim they do. Then this wont do it for you. You have to do it for it
by themafia | 2026-01-29 19:44:28+00:00
> and that data clearly shows that the experiment is successful in reducing crashes

I disagree. You need way more data, like orders of magnitude more. There are trillions of miles driven in the US every year. Those miles often include driving in inclement weather which is something Waymo hasn't even scraped the surface of yet.

> without question

There are _tons_ of questions. This is not even a simple problem. I cannot understand this prerogative. It's far too eager or hopeful.

> We can and should do both

Well Google is operating Waymo and "we" control road policy. One of these things we can act on today and the other relies on huge amounts of investments paying off in scenarios that haven't even been tested successfully yet. I see an environment forming where we ignore the hard problems and pray these corporate overlords solve the problem on their own. It's madness.
by lkbm | 2026-01-29 19:44:48+00:00
> In practice, this isn't reasonable, because "hey we're slightly better than a population that includes the drunks, the inattentive, and the infirm" is not going to win public trust.

Sadly, you're right, but as rational people, we can acknowledge that it should. I care about reducing injuries and deaths, and the %tile of human performance needed for that is probably something like 30%ile. It's definitely well below 75%ile.
Show HN: A cross-framework Markdown/MDX parser to simplify content management
by intlayer_org | 2026-01-29 19:44:51+00:00
I've been frustrated with managing markdown in my projects for a long time so I'm happy to share a new approach that I implemented.

To render md content, the first challenge is the choice of a library:
On one hand, you have the "lego brick" solutions like unified, remark, and rehype. They're powerful, but setting up the whole AST pipeline and that plugging system is for me an unnecessary complexity. On the other hand, you have things like @next/mdx which are cool but too page-focused and doesn't work on the client side.

So I used to prefer solution like markdown-to-jsx or react-markdown. The DX is much better, works client and server side, the solution is lighter.

But that solutions don't support HTML or MDX out of the box, so you end up with the same plugin issues.
Plus, using them with i18n (like i18next or next-intl) is usually a mess. You end up with a if/else logic to render the right language, and your page weight explodes. I finally also came across several issues regarding the front-matter handling. (And Until recently both of that solutions used to be react only solutions.)

So I decided to build something new for intlayer. Something that just works out if the box.

> Note that to do it, I chose to fork the amazing work from markdown-to-jsx v7.7.14 (by quantizor) which is based on simple-markdown v0.2.2 (by Khan Academy) to build the solution.

So I build this parser with a few main goals:
- Lightweight solution
- Framework-agnostic (React, Vue, Svelte, Angular, Solid, Preact)
- Simple MDX setup: No crazy plugin chains
- SSR and Client-side support
- Configurable at the provider level to map your design system components
- Component-focused, to fine grain the rendering for each part of my app
- Type-safe (Retrieving front-matter as a typed object, get types components Props)
- i18n friendly (Loading optimized for i18n use cases)
- using zod schema to validate the front-matter
Demo:

So what’s the innovation here?
- Truly Universal: The exact same logic for React, Vue, Svelte, etc.
- Lightweight MDX-like Compiler: Works seamlessly on the edge and server.
- No Loading Time: Content is loaded at build time, whatever you are using fs, fetch, etc
- Allows you to organize and reuse small markdown sections across multiple docs or pages easily.
- Parse your front-matter in a type safe way. (like used to do contentLayer)

For what use cases is it designed for?
- Blogs / Doc / Privacy Policy / Terms of Service
- Dynamic content retrieved from a backend
- Externalizing pages content to a headless CMS
- Loading .md files

Complete docs: https://intlayer.org/doc/concept/content/markdown
Code https://github.com/aymericzip/intlayer/

Does this resonate with you? Curious if others feel the same, and how you’re currently handling Markdown in your apps?
by OutOfHere | 2026-01-29 19:45:00+00:00
For someone who is in such a position in the future, always notify the local police in writing and by phone call, if not also in person, before starting such an exercise. Make sure they have the get-out-of-jail documentation in advance of the exercise. If the police doesn't approve, don't do it. It would be better to get a no-objection letter from the police in advance. Make sure an attorney is aware of the activities and all documentation. Do not take any chances. You don't live in a kind or forgiving world.
by 0xffff2 | 2026-01-29 19:45:08+00:00
I've lived all over California and I agree that 25mph is the norm here.

Edit: However, elsewhere in the thread someone linked this Streetview image that shoes that this particular school zone is 15mph: https://maps.app.goo.gl/7PcB2zskuKyYB56W8?g_st=ac
by pixl97 | 2026-01-29 19:45:15+00:00
>A good rule of thumb in biology and particular any kind of hormone production and balance is "use it or lose it" -

Very basic and very often wrong rule, so take it with a grain of salt.

Insulin for example is the opposite. "lose it then use it" would be a general rule for type 2 diabetics where insulin resistance commonly due to weight gain is the primary problem. Losing the weight leads to better uptake and usage. For a type 1 "lose it then use it" you typically lose the ability to produce insulin to an an autoimmune disorder, then are stuck using insulin for the rest of your life.

The body itself typically attempts to main homeostasis, but at population scales this is something that is going to have a massive range of ways it shows up. Evolution, at grand scales, doesn't care if you survive as long as enough of your population survives and breeds. At the end of the day you might just be one of those people that was born broken and to work properly you need replacement parts/chemicals. A working medical system should be there to figure out which case is which.
by agentcoops | 2026-01-29 19:45:29+00:00
I don't know what it looks like on the ground now, but Scala was the defacto language of data infrastructure across the post-Twitter world of SV late stage/growth startups. In large part, this was because these companies were populated by former members of the Twitter data team so it was familiar, but also because there was so much open source tooling at that point. ML teams largely wrote/write Python, product teams in JS/whatever backend language, but data teams -- outside of Google and the pre-Twitter firms -- usually wrote Scala for Spark, Scalding etc in the 2012-2022ish era.

I worked in Scala for most of my career and it was never hard to get a job on a growth stage data team or, indeed, in finance/data-intensive industries. I'm still shocked at how the language/community managed to throw away the position they had achieved. At first I was equally shocked to see the Saudi Sovereign Wealth fund investing in the language, but then realized it was just 300k from the EU and everything made sense.

It's still my favorite language for getting things done so I wouldn't be upset with a comeback for the language, but I certainly don't expect it at this point.
by OkayPhysicist | 2026-01-29 19:45:37+00:00
I could see teleoperated help catching on. Americans are weird about staff. When I visit my old-world family, it's seen as perfectly normal to have someone living in an attached apartment, handling the cooking the cleaning, etc. There are well-established etiquette rules, understood both by the staff and the family, which help navigate the rather complicated, radically unequal relationship between the two.

Americans by and large don't do that. We software developers have not that different of an income gap between us and minimum wage workers compared to my family overseas and their staff. Yet, it would be considered weird, extravagant even, for a $300-500k/yr developer to have dedicated help. We're far more comfortable with people we don't need to interact with directly, like housecleaners, landscapers, etc.

Teleoperated robots sidestep that discomfort, somewhat, by obscuring the the humanity of the staff. It's probably not a particularly ethical basis for a product, but when has that ever stopped us.
by bluGill | 2026-01-29 19:45:41+00:00
If you tools are not updated that isn't the fault of C++. You will feel the same about Rust when forced to used a 15 year old version too (as I write this Rust 1.0 is only 10 years old). Don't whine to me about these problems, whine to your vendors until they give you the new stuff.