JoshTriplett

The most likely answer is that they didn't think about it or didn't understand or didn't care. But on the off chance they did, perhaps they thought the DNS provider would enforce the ruling worldwide.

At this point, I think it'd be reasonable to start saying "why do we trust intermediate roots, period".

The device is in the user's possession, so you'll lose eventually, it's just a matter of how long it takes.

I like that this isn't trying to be aggressively narrow like so many other fonts do. I currently use DejaVu Mono because it feels comfortably spaced.

There is a degree to which people who have pets assume that everyone should react to animals the way that they do. If someone's dog jumps on its owner, they often react positively, rather than negatively. (In my case, the reaction would instead be "I have serious allergies and do not wish to have an unpleasant allergic reaction for the rest of the day".)

Some dog owners (to be clear, some, not by any means all, but it only takes some to affect other people's general perceptions) seem to think they are objectively correct and the people who do not want that are wrong. So it is not hard for me to imagine someone who finds themselves regularly having unpleasant interactions with dogs feeling like "dog owners should stop that from happening", rather than (as is sometimes the case) acting like there's something wrong with people who think it's a problem. Conversely, it is understandable how people who are close to and friendly with an animal all day will sometimes fail to have sufficient perspective-taking to realize that not everyone feels as they do.

I've personally never had the extremely unpleasant experience of having a large dog try to jump at me. I have on rare occasions had the experience of having a small dog run at my legs, and the owner not immediately treat that as a failure on their part, which was unpleasant. Fortunately, most of those have then had the "I'm so sorry" reaction, rather than reacting with indignance, but I've definitely encountered pet owners who projected indignance that you don't think their animal is a precious sweetums who can do no wrong.

Most pet owners are extremely reasonable people, and it's unfortunate that encounters with the exceptions to that can give people a poor impression.

Flash dying is a great victory for Open Source browsers. I don't miss a thing about that world; as an authoring tool, it was hugely overused, for things it should never have been used for, like literally anything other than games.

I am thinking of it as markup. I stand by the point: I think "forgiving" is not a feature in parsing; it's a bug.

I don't think "parsed strictly" makes something hard; on the contrary, I think it's helpful to make something easy. Clear feedback, easy to test.

But then, I've always preferred strongly typed over stringly typed.

With the benefit of hindsight, if the web had been that way from the beginning, I think we would have been better off. The moment you tested your content in any browser, you'd immediately see if it was broken.

But it wasn't something that could get introduced later, after all the broken content that already existed.

> I chopped the 118 KB off the front and threw it into IDA

How long until someone uses AI to find an exploit in IDA and starts putting that in their malware, so that if you try to disassemble it you get pwned?

That's exactly what I was thinking when I saw https://www.assbench.com/ posted a while back: "oh no, this is going to be somebody's job".

It is important to try, for a few reasons. Among other things, increasing amounts of Rust written in the Linux kernel itself, and other environments where you need to take more care with memory allocation.

Rust as a language is capable of that. If you don't use the standard library then you can provide that functionality yourself. The standard library is trying to support it, without creating interfaces that are a massive pain to use.

For instance, it's easy for us to support `Vec::try_reserve`, and we do, but that's not trivial for users to use everywhere; it's error-prone, and it's easy to make a mistake and call a method that goes past your reservation. It's painful for us and for users to make `Vec::push` support this (and having a `try_` variant for every function), so we've been working on a better solution. One current possibility is to have a dedicated type for a Vec that has OOM handling, where `push` can return an error, so you know if you use that type you can never accidentally fail to handle OOM.

Yup. UFO conspiracies, aliens on the moon, PSI...

I've always used https://screenmessage.com/ for this.

bigwords has the advantage of accepting inline parameters though.

That would be an absurd amount of money to spend on typosquatting.

To a first approximation, the 3% isn't paying for disputes; it's paying for rewards to the customer (essentially a built-in discounting mechanism that gets to discriminate on credit rating), and for profit margin to the payment processor. Disputes are paid for by the merchant, and if you get too many of them you potentially lose the ability to process credit cards.

> You could trivially mandate some stringent data retention policies, block cross-camera tracking if you really want,

...or ban them. Just ban them. Let's have less surveillance.

The pro surveillance side keeps ratcheting things upwards and moving the Overton window. Let's claw some things back.

It's one of the standard ways of prohibiting states from doing something, in order to enforce individual rights. Within the federal government, it can be harder to say "states may not" and easier to say "we won't give any money to states that". I'm glad to see these cameras prohibited locally, so that Flock and others can't just go shop it around to jurisdictions until they find one scared enough to buy.

> What's the argument here?

The most common argument for this is some core unexamined axiom that only humans can reason by definition, and then working backwards to a justification for that.

> It’s insane. 45 minutes to build debug from scratch. Linking is super slow even in debug and that’s without LTO.

How much memory do you have, and do you have swap turned on?

I have 32GB of RAM, and it barely manages to build release if I shut down everything else on the system that uses RAM. 64GB would be better. If you have 32GB or less and you have swap on, the performance might be mostly because you're spending a lot of time swapping. And that's for release; debug on a repo that size may spend a lot of time and memory linking debug info.

> I know, which is why I don't bother with lawns. I'd rather fill the entire area with solar panels instead.

Agreed. Or xeriscaping, or something better than grass (which is a really low bar to be better than).

+1. Some of the added detail (e.g. more realistic-looking brick) looked great. Some of it was the kind of thing that better depicts "areas you've failed to maintain", iff you want your simulator to have those bits of verisimilitude.

I'd be all for separating "better, more lifelike, more realistic rendering, with interesting variation" from "decay".

It's unpleasant to accuse someone of being naive in a paternalistic fashion that implies "you're wrong, because you don't know any better, but if you knew better you'd agree with me".

The post you replied to embodied a preference. You responded that they were wrong and naive for not wanting to depict cities constantly "being pulled into the ground". Some people playing a simulator do not want the simulator to force unavoidable decay everywhere. This is something for which there is room for a breadth of preferences, not something for which there is a correct and incorrect answer.

I had the same reaction. Like, add these effects for when your city simulation is simulating what happens when your city is being neglected.

That's a different case where they're not trying to be surreptitious. For that case, see https://news.ycombinator.com/item?id=49937347 and my response.

I wish you the best of luck in beating the odds and actually continuing to operate effectively post-acquisition for as long as possible. Turso is great, and I'm looking forward to the point where it feels like it crosses from "keep a close eye on" to "use in production with no qualms".

A church is commonly expected to filter on religion (somewhat, many welcome respectful outsiders). A software project filtering on religion is very different. One common aspect of cults is pervading every aspect of people's lives, including their work ("company store" style).

Full acknowledgement for the fact that the line between "religion" and "cult" is blurry, but "all developers of this project must share a common religion and agree to these monastic religious tenets" sure ticks some boxes on "extremism".

They are, of course, free to do so; freedom of association is their right. Others are free to judge them for it, and to question whether they should be using the resulting software. The license is open, the community is not. So, seeing a project come along that looks to build something more open (and it's really saying something when "project whose governance is owned by a company, but open to pull requests" is more open) seems like a positive step.

(Also, as a database project, surely they shouldn't be mixing church and state. ;) )

Sure, a state can do that, and some have tried at various times. But even authoritarian states have a number of competing aims they have to balance. And CT makes authoritarian goals harder; they can no longer do as much surreptitiously.

I meant "cult" quite literally, not hyperbolically. They literally filter acceptable developers based on religion.

More async, more concurrency, more dialects (not just postgres), better defaults, ability to be called from safe languages without going by way of an unsafe FFI layer, open community...