I still think that a major problem is that biological processes are not “fast” as coding, but they are verifiable. If during post processing we are able to give enough harness to test and verify this kind of environment (maybe via simulation and real data) we will for sure achieve incredible performance also in this domain.

I still think that a major problem is that biological processes are not “fast” as coding, but they are verifiable. If during post processing we are able to give enough harness to test and verify this kind of environment (maybe via simulation and real data) we will for sure achieve incredible performance also in this domain.

Comments URL: https://news.ycombinator.com/item?id=47566051

Points: 4

# Comments: 0

The project relies entirely on Markdown files and GitHub Actions—no database or servers. Users propose places via Issues, and once a voting threshold is met, a script automatically validates the location and commits it to the repository. This ensures total transparency without black-box algorithms.

I would love your feedback!

Comments URL: https://news.ycombinator.com/item?id=46666520

Points: 2

# Comments: 1

This is my first open source project, and I’m excited (and a little nervous) to share it with you.

I love traveling, but I’ve lost trust in traditional review sites. Between SEO spam, bots, and paid 5-star ratings, finding genuine recommendations has become a noise-filtering exercise. I wanted a curated list where the "noise" of anonymous internet crowds is replaced by a transparent commit history.

Git Guide is an experiment in building a community-curated travel directory without a traditional backend or database.

* No Database: The "database" is just folders of Markdown files (countries/Italy/Rome/Eat/best_pizza.md). * No Servers: It runs entirely on GitHub Actions. * IssueOps: Data isn't entered via a custom form; it's entered via GitHub Issues with YAML templates.

How it works: 1. A user opens an Issue to propose a place. 2. The community votes using GitHub reactions (/). 3. Once a threshold is met (currently testing with net 100 votes) and a moderator approves, a Python script (running via GitHub Actions) triggers. 4. The script validates the location using geopy (OpenStreetMap), creates the Markdown file, commits it to the repo, and updates the README indexes automatically.

I wanted maximum transparency. If a place is added or removed, you can see exactly who proposed it, who voted for it, and the commit that changed it. There is no black-box algorithm sorting the results.

And I need your help! This is my first real foray into open source. The architecture works, but I have a lot of ideas for the future (better frontend, more complex voting logic, decentralized moderation).

Comments URL: https://news.ycombinator.com/item?id=46659246

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46224967

Points: 1

# Comments: 1

I have compared them, and because BLE is a narrowband signal, it is highly susceptible to Non-Line-of-Sight (NLOS) conditions compared to UWB.

I also attended a prototype presentation by a large European silicon company. I noticed that even in their demo, BLE did not achieve 30 cm accuracy, but rather hovered around 1 m.

I have only tested PBR and RTT ranging with a simple Kalman Filter, so maybe someone has found a clever combination of these data sources (I hope).

Comments URL: https://news.ycombinator.com/item?id=45907730

Points: 1

# Comments: 0

The main problem that I still see is: we are not able to fully understand how much can we scale the current models. How much data do we need? Do we have the data for this kind of training? Can the current models generalize the world?

Probably before seeing something really interesting we need another AI winter, where researchers can be researcher and not soldiers of companies.