MurphyA/hacker-news huggingface dataset:
Built a Product Hunt People Are Using
by h100ker | 2025-07-08 19:42:21+00:00
When I look back, Buildbook wasn’t born in a boardroom — it started from a place of frustration. I was studying Mathematical Finance at CSU Long Beach and looking for people to build real software with. Not for a class, not for a grade — just to get better. But around me? Nothing. No builders. No momentum.

So I started looking elsewhere. I found a Discord server of people helping each other with Leetcode. We started talking. It turned out many of them were from Berkeley or nearby, and they were just as hungry to build something real. We spun up a side chat and built a real-time podcast fact-checking extension together. It wasn’t perfect, but it clicked. Everyone grew. We gained new skills, new stories to tell in interviews, and most importantly, new collaborators.

That one project changed everything. It made me realize that what’s broken isn't just recruiting — it’s how technical people find each other, collaborate, and show the world what they can do. LinkedIn is outdated. GitHub is noisy. Product Hunt is a ghost town. None of these platforms were built for what Gen Z and AI-native builders need.

So we started Buildbook — a place where technical students and professionals collaborate in public, get credit for what they build, and get discovered based on real work. It’s social GitHub meets verified identity. We launched in January, and since then over 16,000 users have joined us — all grassroots, all word of mouth.

This isn't just about helping students build resumes. It’s about redefining how people break into tech, how they grow, and how recruiters find actual builders instead of keyword matches. I’m building Buildbook because I needed it. And I know a million other people do too.
by borromakot | 2025-07-08 19:42:31+00:00
Simultaneously bullish on LLMs and insanely confused as to why anyone would literally ever use something like a Supabase MCP unless there is some kind of "dev sandbox" credentials that only get access to dev/staging data.

And I'm so confused at why anyone seems to phrase prompt engineering as any kind of mitigation at all.

Like flabbergasted.
by reaperducer | 2025-07-08 19:42:33+00:00
To be fair you shouldn't be sitting in the bathroom for that long because you'll develop hemorrhoids.

Maybe he's really good at chess?

(Unlike my former co-worker who would monopolize the one men's room stall for two hours at a stretch doing chess puzzles on his phone, and I'd have to go to the IT building. Gross.)
by etchalon | 2025-07-08 19:42:42+00:00
Ugh. Can they not? Who do I talk about them not?

NuxtLabs was doing great work building out support for Cloudflare, making it a viable alternative to Vercel.

Now, I'm sure all that work will get dropped and we'll be stuck with only Vercel being a first-class host for Nuxt-based applications.
by Groxx | 2025-07-08 19:43:46+00:00
Global use looks fine - it's a very-simply-used sync pool to do larger blocks of rand reads, which makes plenty of sense for performance.

Unsafe use also looks fine, values either don't escape the function (a type string->byte type cast for function signature reasons) or they do but they're new temporary data (the byte->string cast, which is fine because there's no risk of reusing or modifying the original bytes).

I'm going to intentionally not make any claims to "cryptographic security" or "is this a GUID" as I'm not super clear on the details there. The code looks pretty normal to me though, with the possible exception of the base64 encoding (why not base64.URLEncoding? https://pkg.go.dev/encoding/base64#pkg-variables).
by mschuster91 | 2025-07-08 19:44:05+00:00
> - Mozilla should not let a few extremely rich executives loot the business.

The problem is, when searching for high-level executives, you're not competing against other NGOs, you're competing with the wide free market - and salaries there are, frankly, out of control and have been so for decades [1]. Either Mozilla Foundation plays the dirty game just like everyone else does, or they go out of business.

It's the system that's broken at a fundamental level, not individual actors.

[1] https://www.epi.org/publication/ceo-pay-in-2023/
by davetron5000 | 2025-07-08 19:44:06+00:00
The biggest thing is the mocking system. MiniTest's feels so difficult to use.

I also like creating custom matchers vs. creating my own assert_* methods.

I would agree that many features of RSpec are, honestly, bad: shared examples, shared contexts, etc. Excessive use of let! and let, plus the predicate matchers are all just really confusing to me.

I actually thought about patching the RSpec gem to remove the features I didn't like :) Might still consider it heh
by funnyflywheel | 2025-07-08 19:44:55+00:00
I find that having Brendan Eich back in charge of Mozilla would be very unlikely for two reasons:

- He’s already built a modestly successful competitor in Brave, so there might not be much incentive for him to jump ship. - It’s possible that bringing him back may risk the ire of the LGBTQ+ community. (His comments against same-sex marriage led to his resignation as CEO of Mozilla back in 2014.)

However, this is just my speculation.
by CLEARrecruits | 2025-07-08 19:45:18+00:00
CLEAR | Senior Frontend Engineers, Android Engineers, Principal Backend Engineers | NYC Onsite (4-5 days in-office w/ free catered lunch daily) | https://www.clearme.com/

CLEAR's mission is to strengthen security and create frictionless experiences. With over 30 million members and a growing network of partners across the world, CLEAR's identity platform is transforming the way people live, work, and travel. CLEAR connects you to the things that make you, you – making everyday experiences easier, more secure, and friction-free. We're committed to privacy done right which means members are always in control of their own information, and we never sell member data.

If interested, apply here --> https://grnh.se/e4e5dc881us
by MangoCoffee | 2025-07-08 19:45:21+00:00
>Imagine canning your 7nm process last minute only few years before the chip shortage.

https://www.eetimes.com/samsung-globalfoundries-prep-14nm-pr...

"Samsung expects to be in production late this year with a 14 nm FinFET process it has developed. GlobalFoundries has licensed the process and will have it in production early next year."

GlobalFoundries licensed 14nm from Samsung. How do you know GlobalFoundries is capable of 7nm?
by mandmandam | 2025-07-08 19:45:47+00:00
You aren't engaging with any of my points, just repeating the dogma - which helps proves my point.

> School closures worked well for preventing spread.

Show me the data.

And, at what cost? Was the juice worth the squeeze? ... How many teachers have you talked to lately? Because the universal consensus is that closures did serious damage, still being felt to this day.

And it's an undeniable fact, that conversation (among many others) was heavily suppressed. Researchers who raised it were shadow-banned from Twitter, Facebook etc. That's not science, it's authoritarian dogma from an unaccountable political class.

There were superior alternatives - putting air purifiers in classrooms would have been a big one. But we weren't permitted to even have that conversation.

> Vaccines actually solved the covid issue.

Or, basically everyone already got corona and now there's a level of herd immunity; like with every global pandemic ever. Did you see any data on this? Or are you 'trusting the science' which you haven't actually seen.

> Lockdowns did worked, actually.

Oh? So, you can point to countries where there were no lockdowns and they got torn apart, can you? ... Because researchers who have looked at that question say it isn't actually that clear [0].

The purpose of lockdowns was to slow the spread so that chronically underfunded and privatized healthcare systems wouldn't utterly collapse. Fair enough - but it wasn't presented that way, and investment in public health hasn't been improved since. Instead, most systems in the West seem stretched more than ever, while we have plenty of money for sending Israel bombs and weapons, or building concentration camps, or deporting people at ludicrous expense, etc.

... But that wasn't even what I was talking about - I was talking about how even questioning mandatory lockdowns was enough to make people lose their jobs, and get censored from mainstream and social media. It's not very scientific to censor scientists.

> there is no "both sides" on climate change. Republicans are actively trying to make it happen.

And Democrats pay lip service to stopping them, but don't seem very effective. And when something like Deepwater Horizon happens, or the DAPL protests, or support for fracking is an issue, where is the Dem leadership? Quietly backing the fossil fuel companies, every single time.

What's needed is radical change, immediately. That's the view of basically every scientist. Democrats pretend not to understand that. It's nowhere near good enough, and I see no reason to expect change; not the slightest glimmer of hope for what's necessary.

0 - https://www.bbc.com/future/article/20250304-the-countries-th...
by fsflover | 2025-07-08 19:47:34+00:00
> The unix philosophy cries out: is this the end of Linux (or, as many are calling it, GNU plus Linux)?

I still see no counterarguments here. Meanwhile, systemd, like cancer, is eating Linux from the inside, breaking its flexibility and therefore future resilence:

https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd

https://news.ycombinator.com/item?id=42918448

https://news.ycombinator.com/item?id=42889792
by alganet | 2025-07-08 19:48:03+00:00
We brazillians have a popular saying: "muito cacique pra pouco índio" (a rough translation would be "too many shamans for too few tribesmen"). It's used as a criticism when too many people want to be at the helm.

I can related to that wisdom much more than I can relate to some old chinese (or old anything) text. I lived it, many times.

Maybe there are some important leadership advice in the text. But should you really apply it in the 21st century?
by dlcarrier | 2025-07-08 19:48:39+00:00
That's what I was complaining about; non-commercial production EVs could be much easier to repair than any other vehicle type, but they aren't. Car manufacturers, for both combustion and electric vehicles, can and do lock out components to prevent end users from servicing and repairing their own vehicles. If modern batteries and IGBTs existed decades ago, we would have had a period of mass-produced electric vehicles that were as easy to work on as a Model T. Really, electric vehicles have existed since the Model T, but none of them ever sold well, because they were to slow and had too little range.

People DIY their own EVs all the time, and on the electronics side all you need is a battery, a battery management unit, a charge controller, a motor controller, and the motor. Some of those parts can even be integrated into a single module If your combustion-powered car is fuel injected, it probably needs just as complicated of computer systems as an EV. (with the exception being rare cases of mechanical fuel injection)

The rest of an EV drivetrain is the same as any combustion car, except the transmission can be much simpler or may not be needed at all.

If an electronic components dies within one of those modules, swapping it out is no more work than swapping out something like an alternator or a starter. If the motor itself needs replacement, that's much, much easier than swapping out a combustion engine. Most electric cars have motors small enough that a single person could lift and carry one. If your motor controller died, you might be able to fix it with board level repair, just as you could rebuild an alternator yourself, but almost everyone working on a vehicle, whether DIY or commercially, is going to replace it, with either something new or something repaired/rebuilt by a specialist.

It's possible to get EVs with cheap components that won't last long, but it's also possible to get components with good design and build quality that will last a lifetime. Combustion engines, on the other hand, are regulated into designs that have extremely high efficiency when brand new, with no care for their long-term performance, so pretty much any modern consumer combustion vehicle has extremely fragile piston rings that begin leaking almost immediately, making for much shorter lifespans than decades-old combustion vehicles.

Driver assist is completely unrelated to the fuel type and open-source solutions do exist, that work on both combustion and electric drivetrains.
by dcminter | 2025-07-08 19:48:49+00:00
...and if he does, why does he then consider the year 99999 to be out of reach? As I understand it the idea is to promote "long term thinking" but I really don't see how this affectation is actually supposed to achieve anything beyond mildly irritating/confusing the reader.

At least the Long Now Foundation stuff comes with that context built-in.

https://longnow.org/
by akdom | 2025-07-08 19:48:52+00:00
A key tool missing in most applications of MCP is better underlying authorization controls. Instead of granting large-scale access to data like this at the MCP level, just-in-time authorization would dramatically reduce the attack surface.

See the point from gregnr on

> Fine-grain permissions at the token level. We want to give folks the ability to choose exactly which Supabase services the LLM will have access to, and at what level (read vs. write)

Even finer grained down to fields, rows, etc. and dynamic rescoping in response to task needs would be incredible here.
by conradev | 2025-07-08 19:50:20+00:00
I'm genuinely trying to engage and I'm curious where my preconceptions are "fundamentally wrong" versus not understanding "what makes a dance copyrightable where a massage is not".

Where are you on the continuum? Regarding training an AI model in my basement on purchased music, do you think I should:

- Not be allowed to train it

- Not be allowed to run it

- Not be allowed to share outputs from it anywhere

- Not be allowed to share outputs from it publicly

- Not be allowed to share outputs from it commercially

- Not be allowed to share its weights for others to run it

Or are you primarily focused on the current legal precedent?
by glenstein | 2025-07-08 19:50:49+00:00
Exactly, and to your point, a lot of the charges against Mozilla are mutually exclusive, contradictory, or barely even half-made attempts at arguments. You've outlined the make money/don't make money contradiction. But to add a few more of the crazy criticisms, sincerely made:

- Implying without evidence that the VPN is run at prohibitively massive cost and at the expense of other programs

- Claiming that Mozilla has "run out of money" (they have over $1 billion in assets)

- Overstating costs of Mozilla's dabbling in blockchain (they wrote a paper or two)

- Claiming the CEO pay has crippled Mozilla's ability to work on core browser (it's slightly more than 1% of their revenue)

- Claiming without any mechanism or argument that there's a missing feature Mozilla could have developed that would have restored all their market share

- Related to the above, completely ignoring that Chrome drove market share in its own proactive ways, leveraging its search and Android dominance, rolling out affordable Chromebooks and that these drove the market share more than anything specific to Mozilla

- Firefox has become bloated and slow (Outdated talking point, it was true for a time, but then they did the dang thing and delivered Quantum, which delivered the major advances in speed in stability that everyone asked for)

That's not to say there's no valid criticisms, there are plenty. There seems to be real cause and effect, for instance, on Firefox's investments in FirefoxOS and the ability to invest resources in the browser, and that did happen over a time where market share was lost. And the dabbling in ads risks compromising the soul of their mission in critical ways.

But meanwhile these (above) have all generally been basically misunderstandings or bad arguments with no internal logic, but claimed over and over again in the backwaters of internet comment sections with complete impunity. The case study in comment section hallucinations is as interesting to me as what is presently unfolding at Mozilla itself.
by tptacek | 2025-07-08 19:51:00+00:00
Can this ever work? I understand what you're trying to do here, but this is a lot like trying to sanitize user-provided Javascript before passing it to a trusted eval(). That approach has never, ever worked.

It seems weird that your MCP would be the security boundary here. To me, the problem seems pretty clear: in a realistic agent setup doing automated queries against a production database (or a database with production data in it), there should be one LLM context that is reading tickets, and another LLM context that can drive MCP SQL calls, and then agent code in between those contexts to enforce invariants.

I get that you can't do that with Cursor; Cursor has just one context. But that's why pointing Cursor at an MCP hooked up to a production database is an insane thing to do.
by idopmstuff | 2025-07-08 19:51:20+00:00
I played online poker successfully for years back when it was booming.

There are definitely online players who lack the skills you're describing, but that's not as much of a problem as you think. You can hide tells just by shutting up and staying still while you're in the action.

The other half of that is reading other people's tells, and online poker is more helpful there than you'd think. Most of reading other people (especially at relatively low-mid levels) is about reading the story they're telling with their action rather than reading their face/words/etc.

Classic example is: There are two hearts on the board on the flop and the person calls your bet. Turn comes, not a heart, person calls again. River comes, not a heart, person suddenly bets big to try to get you to fold, because they had two hearts and failed to make their flush.

Bigger picture, you read their style of play. Are they playing a lot of hands or very few? Passive or very active? None of these things require reading the person's mannerisms, and you can practice all of them very well online (though online you also run tracking software that gives you stats on opponents, which helps when you're playing a bunch of tables at a time).

Writing this out makes me miss online poker. Shame the games are terrible now (and I also have a child and business as opposed to the endless free time of my twenties, to be fair).
by Macha | 2025-07-08 19:51:28+00:00
> We can point at what we'd like to see, sure. Did you know there's already a special developer's edition? No web designer is building on Firefox first any more. We're lucky if they even test on it. All the functionality attached to Firefox's "Browser tools" sub-menu should be unceremoniously ripped out, banished to the developer's edition.

If they're still developing the dev tools (which I'd argue they need to if they want any companies to support the browser), then what's there to gain by removing it from the regular build? I don't get it.
by solarwindy | 2025-07-08 19:51:43+00:00
Relative to humans, these models sure have ungodly amounts of knowledge, but they also kinda have a lobotomy, in never having moved through the world. It’s remarkable they work as well as they do trained chiefly on text, but being so untethered from the only reality we know intelligence to have emerged from... frankly, what do we expect?
by gregnr | 2025-07-08 19:52:16+00:00
We're experimenting with a PostgREST MCP server that will take full advantage of table permissions and row level security policies. This will be useful if you strictly want to give LLMs access to data (not DDL). Since it piggybacks off of our existing auth infrastructure, it will allow you to apply the exact fine grain policies that you are comfortable with down to the row level.
by lilyball | 2025-07-08 19:52:51+00:00
I can easily see this bug happening in Rust. At some level you need to transform your data model into text to write out, and to parse incoming text. If you want to parse linewise you might use BufRead::lines(), and then write a parser for those lines. That parser won't touch CRs at all, which means when you do the opposite and write the code that serializes your data model back to lines, it's easy to forget that you need to avoid having a trailing CR, since CR appears nowhere else in your code.
by sandspar | 2025-07-08 19:53:16+00:00
One striking thing about Gen Alpha and young Zoomers is how RAPIDLY they learn. Being young is like being on learning-focused anabolic steroid #1 + online programs and AI are like learning-focused anabolic steroid #2. It's really impressive. Take any "time to learn" estimate you have, like "2 years to become good at chess", and today's young people can slice it by 10x.
by ollien | 2025-07-08 19:53:45+00:00
Untrusted user input can be escaped if you _must_ eval (however ill-advised), depending on your language (look no further than shell escaping...). There is a set of rules you can apply to guarantee untrusted input will be stringified and not run as code. They may be fiddly, and you may wish to outsource them to a battle-tested library, but they _do_ exist.

Nothing exists like this for an LLM.
by StillBored | 2025-07-08 19:54:20+00:00
POSIX threads, used by C/C++ and a lot of other language runtimes is somewhat platform independent and provides for affinity, priority and policy controls.

For starters: https://man7.org/linux/man-pages/man3/pthread_setschedparam....

None of the standard attributes (AFAIK) are directly "put me on a tiny core", but they frequently work hand in hand with those decisions. Lower your priority and the scheduler dumps you on some low clocked small core kinds of effects when its not busy. Or if you have machine knowledge just set your core affinity with pthread_setaffinity_np() which as the extension states is non-portable but can directly translate to "run me on a tiny core" if the right mask is provided.

At least in C/C++ most if not all modern platforms provide these kinds of controls and metadata and while the API might change a bit writing a couple versions of schedule_me_on_a_tiny_core() for each target platform is fairly trivial.
by Qem | 2025-07-08 19:54:28+00:00
> Python's object model that can be summarized as "everything is a dict with string keys".

Given this "it's dicts all the way down" nature of CPython, I'm curious if the recent hash table theoretical breakthrough[1] discussed here[2] a few months ago may eventually help making it much faster, given the compounding of dict upon dict?

[1] https://www.quantamagazine.org/undergraduate-upends-a-40-yea...

[2] https://news.ycombinator.com/item?id=43002511
by losvedir | 2025-07-08 19:54:50+00:00
The problem is, as you say, eval() is still useful! And having LLMs digest or otherwise operate on untrusted input is one of its stronger use cases.

I know you're pretty pro-LLM, and have talked about fly.io writing their own agents. Do you have a different solution to the "trifecta" Simon talks about here? Do you just take the stance that agents shouldn't work with untrusted input?

Yes, it feels like this is "just" XSS, which is "just" a category of injection, but it's not obvious to me the way to solve it, the way it is with the others.