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

The Summer after graduating high school is sometimes used to travel, taking extended backpacking trips or other. Couching could be a big hit for this demographic that takes a cultural immersion.

I see 900+ Couchers registered among a few of the New York City boroughs. My impression is that this means someone can live in NYC for an entire Summer, couch-surfing the big city and establishing a real connection with at least 60 hosts. That would be quite an experience, with many stories to share.


>, couch-surfing the big city and establishing a real connection with at least 60 hosts. That would be quite an experience, with many stories to share.

Sounds like my idea of Hell, but i'm introverted.


Top locations have way more people interested in couchsurfing than there are people hosting, so probably not feasible.

I am a couchers host in NYC and don't actually get too many requests! I host someone about once or twice a month.

How’s your towel design?

Terrible but worth it for the location

I worked in a nascent water tech space recently involving an IOT water flow sensing device installed on a main water line. I worked extensively on detection models capable of distinguishing water fixture use during simultaneous usage scenarios. When your full time job involves a niche domain such as this, a whole new world begins to reveal itself. You can distinguish people based on their patterns of fixture usage. You can determine how many people are living in a residence. You can determine hygiene habits of each person. There's a lot more to these smart home devices than what meets the eye. You thought the sensor was good for just detecting leaks and approximately breaking down water consumption? Think again.

This device alone is capable of doing a lot, but when combined with other sensing devices such as a WIFI motion detection system, you can create a system where the whole is greater than the sum of the parts. First, you may not even need to monitor water flow now because detecting a person in the bathroom, moving about, is sufficient to detect toilet usage followed by hand-wash, and shower usage. You will know duration of each. You may be able to distinguish people in a residence, which means you'll learn who did what throughout a household.

Right about now you may be wondering who would ever want to know this kind of stuff? Who cares if you just used the toilet and didn't wash your hands? Who cares if you frequently use the toilet, or wash your hands excessively, or frequently and excessively wash your hands throughout the day? What if you are a landlord with a tenant leasing agreement stipulating no one other than the listed members on the contract shall occupy the residence without permission of the landlord (with exceptions, of course).


Thanks for sharing this. Check out this other comment on this page to see what one company says they can do (health baselining etc)

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


What LLM(s) is the agent using? Are you fine-tuning the model? Is the agent/model development a proprietary effort?


Currently claude 4 sonnet as the main driver, with a combination of smaller models for certain scenarios


The greatest burden about clients is keeping them synchronized with the API. It feels like this problem is finally about to be addressed.


My experiences with Timescale revealed the need for a full time DBA expert of TSDB to make the db viable for queries exceeding more than the last week of time series data. Tiered reads barely work at all. Do you want a degree in how to use a crippled Postgres offshoot?


Tbf, my experience as a DBRE has been that most places should have a DB expert on staff, especially for Postgres. I’ve not used TigerData / Timescale, but IME there’s far more complexity to reason about and manage than people think.


Generally developers need to be watched so they don't blow up the application performance and so they reuse queries in the correct manner so you optimize things like the query cache and the indexes you have.

Query optimization is one of those places where it can be easy to get orders of magnitude performance increases.


Agreed, though it’s also a monstrous effort to get devs to stop chucking everything into JSON, or my new favorite hell, serializing entire classes and storing them as a BLOB.

It’s my fervent belief that we should revert to specialized roles, with a DB team designing schema and queries based on a team’s needs, who can access them via API only. Slows down velocity? Yes. Faster queries and more efficient use of resources? Yes. Fewer incidents and better referential integrity? Also yes.


I'm sorry to hear about your experience. Would love to hear more if you are open to it: ajay [at] tigerdata [dot] com.


I support this effort. Government should tax economic gains, not revenue. A business with $1 million in revenue and $950,000 in expenses is far less profitable than a business with $1 million in revenue and $200,000 in expenses. If both were taxed on their $1 million revenue, the first business would be in a dire situation.


The Claude models are so far ahead of the pack right now with Elixir and Erlang capabilities, comparing with o3, gemini2.5, grok3-think, and ds-r1.

Elixir is so good for workflows and pipelines, utilizing all available hardware resources. It makes sense why Elixir will be used more going forward for agentic workflows, but the greenfield engineers/architects are rushing to market with Python and here we are.


Hey, this is really interesting. What are the features you used to measure the reasoning complexity? In other words, how does one evaluate a query during classification?


We use an adaptive classifier to learn how many tokens the model takes to respond correctly on a known dataset. I used the https://huggingface.co/adaptive-classifier/llm-router for experiments it is based on distilbert.


Time series data is naturally difficult to work with, but avoidable. One solution is to not query raw time series data files. Instead, segment your time series data before you store it, normalizing the timestamps as part of event processing. Sliding window observations will help you find where the event begins and then you adjust the offset until you find where the time series returns to its zero-like position. That's your event.


Segmenting data is exactly what writing it into non-overlapping Parquet files is. My point is that many tools can read a bucket full of these segments, and most of them can handle a scheme where each file corresponds to a single value of a column, but none of them can agree on how to efficiently segment the data where each segment contains a range, unless a new column is invented for the purpose and all queries add complexity to map onto this type of segmentation.

There’s nothing conceptually or algorithmically difficult about what I want to do. All that’s needed is to encode a range of times into the path of a segment. But Hive didn’t do this, and everyone implemented Hive’s naming scheme, and that’s the status quo now.


Hopefully this clarifies the value proposition for others:

Existing Lakehouse systems like Iceberg store crucial table information (like schema and file lists) as many small "metadata files" in cloud object storage (like S3). Accessing these files requires numerous network calls, making operations like query planning and updating tables inefficient and prone to conflicts. DuckLake solves this by putting all that metadata into a fast, transactional SQL database, using a single query to get what's needed, which is much quicker and more reliable.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: