piotrkaminski

This part:

> Sometimes, if the problem (like the injury or damage) was not discovered right away, the statute of limitations generally starts counting from the date the problem was discovered or should reasonably have been discovered, whichever comes first.

> Given what we have already seen of AI, we can be confident that its widespread adoption will create a less free society, a less virtuous people, and a degraded culture.

I think this claim needs stronger evidence than "we can be confident".

I thought this was the weakest argument in the article. Yes, non-determinism is inherent to LLMs. It's also inherent to human brains, yet somehow we still manage to call (some) people reliable.

The bit about backwards compatibility doesn't make sense either. LLMs, just like humans, can take backwards compatibility into consideration — or not. Sometimes they'll forget, and sometimes they'll fixate on it even in a system that hasn't been deployed yet. It has nothing to do with LLMs never doing "the same thing the same way twice".

LLMs may or may not become as reliable as other productivity-improving infrastructure, but it's not the nature of their technology that will decide this.

By and large we do. Unfortunately, the losers don't care unless you identify them personally. For them, the thrill of cheating and griefing others easily overcomes some generalized cultural zeitgeist.

That certainly used to be the case in Canada 20 years ago, don't know if they've standardized since.

> I prefer to call them Low Information High Satisfaction theories

If you called them Low Information Excessive Satisfaction theories instead you'd end up with a much more satisfying acronym! :)

> brand that emphasizes safety or enjoyment of experience (like Hondas and Toyotas)

This is plausible on its face, and yet the Honda CR-V Hybrid ended up higher on the list than the Model Y. No idea how to explain that...

What in the world is the Honda CR-V Hybrid doing so high on this list?! That doesn't seem to fit any of the theories I've seen spun up so far.

We do three things:

First, we use Missive to integrate email and chat. This way everything's in one place, properly threaded, and we can easily discuss emails internally in context. Much much better than GMail + Slack.

Second, I run video chat office hours twice a week (Tuesday/Thursday). Anybody can drop in to discuss anything — or not, if there's no need. This lowers the activation energy for "in person" discussions that otherwise might not get scheduled and promotes async work the rest of the time.

Third, regular company offsites! Even a few days a year is good.

The "cute dogs" in the title is obviously clickbait but at least one cute dog does show up in the article:

> Vermeulen produces a popular YouTube series starring his dog, Sir Willie the Wiener, riding on his back.

Not the video you asked for, but that is one cute dog! https://www.youtube.com/watch?v=JqhhadyMntk

I'm building an open source implementation of the Firebase RTDB server, that will be wire-compatible with Google's. This means that all the (already open sourced) SDKs will work pretty much as is, over REST or websockets. Security rules will also be fully supported. (The only meaningful caveat is that it's just the RTDB, so you need to deal with authentication yourself, and kinda shoehorn it into the existing APIs.)

What I get out of this is that even for teams that prioritize trust and velocity and eschew the use of pre-commit code reviews, there's a strong argument to be made for putting all new hires on an approval-required list for the first few months!

Yep, Git's semantics are seriously lacking (see also renames). In Reviewable, we work around this with heuristics: we use Change-Id if it happens to be available, and otherwise do best-effort loose lexical matching on the commit messages to match up pairs across a rebase. It works reasonably well in practice but it's a bunch of complex code that I'd rather not have to maintain...

Agreed that their API is the most important thing, but IMHO they're not doing a particularly great job of it. You've got two separate API systems (REST and GraphQL) that overlap but with neither a superset of the other, two separate ID systems, no help in handling the wide range of incompatible API versions used by old GHE instances in the field, OAuth apps vs Apps that have different constraints on the APIs they're allowed to call and with no clear migration path between them, important bits of functionality used by their own UI that aren't available through the API at all, a convoluted API quota system, etc.

Frankly, a lot of it feels like they were trying to deprecate and replace an older system with the shiny new thing, then realized halfway through that they couldn't and now we're stuck with two somewhat incompatible ones for the foreseeable future. They could really use a strong tech lead on this.

To be fair, they did improve several things in the PR flow over the last decade but there's definitely a lot more that could be done. I just hope they keep their API team well-resourced so that code review tools like Graphite and Reviewable can keep working! (Disclaimer: I'm the founder of Reviewable.)

> Sports stadiums add culture to cities in the same way that aquariums, museums, music venues and art galleries do.

Citation required.

Discussion of the original source: https://news.ycombinator.com/item?id=39324491

One simple trick helped us a lot: we have a rules transpiler (fireplan) that adds a default "$other": {".read": false, ".write": false} rule to _every_ property. This makes it so that any new fields must be added explicitly, making it all but impossible to unknowingly "inherit" an existing rule for new values. (If you do need a more permissive schema in some places you can override this, of course.)

Our use of Firebase dates back 10+ years so maybe the modern rules tools also do this, I don't know.

What would really help us, though, would be:

1. Built-in support for renaming fields / restructuring data in the face of a range of client versions over which we have little control. As it is, it's really hard to make any non-backwards-compatible changes to the schema.

2. Some way to write lightweight tests for the rules that avoids bringing up a database (emulated or otherwise).

3. Better debugging information when rules fail in production. IMHO every failure should be logged along with _all_ the values accessed by the rule, otherwise it's very hard to debug transient failures caused by changing data.

Our experience has been very different. Our Firebase security rules are locked down tight, so any new properties or collections need to be added explicitly for a new feature to work — it can't be "forgotten". Doing so requires editing the security rules file, which immediately invites strict scrutiny of the changed rules during code review.

This is much better than trying to figure out what are the security-critical bits in a potentially large request handler server-side. It also lets you do a full audit much more easily if needed.

I'm no billionaire, but if there's a legal way for me to avoid paying a tax, of course I'm going to do it. Why should billionaires be held to a different standard? Tighten up the laws for everyone instead.

> if you want to reverse the car, you have to use on-screen controls!

So? If you're switching to reverse then by definition you're stopped (or nearly so) and can afford to take your eyes off the road. The control is no further than most cars' center tunnel-mounted gear levers. Plus it only has the two common drive/reverse settings accessible via the swiping action, rather than all the rarely-used options. (Do you know how many times I've shifted into Neutral or Low by mistake in an unfamiliar car...?)

What exactly is the risk?

If they intend to go straight through Earth at relativistic speeds (to establish a hyperspace bypass, perhaps?), then there's really not much we can do about it anyway. :p

That would actually make them easier to spot, as they'd need to flip around for a breaking burn roughly equal to their acceleration burn, pointing their engines straight at us. (Assuming they want to stop by and say hi, of course. If not, then there's not much to worry about.)

Heartily seconded. Also don't forget the docs: Google Cloud docs are generally fairly sane and often even useful, whereas my stomach churns whenever I have to dive into AWS's labyrinth of semi-outdated, nigh-unreadable crap.

Not necessarily. Speaking for myself, I like the convenience of SSO, and I generally trust Google to keep my account secured more than a random web site (if they even offer OTP!). As long as I know there's an escape hatch.

This assumes you're using a consumer Gmail account, I guess? If so, yeah, you're SOL. But I think as long as you have your owns domain you should be fine, even if you hook it up to Google Workspace for email, since you can always switch it to another provider. (And yeah, I realize this is not something civilians are likely to be able to figure out / do...)

Wouldn't any sane SSO implementation let you recover and switch to a password simply by proving ownership of the email address via a challenge email?

> Also Mercedes is accepting 100% liability while their cars are in self driving

That's what I thought too, but apparently it's not that clear cut. Their manual says that the driver must be ready to take over not only when prompted by the system but also "due to obvious circumstances". It's not clear what that means — cue the lawsuits. https://safeautonomy.blogspot.com/2023/09/no-mercedes-benz-w...

Thanks for writing this up — that's a really interesting perspective on the problem, and definitely worth pondering. I'm not familiar with the underpinnings of cross-country payments so I'll just take your description as valid.

I think it's not completely incompatible with my view, though: if you don't have a country B subsidiary (the assumption underlying this entire discussion!) then the most country B can do is tell the payment processing company you're contracting with to stop doing business with you. That's completely fair and I see it as a kind of "financial firewall" for country B.

Even this power is subject to some checks and balances, though: 1. If your service/site is popular, country B's population may object to no longer being able to do business with you and put pressure on country B's government. 2. You could bypass the financial system with crypto payments. (Yeah, not terribly practical for most use cases, but could become more popular in case of government overreach.) 3. Ad-supported businesses — like the one in the original article, apparently — are immune to this kind of intervention!

Ultimately, a country can only control entities with a physical presence inside its borders, and while some common commercial architectures necessitate this (to some degree) not all do. Countries that make laws that pretend otherwise just end up looking silly.

> Yes, that's how it works. Specifically, the common argument that applies to most companies (incl. Rumble), is that you're trading within that country if anyone from that country is either paying for your product/service, or making money from your product/service; and therefore you essentially need to function as (if not actually legally have) a per-country corporate subsidiary amenable to the laws of that country, if you want to continue doing that.

I think an equally valid (and frankly more reasonable) interpretation is that if anyone from another country is paying for your product/service, then they're trading within _your_ country. If in doing so they contravene laws of _their_ country (e.g., forbidden speech, taxes, etc.) then that's their problem, not yours. This interpretation has the advantage of actually being enforceable, unlike the alternative.

And if a country doesn't like that then they're free to "protect" their citizens by building a Great Firewall, which is _totally and only_ for their people's benefit.