For what it's worth, upcoming iOS 26 has a new screening feature. The idea is that calls from numbers you don't have a connection with will be asked to briefly identify themselves and why they're calling. It'll show you this text and give you the choice to block/send-to-voicemail/ignore/accept.
The problem I have with my iPhone is not callers, thankfully, it’s random iMessage from emails spamming me constantly, as many as 5 per day. The “filter unknown senders” option does not appear to work at all for these scammers.
I had this on my old Pixel. The result was that people generally hung up and didn't leave a message. Apple is a little bit better with marketing and hopefully won't make the same dumb move of making it a "pro only feature" so maybe it'll be different this time around...
I've been running the iOS 26 beta for a while and really the only problem people have had with it is that it's very clear the message the caller gets is pre-recorded, and without fail everyone who's interacted with it was expecting a beep, like an answering machine, before responding to it; but it doesn't actually beep, it just asks the caller to describe who they are and why they're calling.
So every screening popup I got had amusing text like "Is it going to beep? Hello?"
When it becomes commonplace, I expect the real problem with it will be that spam callers will recognize it and just starting giving false information to it to try to trick the party into accepting the call.
Spammers leave a message because they hear something and their bot starts talking. So it is worse than if I just don't answer.
But legit people, they just hang up. That's also a worse situation than not answering because in that case they'd have left a message. (this is hit or miss. Sometimes they leave a message. But 0 times have they actually responded to the screening)
There's also a "send unsaved numbers to voicemail" option if you don't like the call screening, and a separate toggle that puts calls/voicemails from unknown numbers on a separate list from the main one.
You're missing the point. The approach is block anything that doesn't execute the javascript. The javascript generates a key that allows your queries to work. No javascript => no key => no content for you to scrape.
Its a nuclear option. Nobody wins. The site operator can adjust the difficulty as needed to keep the abusive scrapers at bay.
Right up front: I agree. But, implementing this will be an absolute PITA because so many other things are systemically broken.
Case in point: cost breakdown from the invoice of an online order a few months ago (with the dollar amounts removed):
> Subtotal
> Shipping (Economy)
> Tax (Solano County Tax 0.25%)
> Tax (Vacaville City Tax 0.75%)
> Tax (Solano County District Tax Sp 0.125%)
> Tax (Solano Co Local Tax Sl 1.0%)
> Tax (California State Tax 6.0%)
Once your address is known taxes can be calculated. At what point is an after-tax final price to be shown? On an ad? On a targeted Ad? Once you reach the storefront based on unreliable geolocation? (which would be wrong for me, because geolocation bundles two cities here together as one) Once you create an account? At the checkout when you've specified the shipping address? As things tend to happen today, its usually only at the last step.
As much as I'd like to see it, I don't see much chance of improving the visibility of final prices without comprehensive systemic tax reform first.
The obvious quick solutions aren't exactly fair in the current US system. Imagine a "quick fix" of requiring the vendors to price in-a generic taxes for everyone. Just like with credit card system fees, "simple" fixes like that that benefit the residents of high-sales-tax states to the detriment of no-sales-tax state residents. While such a system would work for physical stores, they would get hammered if they had to prices on the shelves or signs that were higher than online prices.
As much as we all want a fair straight-forward system, I don't imagine it happening any time soon in the US. There are way too many unresolved zero-sum political fights and ideological differences standing in the way.
It certainly can be done (eg: Australia) but the circumstances there were very different.
I agree, it is not currently feasible in all cases. But something like AirBNB should be straightforward. Price tags on store shelves also straightforward. As you point out, it's tough for online shopping, at least until you have an established account. For advertising purposes it would be tough.
My guess is the only solution (and it would suck and be met with much resistance) would be to make all the taxes based strictly on where the seller is, not where the buyer is. Then the buyer would have to be on hook for use tax instead of sales tax. States would not like this because most people skip paying use tax altogether.
Or just get rid of sales tax as a thing, and if you want localized taxes put them on property. That's what my state does (plus income tax).
I agree that we're unlikely to see any sane solution in the US in our lifetime.
It's really simple: ban sales taxes levied by anyone except the national government. That's how other countries do it, and it works fine. Then everyone in the whole country pays the same tax rate, no matter where they are.
Short of that, ban sales taxes levied by local governments; only allow states to levy them. It's easy enough to figure out which state someone is in.
> "how are you supposed to write a compiler for this?"
It's been a while so I probably am misremembering the terminology, but I was always amused with the dynamic profile/feedback system that I always imagined would be more useful for a JIT code generator or JVM style runtime than a traditional compiler.
Every time I see people struggling with this, I am so incredibly glad that I forced the issue for FreeBSD when I did the initial amd64 port. I got to set the fundamental types in the ABI and decided to look forward rather than backward.
The amd64 architecture did have some interesting features that made this much easier than it might have been for other cpu architectures. One of which was the automatic cast of 32 bit function arguments to 64 bit during the function call. In most cases, if you passed a 32 bit time integer to a function expecting a 64 bit time_t, it Just Worked(TM) during the platform bringup. This meant that a lot of the work on the loose ends could be deferred.
We did have some other 64 bit platforms at the time, but they did not have a 64 bit time_t. FreeBSD/amd64 was the first in its family, back in 2003/2004/2005. If I remember correctly, sparc64 migrated to 64 bit time_t.
The biggest problem that I faced was that (at the time) tzcode was not 64 bit safe. It used some algorithms in its 'struct tm' normalization that ended up in some rather degenerate conditions, eg: iteratively trying to calculate the day/month/year for time_t(2^62). IIRC, I cheated rather than change tzcode significantly, and made it simply fail for years before approx 1900, or after approx 10000. I am pretty sure that this has been fixed upstream in tzcode long ago.
We did have a few years of whackamole with occasional 32/64 time mixups where 3rd party code would be sloppy in its handling of int/long/time_t when handling data structures in files or on the network.
But for the most part, it was a non-issue for us. Being able to have 64 bit time_t on day 1 avoided most of the problem. Doing it from the start was easy. Linux missed a huge opportunity to do the same when it began its amd64/x86_64 port.
Aside: I did not finish 64 bit ino_t at the time. 32 bit inode numbers were heavily exposed in many, many places. Even on-disk file systems, directory structures in UFS, and many, many more. There was no practical way to handle it for FreeBSD/amd64 from the start while it was a low-tier platform without being massively disruptive to the other tier-1 architectures. I did the work - twice - but somebody else eventually finished it - and fixed a number of other unfortunately short constants as well (eg: mountpoint path lengths etc).
FreeBSD was also more radical in dealing with off_t which became 64 bits since 2.0. Linux still has rudiments of old size in its 32-bit versions.
> One of which was the automatic cast of 32 bit function arguments to 64 bit during the function call.
AFAIU this works only for unsigned arguments (as loading to %edi clears upper part of %rdi). SysV ABI spec for x86-64 says nothing about extending all values in registers or stack to full 64-bit value, and comment on boolean (only LS byte contains something significant) suggests this is a common rule.
> Every time I see people struggling with this, I am so incredibly glad that I forced the issue for FreeBSD when I did the initial amd64 port. I got to set the fundamental types in the ABI and decided to look forward rather than backward.
Hold on. You're saying that when amd64 happened, FreeBSD ported i386 time_t to 64 bits as well? That's wild. Were other 32 bit architectures ported to 64 bit time_t as well, like the Motorola 68000 and sparc32?
I had two apple US$49 battery replacements both of my iPhone 8 phones before my wife and I jumped to a 14 pro max.
I preferred touchid over faceid. Sure, there was always the SE option, but if I was buying a newer phone then it was going to be new one, damn it.
What pushed the needle in the upgrade vs repair decision for me was wear concerns on the nand flash. I've encountered plenty of stories of flash failures after the 4th, 3rd or even 2nd battery replacement. I never found a way to get a meaningful health check for iphone flash lifetime but I really didn't want to find out the hard way.
That was in addition to 5G vs LTE. LTE in our area is a quagmire.
I went 8 -> 13 mini recently and I strongly preferred Touch ID also. It doesn’t require light, the right angle, or a button press to confirm the intentionality of actions like a purchase.
But yeah overall it’s bonkers how similar the two devices are for purportedly between four generations apart.
Main issue for me in bed is failure to identify face smooshed into pillow. Raise head and unlock fine, even in full dark. Still requires neck muscle actuation that wasn't required with touch id.
Depending on where you sit on the conscience/security sliding scale you might want to considering turning off “Require attention”. That solves 90% of glasses/sunglasses related issues.
I do it all the time, fwiw, but my girlfriend cannot get it to work reliably. So your mileage might vary, but in my experience ambient light does not matter.
No, but for me it often fails when outside in bright sunlight, especially if the sun is low in the sky, as it often is in my latitude. Perhaps it might work better if I try training it on my squinting face.
Sort of the same experience in some specific lighting conditions.
What I found out though is that it's because in such lighting conditions I don't blink, compounded by the fact that if it doesn't unlock I unconsciously keep on not blinking to... see it hopefully unlock! So when this happens I consciously blink and it unlocks immediately, which is kind of cognitively dissonant.
Unknown if that would apply to your situation, YMMV but I thought I'd throw this one out.
There's also a kind of annoying recurring situation where I want to look at stuff on the lock screen but don't want to actually unlock...
I do wish they'd have reintroduced Touch ID in the camera control button sensor (or just in the power button, as for the iPad Air) but I guess cases would cause a problem.
To me the best iPhone was the iPhone 7, with TouchID but no physical button. If I wanted, there was a completely silent mode that didn't have that "clunk" when you press that button.
I preferred the physical button. I hate the feel of "fake" clicks.
I used to think I wanted FaceID over TouchID, because TouchID would regularly fail to recognise my thumb if I'd recently washed my hands, or was a little dehydrated. Anything that affected my skin tension.
In practice, FaceID fails way more often, and also "resets" (the phone decides it wants a passcode before it'll trust my face again) multiple times a day. TouchID almost never did that.
You can disable "Require Attention for Face ID" under Settings > Face ID & Passcode. That makes Face ID far more reliable and consistent in my experience (assuming you're okay with the reduced security tradeoff).
If you have an Apple Watch, you can also configure it to unlock your phone automatically when an obstruction prevents Face ID from recognizing your face.
I'd never go back to Touch ID. Face ID works in the dark, at pretty much any angle, and requires zero interaction.
> You can disable "Require Attention for Face ID" under Settings > Face ID & Passcode. That makes Face ID far more reliable and consistent in my experience (assuming you're okay with the reduced security tradeoff).
I have had it in this mode for years. It's still very fragile and/or skittish regarding making me use my passcode. Intuitively, it feels like about 10-15% of logins require the code rather than my face.
> If you have an Apple Watch, you can also configure it to unlock your phone automatically when an obstruction prevents Face ID from recognizing your face.
That's a very expensive solution.
> Face ID works in the dark, at pretty much any angle, and requires zero interaction.
Yeah, my experience is very similar. Unlike the other replier I don't think there was much gained with FaceID in the end, especially with that stupid notch would made their remove useful information. Also considering the added cost and the even worse repairability than TouchID it's not a very good deal for the consumer.
Especially since it makes many operations a 2-step process when it was much smoother before; like for example Apple Pay where you find yourself looking at your phone like an idiot instead of doing it all in a single movement.
When my girlfriend saw the new camera button, she thought Touch ID had been added to the new iPhone, just like on her iPad mini. She got super excited for a moment, and I felt bad having to tell her that the new button doesn’t have Touch ID.
I feel the same way. If there’s one feature I miss, it’s toichid.
On the other hand, my parents, who are older, find Face ID to be a lifesaver since their fingerprints have mostly worn out.
I switched to Samsung partly because of the lack of Touch ID. Face ID was annoying, it didn't work well with masks (even with the special option turned on), it didn't work well in the morning when I'm lying in bed, it didn't work well when I was carrying my son in a carrier because the angle was wrong.
My memories of Android phones are bad enough that I can’t imagine actually switching back over this feature — there’s just way too much else I appreciate about the Apple ecosystem. But respect to you!
I'd say it's significantly better... I did a brief stint with android a long time ago but didn't like it, but now I've been using it for 3 yearsish and I actually get annoyed when I use my wife's iphone. There's a lot to like from F-Droid, the fact that the quick settings menu is better (just a recent example, you long press on the hotspot button you get sent to the settings showing you the hotspot password),...
Yeah, I think the hardware has improved so much that now the more complexe software can now be much more useful.
This is what Apple has missed in my opinion; the iPhone is no longer a no-nonsense, simple as it gets, with a strict selection of features (both hardware and software) to meet a palatable price point, device that it once was.
But then in comparaison to modern Android it feels like at the same time it is too complicated but also missing a lot of options/features/freedom.
Apple is working hard to add all kinds of "missing" features and complexity all over the place, all while raising the price of the device as much as possible. But in the end, what kind of client will be satisfied with this approach but noy with an Android?
Not a whole lot I believe.
This is more common than you might think. I have encountered cheap home routers that have dumb dns proxy caches on them that simply cache everything for a fixed time period. I heard of one that simply flushed its cache at the same time every hour.
You find out all sorts of bad DNS behavior when you run anything CDN related.
We took a shot at doing ultra-fast kernel threads on FreeBSD a few decades ago. For various reasons, it was reverted and removed a few major versions later.
If you look a the old KSE work, the general gist was that if you were about to block in a syscall then you'd effectively get a signal-style longjmp back to your userland thread scheduler. You'd pick another thread and continue running all in the same process/task context.
There were many problems with what we did and how we did it, but the unavoidable fundamental problem at the time was that it inverted assumptions about costs of low level primitives. Important(TM) software was optimized for the world where threads and blocking were expensive and things like pthread mutex operations were cheap. Our changes made threads and blocking trivially cheap but added non-trivial overhead to pthread mutex etc operations. Applications that made extensive use of pthread mutexes to coordinate work dispatching on a precious small pool of expensive threads were hit with devastating performance losses. Most critically, MySQL. We'd optimized for hundreds of thousands of threads rather than the case of multiplexing work over a few threads.
It became apparent that this was going to be an eternal uphill battle and we eventually pulled the plug to do it the same way as Linux. We made a lot of mistakes with all of this.
Since they mention "a few decades ago" I'm guessing it's a very different mutex than the one you'd use today.
Today I believe all of these operating systems (except MacOS, LOL) have either futex or an equivalent technology (the Windows thing works on bytes rather than aligned 32-bit values, so that's cool) and so it seems like only contention could be more expensive as the whole point of a futex is that uncontended acquisition is a single CPU store and that's userspace, the kernel is nowhere near it.
I was not aware. I wonder if anybody tried asking Apple? That's what happened for SRWLOCK in Windows. Mara asked Microsoft if they can promise it actually does what it seems like it does, formally, and they did document that promise so then Rust used SRWLOCK [today your Rust does not use SRWLOCK, this year it was replaced for performance reasons, which is timely because it turns out SRWLOCK is faulty and so "Don't use SRWLOCK" is the most practical fix in the medium term, awkward for poor C++ though as they used SRWLOCK too].
Apple are even less talkative than Microsoft, but it is possible that the reason libc++ uses this is that it's actually guaranteed and if properly asked Apple would say so. It would be nice for (newer) macOS to get the same promises as the mainstream platforms with respect to these primitives.
Playing devils advocate for a moment: One reason why is that many app developers truly do not have your best interests at heart. Taking heat for being a gatekeeper sucks, but the downsides of the alternatives are potentially limitless.
Random example: the fuss about the facebook advertising/tracking SDKs back in the day. When apple started giving unique device IDs to each app, this cross-app tracking mesh imploded and they were screaming about lost revenue. Maybe you find billions of dollars worth of tracking to be creepy, maybe not. But if facebook had the option of getting that functionality and revenue back via an easy sideloading or some other frictionless alternative mechanism then the entire app ecosystem that was even remotely related to facebook tracking would have been off the app store in a heartbeat. Instead of being at the mercy of apple, you, and your extended tech-support family would have been at the mercy of facebook.
Apple is no angel, but the potential downsides are limitless. Instead of the facebook tracking example, consider partially or overtly malicious apps that your parents are now installing on their phones (as well as their malware-ridden PCs).
On the other hand, sideloading is a fairly low barrier for technically competent folks. Stuff like iResign and other tools have been around forever. You can grab any pirated/hacked/etc app package, sign it yourself, and sideload it via your dev credentials. But at least you don't have to worry about your parents doing that. Or facebook telling your parents to do that.
Anyway, that's a "for some reason" example. The readership of HN are not the target audience that the app store gatekeeping is there for.
(But don't get me started on fees/commissions/etc - that's indefensible IMO)
Apple controls the OS and the sandbox apps run on independently of the source of the app. Facebook would be able to tell users "you have to give us location access or the app won't run", but Apple controls what data is given to the app. Facebook could implement something to track users in the background, but the sandbox still kills/freezes the app as soon you hide it. They could implement some kind of tracking, but again, remember that the app runs in a sandbox and Apple controls that sandbox.
This is why a malware app on an iPhone can only do limited damage. It can't access all files, it can't encrypt the storage, it can't launch a DDoS in the background because the OS doesn't let it run, etc. iOS or Android are not Windows.
If you want to know how it works in practice, look at Android. It has supported sideloading for a long, long time. People do install a lot of crap, but that's from the app store. My parents are really bad with tech and never sideloaded anything.
And there are other layers of security too. If you go to a store, buy a Samsung, a Google Pixel, a OnePlus, Nokia, etc, they all come with Google Services, which includes Google Play Protect... essentially an anti-virus that looks at your apps and flags anything that is known to be malicious.
Are there any downsides? Yes. Are they as bad as some say? The Android example tells us that it doesn't have to be that bad.
> They could implement some kind of tracking, but again, remember that the app runs in a sandbox and Apple controls that sandbox.
Sandbox escapes are incredibly common, Apple still controls eliminating your business from iphones if you attempt to use an exploit to pull user data when you distribute through the App Store.
If you can do distribution via your own site, it becomes a whack-a-mole game with Apple - where data exfiltration exploits are found, Apple fixes them in a new update, then we have to wait for people to update.
And until most users update, the at-fault company is busy siphoning data from any user who can't update (e.g. no wifi / limited data plan) or any user who is slow to approve the update dialog. Eventually the company's app will grow to contain an exploit for the last dozen iOS versions that conditionally execute based on the iOS version/feature detection/probing for exploit availability.
Apps without app store review could also start delivering dynamic code packages that aren't included in the binary. There could be targeted attacks via these apps on specific users (say, journalists, politicians and their families, etc) not delivered to everyone; Apple thus can't analyze until it's been delivered to a device they control. App Store rules forbid dynamic native code delivery.
Perhaps journalists and politicians should stick with the App Store (which is what 99% of users do on Android, where you can sideload apps) and use Lockdown Mode.
There are downsides for Apple to the rate of their 30% cut. That is why they are doing their best to keep sideloading off their devices. Not to protect users - as you already stated there are many other layers of protection in place for that - but to protect their revenue.
I think one thing that's happening is that people have forgotten (or are too young to have really experienced) the absolute torrent of crapware that preceded the closed mobile app ecosystem. Almost no app developers had your best interests at heart, and some of the few who did ended up selling their apps to developers that didn't. If that risk seems remote now, it's in part because of the App Store.
I remember, and would still prefer that "torrent of crapware" which one could make up one's own mind about, rather than the dictatorship of the walled garden.
It's not like the App Store review process is particularly trustworthy either. There have been plenty of stories here and elsewhere of that.
Almost no app developers had your best interests at heart
Neither does Apple nor the developers of apps in the App Store. In fact, given the fees, they have even less incentive to avoid greed.
Just because the app store is closed it doesn't mean it's not full of crapware?
All the "games" are IAP fests. Every time you search for some big name app you get the app (if available) and a bunch of results that are named so deceptively that you're afraid to click on them.
Every week there's another story about a flashlight app that charges a 50/month or 9.99/week subscription.
So tell me how Apple's app curation helps?
> If that risk seems remote now
Maybe to you? I haven't looked at iOS games since the days of the iPad 1, when Apple hadn't pushed all game devs into IAPs yet.
And the few apps I bought, they were mentioned on forums not connected to Apple. And as you said yourself, there's always the chance the app gets sold and the terms change, and the walled garden won't help a single bit.
Not so much, no, but if you'd said in 2005 that there'd be a mainstream platform for general-purpose computing where the worst problem was that a lot of the games had in-app purchases, nobody would have believed you.
Conveniently ignoring the subscription flashlight apps and the still existing chance that apps get sold and become predatory on the next update, I think…
Do you know anyone that has any of that old crapware on their Macs or had their Mac infected by malware in the past 5 or 10 years? I don't. And they can go to a website, download and install any app they want.
What about Android, which lets you sideload apps? How many people do you know that sideload apps or have installed a malicious app from outside the Play Store?
Yes, the App Store was and is important, but you need to look at other platforms if you really think that Apple allowing app sideloading (proper sideloading, not that shit they're doing in the EU) is going to take us back to the days of browser toolbars. iOS is not Windows XP.
China's Great Firewall is known actively detect and block most VPN protocols and things like SSH tunneling. There are custom protocols designed to camouflage traffic, but they require apps (e.g. Shadowrocket for iOS) which are, surprise, unavailable on the Chinese App Store. IIRC the same sort of blocking also happens in Iran as well.
I'm not sure a country where they're forcing a company to take down apps would allow them to then get sued for the act of compliance being considered anti-competitive. Obviously whatever Apple does in a specific country can't be used to prove anti-competitiveness in another country since that country doesn't have jurisdiction.
Not quite sure I follow that logic. The point is an iphone can be configured to use a VPN (operated by anybody, not limited to Apple) without requiring the use of apps.
> The point is an iphone can be configured to use a VPN (operated by anybody, not limited to Apple) without requiring the use of apps
A very specific type of VPN, which is easily blocked.
I don't know if it's monopolistic as the comment you replied to says, but in the context of the thread, the build-in support doesn't fix the problem banning apps from the app store creates.
One of the things I've done in the past that is quick and easy is to use grub to chainload another bootable volume. Scp an iso or other disk image over, chainload to that, run the installer inside it as though it had just been pxebooted or booted from a flash drive. If you can netinstall from there, then you're good to go with the OS of your choice.
There's lots of ways if you have access to common cloud primatives (replacement root volume, etc) and have some creativity.
I did appreciate this post though because it's for a way I haven't used before.
