On 2023-10-01 17:18, Frankie wrote:
> On 1/10/2023, Alan Browne wrote:
>
>>>> These come at the expense of performance.
>>>
>>> The only way Apple can reduce overheating is at the expense of performance.
>>
>> Since the fix is bug fixes in iOS and some apps, would you care to
>> elaborate?
>
> The only way Apple can lower the heat output is to lower performance.

Not at all. There are many ways you can make errors that cause CPU use
to rise w/o doing any useful work. For example a good app will sleep
itself if it has nothing left to do. But it might be sitting in a loop
waiting on a signal state, message, etc. instead of giving up the
balance of its time slice. So it's only interrupted on pre-emption.

And such bugs can be in 3rd party apps, Apple apps and the OS.

> That means all the benchmarks to date are no longer valid.
> They never were valid.

What it means is after the bug fix is that the benchmarks will be pretty
much identical.

>
> Apple sold an inherently untested product which turned out to be defective.
> The benchmark results are on that defective product.

In any new product and OS release, the chances of bugs is pretty high no
matter how much testing was done. These are consumer appliances and
there are too many undetermined (undeterminable) cases to test them all.

> It's fast. But too hot.

See above. Threads can be very fast and very unproductive. Fix that
and life goes on.

>
> The non-defective iPhone will be cooler.
> And slower.

Nope.

>
> There is no other way to solve the problem without a complete hardware
> redesign (which isn't what Apple said they would do to fix the problem).

Nope.

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

On 10/1/23 14:24, Alan wrote:
> On 2023-10-01 12:13, Wally J wrote:
>> Your Name <YourName@YourISP.com> wrote
>>
>>>> Because people expect polish?? What kind of argument is this? Ship now,
>>>> fix later is hated by consumers for a reason.
>>>
>>> No computer company on the planet does, nor can, terst their devices
>>> against every single piece of third-party made software and hardware.
>>> It's not remotely sensible for anyone to expect them to either.
>>
>>   *All these excuses for a defective product mean Apple forgot to test
>> it.*
>
> No, clown.
>
> It doesn't.
>

Then how did so much slip through?
--
user <candycane> is generated from /dev/urandom

On 2023-10-01 17:38, Alan wrote:
> On 2023-10-01 14:13, Wally J wrote:
>> Jolly Roger <jollyroger@pobox.com> wrote
>>
>>> No, you very clearly haven't.
>>
>> Well, both badgolferman and I have said we've worked on military grade
>> software for decades but you can choose to disbelieve what we say.
>
> That's convenient, Clown...
>
> ...because we do so choose.

Using terms like "military grade software" is a red flag.

There is a way to say what he desperately wants to convey but since he
said it the way he said it we know it is poppycock (at best).

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

On 2023-10-01 17:43, candycanearter07 wrote:
> On 10/1/23 16:36, Alan Browne wrote:
>> On 2023-10-01 16:38, sms wrote:
>>> On 10/1/2023 12:20 PM, Patrick wrote:
>>>
>>> <snip>
>>>
>>>> Damn Instagram.
>>>>
>>>> Why is it always the app that nobody uses that makes the iPhone
>>>> overheat.
>>>
>>> LOL, here are the iOS apps that are downloaded the most:
>>> 1. TikTok
>>> 2. Instagram
>>> 3. Facebook
>>> 4. WhatsApp
>>> 5. Telegram
>>>
>>> I did see a complaint that Instagram causes Android phones to heat up
>>> as well. It seems like Instagram will just use as much CPU power as
>>> it can get. This is not really a bug in Instagram, the operating
>>> system should be limiting the amount of resources that an app can
>>> consume.
>>
>> Not at all.  The OS cannot tell if badly written software is doing
>> something useless driving up power consumption.
>
> 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.

Some apps justifiably need a lot of CPU so the OS cannot do more that
allow the app / thread to run its time slice until the slice is over or
pre-empted by something with higher priority for which no other core is
available.

Could one design an OS that applies the rule as you say? Sure. But
that is not the case in general purpose OS'.

Could the OS detect race conditions and kill a thread (or several)?
Probably. My example has no such possible state.

And while my example might be trivial, there are cases where converging
on a solution with many variables can take a hell of a lot of CPU and
time. And it's a very valid thing for a program to do.

The main point is that OS' don't arbitrarily kill processes (or throttle
them) just because a given process is using a lot of CPU.

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

On 2023-10-01 17:44, candycanearter07 wrote:
> On 10/1/23 14:24, Alan wrote:
>> On 2023-10-01 12:13, Wally J wrote:
>>> Your Name <YourName@YourISP.com> wrote
>>>
>>>>> Because people expect polish?? What kind of argument is this? Ship
>>>>> now,
>>>>> fix later is hated by consumers for a reason.
>>>>
>>>> No computer company on the planet does, nor can, terst their devices
>>>> against every single piece of third-party made software and hardware.
>>>> It's not remotely sensible for anyone to expect them to either.
>>>
>>>   *All these excuses for a defective product mean Apple forgot to
>>> test it.*
>>
>> No, clown.
>>
>> It doesn't.
>>
>
> Then how did so much slip through?

General purpose appliance for the masses.

It's a miracle so few bugs do.

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

On 10/1/23 16:59, Alan Browne wrote:
> On 2023-10-01 17:43, candycanearter07 wrote:
>> On 10/1/23 16:36, Alan Browne wrote:
>>> On 2023-10-01 16:38, sms wrote:
>>>> On 10/1/2023 12:20 PM, Patrick wrote:
>>>>
>>>> <snip>
>>>>
>>>>> Damn Instagram.
>>>>>
>>>>> Why is it always the app that nobody uses that makes the iPhone
>>>>> overheat.
>>>>
>>>> LOL, here are the iOS apps that are downloaded the most:
>>>> 1. TikTok
>>>> 2. Instagram
>>>> 3. Facebook
>>>> 4. WhatsApp
>>>> 5. Telegram
>>>>
>>>> I did see a complaint that Instagram causes Android phones to heat
>>>> up as well. It seems like Instagram will just use as much CPU power
>>>> as it can get. This is not really a bug in Instagram, the operating
>>>> system should be limiting the amount of resources that an app can
>>>> consume.
>>>
>>> Not at all.  The OS cannot tell if badly written software is doing
>>> something useless driving up power consumption.
>>
>> 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.
>
> Some apps justifiably need a lot of CPU so the OS cannot do more that
> allow the app / thread to run its time slice until the slice is over or
> pre-empted by something with higher priority for which no other core is
> available.
>
> Could one design an OS that applies the rule as you say?  Sure.  But
> that is not the case in general purpose OS'.
>
> Could the OS detect race conditions and kill a thread (or several)?
> Probably.  My example has no such possible state.
>
> And while my example might be trivial, there are cases where converging
> on a solution with many variables can take a hell of a lot of CPU and
> time.  And it's a very valid thing for a program to do.
>
> The main point is that OS' don't arbitrarily kill processes (or throttle
> them) just because a given process is using a lot of CPU.
>

At the very least, it should warn the user if a program is using a lot.
--
user <candycane> is generated from /dev/urandom

On 2023-10-01 14:44, candycanearter07 wrote:
> On 10/1/23 14:24, Alan wrote:
>> On 2023-10-01 12:13, Wally J wrote:
>>> Your Name <YourName@YourISP.com> wrote
>>>
>>>>> Because people expect polish?? What kind of argument is this? Ship
>>>>> now,
>>>>> fix later is hated by consumers for a reason.
>>>>
>>>> No computer company on the planet does, nor can, terst their devices
>>>> against every single piece of third-party made software and hardware.
>>>> It's not remotely sensible for anyone to expect them to either.
>>>
>>>   *All these excuses for a defective product mean Apple forgot to
>>> test it.*
>>
>> No, clown.
>>
>> It doesn't.
>>
>
> Then how did so much slip through?

There is a difference between not finding a particular issue in
particular circumstances and "forget[ting]" to test.

Agreed?

On 10/1/23 17:25, Alan wrote:
> There is a difference between not finding a particular issue in
> particular circumstances and "forget[ting]" to test.
>
> Agreed?

If so many people have this issue then it would've come up in testing.
--
user <candycane> is generated from /dev/urandom

On Oct 1, 2023, Alan Browne wrote
(in article <xQlSM.36250$%_f1.3838@fx06.iad>):

> On 2023-10-01 17:38, Alan wrote:
> > On 2023-10-01 14:13, Wally J wrote:
> > > Jolly Roger <jollyroger@pobox.com> wrote
> > >
> > > > No, you very clearly haven't.
> > >
> > > Well, both badgolferman and I have said we've worked on military grade
> > > software for decades but you can choose to disbelieve what we say.
> >
> > That's convenient, Clown...
> >
> > ...because we do so choose.
>
> Using terms like "military grade software" is a red flag.
>
> There is a way to say what he desperately wants to convey but since he
> said it the way he said it we know it is poppycock (at best).

Military Grade software does exist. VHDL (MIL-STD-454N) and Ada
(MIL-STD-1815) are examples. But just because something is military grade
doesn't mean it is good. Military grade means it is the cheapest made while
still meeting minimum contract specifications.

On 2023-10-01 16:04, candycanearter07 wrote:
> On 10/1/23 17:25, Alan wrote:
>> There is a difference between not finding a particular issue in
>> particular circumstances and "forget[ting]" to test.
>>
>> Agreed?
>
> If so many people have this issue then it would've come up in testing.

You're so sure of that, are you?

On 2023-10-01 22:05:14 +0000, candycanearter07 said:
> On 10/1/23 16:59, Alan Browne wrote:
>> On 2023-10-01 17:43, candycanearter07 wrote:
>>> On 10/1/23 16:36, Alan Browne wrote:
>>>> On 2023-10-01 16:38, sms wrote:
>>>>> On 10/1/2023 12:20 PM, Patrick wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>> Damn Instagram.
>>>>>>
>>>>>> Why is it always the app that nobody uses that makes the iPhone overheat.
>>>>>
>>>>> LOL, here are the iOS apps that are downloaded the most:
>>>>> 1. TikTok
>>>>> 2. Instagram
>>>>> 3. Facebook
>>>>> 4. WhatsApp
>>>>> 5. Telegram
>>>>>
>>>>> I did see a complaint that Instagram causes Android phones to heat up
>>>>> as well. It seems like Instagram will just use as much CPU power as it
>>>>> can get. This is not really a bug in Instagram, the operating system
>>>>> should be limiting the amount of resources that an app can consume.
>>>>
>>>> Not at all.  The OS cannot tell if badly written software is doing
>>>> something useless driving up power consumption.
>>>
>>> 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.
>>
>> Some apps justifiably need a lot of CPU so the OS cannot do more that
>> allow the app / thread to run its time slice until the slice is over or
>> pre-empted by something with higher priority for which no other core is
>> available.
>>
>> Could one design an OS that applies the rule as you say?  Sure.  But
>> that is not the case in general purpose OS'.
>>
>> Could the OS detect race conditions and kill a thread (or several)?
>> Probably.  My example has no such possible state.
>>
>> And while my example might be trivial, there are cases where converging
>> on a solution with many variables can take a hell of a lot of CPU and
>> time.  And it's a very valid thing for a program to do.
>>
>> The main point is that OS' don't arbitrarily kill processes (or
>> throttle them) just because a given process is using a lot of CPU.
>
> At the very least, it should warn the user if a program is using a lot.

At the very least the user should have enough brains not to use utter
crap "Social Media" apps like Instagram. :-p

On 2023-10-01 23:04:06 +0000, candycanearter07 said:
> On 10/1/23 17:25, Alan wrote:
>>
>> There is a difference between not finding a particular issue in
>> particular circumstances and "forget[ting]" to test.
>>
>> Agreed?
>
> If so many people have this issue then it would've come up in testing.

So far, almost all the people reporting the issue have been reviewers,
many of whom by necessity of the job would be pushing the device to the
limit. There's also the likelihood that some reviewers also got early
production models so they could review the device.

On 10/1/23 18:54, Your Name wrote:
> On 2023-10-01 22:05:14 +0000, candycanearter07 said:
>> At the very least, it should warn the user if a program is using a lot.
>
> At the very least the user should have enough brains not to use utter
> crap "Social Media" apps like Instagram.  :-p
>
>

While I don't disagree, they should still have some safeguards against
rouge apps.
--
user <candycane> is generated from /dev/urandom

On 10/1/2023 2:43 PM, candycanearter07 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.

--
“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 10/1/23 19:22, sms wrote:
> On 10/1/2023 2:43 PM, candycanearter07 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.
>

That's what I said?
--
user <candycane> is generated from /dev/urandom

On 2023-10-01, Dorper <usenet@dorper.me> wrote:
> On Oct 1, 2023, Alan Browne wrote
> (in article <xQlSM.36250$%_f1.3838@fx06.iad>):
>
>> On 2023-10-01 17:38, Alan wrote:
>> > On 2023-10-01 14:13, Wally J wrote:
>> > > Jolly Roger <jollyroger@pobox.com> wrote
>> > >
>> > > > No, you very clearly haven't.
>> > >
>> > > Well, both badgolferman and I have said we've worked on military
>> > > grade software for decades but you can choose to disbelieve what
>> > > we say.
>> >
>> > That's convenient, Clown...
>> >
>> > ...because we do so choose.
>>
>> Using terms like "military grade software" is a red flag.
>>
>> There is a way to say what he desperately wants to convey but since
>> he said it the way he said it we know it is poppycock (at best).
>
> Military Grade software does exist. VHDL (MIL-STD-454N) and Ada
> (MIL-STD-1815) are examples. But just because something is military
> grade doesn't mean it is good. Military grade means it is the cheapest
> made while still meeting minimum contract specifications.

The reason Arlen (Wally) is mentioning military grade software is
because he desperately wants to deflect from the original point which is
that Apple deploys complex system and app software to hundreds of
millions of heterogeneous devices regularly, where it is not uncommon
for bugs that affect numerous devices (albeit a relatively small number
of the total deployment base) to be found after release. Arlen and
other regular trolls in the Apple newsgroups repeatedly claim that the
fact that bugs exist in Apple software supposedly means "Apple never
tests their software" (yes, that's a direct quote), which is an
idiotic and baseless claim and completely ignores that Apple's
software teams, like many other large software teams, hold and manage
bug databases and go through traditional alpha and beta testing
phases, including public betas. They claim to know all about software
development, but turn around and claim bugs shouldn't exist. And this
says way more about them than Apple.

--
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-01, candycanearter07 <no@thanks.net> wrote:
> On 10/1/23 14:09, Wally J wrote:
>> It's _you_ who hasn't ever worked with software as complicated as the
>> military grade stuff both badgolferman and I worked on for decades.
>
> You've coded operating systems?? That's awesome!

In his (and your) fevered dreams.

--
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-01, Frankie <frankie@nospam.usa> wrote:
> On 1/10/2023, Alan Browne wrote:
>
>>>> These come at the expense of performance.
>>>
>>> The only way Apple can reduce overheating is at the expense of performance.
>>
>> Since the fix is bug fixes in iOS and some apps, would you care to
>> elaborate?
>
> The only way Apple can lower the heat output is to lower performance.

Wrong. It is quite typical for bugs to cause excessive resource usage
which lowers performance, and fixing those bugs results in an increase
in performance as resources are then free to be used more efficiently.
Your ignorance is on full display.

--
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-01, Alan Browne <bitbucket@blackhole.com> wrote:
> On 2023-10-01 17:18, Frankie wrote:
>> On 1/10/2023, Alan Browne wrote:
>>
>>>>> These come at the expense of performance.
>>>>
>>>> The only way Apple can reduce overheating is at the expense of
>>>> performance.
>>>
>>> Since the fix is bug fixes in iOS and some apps, would you care to
>>> elaborate?
>>
>> The only way Apple can lower the heat output is to lower performance.
>
> Not at all. There are many ways you can make errors that cause CPU
> use to rise w/o doing any useful work.

Any software developer who has even just a basic grasp of the profession
knows this. That tells you all you need to know about these dimwit
trolls.

--
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-01, candycanearter07 <no@thanks.net> wrote:
> On 10/1/23 17:25, Alan wrote:
>> There is a difference between not finding a particular issue in
>> particular circumstances and "forget[ting]" to test.
>>
>> Agreed?
>
> If so many people have this issue then it would've come up in testing.

Oh, it's "so many", huh? Go ahead and tell us, oh wise one, what
percentage of the 1+ billion active iPhone users have this issue. 🤡

--
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-01, Alan Browne <bitbucket@blackhole.com> wrote:
> On 2023-10-01 15:59, Frankie wrote:
>> On 1/10/2023, sms wrote:
>>
>>> These come at the expense of performance.
>>
>> The only way Apple can reduce overheating is at the expense of performance.
>
> Since the fix is bug fixes in iOS and some apps, would you care to
> elaborate?

"eAsY: ApPlE iS gOiNg To ThRoTlLe IpHoNeS aGaIn! iT'S tHrOtTlEgAtE 2 ElEcTrIc
BuGaLoO!" #IAmVerySmart! 🤡

--
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 1/10/2023, Alan Browne wrote:

>> The only way Apple can lower the heat output is to lower performance.
>
> Not at all.

You believe in miracles.
You don't remember the pre-and-post benchmarks with iOS 10.2 it seems.

> What it means is after the bug fix is that the benchmarks will be pretty
> much identical.

Apple will greatly chop performance as it was with the iOS 10.2 "fixes."
Apple "fixed" that problem the same way Apple's going to "fix" this one.

>> Apple sold an inherently untested product which turned out to be defective.
>> The benchmark results are on that defective product.
>
> In any new product and OS release, the chances of bugs is pretty high no
> matter how much testing was done. These are consumer appliances and
> there are too many undetermined (undeterminable) cases to test them all.

It's obvious that Apple only tested for overheating after it blew up.
Same as when the battery issue came up. It couldn't have been tested.

>> It's fast. But too hot.
>
> See above. Threads can be very fast and very unproductive. Fix that
> and life goes on.

Maybe you don't remember how Apple handled a similar issue in the past.
What happened in the past, is what's going to happen in the future.

Nobody should buy oveheating iPhones until we see all new benchmarks.

On 2/10/2023, Jolly Roger wrote:

>> The only way Apple can lower the heat output is to lower performance.
>
> Wrong. It is quite typical for bugs to cause excessive resource usage
> which lowers performance, and fixing those bugs results in an increase
> in performance as resources are then free to be used more efficiently.

Maybe you don't remember how Apple "fixed" the problem the last time Apple
had to go back and test their iPhone under real world use conditions.

Apple "fixed" that by throttling to about a quarter of the speed in some
cases, half in others, three quarters in others, but always throttled.

The iPhone never speeds up after Apple has to come up with "the fix."
There is no chance that the overheating iPhones will not be slowed down.

As a result of the inevitable slowdown that will happen because Apple
didn't test these overheating iPhones, all current benchmarks are wrong.

Apple should put a moratorium on sales of the overheating iPhones until the
"fixes" are implemented & new benchmarks are produced after the slowdown.

On Mon, 2 Oct 2023 12:54:57 +1300, Your Name wrote:
>> At the very least, it should warn the user if a program is using a lot.
>
> At the very least the user should have enough brains not to use utter
> crap "Social Media" apps like Instagram. :-p

This idea from Your Name is great as it will instantly solve all of Apple's
overheating iPhone 15 problems while still allowing sales to proceed.

Apple should instantly remove TikTok, Instagram, Facebook, WhatsApp &
Telegram from the App Store (and Apple should remove those installed).

That way Apple doesn't have to do anything else to fix the overheating
phones. Well, there is the problems of indexing and iOS 17 bugs too.

For that, Apple should turn off indexing (what does it do anyway?).
And Apple should allow the overheating iPhones to backport to iOS 16.

Problem solved thanks to Your Name!

On Mon, 2 Oct 2023 11:33:26 +0800, Patrick wrote:

>> At the very least the user should have enough brains not to use utter
>> crap "Social Media" apps like Instagram. :-p
>
> This idea from Your Name is great as it will instantly solve all of Apple's
> overheating iPhone 15 problems while still allowing sales to proceed.
>
> Apple should instantly remove TikTok, Instagram, Facebook, WhatsApp &
> Telegram from the App Store (and Apple should remove those installed).
>
> That way Apple doesn't have to do anything else to fix the overheating
> phones. Well, there is the problems of indexing and iOS 17 bugs too.
>
> For that, Apple should turn off indexing (what does it do anyway?).
> And Apple should allow the overheating iPhones to backport to iOS 16.
>
> Problem solved thanks to Your Name!

Good idea. Apple also needs to remove Uber and Asphalt 9 Legends games.
And Apple has to figure out how to turn off charging the iPhone 15 too.

As a side note, Apple has made the unusual admission that their iPhone may
feel slightly warmer but if you stop holding it - you won't feel it at all.

Apple suggests you lay the phone on a flat fire-proof surface and that you
interact with it remotely - they even sell a ten-foot long iStick for that.