tpolzer

Apple sends your searches to Google for money. I would call search queries data?

Apple, Samsung and Google all earn money from ads on your phone, just with different monetization pathways.

Indeed, but then I wouldn't call it a "big miss" (the title of the article, which doesn't mention regions either).

A moving GC would make it simple to move any remaining live objects back under normal GC control once the arena goes out of scope.

You could probably also do it without moving actually, it just gets a little more complex.

I wonder whether it would be possible to retrofit Arena allocation transparently (and safely!) onto a language with a moving GC (which IIUC Go currently is not):

You could ask the programmer to mark some callstack as arena allocated and redirect all allocations to there while active and move everything that is still live once you leave the arena marked callstack (should be cheap if the live set is small, expensive but still safe otherwise).

Unlike opaquely financed and privately owned media companies, the Guardian is actually relatively clear and open in how it is financed and set up in a way to try to make them as independent as possible (see for example the Scott Trust's annual report https://uploads.guim.co.uk/2025/09/11/The_Scott_Trust_Limite...).

That's not to say that they don't run their fair share of gossip/clickbait... but show me an online medium that does not.

It's a question of energy density. Multiple joules into your big phone battery is nothing, multiple joules into a small SMD component means it evaporates immediately in a bright flash!

Bad drivers could brick (parts of) your hardware permanently.

While you should have a backup of your data anyway.

One of the oldest (AFAIK) occurrences of this was AOL releasing a data set of "anonymized" search queries in 2006 and it took a about a day for the first person to be deanonymized.

https://www.nytimes.com/2006/08/09/technology/09aol.html

https://techcrunch.com/2006/08/09/first-person-identified-fr...

A std::monostate member will still have non zero size, because it needs a unique address.

See https://en.cppreference.com/w/cpp/language/ebo

If there was a std::unit_t and it was implicitly convertible to optional, tuple and pointer, I don't think that would be worse in terms of usability at all (maybe worse in readability for people who haven't heard of a 'unit' type).

As for the std::variant use case, using std::monostate is only a matter of convention there. You could use any of the other unit types just the same.

What's really weird to me is not that C++ has a unit type and picked a weird name for it (that's just C++). The weird thing is how many unit types it has:

- std::nullopt_t

- std::nullptr_t

- std::monostate

- std::tuple<>

And I'm sure there's more.

I find it annoying that (a) this seems to be a hardware feature that is almost universally permanently disabled in firmware and (b) it's almost impossible to find out whether it is supported by any given product (neither of the two products you link provide any mention on the spec sheet).

The theoretical limit is 50% according to Wikipedia, but there's other factors being optimized for as well aside from efficiency:

https://en.wikipedia.org/wiki/Engine_efficiency#:~:text=Mode....

SD Express is basically dead as far as I can tell.

SD card users who care about speed have UHS-II equipment, but SD Express and UHS-II use mutually incompatible high speed signalling on the same pins (so cards and readers are only supporting one of the two - I guess technically this could be fixable with special purpose chips, but at large cost).

Users who care about speed but not about SD card compatibility are already using CFExpress, which is supported by most modern professional cameras and has much better hardware availability than SD Express.

Ideally with PPS, your device can actually just ask exactly for the regulated voltage it needs on USB-C.

Most modern smartphones can use that to charge their batteries more efficiently/with less heating of the phone.

Unless your 5 GHz spectrum is crowded by other WiFi, you really want to be on channel 36, because that way you do not have DFS at all, see the table on Wikipedia: https://en.wikipedia.org/wiki/List_of_WLAN_channels

The AP still has to send regular beacons for each hidden SSID, taking up air time.

Over all age groups? Definitely not, cardiovascular diseases and cancer get ~everybody in the end: https://ourworldindata.org/grapher/annual-number-of-deaths-b...

You're right for 15-49 year olds, where drug overdoses only recently (around 2015) overtook cancer: https://ourworldindata.org/grapher/causes-of-death-in-15-49-...

Is this just a less polished/active version of https://github.com/mvp/uhubctl?

A decade is roughly the upper limit of specified battery shelf life for cheap batteries. Making the battery bigger doesn't really help much at that point where it's limited by shelf life, not capacity.

There are longer life batteries, but they're _expensive_, e.g. a Tadiran TL-4934, 1Ah, with a shelf life of 40 years will cost ~5$ in bulk.

That doesn't help at all if your loop variable is a 32 bit int that your compiler decided to transform away into vectorized loads from a 64 bit pointer.

But that's exactly one of the transformations that get enabled by assuming undefined overflow.

There are SSDs on the market that use all of their TLC flash as SLC cache, so you can almost use them as SLC drives if you partition them to leave 2/3 empty.

Eg the ADATA XPG SX8200. Look for whole drive fill speed benchmarks, if they use the whole drive as cache, the first third is fast (usually the SLC area is much smaller).

If you assume that all three numbers are small integers, doing the division last minimizes precision loss (and doesn't have any loss if the accurate result is representable as a float).

Otherwise you get loss from the division and then multiply that loss (by >1).

Some people try to spin this as a Google vs open standards, while it's mostly a Google devs vs. some other Google devs situation:

If you look at https://github.com/libjxl/libjxl/graphs/contributors, ~everybody except Jon Sneyers is a Google employee (I think the AVIF ratio is similar, but I didn't check).

So the question isn't about which format is better, but who won internal politics and it's clearly the AVIF folks - for reasons which aren't really possible to tell from the outside.

Try with -ffreestanding. Otherwise clang is allowed to make assumptions about the behavior of "malloc".

It then does the typical unsatisfying clang thing of unrolling and vectorizing a _lot_ with unclear benefits: https://godbolt.org/z/eG33YM7qs

Now if only https://github.com/openzfs/zfs/issues/10348 could be fixed. I'm using frequent zfs snapshots, but recovery is more annoying than I'd like.

You can use ZFS as a root file system, and it actually has such a switch (called "utf8only").

unique_ptr is nearly overhead free compared to a bare pointer (except for argument passing... because of ABI concerns).

shared_ptr is expensive and easy to build leaks with, so a lot of code bases avoid it where possible. Though it's only expensive when you copy it, moving it is ~free.

I've had a similar experience, especially with skin tones. The out of camera jpegs can be a little aggressive in making skin and grass colors "pop", but they still beat Darktable (even with significant tinkering).