On 2023-10-02 18:15, candycanearter07 wrote:
> On 10/2/23 20:05, Wally J wrote:

>> Remember, people like Alan Browne have a low IQ so we have to dumb
>> down the
>> message for them - but if you want to take a look at my software,
>> there are
>> papers I've published that you might find my writing style in.
>>
>> Hell... some of those papers are in a completely different field than
>> software, since I have multiple degrees in vastly different arenas.
>>
>> Anyway, the point here is that we have to remember the iKooks aren't only
>> stupid - they're religious fanatics who are stupid.
>>
>> Sure, none of the iKooks has an IQ approaching normal (nospam's is
>> probably
>> about 80, and Alan Browne's ten points below that - with the rest like
>> Jolly Roger and Joerg Lorenze and Alan Baker half of what those are).
>>
>> Sure, none of the iKooks has any formal education, with Joerg Lorenz and
>> Jolly Roger and Alan Baker never having graduated even what we'd call
>> High
>> School in the USA - Jolly Roger tried three times for the GED & failed -
>> for example.
>
> Ouch, really?

No, not really.

This is Arlen, so what can you expect.

It is a fact that I graduated from Grade 13 High School in Ontario;
which is probably harder than any final year of high school anywhere in
the US. My final year subjects were:

Advanced Physics
Chemistry
Three maths (Advanced Calculus, Advanced Trigonometry, and I can't remember.
Music (played trumpet in the school concert/marching band and in the
dance band—we even got paid gigs).

I ask you to reevaluate your trust in what Arlen says in light of those
undeniable facts.

:-)

On 2023-10-02 20:57, sms wrote:
> On 10/2/2023 2:40 PM, Mark L wrote:
>> On 2023-10-02 10:38, Alan Browne wrote:
>>> On 2023-10-02 09:55, sms wrote:
>>>
>>>> For the overheating, they can throttle the CPU under certain
>>>> conditions but it doesn't address the root cause of the need for a
>>>> better thermal solution (vapor chamber).
>>>
>>> Laughably stupid.  If the cause of the CPU overrun is a bug in s/w,
>>> you don't implement a mechanical change, you implement a software
>>> change.
>>
>> +1
>
> If the cause were a bug in the s/w then it would have shown up long ago
> since iOS 17 was out long before the iPhone 15 or the A17 Bionic. It can
> be "fixed" in software.

The point is your root cause above is not the root cause.

As to the bug "showing up", bad code can go undetected for years because
the conditions that invoke a problem are not met.

New h/w + OS = good chance some old bugs get their opportunity.

As Jolly Roger points out, this overheating issue is occurring in older
devices as well.

And yes, it can be fixed in s/w w/o any affect on performance.

On 10/3/2023 7:59 AM, Mark L wrote:

<snip>

> As Jolly Roger points out, this overheating issue is occurring in older
> devices as well.

LOL, you might want to reconsider who you believe.
>
> And yes, it can be fixed in s/w w/o any affect on performance.

Thermal throttling is a fact of life. You try to manage thermals with
proper PC board layout (not putting high wattage components close
together), heat sinks, heat pipes, fans, and vents, but ultimately
you’re probably going to have to throttle the CPU speed if the CPU just
runs too hot at maximum frequency.

If you’d ever worked in the semiconductor or consumer electronics field
as a hardware designer you’d quickly learn that you spend a huge amount
of time on two issues: 1) thermals, and 2) EMI/RFI. Both of these issues
need to be considered in the design phase, waiting until the end, and
then trying to manage thermals with additional hardware (heat sinks,
heat pipes, fans, etc.), and trying to manage EMI/RFI with more
shielding, more ferrite beads, etc., is not the right way to do things.
There’s a great book on electronics cooling “Hot Air Rises and Heat
Sinks” < https://www.amazon.com/dp/0791800741.

The Bionic performance has just gotten too great for the kind of thermal
solutions that were adequate in the past. Samsung ran into a similar
problem with their S23 and uses vapor chamber cooling. Phones from
manufacturers other than Apple now integrate the modem into the SOC
which makes things even more challenging since now you can’t separate
the two highest power chips on the board. If Apple succeeds with their
modem development, and eventually integrates their modem into the
Bionic, it will be even more challenging to manage the thermals without
vapor chamber cooling (which was predicted for the iPhone 14 by Kuo, but
didn’t happen).

If this were some bug in iOS 17 then you'd have seen the same kind of
reports with the iPhone 14 Pro/Pro Max running iOS 17 that you're seeing
now with the iPhone 15 Pro/Pro Max. There's just too many millions of
those devices out there for this issue to not have shown up on the older
devices.

As Kuo stated: “It’s expected that Apple will address this through
software updates, but improvements may be limited unless Apple lowers
processor performance.” I doubt if anyone, other than perhaps gamers,
will notice any difference. They just need to adjust the temperature at
which the A17 throttles in order to reduce the case temperature to an
acceptable level.

Kuo is probably correct when he absolves TSMC's 3nm process of blame.
But no one should have expected the 3nm processor to reduce the heat per
transistor versus the 4nm process, it doesn't work that way. A smaller
geometry lets you cram more transistors into a given die area but when
you get down to these kinds of geometry you're not gaining any thermal
advantage, in fact you're making things more difficult in terms of
getting the heat out of the device.

--
“If you are not an expert on a subject, then your opinions about it
really do matter less than the opinions of experts. It's not
indoctrination nor elitism. It's just that you don't know as much as
they do about the subject.”—Tin Foil Awards

On 2023-10-03, Frankie <frankie@nospam.usa> wrote:
> On 3/10/2023, Jolly Roger wrote:
>
>>> It can be "fixed" in software.
>>
>> Apple is on record stating the fix will be *drum roll* in software.
>
> Which means the only solution will be to slow down performance.

Proving, once again, you don't know much about software development.
Bugs that cause software to needlessly overuse resources are
*commonplace*, and fixing those bugs actually *increases* performance,
as those resources can be used more efficiently. This is a basic
computing concept, and you and your little troll gang are *desperate* to
ignore it as if it doesn't exist.

> Either way, the performance of the "fixed iPhone 15" will be reduced.

No.

--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

On 2023-10-03, sms <scharf.steven@geemail.com> wrote:
> On 10/3/2023 7:59 AM, Mark L wrote:
>
><snip>
>
>> As Jolly Roger points out, this overheating issue is occurring in
>> older devices as well.
>
> LOL, you might want to reconsider who you believe.

You twerps are so *desperate* to portray this as a hardware issue that
only affects the iPhone 15.

>> And yes, it can be fixed in s/w w/o any affect on performance.
>
> Thermal throttling is a fact of life.

So is fixing bugs that cause excessive resource usage.

--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

On 2023-10-02 21:55, Oscar Mayer wrote:
> On Mon, 2 Oct 2023 10:12:50 -0500, candycanearter07 wrote:
>
>>> IAC, in some time in the near future, this will all be a memory.
>>>
>>
>> I actually didn't know that, that makes a lot of sense.
>
> There are very many instances of Apple not testing the hardware and/or
> software before making a big deal of their "big" release of the product.
>
> Apple Maps is one of them, but a whole bunch of iPhones had hardware issues
> that Apple didn't test for (the antenna, the power delivery, the modem).
>
> Thankfully the new bold colors WERE TESTED thoroughly - and were a hit!

You remind of the boy in high school who hangs out with some popular
alpha male, remaining safe in his shadow, and ends up with a dead end
life void.

--
“Markets can remain irrational longer than your can remain solvent.”
- John Maynard Keynes.

On 2023-10-02 21:37, Frankie wrote:
> On 2/10/2023, sms wrote:
>
>>> The operating system controls thread scheduling and memory. They can
>>> just lower the apps priority if its past a certain usage percentage, or
>>> outright kill it.
>>
>> Actually the OS _can_ stop the app from consuming excessive resources by
>> shutting it down. There have been complaints by developers of this
>> happening when the app has a legitimate need for those resources.
>
> Given there are many disparate excuses Apple has provided for why the
> defective iPhones are overheating, do you think the "fix" will involved
> Apple lowering the performance?
>
> I'm not speaking of the CPU speed since Apple will be clever to blame the
> apps and not the processor - so the wording of Apple's public apology will
> likely be just as much a Doozy as the last one was that Apple issued.
>
> Do you think there's any chance Apple can decrease the disparate
> overheating (happens during charging!) without lowering performance?

Yes. Bugs that cause excessive CPU consumption w/o contributing useful
work are very possible. This has been explained to you. But you lack
the knowledge to understand it. That's okay - when Apple (and some app
writers) implement their changes you'll see it for what it is (or more
likely go off on some other bizarre tangent).

--
“Markets can remain irrational longer than your can remain solvent.”
- John Maynard Keynes.

On 2023-10-02 21:33, Frankie wrote:
> On 2/10/2023, Alan Browne wrote:
>
>> There are user settings in Unix to lower the priority of a program, but
>> it will still get all the CPU it can that is available. Not sure if
>> there are internal calls in iOS so an app can have its priority lowered.
>
> Apple has to lower performance, where that's one way they might do it.

It's clear you have no idea how pre-emptive OS's work.

Because, in fact, even when a thread or process has the lowest priority,
it will still get all the CPU time it craves when other processes of
higher priority don't need the CPU.

So Apple just need to fix the offending processes (bugs) and there will
be no need to throttle performance to resolve this issue.

--
“Markets can remain irrational longer than your can remain solvent.”
- John Maynard Keynes.

On 2023-10-02 21:21, Frankie wrote:
> On 2/10/2023, Alan Browne wrote:
>
>> I used to write real time programs for a living. It is all too easy to
>> make mistakes and have a section of code run in circles doing nothing
>> productive but consume power.
>
> You don't understand if that's your absurd excuse for the overheating.

I do. Completely. A little non-care in crafting complex code can
indeed result in a loop that should have called a ThreadSleep or exited
- but instead circles waiting for a signal or message rather than having
the thread manager "deliver" the message or wake the thread (OS
dependencies are also important...)

That's the nature of bugs. And further, bugs in multi-threaded apps can
be very hard to track down and fix (put another way: multi-threaded apps
are rife with opportunity to create bugs).

For that matter the CW is if you can avoid multi-threading, do avoid it.

> We used to call those "for loops" or "do loops" (adding nops in between,
> pronounced "no ops") but for you to make the assertion without a single
> fact that the dozen or so things Apple blamed are all that, is absurd.

No need for NOP's, (and depending on language loops are still called do
/ for / while / etc ).

Waiting on a state change w/o calling ThreadSleep for some reasonable
period (which may be 10's or 100's of µs or ms or s. depending on the
nature of that signal) is a fine way to gobble CPU w/o doing anything
useful. And if the timeslice is long (say 10ms) and there are few
competing CPU hungry apps, then that thread can really burn CPU w/o
doing anything useful.

Of course I've not only written such code w/o error and also written
such code with errors and found those errors (sometimes with
difficulty), so, unlike you I don't have to talk out of my hat.

Been there. Got the paycheque.

These days, I write multithreaded code on my Mac and on Raspberry Pi and
can fall into the same sorts of errors when not careful.

> Every crazy excuse you're making without any evidence is ridiculous.
> Apple will slow down the performance of the iPhone 15.
>
> It's the only choice Apple has.

Now those statements are the definition of ridiculous.

>
> Either Apple will slow down the CPU (but they won't do that).
> Or they'll slow down the apps running on that CPU (that's what they'll do).

Again, even the lowest priority thread has all the CPU it wants until it
is pre-empted (before or at the end of its time slice).

(Minor caveat, Apple silicon has "fast" and "efficiency" cores, so I
expect low priority threads are put onto the efficiency core.).

>
> Either way.
> The only choice Apple has now is to greatly slow down the performance.

Keep pounding at that statement. It does not make it valid.

>
> Which means all the current benchmarks are trash.
> The "fixed" iPhone 15 will be much slower than the overheating iPhone 15.

Which means 3rd party types will run their benchmark s/w and show the
result for before and after. So you'll have your "evidence" then.
<chuckle>.

>
> My recommendation is people not purchase these defective iPhones.
> Nothing good can ever come of them.
>
> They should wait for the iPhone 16 to be designed & tested to not overheat.

Nothing to worry about at all. Indeed my SO will be picking up her new
iPhone 15 in the next week or so.

--
“Markets can remain irrational longer than your can remain solvent.”
- John Maynard Keynes.

On 3/10/2023, Alan wrote:

>> How can someone be _that_ ignorant when NOBODY who races and NOBODY who
>> owns a bimmer or a beemer (I own both) would be _that_ completely clueless.
>
> Sorry... ...I never heard a distinction made about those two terms.

https://www.google.com/search?q=bimmer+versus+beemer

On 3/10/2023, Alan Browne wrote:

>>> I used to write real time programs for a living. It is all too easy to
>>> make mistakes and have a section of code run in circles doing nothing
>>> productive but consume power.
>>
>> You don't understand if that's your absurd excuse for the overheating.
>
> I do. Completely. A little non-care in crafting complex code can
> indeed result in a loop that should have called a ThreadSleep or exited
> - but instead circles waiting for a signal or message rather than having
> the thread manager "deliver" the message or wake the thread (OS
> dependencies are also important...)

I'm not saying loops don't exist.

I'm saying very clearly that it's insanely absurd to the point of
incredularity for you to make up the blame that all these overheating
causes are due to what you have shown not even a single one to be.

> That's the nature of bugs. And further, bugs in multi-threaded apps can
> be very hard to track down and fix (put another way: multi-threaded apps
> are rife with opportunity to create bugs).
>
> For that matter the CW is if you can avoid multi-threading, do avoid it.

Take the example of overheating while charging - as just one of the dozens
of causes that Apple has identified. How is THAT due to loops you claim?

>> We used to call those "for loops" or "do loops" (adding nops in between,
>> pronounced "no ops") but for you to make the assertion without a single
>> fact that the dozen or so things Apple blamed are all that, is absurd.
>
> No need for NOP's, (and depending on language loops are still called do
> / for / while / etc ).
>
> Waiting on a state change w/o calling ThreadSleep for some reasonable
> period (which may be 10's or 100's of µs or ms or s. depending on the
> nature of that signal) is a fine way to gobble CPU w/o doing anything
> useful. And if the timeslice is long (say 10ms) and there are few
> competing CPU hungry apps, then that thread can really burn CPU w/o
> doing anything useful.
>
> Of course I've not only written such code w/o error and also written
> such code with errors and found those errors (sometimes with
> difficulty), so, unlike you I don't have to talk out of my hat.
>
> Been there. Got the paycheque.
>
> These days, I write multithreaded code on my Mac and on Raspberry Pi and
> can fall into the same sorts of errors when not careful.

Your claims are completely made up out of nothing but your own desperation.

>> Every crazy excuse you're making without any evidence is ridiculous.
>> Apple will slow down the performance of the iPhone 15.
>>
>> It's the only choice Apple has.
>
> Now those statements are the definition of ridiculous.

You deny that the most common cause of overheating is the processor
workload even as Apple has clearly said that it is processor workload?

Why are you so desperate to not only claim Apple lied about what caused the
overloading but now you're saying what Apple claimed is ridiculous?
>
>>
>> Either Apple will slow down the CPU (but they won't do that).
>> Or they'll slow down the apps running on that CPU (that's what they'll do).
>
> Again, even the lowest priority thread has all the CPU it wants until it
> is pre-empted (before or at the end of its time slice).
>
> (Minor caveat, Apple silicon has "fast" and "efficiency" cores, so I
> expect low priority threads are put onto the efficiency core.).

I don't think you realize that you're desperate to claim that Apple lied
about the solution being the processor workload needed to be reduced.

>> Either way.
>> The only choice Apple has now is to greatly slow down the performance.
>
> Keep pounding at that statement. It does not make it valid.

Apple said what the problem was. You claim Apple lied.
You are a nut.

>>
>> Which means all the current benchmarks are trash.
>> The "fixed" iPhone 15 will be much slower than the overheating iPhone 15.
>
> Which means 3rd party types will run their benchmark s/w and show the
> result for before and after. So you'll have your "evidence" then.
> <chuckle>.

You now claim not only did Apple lie about the causes, but now you're
claiming that the 3rd parties are all conspiring against Apple?

Why can't you just admit Apple screwed up?

>
>>
>> My recommendation is people not purchase these defective iPhones.
>> Nothing good can ever come of them.
>>
>> They should wait for the iPhone 16 to be designed & tested to not overheat.
>
> Nothing to worry about at all. Indeed my SO will be picking up her new
> iPhone 15 in the next week or so.

The problem with any phone older than the iPhone XR is that it's
unsupported and the problem with the iPhone 15 is it's defective.

You deny both of those because you say Apple lied about both.

Despite your claims Apple lied, the truth remains that Apple won't fully
patch any phone older than the iPhone XR and Apple has already said they
are going to reduce the performance in order to solve the overheating.

On 3/10/2023, Alan Browne wrote:

> So Apple just need to fix the offending processes (bugs) and there will
> be no need to throttle performance to resolve this issue.

Apple already said they have to reduce the performance "of certain apps."

On 3/10/2023, Alan Browne wrote:

>> Do you think there's any chance Apple can decrease the disparate
>> overheating (happens during charging!) without lowering performance?
>
> Yes. Bugs that cause excessive CPU consumption w/o contributing useful
> work are very possible. This has been explained to you. But you lack
> the knowledge to understand it. That's okay - when Apple (and some app
> writers) implement their changes you'll see it for what it is (or more
> likely go off on some other bizarre tangent).

Apple already said they have no choice but to reduce the performance of the
apps they claim are causing the system to overheat.

Apple said they hope, "long term", that this short-term temporary
performance reduction will not greatly affect the iPhone 15 user base.

It was very clear that Apple said that.

Since you claim to know so much about Apple's solution, what do you make of
those public Apple statements from yesterday?

On 3/10/2023, Jolly Roger wrote:

>> Either way, the performance of the "fixed iPhone 15" will be reduced.
>
> No.

Apple already said they have no choice but to reduce the performance "short
term" of the two dozen apps they claim are causing the system to overheat.

Apple said they hope, "long term", that this short-term temporary
performance reduction will not greatly affect the iPhone 15 user base.

It was very clear that Apple said that.

Since you claim to know so much about Apple's upcoming iPhone 15 solution,
what do you make of those new public Apple statements from yesterday?

On 3/10/2023, Mark L wrote:

> And yes, it can be fixed in s/w w/o any affect on performance.

Apple already said they have no choice but to reduce the performance "short
term" of the two dozen apps they claim are causing the system to overheat.

Apple said they hope, "long term", that this short-term temporary
performance reduction will not greatly affect the iPhone 15 user base.

It was very clear that Apple said that.

Since you claim to know so much about Apple's upcoming iPhone 15 solution,
what do you make of those new public Apple statements from yesterday?

On 3/10/2023, Jolly Roger wrote:

>>> And yes, it can be fixed in s/w w/o any affect on performance.
>>
>> Thermal throttling is a fact of life.
>
> So is fixing bugs that cause excessive resource usage.

Apple already said they have no choice but to reduce the performance "short
term" of the two dozen apps they claim are causing the system to overheat.

Apple said they hope, "long term", that this short-term temporary
performance reduction will not greatly affect the iPhone 15 user base.

It was very clear that Apple said that.

Since you claim to know so much about Apple's upcoming iPhone 15 solution,
what do you make of those new public Apple statements from yesterday?

Alan Browne <bitbucket@blackhole.com> wrote

> You remind of the boy in high school who hangs out with some popular
> alpha male, remaining safe in his shadow, and ends up with a dead end
> life void.

Have you ever said anything that isn't that of a small child, Alan Browne?

On 2023-10-02 18:49, Peter wrote:
> sms <scharf.steven@geemail.com> wrote:
>>> It was a conscious decision not to test these iPhones for overheating.
>>
>> It was likely the belief that since the apps all ran fine on iOS 17 on
>> the iPhone 14 Pro/Pro Max that there was no operating system issue with
>> those apps. They didn't take into account the higher power consumption
>> and higher thermals of the A17 Bionic or the change from a metal with a
>> higher thermal conductivity to one with a lower thermal conductivity.
>
> You are correct because the causes are so mundane that the only way Apple
> could have not known about (charging & Instagram & common games) causing
> the iPhone overheating is that Apple thought they didn't need to test it.

In your utterly uninformed and uneducated opinino...

....right?

Opinions are like assholes: everybody's got one.

On 2023-10-03 14:01, Frankie wrote:
> On 3/10/2023, Alan Browne wrote:
>
>>>> I used to write real time programs for a living. It is all too easy to
>>>> make mistakes and have a section of code run in circles doing nothing
>>>> productive but consume power.
>>>
>>> You don't understand if that's your absurd excuse for the overheating.
>>
>> I do. Completely. A little non-care in crafting complex code can
>> indeed result in a loop that should have called a ThreadSleep or exited
>> - but instead circles waiting for a signal or message rather than having
>> the thread manager "deliver" the message or wake the thread (OS
>> dependencies are also important...)
>
> I'm not saying loops don't exist.
>
> I'm saying very clearly that it's insanely absurd to the point of
> incredularity for you to make up the blame that all these overheating
> causes are due to what you have shown not even a single one to be.

Sorry, experience tells me how such bugs come to be and how, while they
can be a bear to locate, they are usually easy to fix.
>
>> That's the nature of bugs. And further, bugs in multi-threaded apps can
>> be very hard to track down and fix (put another way: multi-threaded apps
>> are rife with opportunity to create bugs).
>>
>> For that matter the CW is if you can avoid multi-threading, do avoid it.
>
> Take the example of overheating while charging - as just one of the dozens
> of causes that Apple has identified. How is THAT due to loops you claim?

While charging could be unrelated. That is to say, charging happens and
heating happens because of it while simultaneously a separate bug also
causes the CPU to consume power and generate heat.

So could be one issue or two. Can't tell on scant information.

>>> We used to call those "for loops" or "do loops" (adding nops in between,
>>> pronounced "no ops") but for you to make the assertion without a single
>>> fact that the dozen or so things Apple blamed are all that, is absurd.
>>
>> No need for NOP's, (and depending on language loops are still called do
>> / for / while / etc ).
>>
>> Waiting on a state change w/o calling ThreadSleep for some reasonable
>> period (which may be 10's or 100's of µs or ms or s. depending on the
>> nature of that signal) is a fine way to gobble CPU w/o doing anything
>> useful. And if the timeslice is long (say 10ms) and there are few
>> competing CPU hungry apps, then that thread can really burn CPU w/o
>> doing anything useful.
>>
>> Of course I've not only written such code w/o error and also written
>> such code with errors and found those errors (sometimes with
>> difficulty), so, unlike you I don't have to talk out of my hat.
>>
>> Been there. Got the paycheque.
>>
>> These days, I write multithreaded code on my Mac and on Raspberry Pi and
>> can fall into the same sorts of errors when not careful.
>
> Your claims are completely made up out of nothing but your own desperation.

Look in the mirror - that would be you.

I actually do these things.

>>> Every crazy excuse you're making without any evidence is ridiculous.
>>> Apple will slow down the performance of the iPhone 15.
>>>
>>> It's the only choice Apple has.
>>
>> Now those statements are the definition of ridiculous.
>
> You deny that the most common cause of overheating is the processor
> workload even as Apple has clearly said that it is processor workload?

I never denied that. Just stated that it is easy to cause the processor
to do un-needed (un-wanted) work - and that will heat things up.

So - solve that bug and the heat issue goes away.

>
> Why are you so desperate to not only claim Apple lied about what caused the
> overloading but now you're saying what Apple claimed is ridiculous?

I didn't say that. That is your own fabrication.

>>
>>>
>>> Either Apple will slow down the CPU (but they won't do that).
>>> Or they'll slow down the apps running on that CPU (that's what they'll do).
>>
>> Again, even the lowest priority thread has all the CPU it wants until it
>> is pre-empted (before or at the end of its time slice).
>>
>> (Minor caveat, Apple silicon has "fast" and "efficiency" cores, so I
>> expect low priority threads are put onto the efficiency core.).
>
> I don't think you realize that you're desperate to claim that Apple lied
> about the solution being the processor workload needed to be reduced.

I'm not desperate to claim anything.

Just pointed out, and quite clearly, how a bug can cause excess CPU load
and thus heat. It's nothing to get in a lather about, but you're foaming...

>
>>> Either way.
>>> The only choice Apple has now is to greatly slow down the performance.
>>
>> Keep pounding at that statement. It does not make it valid.
>
> Apple said what the problem was. You claim Apple lied.
> You are a nut.

I never claimed Apple lied. Apple said there was a bug causing the CPU
load to go up and they will fix said bug.

As to nut, you might go consult a nut expert...
>
>>>
>>> Which means all the current benchmarks are trash.
>>> The "fixed" iPhone 15 will be much slower than the overheating iPhone 15.
>>
>> Which means 3rd party types will run their benchmark s/w and show the
>> result for before and after. So you'll have your "evidence" then.
>> <chuckle>.
>
> You now claim not only did Apple lie about the causes, but now you're
> claiming that the 3rd parties are all conspiring against Apple?

Wow, that's a stretch. Apple has said what the cause is and they will
fix it.

> Why can't you just admit Apple screwed up?

Apple have also said they will help 3rd parties avoid similar errors.

Did Apple "screw up"? Sure - about as much as anyone would expect a
very complex consumer product to have errors on its first week of new
h/w and OS.

And as usual these things will be fixed and life will go on.

>>
>>>
>>> My recommendation is people not purchase these defective iPhones.
>>> Nothing good can ever come of them.
>>>
>>> They should wait for the iPhone 16 to be designed & tested to not overheat.
>>
>> Nothing to worry about at all. Indeed my SO will be picking up her new
>> iPhone 15 in the next week or so.
>
> The problem with any phone older than the iPhone XR is that it's
> unsupported and the problem with the iPhone 15 is it's defective.
>
> You deny both of those because you say Apple lied about both.
>
> Despite your claims Apple lied, the truth remains that Apple won't fully
> patch any phone older than the iPhone XR and Apple has already said they
> are going to reduce the performance in order to solve the overheating.

You're spinning and losing yourself. Get a hobby you can handle.

Maybe knitting. Yes, that's quite appropriate.

--
“Markets can remain irrational longer than your can remain solvent.”
- John Maynard Keynes.

On 2023-10-03 14:04, Frankie wrote:
> On 3/10/2023, Alan Browne wrote:
>
>> So Apple just need to fix the offending processes (bugs) and there will
>> be no need to throttle performance to resolve this issue.
>
> Apple already said they have to reduce the performance "of certain apps."

Cite.

--
“Markets can remain irrational longer than your can remain solvent.”
- John Maynard Keynes.

On 2023-10-03 14:07, Frankie wrote:
> On 3/10/2023, Alan Browne wrote:
>
>>> Do you think there's any chance Apple can decrease the disparate
>>> overheating (happens during charging!) without lowering performance?
>>
>> Yes. Bugs that cause excessive CPU consumption w/o contributing useful
>> work are very possible. This has been explained to you. But you lack
>> the knowledge to understand it. That's okay - when Apple (and some app
>> writers) implement their changes you'll see it for what it is (or more
>> likely go off on some other bizarre tangent).
>
> Apple already said they have no choice but to reduce the performance of the
> apps they claim are causing the system to overheat.

Cite.

>
> Apple said they hope, "long term", that this short-term temporary
> performance reduction will not greatly affect the iPhone 15 user base.

Cite.

> Since you claim to know so much about Apple's solution, what do you make of
> those public Apple statements from yesterday?

Cite.

--
“Markets can remain irrational longer than your can remain solvent.”
- John Maynard Keynes.

On Oct 2, 2023, Wally J wrote
(in article <uffpbs$6toj$1@paganini.bofh.team>):

> The software I worked on is classified as a munition

So what? These two lines of perl implementing RSA would have been considered
a munition too:

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

On 2023-10-03, Alan Browne <bitbucket@blackhole.com> wrote:
> On 2023-10-02 21:37, Frankie wrote:
>> On 2/10/2023, sms wrote:
>>
>>>> The operating system controls thread scheduling and memory. They
>>>> can just lower the apps priority if its past a certain usage
>>>> percentage, or outright kill it.
>>>
>>> Actually the OS _can_ stop the app from consuming excessive
>>> resources by shutting it down. There have been complaints by
>>> developers of this happening when the app has a legitimate need for
>>> those resources.
>>
>> Given there are many disparate excuses Apple has provided for why the
>> defective iPhones are overheating, do you think the "fix" will
>> involved Apple lowering the performance?
>>
>> I'm not speaking of the CPU speed since Apple will be clever to blame
>> the apps and not the processor - so the wording of Apple's public
>> apology will likely be just as much a Doozy as the last one was that
>> Apple issued.
>>
>> Do you think there's any chance Apple can decrease the disparate
>> overheating (happens during charging!) without lowering performance?
>
> Yes. Bugs that cause excessive CPU consumption w/o contributing
> useful work are very possible. This has been explained to you. But
> you lack the knowledge to understand it. That's okay - when Apple
> (and some app writers) implement their changes you'll see it for what
> it is (or more likely go off on some other bizarre tangent).

They'll probably just insist that "Apple is throttling" without evidence
(as usual) and repeat that lie forever. 😉

--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

On 2023-10-03, Frankie <frankie@nospam.usa> wrote:
> On 3/10/2023, Alan Browne wrote:
>
>> So Apple just need to fix the offending processes (bugs) and there
>> will be no need to throttle performance to resolve this issue.
>
> Apple already said they have to reduce the performance "of certain
> apps."

Apple didn't say that. You're lying as usual.

--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

On 2023-10-03, Frankie <frankie@nospam.usa> wrote:
> On 3/10/2023, Jolly Roger wrote:
>
>>> Either way, the performance of the "fixed iPhone 15" will be reduced.
>>
>> No.
>
> Apple already said they have no choice but to reduce the performance

Apple did not say that. You're lying as usual.

--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR