twiss

Wouldn't it be cooler if you could `return IoError{} from ^` and it would find the closest function in the call stack that can return an IoError?

Even better, you could give it some syntactic sugar like `throw IoError{}`? ;)

P.S. I think the `IoError { message, ok }` type is suspiciously close to `Result<(), String>`.. And if you want to return a value in the success case too it'll become even closer. Perhaps it's best to lean into that and find the calling function that can return an IoError as one of the possible values?

> Returns across multiple calls. `return err from load` returns from a function any number of frames up, statically checked, with no unwinder, no `Result` type and no `?` on every call.

Does this mean you have to know the name of the function calling you that's supposed to handle the error? What if you're a library and don't know that?

    class Order < ActiveRecord::Base
      enum :status, { pending: 0, paid: 1, shipped: 2, refunded: 3 }

      def shippable?
        paid? && !refunded?
      end
    end

Bit off-topic but if `:status` is an enum, then `paid? && !refunded?` is equivalent to `paid?`

> It's worth noting that the phrase "It's fine. You'll get over it." is doing an enormous amount of emotional heavy lifting. It's not dismissive — it's pre-emptive closure. It anticipates your grief and resolves it in seven words.

AI still isn't great at counting, I suppose.

https://theonion.com/about-us/ says:

> Rising from its humble beginnings as a print newspaper in 1756, The Onion now enjoys a daily readership of 4.3 trillion and has grown into the single most powerful and influential organization in human history.

so I'm pretty sure it's just a joke.

I know everything they write is potentially a joke but I got curious when The Onion was founded; apparently it was in 1988, 38 years ago :)

FIPS-140 doesn't yet require PQC, nor does Go in FIPS mode (or any other mode).

So, if you only want PQC, you'll have to do that manually either way. But, I think you'll find many servers aren't ready for that: https://www.netmeister.org/blog/pqc-use-2026-09.html

Yeah. Also, IANAL but even if the European Commission does think Apple's interpretation of the DMA is reasonable, Apple could still be sued by an affected company or person, and a judge might disagree, IIUC: https://bureaubrandeis.com/private-enforcement-of-the-dma-a-...

Support period != warranty period. The OnePlus 15 will get 4 years of Android updates and 6 years of security patches.

I think this is more common when reporting heights in feet+inches than in cm. Rounding up 1.76m to 1.80m seems much weirder than rounding up 5'11" to 6', since all measurements in cm are very precise-sounding.

Why do you think being regulated utilities would preclude having multiple classes of service? Airlines had first class before deregulation: https://en.wikipedia.org/wiki/First_class_(aviation)#History

In Celcius, it's less common to round to the nearest 10 degrees (or say things like "in the twenties" as you might with Fahrenheit), because that makes a much larger difference than it does in Fahrenheit. So I wouldn't necessarily assume that "20 degrees" only has one significant digit unless it's explicitly stated. (I haven't checked the original paper, though.)

However, converting something like 21°C to 69.8°F is indeed silly and should just be 70°F.

Do we know that those heavy duty trucks were formerly used to do things you need heavy duty trucks for? It seems more likely that 18% (or more!) of the usage was by people who think heavy duty trucks look cool and wanted to show off theirs.

There are, in fact, some efforts going on to improve beyond the status quo on permission prompts in browsers, e.g. https://chromium.googlesource.com/chromium/src/+/refs/heads/...

Though, that document also states:

> Our research [1] finds that users often make rational decisions on the most used capabilities on the web today — notifications, geolocation, camera, and microphone. All of them have in common that there is little uncertainty about how these capabilities can be abused. In user interviews, we find that people have clear understanding of abuse potentials: notifications can be very annoying; geolocation can be used to track where one was and thus make more money off ads; and camera and microphone can be obviously used to spy on one’s life. Even though there might be even worse abuse scenarios, users aren't entirely clueless what could possibly go wrong.

[1]: https://dl.acm.org/doi/10.1145/3613904.3642252

Spec: https://www.w3.org/TR/css-values-5/#randomness

WPT test results: https://wpt.fyi/results/css/css-values?label=master&label=ex...

Only Safari supports it for now, it seems.

The actual number is 23: https://en.wikipedia.org/wiki/Birthday_problem

The square root approximation works well for large numbers, but leaves out some factors that are relevant for small numbers.

You're right that AES-128 is fine. Normally the birthday paradox only applies to cryptographic hashes.

The only way it would apply to symmetric keys is if you have a server that stores 2^64 encrypted messages, and can somehow find out which messages used the same symmetric key (normally not possible unless they also have the same IV and plaintext), and can somehow coerce the user who uploaded message #1 to decrypt message #2 for you (or vice versa). Obviously that isn't realistic.

> The chances of generating two GUIDs that are the same is astronomically small.

> The odds are 1 in 2^122 — that’s approximately 1 in 5,000,000,000,000,000,000,000,000,000,000,000,00.

This is true if you only generate two GUIDs, but if you generate very many GUIDs, the chance of generating two identical ones between any of them increases. E.g. if you generate 2^61 GUIDs, you have about a 1 in 2 chance of a collision, due to the birthday paradox.

2^61 is still a very large number of course, but much more feasible to reach than 2^122 when doing a collision attack. This is the reason that cryptographic hashes are typically 256 bits or more (to make the cost of collision attacks >= 2^128).

I may be missing something about how the PHP compiler/interpreter works, but I don't quite understand why this is apparently feasible to implement:

    class BlogPostRepository extends BaseRepository<BlogPost> { ... }
    $repo = new BlogPostRepository();

but the following would be very hard:

    $repo = new Repository<BlogPost>();

They write that the latter would need runtime support, instead of only compile time support. But why couldn't the latter be (compile time) syntactic sugar for the former, so to speak?

(As long as you don't allow the generic parameter to be dynamic / unknown at compile time, of course.)

Fair enough, I'm willing to believe it's doing evil things to hosts on the platform, indeed.

But FWIW, the EU is at least making an effort to regulate the company: https://nltimes.nl/2024/09/19/eu-court-says-bookingcom-wrong... (which claims that Booking can no longer prevent hosts in the EU from offering lower prices elsewhere).

I think there is some cultural difference between the US and Europe where in the US it's seen as somewhat OK to hold the customer service agents as personally responsible for the failings of the company, and treat them accordingly. Customer service agents in Europe dealing with Americans may feel the need to point out that they're not personally responsible for fear of said treatment. That (hopefully) doesn't mean that they won't try to help you, just that they hope you won't be angry at them personally.

It may sometimes be useful to verbalize this explicitly by saying "I know you're not responsible for this, but can you please do XYZ to solve the issue", and if it's a reasonable request I assume they'd be happy to comply. Depending on the country and culture, you may also need to be slightly more direct in asking (nicely!) for what you want, rather than hoping that the customer service rep will "make it right" by guessing what you want. You may perceive that as bad service but I think it's mainly about differing communication styles.

Apparently Priceline.com Inc. took over Booking.com (founded in the Netherlands) for € 110 million, and then changed its name to Booking Holdings to reflect the fact that Booking.com was much bigger than Priceline.com. Indeed a great example of "American innovation" :)

How so? At least Booking.com shows me the total price for an accommodation up front, without any additional fees or surprises coming up later in the booking process.

The same cannot be said for AirBnB: if I go to the home page right now it lists a bunch of bookings for e.g. "€ 80 for 2 nights", while when I click through the total price is €160. So apparently what they meant is "€80 per night". I'd call that much more of a dark pattern than anything I've seen Booking do.

It's interesting to claim that tourism in Europe won't be "durable" at a moment when tourism in the US is sharply declining..

Anyway, Booking.com is a European company and has many more customers than AirBnB.

> I arrived in Lyon recently and figured, hey, this is Europe, why not try the European app again, and used Bolt.

A bit off topic but IMHO your first thought should instead be: "hey, this is Europe, why not try the train?"

In Lyon, the train from the airport to the city takes half an hour, same as a car. My guess is that you'll have a vastly better experience than taking the train in North America, and also a better experience than at least the OP had when taking a Bolt.

I, as well, had degraded performance due to the temperature in Amsterdam today :)

Can't complain compared to folks in Spain or Italy, though.. But hopefully they're better prepared than we are.

Is it easy/cheap to get a stable IP address? I would worry that if I just get any cheap VPS host, they might switch the IP address at any point, but I'm not sure how true that actually is.

> But you would also not be reachable if the killswitch is active ;)

I would be, because I asked for a killswitch for the microphone and cameras, not a killswitch for connectivity like the original comment.

If I get a call while the killswitch is active, I can stop the sensitive conversation, turn on the microphone, and answer the call.

I don't think it's easy to not carry a phone, nowadays. Let's say I'm meeting up with someone: I'll need to use navigation, potentially message them if I'm running late, and so on.

Then once I'm there, what do I do with the phone? Ask to put it in a separate room and hope that the microphone isn't powerful enough to pick up our conversation?

I could turn it off entirely, but what if someone needs to call me for an emergency?

For me, as a user, the easiest solution would be to have a killswitch. I understand that building it would be more work, of course :)

I'd be happiest if they'd provide a physical switch for the microphone and cameras. That way, you could have a private conversation and be sure you're not being recorded.

Turning off connectivity doesn't help as much to guarantee your privacy as the phone could theoretically be recording and then upload the recording later, when you turn it back on (if it was thoroughly compromised, which admittedly seems unlikely, but nevertheless it would be nice to have some guarantee that it's impossible).