HN user

mason55

4,555 karma
Posts4
Comments1,308
View on HN

I walked out one morning and had a whole flock of them on the pergola on our second story deck. I was pretty surprised that they managed to get up there, three stories off the ground.

At the same time, they dont seem to be able to fly well when they panic. I let my dogs out one morning not knowing there was a turkey in their fenced area. The turkey freaked out and flew straight into the fence. Never seen a dog move as fast as my 70lb chow/cattle dog mix moved that morning.

And, yes, he destroyed that turkey.

Yeah it's really not worth my mental energy. Sometimes I take the time to reject tracking cookies. But I figure everyone's tracking me and everyone has my SSN at this point, and as long as my credit files are locked I don't really care. Like why do I even care if people are linking all my browsing data together and then using it to market stuff to me.

FWIW I'm 43 and grew up on the dark parts of the internet.

A 10% tender offer isn't really an interesting discussion. You should take definitely take 10% off the table unless you're already pretty wealthy.

The interesting discussion is how much you should take off the table if the offer is uncapped.

I love my ErgoDox EZ but I have the same problem as you. Even after a few years, I'm still not used to the location of some of the punctuation keys that you need when you're writing code (braces, pipe, etc.) which in turn really hampers my flow state. I end up undocking and using my MBP keyboard when I'm writing code because I just can't get into that same flow state on my ErgoDox.

I think the problem is that in spots where the concepts build on one another, you need to memorize the lower level concepts or else it'll be too hard to make progress on the higher level concepts.

If you're trying to expand polynomials and you constantly have to re-derive multiplication from first principles, you're never going to make any progress on expanding polynomials.

There's a very large lower-middle to upper-middle class that is going to be price sensitive.

And that's the point. Maybe I'm pretty well off but $15/day is still painful for me to drive in every day. But! Occasionally I REALLY need to drive my car in to the city, so instead of driving in five times/week I just drive in once/week. That's 80% fewer trips, a huge reduction.

The price will determine how poor you have to be to get forced to do without so the wealthy can benefit from an increase in quality of life.

Doesn't that basically describe access to all scarce resources?

If you don't like the idea of money being used as a way to allocate scarce resources then another way to look at it is forcing people to pay for negative externalities (traffic, pollution). And I don't see why poor people should have to pay less for creating the same negative externalities.

Why should my taxes get used to build infrastructure that's going to be subjected to congestion pricing that prices me out of using that infrastructure?

I think the arguments here are

1. Rich people pay a much higher percentage of the cost of the infrastructure. If you're so poor then you might not be paying for any of it anyway.

2. You still benefit from the infrastructure - fire trucks, police cars and deliveries are all using the roads to your benefit, even if you don't even drive on them

3. This is very similar to someone saying "why should I pay for roads when I don't own a car?"

4. It's also similar to "why should I pay for schools when I don't have a kid?" These things better society as a whole even if you don't use them directly*

FYI - you aren't handling the "scroll up" case.

To see what I mean, click "Creating a Feature" then start scrolling up. Notice that "Creating a Feature" is still highlighted even though the entire screen is made up of text from the "Software" section.

I probably only noticed this because I recently implemented a similar "active anchor" solution with Intersection Observer.

This works for things in the past but not things in the future.

If I say I want something to happen at 8pm New York City time on January 7, 2028 and then the DST rules for NYC change, I likely still want it to happen at 8pm. Converting to UTC and back to local time loses that information and it will happen at the wrong time.

The point is not to improve it until you actually need to change it.

Like you said, you're probably bad at predicting which code is going to need changes in the future, so if it's working now and you don't need to change it then it's a silly risk to try to improve it right now.

Yeah there are just a lot of titles with weird rights situations that no one cares about resolving. Maybe you lost clearance on a song in the movie, or one of the actors has a clause in their contract, or some company bought the distribution rights for a certain territory and then went out of business.

Lots of situations where resolving the rights issues is going to cost more than you expect the movie to bring in, especially once you start talking about splitting the revenue with online storefronts.

Sure - that's why Sony is the winner. Other companies tried other things and lost. Now they see what the winner did and they're following their lead.

When WB started all this it wasn't clear what the winning strategy was going to be. Now that it is clearer, they're just following.

For dates in the past it isn't much of a problem. `America/[city in chile]` in the past (created before the change, refering to times before the change) still has a specific point-in-time meaning even when things change.

Right - date-times in the past are always easy (at least until you have to take relativity into account). An event happened at some instant in the universe and you just need an agreed upon representation of that instant. UTC works fine for this - record the UTC-based instant at which the event happened and you can always translate it into any other representation without losing information. Recording it in your local timezone is fine too, as long as you also record the UTC offset or timezone along with the instant.

I guess it should be detectable which dates may be ambiguous/wrong if you know the date of their creation (before the change was known)

Yeah - in theory, when a timezone is added, you could probably link it to timezones that users of the new timezone might have previously used. And then any future times that were saved using that timezone, you ask someone if they are still correct or if the timezone needs to be adjusted to the new one

For example, if a new timezone was added for southeast Colorado, you might ask someone about all times scheduled in both the Denver & Phoenix timezones, because you don't know which one people might have picked.

It gets complicated though because you need to keep track of which entries have been double checked and which ones haven't, and you need to keep track of the version of tzdb that you reconciled against, because there could be another change in the future.

That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened.

It's actually easier to create this problem than by bisecting a city, and the easier way is even more complex than bisecting a city.

You obviously can't put every hamlet, town and village into tzdb, for a lot of reasons. So, if you're trying to represent a time in a place that isn't in tzdb, you have to pick the nearest location that is in tzdb. And it's quite possible that between when you enter your time and when that time comes to pass, the location you were specifying for changes it's rules in a way that's different from the original place you chose.

If you bisect a city, you could create two new names, so that if you encountered the old name you'd know that something needed to be reconciled. But if you chose the nearest place and then your rules changed, you'd have no way to know automatically that it needed to be revisited.

For example, parts of Chile decided not to do DST any more. To support this, a new timezone, America/Punta_Arenas, was added to tzdb. Before this, if you were in Punta Arenas, you would just put all your times as America/Santiago. And now you have no way of knowing if those times are really supposed to be Santiago or if they were Punta Arenas and Santiago was just the best you could do at the time.

Location-based tz's are the best we can do right now but even still they have intractable problems when things change.

I think that there are just very few notifications where a summary is the thing I want. Most of them I either don't care about at all or I want to see the actual text. Either it's important and the details matter or it's, like, a text from my wife and I want to read it in her voice and not a summary.

The fun of my family group chat is reading the messages from everyone.

It's still cheaper to not buy a phone. Yes, buying with pre-tax dollars is cheaper than at a store. But not buying one at all is even cheaper.

And business expenses, like a new phone, are usually above the line, meaning you essentially get a discount of your marginal tax rate, you don't just get it for free.

Yeah it feels like the ideal way is to feed in a transcript of the announcer audio + some standard stats. That would ensure you catch both the human stories & the factual content.

But I wonder if there are licensing issues with using the audio/transcript to generate your summary. I know that the raw stats are public domain but I wouldn't be surprised if they can't use the transcripts or audio.

Sounds like my local semi-rural NextDoor posts. Lost dogs, cats, the occasional horse. Updates when the main road gets closed. Recommendations for local businesses. And occasionally a politics post that most people ignore while a few people argue for weeks.

I’ve heard that NextDoor in suburban and urban areas is quite a cesspit but ours is pretty helpful and cordial.

You could prove to the type checker that you're only allowing input values that, when fed to your operation, results in outputs that remain in bounds. For example, if you're doing addition, you first check that each input is between 1 and 49, and you exhaustively handle the cases where the values are out of those bounds. Then the type checker can see that the output is always between 1 and 100.

For operations/mutations where it's more complex to validate the inputs, you could assign the result to an unbounded variable, and then prove to the type checker that you're exhaustively handling the output before you assign it to a bounded variable. For example, multiply two unbounded numbers, store the result in an unbounded variable, then do "if result >= 1 && result <= 100 then assign result to var[1..100] else .... end"

Yeah - in theory they are the same thing. You can have a dependent type that's an array with a length of 5 or you can create a type called ArrayLengthFive, and in both cases the type checker ensures that you don't accidentally use an unbounded array.

But the difference is that with a dependent type, you get more guarantees (e.g. my ArrayLengthFive type could actually allow for arrays of length 20!). And the type checker forces you to prove the bounds (there could be a bug in my code when I create an ArrayLengthFive). And the dependent type allows other parts of the system to use the type info, whereas ArrayLengthFive is just an opaque type.

I do think there is room for both ways of working. In the string -> Email example, it's probably enough to parse your string and just call it an email. You don't need to try to encode all the rules about an email into the type itself. But there are certainly other cases where it is useful to encode the data constraints into the type so that you can do more operations downstream.