IreneW

loopless said:

vedelppa said:

DAalseth said:

Skeptical said:

Another day, another iOS/Apple bug. I guess testing is more hit and miss in the rush to deliver a slightly undercooked product. 

As it only impacts Visa, I suspect this is a problem with Visa security. 

It's also possible that code on Apple's side fails when one has a Visa card. Even if Visa's security solutions differ from Mastercard's, the fault may be on Apple's side, too (even if this turns out to be false and it's Visa I think people here tend to assume Apple = perfect and in case if anything goes wrong, 3rd party = evil).

No seriously  - the transaction is sent to the card issuer ( in this case VISA) to approve. Nothing to do with Apple. Obviously MC has some layer that say, hmm $1000 is over a limit for express transit, and blocks it, or some other algorithm. It's about trading convenience ( no need to unlock phone) for security.

You should probably read the paper with the details, before stating stuff like this. Already in the first page:
"We disclosed this attack to both Apple and Visa, and

omar morales said:

Is this an opinion piece? Because it makes zero sense. What this article advocates is for Apple to put it’s customers at risk somthat some bottom feeder random repair shop can service Apple products their way.  🙄🙄🙄 

What "risk" are you talking about? I have had a lot of third-party repairs to my iPhones all these years, should i be worried?

larryjw said:

IreneW said:

larryjw said:

I think one can "blame" the OS. Now, I'm sure there needs to be a balance between performance and OS overhead, but it seems one role of the OS is to prevent run-away apps sucking the battery.

This might go back to the basic design of Unix. Unix is not a real-time OS and does not have preemptory capacity that would allow it to cut off applications eating up resources. 

Without knowing something more, I'd bet that all but specially designed Unix-based OSes have this same problem. 

Please elaborate. There's no reason the scheduler in iOS couldn't prevent individual apps from using more than a predefined quota. The *nix heritage had nothing to do with this, remember Android is built on top of Linux and in the sector i work we tailor the Linux kernel schedulers all the time (balancing safety, efficiency and foreground app performance).
What do you mean? Why couldn't Apple do this?

As I said, there must be a balance between performance and OS overhead. It seems that Apple has chosen a balance which precludes stopping Spotify from eating up resources. Apple doesn't use a Linux kernel but a kernel based on XNU. My first hand knowledge and experience is ancient and based on Unix System V many decades ago -- I've not looked at OS kernels since then. 

Could Apple do something to remedy problems such as this? Beats me -- anything is possible.

Apple does keep battery usage by app, so it's likely they could periodically analyze those stats to detect misbehaving apps. 

But,  I doubt the solution is something that can be dealt with in the scheduler. Applications like Spotify cannot be preempted and still maintain the quality of sound output -- even microsecond delays are detectable by listeners. 

Spotify (and all other similar apps) are definitely preempted - on iOS as well as on macOS, Windows, Android and Linux. No modern, GUI based, computing platform would set up the OS kernel to allow user space applications to freely use the CPU. I'm absolutely sure Apple normally handles this fine, in this case i would guess it is some combination of the Spotify user space behavior and some system calls/libraries that is the problem.
Regarding audio applications and potential glitches when preempted (or not switched in), this is easily mitigated by the I/O buffers in the audio drivers (usually on several different layers in the audio path). Only for extremely latency-sensitive applications (like SW synths and other instruments, DAWs etc), you might need to raise the application priority above default level (and you would seldom be allowed to use something similar to "realtime" prio anyway).

larryjw said:

I think one can "blame" the OS. Now, I'm sure there needs to be a balance between performance and OS overhead, but it seems one role of the OS is to prevent run-away apps sucking the battery.

This might go back to the basic design of Unix. Unix is not a real-time OS and does not have preemptory capacity that would allow it to cut off applications eating up resources. 

Without knowing something more, I'd bet that all but specially designed Unix-based OSes have this same problem. 

Please elaborate. There's no reason the scheduler in iOS couldn't prevent individual apps from using more than a predefined quota. The *nix heritage had nothing to do with this, remember Android is built on top of Linux and in the sector i work we tailor the Linux kernel schedulers all the time (balancing safety, efficiency and foreground app performance).
What do you mean? Why couldn't Apple do this?

Bosa said:

crowley said:

The speed and seeming duplicity of her dismissal certainly lends weight to such a lawsuit.  I honestly can't understand what Apple thought they were doing with that "not to participate in the discussion" comment; that's a massive point of weakness they've left themselves.

The termination has every appearance of being motivated by retaliation, and on that basis alone she has a case.

Apple was being super lenient for what she did, her violations were obvious and they still paid her for months to investigate when it was obvious what she did from day one.

I don’t think she will ever get hired ever again, she has herself to thank 

Ok, so what did she do? As far as I understand Apple has not detailed any reason for firing her, so where did you get your information?