Hacker Newsnew | past | comments | ask | show | jobs | submit | pbronez's commentslogin

Interesting, Project Sunrise aims to run non-stop flights between Sydney and London + New York. They needed to design a new airplane to do it. Targeting service starting late 2027.

Isn’t the solution high-quality identity verification? There are piles of digital identity companies out there. They make money selling to banks for KYC compliance. Heck, there are background check as a service companies designed to add trust to gig economy platforms.

I used to think that a small payment could accomplish the same thing, but X selling blue check marks proved that doesn’t help much. Well, at least it’s a much weaker signal than the previous curated version.

The challenge is any barrier to entry high enough to discourage motivated spammers is also high enough to discourage casual users. That disrupts the network effects you’ve traditionally needed to bootstrap a social website.

If I was trying to get a new social site off the ground right now, I would try:

1) secure a good brand from the pre-AI era. Twitter, Digg, Friendster, MySpace. Something that motivates a first look.

2) Require third party identity verification on sign up, configured so the social site is never the custodian of PII, though require enough demographics to support high-value advertising later. Verification is free to the user, ideally provide multiple verification options- one US and one EU at minimum.

3) Target a few core communities and invest. Find the people who moderate historically great subreddits, were active in twitter communities during the good years, etc. get them in your platform. Maybe even pay them.

That should be enough to tell you if it’s going to work or not.


Loads super fast and scrolls easy. On mobile, my one complaint is that the menu items (top bar, footer) are quite small.

Does that change with the growing market share of 5 over 1 wooden mixed used buildings?

Did it work?

Genuinely poor performers are so toxic. They might not recognize their poor performance and suck up infinite amounts of support for no improvement. They might be ultra-aware of their game and manipulate the institution in mind-boggling ways to protect their graft. You have to get these folks out ASAP.

Of course, they could also be unrealized potential just waiting for someone to believe in them and mentor them to greatness. If you drop them too quickly you miss out on wonderful, loyal, capable people.

The trick is being able to tell the difference quickly, make the best choice you can, and move on.


Yeah I’m planning a similar transition for my personal infrastructure. Railway is super easy to get started with, dashboard and logs features are nice, but I’ve just lost confidence in it.


This is a really lovely website. I had no idea that stamp collectors were a critical market for airships!

> The polar journey, like other zeppelin flights, was largely financed by stamp collectors; Graf Zeppelin carried approximately 50,000 letters sent by philatelists, and made a water-landing to exchange mail with the Soviet icebreaker Malygin, which itself carried a large quantity of mail sent by stamp collectors.


Interesting approach.

> Prioritize recall over precision.

Have you tried stemming your regex? That would help you catch messages where a different form of your word appeared. For example instead of “story” you look for “stor” which catches “stories” as well.

Then you might think, could we do an even better job by figuring out the general semantic intent of the query and history? Let’s project them into a semantic vector space! That’s an embedding.

Then you want to query that, which means you need a vector database. So now we can take the query, embed it, query the vector DB with that embedding and retrieve the N closest history documents. You can use that to augment the generation of the response to your prompt.

This is RAG.

Anyway, interesting to see different degrees of sophistication here. Certainly a handful of naive regex are very snappy.

There’s probably a hybrid approach where you use sophisticated NLP and embedding techniques to robustly define topics, then train a regex to approximate that well.


That assumes one layer of memory. In my experience you need to have at least 4 layers of memory to work well. All of them have different requirements for retrieval. Everything that is in short-term memory (state of the app, current conversation, current workspace artefact) requires fast latency and precision. For example if you want to edit a segment in a financial analysis, a blog post, or a program you only want to edit this segment. RAG on a VectorDB is overkill in my opinion.


Cool, but it looks like it doesn’t actually test anything on your machine? It does hardware detection and then some lookups. Maybe I missed it but I really want a tool like this to actually run a model on my machine to get the speed numbers.

I’ve been using RapidMLX for this. The integrated speed tests matter because the quality of the backend is a moving target and the quantization / MLX format conversion also matter. It’s not enough to say “oh use this model family with X parameters” you have to add the architecture specific quantization too.

https://github.com/raullenchai/Rapid-MLX


You're right that it doesn't run anything — it's a pre-download / pre-purchase decision tool, so it estimates rather than measures by design (you can simulate a GPU you don't own with --gpu). That's a genuine limitation vs running the model: a measured t/s on your exact backend/quant will always beat my estimate. The estimate is bandwidth-bound, per-quant and per-backend, and deliberately conservative on VRAM (weights + GQA-aware KV + activation) so it errs toward "won't fit" rather than crashing you mid-run. Where I can get real measurements I fold them in — calibration data / PRs for specific hardware are very welcome; that's the path to numbers you can trust rather than just plausible ones. On-device measurers like RapidMLX are complementary, a different point in the workflow.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: