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

I built a feature priority and sizing app based on this for my team years ago. It worked very well technically, but it was a challenge to get people past their desire to drive the process with anecdotes and gut feels.

Shorter lifespans drive faster evolution. That was taught in basic biology and we, as a society, know it all too well (infectious diseases).

It’s difficult to square obsession with a long life with a healthy humanity.


Faster evolution does not necessarily translate to better outcomes. Exhibit A: the respiratory capabilities of the brachycephalic pug. Exhibit B: the rabbit fear response – they can get so terrified that they break their own spines trying to escape. Exhibit C: every creature with a hybrid r/K reproductive strategy involving child- or sibling-cannibalism.

> Faster evolution does not necessarily translate to better outcomes.

For individuals, of course yes. But for populations? Also yes, but temporarily as dead-ends (A), or inconsequential stopovers (B), or distasteful (C).


If B's an inconsequential stopover, then explain every other rodent in a similar ecological niche. I picked rabbits because they're cute, not because they live unusually unpleasant lives. Sexual selection can produce far worse than A (e.g. ram horns can grow through their skulls, gradually impaling their brains and eventually killing them). And the category of "distasteful" is very, very large indeed.

Nature is red in tooth and claw: trusting evolution to shape a better humanity in the absence of medical treatment is playing "look, ma, no hands!" with eugenics, retroactively justifying every tin-pot dictator's killing spree as a rightful bestowal of the Darwin Award. Medical care to prevent avoidable injury and death is good, actually.


Why would I use this rather than ‘sam build && sam deploy’? Coding template files is basically a non-issue these days, and provides great flexibility.

That's a bummer. While I'm not in your shoes, I can understand the excitement of solving a new library's "puzzle". And, how that may seem less valuable when a code generator can nearly instantly apply itself to using the same library.

Have you tried branching-out into different areas of programming?


I don’t want to believe for a second anyone would walk away from Silicon Valley because of being taxed. The impact on the calculus of reward simply doesn’t make sense. On the other hand I am always surprised by people and the strange things we do.

People walk when they don’t make money. You don’t look at Silicon Valley for these types of things. You look at a deprived forgotten town that could had survived were they not squeezed so much

Most people, by count, of course would not leave because of the wealth tax currently being proposed in California as it targets just a tiny segment of the population - current estimates are that less than 250 Californians, or less than 0.001%, would pay the currently proposed statewide wealth tax. The other 99.999+% would not (yet) have to pay a wealth tax. However, the <0.001% that (esp. the wealthiest among them) who would pay the wealth tax would be motivated to move.

Unfortunately for California about 40% of the total state income tax collected (which accounts for about 65% of the state general fund) is paid by the top 1% of income earners -- which includes those 0.001% who will be motivated to move by a wealth tax (or even merely the threat of one).

The <0.001% number appears to be based on population _before_ several billionaires moved out before Jan 1, 2026 - likely at least partially motivated by the small, but real, risk of the "billionaire's tax" qualifying for the ballot and passing (and that proposed tax is only "temporary" and is only a total of 5% over three years so isn't nearly as alarming to the wealthy as a "permanent" tax would be). If it looks like this measure will end up on the ballot and have a chance of passing, expect many more to leave. This will, even if it does not ultimately pass, erode the income tax base.

California has rebelled against wealth taxes in the past - most notably by the passage of Prop 13 almost 50 years ago (a property tax is a wealth tax). They are not popular except when the hit "the other guy" -- but "the other guy" is the one most able to avoid the tax.

Wealthy people are typically very flexible as to where they live. They often already own multiple homes and often spend a lot of time out of the state they "live" in. When they move, they are not packing and labeling their own boxes or are likely even present on "moving day". They also are more likely to set up HQ and shop near where they spend a lot of their time. Even if they have family in California, they can still get together with them for Thanksgiving dinner -- either by flying the family to them on their private and chartered jets or by themselves flying to California for the weekend on one of their jets. They can conduct most business very efficiently remotely and often do so now to a significant extent.

It only takes a few to leave to tank the California budget - likely causing the progressive income and wealth taxes to reach deeper and deeper into the upper middle classes as California desperately tries to balance their budget without cutting yet more programs.

Other states are loving this though and will cut tax deals to attract these very billionaires that California are encouraging to leave.


Fair point that yes I’m eating my own dog food here. And I’ve been called a robot enough times maybe I should keep track.

To the question, UDP is easier on a battery than MQTT.


To be clear I understand you are not a robot, but the article reads more as LLM generated especially toward the end which is why I said "AI-assisted".

Thanks for sharing this project; TIL about AliExpress Dollar Express tiny touch screen ESP32 dev kits for first-time buyers for $9 including shipping.


WireGuard doesn’t add noticeable battery drain in my experience. I have a fleet of Xiao ESP32-C3 devices with DS1820 temperature sensors that run on batteries and send samples over WireGuard.

The battery drain is 100% a function of the transmit time, so by pre-encrypting the buffers before powering on the radio I save a bit. Likewise for the response handshake - get the packet, shut down the radio, then decrypt it.

When sending samples between handshakes, I don’t have to wait for an ACK of any kind - I just send the packet and shut down the radio. That saves a ton of power compared to TCP.


I monitor packet loss on both sides all day every day. It’s still a thing, but different than I’d imagined:

- Episodic most often. Something transient causes high loss for a short time. This happens locally and “in the cloud”. - Persistent due to a back connection or very high network load. I only really ever see this locally.

But I can go days at a time and not lose even one of millions of probes and responses.

When connections are good, they’re excellent these days. When they’re bad, well that doesn’t seem to have changed.


WireGuard is far smaller in my experience. I don’t set aside the possibility that someone more clever than me can get IPsec condensed down to something tiny but I never could — it’s just too much in one bag, so to speak.

The zero is just a magic number to indicate grab the newest. So it’s just showing the most recent comments.

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

Search: