Isn't the obvious thing to generate different classes for different ranges over the input? Then the classes could be loaded lazily.

And if you then make the ranges tree-shaped you get logarithmic complexity, which massively cuts down the O(n) of the rather naive chained `if` statements.

Clear you must bite your nails!

I sometimes speak into my voice recorder when I’m out for a walk and have a thought. Those voice notes can be many minutes long, and full of repetition and silence.

When no one’s looking obviously.

Not sure how that would work with the ring. Either lots of small similar notes. Or a dead battery.

I don't think that's the use case they're aiming for. If you want to have a meandering voice recording that lasts minutes, the friction to pull out your phone is less of an issue while you're out walking your dog.

But when you're having a conversation with someone and they ask you to pick up milk from the store later, or you're running to the bus and want to just jot down an idea you had briefly, and other moments where the friction is higher...then this seems like the solution.

Sure, but these use cases do blend into one another. And I'm not sure how useful the device when only constrained to the very short end of the spectrum.

iOS has recently added a ”trigger voice recorder” to the swipe-down screen from the lock screen.

It takes a random length of time to start recording. But it’s always too long. And it’s unreliable.

This would be much more convenient. Though I’m not sure the battery situation would convince me.

> at any time during the lifetime of the product

Eric said that the lifetime of the product is 'up to years'. Presumably because that's the limitation imposed by a disposable battery.

I wonder if the circular reasoning would fly in the EU.

Not only your government. The Conservatives who proposed it. Labour who provided no opposition. But most importantly Ofcom, who comprehensively failed to implement a competent and reasonable solution.

Everyone could have done a lot better, and could have achieved the stated aims without so much damage.

Labour actively supported it and still do. I got this from my Labour MP:

The UK has a strong tradition of safeguarding privacy while ensuring that appropriate action can be taken against criminals, such as child sexual abusers and terrorists. I firmly believe that privacy and security are not mutually exclusive—we can and must have both.

The Investigatory Powers Act governs how and when data can be requested by law enforcement and other relevant agencies. It includes robust safeguards and independent oversight to protect privacy, ensuring that data is accessed only in exceptional cases and only when necessary and proportionate.

The suggestion that cybersecurity and access to data by law enforcement are at odds is false. It is possible for online platforms to have strong cybersecurity measures whilst also ensuring that criminal activities can be detected.

I went down a 1-minute rabbithole. I hate Whatsapp, but it's not optional. So I was curious if it's compatible.

There's a Sailfish help page [0] showing how to get the APK from Aptoide, or downloading directly from Whatsapp.com .

But with Google killing off 'sideloading', is it credible that independent APK sources are going to dry up in future?

[0] https://docs.sailfishos.org/Support/Help_Articles/Whatsapp_S...

That shouldn't be a problem as long as you can still download apps from the Play Store itself (not the official app). Basically, take a look at how proxy stores like Aurora work, they connect to the Play Store servers and allow you to download apps directly from Google, without needing the Play Store app.

Of course, this doesn't mean that the downloaded app will work on such a device (if it doesn't have Google Play Services), but at least it lets you download the app, which isn't much different from downloading it from say, APK Mirror. And as long as you can extract the apps from either the Play Store or Android devices itself (via adb/root etc), I'm assuming sites like APK Mirror will continue to exist.

WhatsApp works okay on my Jolla C2. Occasional annoyance with device detection (BT headphones) where it'll still end up outputting to speaker, but I haven't had that with any other Android app running via AppSupport like YouTube Music, so dunno if that's just WhatsApp being problematic.

Installed it from Aurora, an open source frontend to the Play Store.

Biggest pain-points for me with AppSupport is:

1. Lack of Bluetooth passthrough in a sane way (community workaround results in it being unavailable with host OS). 2. It does not report to apps that PIN entry is enabled, meaning some awful but important apps like Danske ID don't work.

Otherwise it does the job remarkably well. Still prefer native SFOS apps when available, however it is a small ecosystem and so depending on your usecase you may find yourself installing Android apps.

While WhatsApp is not very much used in the US, in some other countries such as Brazil it is basically the primary form of "phone" communication. It is everyone's default text, voice and video message platform. People don't ask if you have WhatsApp there, they just assume it. You talk to your Bank/Investor manager using WhatsApp. You order pizza through WhatsApp. Customer Support for services is WhatsApp bots that send you to the correct places. If I don't have WhatsApp, I can't voice chat with my mom, she won't see her grandkids. If you have any sort of business, you need WhatsApp.

And yes, I do have Signal installed, and there are only 2 people who talk to me through it (one being my partner).

Phone carriers got too greedy charging for every single SMS message and phone call, WhatsApp took over when smartphones became popular.

This. Some people just don't realize how pervasive and essential WhatsApp is in some countries, mine included.

I'd much rather use Signal but that's not realistic.

But isn't it a timebomb waiting to blow up eventually? Like, Meta fucks something up with it and there is nothing you can do.

IIRC South Korea used to be fully depedent on a horrendous AcriveX applet running only in Internet Explorer for all their online services, yet they eventually managed to get rid of it. It should be possible here as well.

If WhatsApp does something really bad tomorrow, the population will probably migrate to Telegram very quickly, as it seems to be the 2nd most popular app for the category there.

There was a time where IRC was the most popular way to chat, and then MSN became IM default. Then people 'pinged' with BBOS. At one point, WhatsApp became the default, and just now Signal got popular, [1] thanks to Donald Trump.

[1] https://old.reddit.com/r/signal/comments/1j38sgw/signal_is_t...

To rephrase: Social contact is ultimately higher in my needs than technology choice.

They are having phones, with like, cellular communication methods, you know...

It's fascinating how different this challenge must be between Latin vs CJK.

How do you match up the scans with unicode entities? Human supervision and/or OCR? To what extent is the breadth and quality of OCR the limiting factor?

How do you define your target entity coverage?

Great questions — and you’re absolutely right that Latin vs. CJK is effectively two different universes in terms of reconstruction.

1. Latin vs. CJK differences Latin glyphs are structurally simple: limited stroke vocabulary, mostly predictable modulation, and relatively low topological variation. Once you can recover outlines and stroke junctions accurately, mapping to Unicode is almost trivial.

That can be done with standard OCR methods for Latin.

CJK is the opposite. Each character is effectively a miniature blueprint with dozens of micro-decisions: stroke order, brush pressure artifacts, serif style, shape proportion, and even regional typographic conventions. Treating it like Latin “but bigger” doesn’t work. So the workflow for CJK has extra normalization steps and more constraints, especially when reconstructing consistent glyph families rather than one-offs.

From a simple perspective, CJK has many characters with disconnected pieces that are still part of the same character.

2. How we match scans to Unicode entities We don’t rely on conventional OCR at all. OCR engines are optimized for reading text, not recovering the underlying design intent. Our process is closer to forensic glyph analysis — reconstructing stable structural signatures, then mapping those signatures to references.

This ends up being a hybrid: • deterministic structural matching • limited supervised correction when ambiguity exists • and zero reliance on any off-the-shelf OCR models

It’s not “OCR first, match later.” It’s “reconstruct the letterpress structure, then Unicode becomes a lookup.” OCR quality literally doesn’t limit us because OCR isn’t part of the critical path.

3. What determines coverage Coverage is defined by what we can physically access and reconstruct cleanly. For Latin, coverage is straightforward. For CJK, coverage is shaped by: • typeface completeness in the source material • the consistency of impression depth • survivability of fine strokes in early printings • and the practical question of how many thousand characters the original font designer actually cut

There’s no need for the entire Unicode set per book. The historical font only ever covered a finite subset. It is unfortunate that every book doesn't use every glyph, but not catastrophic because we can source many public domain books from the same era and eventually find enough characters matching the style.

In short: Latin is an engineering challenge. CJK is an archaeological one. OCR is not a bottleneck because we don’t use it. Coverage follows the historical material, not Unicode completeness.

Would love to hear or read more about this if it is public.

Please share what you told the LLM! I can't be the only curious one.

See above

I think those are a pre-surgery photographs.