*What exactly is the size difference between Android/iOS updates?*

nospam wrote:

>> Plus the iOS image is significantly smaller than the Android image for
>> obvious reasons.
>
> conveniently neglecting to mention what they are.

Adult observation... (this post contains information which requires the
reader to comprehend that iOS & Android update completely _differently_).

*What exactly is the size difference between Android/iOS updates?*

It is an interesting question, the answer to which I doubt neither Steve
nor nospam (nor any of the low-IQ ignorant iKooks) own the mental capacity
to comprehend how _differently_ the two operating systems actually update.

To put it succinctly for those who don't understand operating systems...
a. All operating systems _other_ than iOS update in asynchronous layers.
b. Only iOS updates in using the primitively Paleolithic monolith
c. But even so, iOS breaks down that monolith individually for each device.

That means, for example, on _my_ iOS devices (which are rarely updated),
the iOS monolith will be hugely larger than on, oh say, nospam's device,
which he likely updates every single time Apple pushes out a new release.

> is the smaller and more efficient code size of ios listed in your
> 'document'? rhetorical question.

*What exactly is the size difference between Android/iOS updates?*

Given it's obvious that neither nospam nor Steve even _understands_ that
iOS updates differently than _all_ other common consumer operating systems,
I doubt there is a simple answer to the "code size" question as a result.

The whole iOS monolith has to be built if Apple is told about a Webkit flaw
exploited in the wild that requires only a single line of code to fix.

Yet, for any individual user, only that "portion" of the iOS code that
changed between their prior release and this new release, gets updated.

It's not clear that nospam or Steve comprehends what I just explained.

Likewise, for Android, the Google Framework has a switch (on by default),
which seamlessly updates only the one Chrome app which has that update.

Who is to say which of those two "one line" updates is larger or smaller?

>> I suppose Google could limit seamless updates to phones with at least
>> 64GB of storage but there' not a reason to spend a lot of effort on this
>> feature since almost no one really cares about it.
>
> there you go again, when any time android can't do something, 'nobody
> really cares about it' despite evidence to the contrary, yet you're
> happy to mention things that favour android which really do not matter
> at all.

*What exactly is the size difference between Android/iOS updates?*

Unfortunately, nospam, the horribly ugly thing about your personality is
that you own no tenets of common behavior in that every accusation you make
of Steve is actually what you do all the time, far more than Steve does it.

On this, badgolferman recently called you out, where he's one of the few
adults on this newsgroup - so you should have taken heed when he did that.

Your inner personality is so appalling, nospam, so unseemly, that you
always project your own loathsome personal traits onto people like Steve.

>> You do an update and
>> a few minutes later it's done. Splitting up the time between "download"
>> and "install" is not buying you much.
>
> actually, it does, which is one reason why it's split.

*What exactly is the size difference between Android/iOS updates?*

If any adults are on this newsgroup, the question to answer is what are the
size differences given how completely differently the monolithic iOS
updates compared to how Android (and all other common operating systems)
update.

To oversimplify for the least educated people on this ng to grasp...
a. Android updates in _layers_, each of which can be different in size
b. iOS updates monolithically - but - each device update is tailored
for that device - so the size is dependent on device-specific factors.

Having expended appreciable information in the above post, I doubt there is
a single person on the Apple newsgroup who owns the adult mental capacity
to comprehend a single word I said, but whether or not you can comprehend
these facts, one of my goals is to disseminate the truth to everyone.

Whether or not you own the mental capacity to comprehend what I explained.
--
This is posted because I have two goals on this newsgroup, one of which is
to learn and disseminate useful information; information which most people
don't appear to have the basic mental capacity to even begin to comprehend.

Andy Burnelli wrote:

>  *What exactly is the size difference between Android/iOS updates?*
>
> If any adults are on this newsgroup, the question to answer is what are the
> size differences given how completely differently the monolithic iOS
> updates compared to how Android (and all other common operating systems)
> update.

Like so many things, the answer is "it varies".

For phones (e.g. Google Pixels) which use the seamless A/B updates, an
upgrade from version "n-1" to version "n" should be a smaller delta
upgrade, but if it's running "n-2" or earlier, it will be a full image.

See the various mechanisms in the sidebar under "Updates"
<https://source.android.com/docs/core/ota>

Some apply to major e.g. android 11, Android 12, Android 13 upgrades
others apply to monthly fixes, or to driver updates by the phone
manufacturer, or core system library udates.

I wish I had time to poke about in the APEX files, but there are lots of
other things eating my time nowadays.

Andy Burns wrote:

> Like so many things, the answer is "it varies".

Thanks Andy for taking a shot at answering the question, because it's
something that matters for Android and for iOS, but in different ways.

For Android, the current issue is the A/B stuff that you had explained to
me a while ago when I you and I delved into how long the project mainstream
updates occurred on one of your oldest Android devices.

Since I own an excellent memory, I remember you initially questioned my
characterization of "forever" as the length of time the mainstream/treble
updates occurred - where we concluded - at that time - there were _layers_
of updates for Android, some of which have no known stated end of life.

For the iOS users, claiming an arbitrarily small slice of the iOS monolith
is their way of minimizing the negative impact of the all-too-many iOS
updates which are required because every bug requires a whole new release.

Given every iOS bugfix requires a new release stream, what Apple naturally
does is "wait a while" to collect enough bugfixes to make their update
worthwhile...

However... that inherently primitive monolithic '*wait a while*' flaw in
iOS updates is why half of the past years' worth of zero-day holes were
widely reported to be actively exploited.
<https://www.securityweek.com/apple-patches-exploited-ios-vulnerability-in-old-iphones/>

Notice that while Apple is desperate to minimize the size & frequency of
these bugfix releases - their very delay is what allows attackers in.

Meanwhile, Android's layered approach allows Google to update dozens of
core Android 10+ components, as you're well aware, without any delay.

The main question, always though, is how do we even _know_ when Google is
updating our phones, because it's hard to tell since it's done seamlessly.

Can you tell when Google updates your project mainstream components?
I can't.

> For phones (e.g. Google Pixels) which use the seamless A/B updates, an
> upgrade from version "n-1" to version "n" should be a smaller delta
> upgrade, but if it's running "n-2" or earlier, it will be a full image.

On that question of "seamless", since you know about A/B updates (you
explained them to me long ago); how "seamless" are those updates to you?

I only care for the truth - as I don't love Google any more than I love
Apple, so I'm really curious how "noticeable" those A/B updates are for
you.

While I know iOS is nothing even close to seamless (because I have iOS
devices and they're horrid in terms of their impact on the user), I don't
have experience with A/B updates.

How much of an impact is it to an Android pixel user to be updated A/B?
Could it happen without you even noticing it, for example?

Does it take the phone down for a while (like iOS updates always do)?
Please let me know, and no need to sugarcoat it as I only care of truth.

> See the various mechanisms in the sidebar under "Updates"
> <https://source.android.com/docs/core/ota>
>
> Some apply to major e.g. android 11, Android 12, Android 13 upgrades
> others apply to monthly fixes, or to driver updates by the phone
> manufacturer, or core system library udates.
>
> I wish I had time to poke about in the APEX files, but there are lots of
> other things eating my time nowadays.

As for the APEX files, I wish Google did NOT move to that standard, as I
loved that APK files are _portable_ among all phones (at least in my
experience they have been for years).

I just don't have the skills you have in determining what happens during an
update - but I would LOVE to know how "seamless" you find a typical minor
and major update to your Pixels when the A/B system comes into play.

As you know, my Samsung doesn't have A/B updates, so for me, most updates
happen without me knowing it (e.g., if Google Chrome were to be updated).

Some of my updates are noticed because the phone let's me know, such as the
security updates - which they could do without even bothering to tell me.

And yet others (like Android 11 to Android 12) require a full reboot
and a lengthy (about ten minutes) indexing issue, which, in the scheme of
things is nowhere near as horrible as typical iOS updates - but still -
that's ten minutes taken out of our life for something called "indexing".

In summary, can you answer the one salient question about "seamless" A/B
updates in that it would be nice to know how supposedly seamless they are.

On 2/4/2023 12:34 PM, Andy Burns wrote:
> Andy Burnelli wrote:
>
>
>>   *What exactly is the size difference between Android/iOS updates?*
>>
>> If any adults are on this newsgroup, the question to answer is what
>> are the
>> size differences given how completely differently the monolithic iOS
>> updates compared to how Android (and all other common operating systems)
>> update.
>
> Like so many things, the answer is "it varies".

True.

iOS 16.3 is 2.8GB.
Android 13 for the Pixel 7 Pro is 2.18GB

The big difference is that, unless they've recently changed the way iOS
is updated, every time they roll the rev, for just a minor fix, it's a
full update.

For Android, you only do a complete update when it's a new Android
version, for revisions to the installed version, it's not a full update
so it's only a small download. This is likely the reason that Google
hasn't bothered to do "seamless upgrades" they are not requiring
multi-GB downloads very often, so it's no big deal to not have seamless
updates available.

I thought that I read somewhere that Apple was going to switch to doing
minor updates the same way that Android does them, but I can't find that
article.

Also, Apple used to promise four years of updates on phones that they
were still selling, but that's no longer the case. You'll definitely get
at least four years from when the device was launched, but not
necessarily from when the device was sold by Apple (not by a carrier who
often sells older, new devices, that Apple isn't selling direct
anymore), see
<https://www.igeeksblog.com/is-android-beating-apple-at-os-updates/>.

In article <trmnpe$25f7f$1@dont-email.me>, sms
<scharf.steven@geemail.com> wrote:

>
> The big difference is that, unless they've recently changed the way iOS
> is updated, every time they roll the rev, for just a minor fix, it's a
> full update.

very much false.

ios updates are incremental and have been for nearly 15 years.

those who actually have ios devices know this because the download time
per update varies, sometimes very quick to download.

> For Android, you only do a complete update when it's a new Android
> version, for revisions to the installed version, it's not a full update
> so it's only a small download.

for ios too, as well as mac os and other systems.

> This is likely the reason that Google
> hasn't bothered to do "seamless upgrades" they are not requiring
> multi-GB downloads very often, so it's no big deal to not have seamless
> updates available.

there you go again with the 'is likely' weasel words. you don't know
the reasons why google, apple, or any other company does or doesn't do
something unless they publicly state the reason, and even then, it
probably isn't the full story.

> I thought that I read somewhere that Apple was going to switch to doing
> minor updates the same way that Android does them, but I can't find that
> article.

of course you can't find it, because no such article exists. it's just
more of your usual easily debunked bullshit. again, ios updates are
incremental.

> Also, Apple used to promise four years of updates on phones that they
> were still selling, but that's no longer the case.

yes it is still the case, with support *much* longer than 4 years.

the iphone 5s, released in late 2013 (nearly 10 years ago), just got an
update *last* *month*.

nospam <nospam@nospam.invalid> wrote:
> In article <trmnpe$25f7f$1@dont-email.me>, sms
> <scharf.steven@geemail.com> wrote:
>
>>
>> The big difference is that, unless they've recently changed the way iOS
>> is updated, every time they roll the rev, for just a minor fix, it's a
>> full update.
>
> very much false.
>
> ios updates are incremental and have been for nearly 15 years.
>
> those who actually have ios devices know this because the download time
> per update varies, sometimes very quick to download.
>

I’d have to agree with nospam here. Minor versions can take just a few
minutes to download and install.

badgolferman wrote:

> I'd have to agree with nospam here. Minor versions can take just a few
> minutes to download and install.

Hi badgolferman,

I too have iOS devices so I understand where the likely disconnect is.

You have to take into account that neither Steve nor nospam knows what's
different about how iOS and Android update. Steve knows more than nospam
about Android while nospam knows more than Steve about iOS - but both are
ignorant that Android updates in layers and iOS updates as a monolith.

Worse, both have an agenda which isn't necessarily the God's honest truth
(where truth is always _my_ agenda).

What nospam is doing is playing games with Steve's wording because an iOS
update is _always_ complete when it is created, as Apple has to rebuild the
_entire_ primitive monolithic iOS release stream _every_ numerical change.

Yes. Every bugfix change causes a brand new iOS release in its entirety.
No other common operating system is released that way except for iOS.

That is, if Android or Windows needs to update their default browser, they
do NOT need to create an entire new release stream just to fix the browser.

Notice if iOS needs to fix their default browser, they can't release it
without creating an entirely new monolithic iOS release stream for it.

That's _why_ iOS is built as a primitive static monolith, badgolferman.

This method is so primitive that it's _why_ iOS has the _shortest_ support
of all common consumer operating systems, bar none, badgolferman.

There isn't an iKook alive who comprehends what I just said, but I hope you
do, because the monolith is _why_ Apple has so many bug holes so often.

Now, having explained the monolith, what nospam is talking about is
different. What he's saying is that there is a 'diff' that goes on between
that primitive iOS monolith and every single iOS device on the planet!

What happens is each iOS update to each of the billions of iOS devices gets
their own personal diff of the differences between what they have on their
device today and what Apple's latest primitive monolith has changed.

Notice nospam either plays his classic kindergarten games claiming that
this "diff" is the release or, more likely, it's likely nospam has no clue
this is how Apple puts the primitive monolith diff onto each iOS device.

It's hard to tell with nospam since he's so ignorant of the most obvious
things about either Android or iOS and because he's always playing games.

By way of contrast, Android is _not_ released as a primitive monolith.

Android is released in layers, so Steve is perfectly correct in how he
characterized the size of a complete Android versus that of the layers.

In summary, it's difficult to accurate compare sizes (as Andy Burns noted),
simply because the two operating systems release completely differently.

In laymans terms,
a. Android releases as a modern layered operating system, while
b. iOS releases in a primitive static monolithic operating system.

Obviously the monolith only benefits Apple as no other common consumer
operating system releases the way iOS does (which has huge drawbacks).

On 2023-02-04, nospam <nospam@nospam.invalid> wrote:
> In article <trmnpe$25f7f$1@dont-email.me>, sms
><scharf.steven@geemail.com> wrote:
>
>> The big difference is that, unless they've recently changed the way
>> iOS is updated, every time they roll the rev, for just a minor fix,
>> it's a full update.
>
> very much false.
>
> ios updates are incremental and have been for nearly 15 years.
>
> those who actually have ios devices know this because the download
> time per update varies, sometimes very quick to download.

The outright lies these asshole trolls try to push to the Apple
newsgroups are laughably false. Anyone with a couple brain cells to rub
together can see for themselves they are obvious lies. And they just
ignore any corrections people make and continue to blurt them out over
and over again as if they think they are fooling anyone. It's frankly
pathetic, and sad.

--
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-02-05 01:47:12 +0000, Andy Burnelli said:

> What happens is each iOS update to each of the billions of iOS devices gets
> their own personal diff of the differences between what they have on their
> device today and what Apple's latest primitive monolith has changed.

No wonder it takes Apple so long to get a release out the door.

In article <trn222$27f4b$1@dont-email.me>, gtr <xxx@yyy.zzz> wrote:

>
> No wonder it takes Apple so long to get a release out the door.

apple releases updates as quickly as a couple of days, if needed.

On 2/4/2023 4:10 PM, badgolferman wrote:
> nospam <nospam@nospam.invalid> wrote:
>> In article <trmnpe$25f7f$1@dont-email.me>, sms
>> <scharf.steven@geemail.com> wrote:
>>
>>>
>>> The big difference is that, unless they've recently changed the way iOS
>>> is updated, every time they roll the rev, for just a minor fix, it's a
>>> full update.
>>
>> very much false.
>>
>> ios updates are incremental and have been for nearly 15 years.
>>
>> those who actually have ios devices know this because the download time
>> per update varies, sometimes very quick to download.
>>
>
> I’d have to agree with nospam here. Minor versions can take just a few
> minutes to download and install.

The update from 16.2 to 16.3 was 600MB. At 10MB/s or so (100Mb/s) it
would take only 60 seconds. The install is what takes a long time on my
iPhones, but perhaps it's faster on the latest Bionic processor-equipped
phones. 16.0 to 16.3 was much larger, and 15.x to 16.0 larger still. But
it does appear that they've figured out how to not have to update the
entire OS which is good.

On 2023-02-05, gtr <xxx@yyy.zzz> wrote:
> On 2023-02-05 01:47:12 +0000, Andy Burnelli said:
>
>> What happens is each iOS update to each of the billions of iOS
>> devices gets their own personal diff of the differences between what
>> they have on their device today and what Apple's latest primitive
>> monolith has changed.
>
> No wonder it takes Apple so long to get a release out the door.

How long is "so long", according to you?

--
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

Andy Burnelli <nospam@nospam.net> wrote:
> badgolferman wrote:
>
>> I'd have to agree with nospam here. Minor versions can take just a few
>> minutes to download and install.
>
> Hi badgolferman,
>
> I too have iOS devices so I understand where the likely disconnect is.
>
> You have to take into account that neither Steve nor nospam knows what's
> different about how iOS and Android update. Steve knows more than nospam
> about Android while nospam knows more than Steve about iOS - but both are
> ignorant that Android updates in layers and iOS updates as a monolith.
>
> Worse, both have an agenda which isn't necessarily the God's honest truth
> (where truth is always _my_ agenda).
>
> What nospam is doing is playing games with Steve's wording because an iOS
> update is _always_ complete when it is created, as Apple has to rebuild the
> _entire_ primitive monolithic iOS release stream _every_ numerical change.
>
> Yes. Every bugfix change causes a brand new iOS release in its entirety.
> No other common operating system is released that way except for iOS.
>
> That is, if Android or Windows needs to update their default browser, they
> do NOT need to create an entire new release stream just to fix the browser.
>
> Notice if iOS needs to fix their default browser, they can't release it
> without creating an entirely new monolithic iOS release stream for it.
>
> That's _why_ iOS is built as a primitive static monolith, badgolferman.
>
> This method is so primitive that it's _why_ iOS has the _shortest_ support
> of all common consumer operating systems, bar none, badgolferman.
>
> There isn't an iKook alive who comprehends what I just said, but I hope you
> do, because the monolith is _why_ Apple has so many bug holes so often.
>
> Now, having explained the monolith, what nospam is talking about is
> different. What he's saying is that there is a 'diff' that goes on between
> that primitive iOS monolith and every single iOS device on the planet!
>
> What happens is each iOS update to each of the billions of iOS devices gets
> their own personal diff of the differences between what they have on their
> device today and what Apple's latest primitive monolith has changed.
>
> Notice nospam either plays his classic kindergarten games claiming that
> this "diff" is the release or, more likely, it's likely nospam has no clue
> this is how Apple puts the primitive monolith diff onto each iOS device.
>
> It's hard to tell with nospam since he's so ignorant of the most obvious
> things about either Android or iOS and because he's always playing games.
>
> By way of contrast, Android is _not_ released as a primitive monolith.
>
> Android is released in layers, so Steve is perfectly correct in how he
> characterized the size of a complete Android versus that of the layers.
>
> In summary, it's difficult to accurate compare sizes (as Andy Burns noted),
> simply because the two operating systems release completely differently.
>
> In laymans terms,
> a. Android releases as a modern layered operating system, while
> b. iOS releases in a primitive static monolithic operating system.
>
> Obviously the monolith only benefits Apple as no other common consumer
> operating system releases the way iOS does (which has huge drawbacks).
>

As the end user what is the drawback to me? A few minutes or something
else?

On 2023-02-04 20:05, badgolferman wrote:
>> In summary, it's difficult to accurate compare sizes (as Andy Burns noted),
>> simply because the two operating systems release completely differently.
>>
>> In laymans terms,
>> a. Android releases as a modern layered operating system, while
>> b. iOS releases in a primitive static monolithic operating system.
>>
>> Obviously the monolith only benefits Apple as no other common consumer
>> operating system releases the way iOS does (which has huge drawbacks).
>>
> As the end user what is the drawback to me? A few minutes or something
> else?
>

Don't worry about it.

If iOS updates were routinely smaller than Android updates, Arlen would
find some reason that larger was better.

sms wrote:

> But it does appear that they've figured out how to not have
> to update the entire OS which is good.

Hi badgolferman,

Note that no other common consumer operating system releases like iOS does.
This is important information below that you need to know about iOS.

All I care about is the truth - no matter what that truth is.
*iOS 15 users are Exposed. Naked. Vulnerable. Pitifully left to rot.*

Only iOS 16 users are safe - and - even they are exposed, naked, and
vulnerable until Apple times out on their "wait and see" bugfix attitude.

In bringing the truth to the fore, I need to point out that neither Steve
nor any of the iKooks who have responded have shown _any_ comprehension
whatsoever of _how_ Apple supports, builds & releases iOS.

This is important because no other common consumer operating system is
built using the primitive Paleolithic monolithic format that iOS is.

That primitive build mechanism has huge drawbacks, not the least of which
is Apple is forced to constantly release entirely new releases each and
every time a bug shows up if they don't "wait for a while" for more bugs.

Notice what I said because it's _critically important_ to understand that
Apple is forced, by the primitive monolith they designed, to adopt a "wait
and see" attitude for when to release their collection of bug fixes.

Specifically, this primitive monolith _slows down_ the Apple releases, and,
at the same time, paradoxically, it forces Apple to release bugs before
they're truly fixed (which we've seen time and time again with Apple).

This "wait and see" attitude Apple adopts for their primitive monolith is
one of the main reason nearly _half_ of all zero-day bugs on iOS are widely
exploited in the wild well before Apple ever gets around to the release.

Worse, the instant a release moves from one major version to the next, the
old release is _completely dead_ (in terms of complete hotfixes that is).

This means anyone on iOS 15 today is dead in the water in terms of having
all the hotfixes that Apple has made which will definitely affect users.

They're dead. Exposed. Naked. Vulnerable. Pitifully left to rot by Apple.
Mainly due to the primitive monolithic structure Apple employs for iOS.

Note that no other common consumer operating system releases like iOS does.
*It's a key reason why iOS has the _shortest_ support life of phone OSs.*

badgolferman wrote:

> As the end user what is the drawback to me? A few minutes or something
> else?

Hi badgolferman,

Have I ever told a mistruth? Have I ever steered you wrong?
Keep that in mind because what I say below is _why_ you might want to care.

Note that most iKooks, and Steve, are completely ignorant of everything I
say below - but that's only because they have never read the news, nor do
they comprehend how iOS is supported, built, and released.

Clearly none of them understand how a normal (i.e., not iOS) common
consumer operating system is built & supported (e.g., layers).

With that in mind... to faithfully and good heartedly answer your query...

I wouldn't claim that the horrible problems people have habitually
experienced with iOS releases is a big deal overall, just as I wouldn't
claim the lack of A/B releases in non-Pixel Androids is a big deal.

What _is_ a big deal is that the iPhone has the absolute _worst_ record
(for years on end) in terms of zero-day exploits for _all_ smartphones.

Bear in mind Apple has _never_ in its entire history ever found these
zero-day exploits (by definition so that's just a fact); which means Apple
is extremely dependent on other people _telling them_ what holes exist.

Do you care that your iPhone has the worst zero-day record of all phones?

If you don't care that *your iPhone has more zero-day holes* than any other
smartphone, you might _begin_ to care when you find out that nearly _half_
those zero-day exploits were rampant in the wild _before_ Apple had any
idea that you, the supposed valuable customer, was being pwned by hackers.

Do you care that your iPhone is so vulnerable, half have been exploited?

You also may care that *your iPhone has the _shortest_ lifespan* in terms
of support for flagship phones, in that Apple's primitive iOS monolith is
such a burden to support, even for Apple, that Apple dropped iOS 15 hotfix
support like a hot potato. (Note I am well aware Apple made a token fix to
iOS 15, and even further down - but anyone calling that token bugfix a full
hotfix release would be proving how ignorant they are of how iOS is fixed.)

Do you care that your iPhone has the shortest full hotfix support lifespan?

Sure, if you don't care that it takes Apple weeks, and sometimes months to
get around to fixing bugs, then you won't care _how_ Apple builds and
supports its releases.

But the fact iOS is a monolith sets how long it takes Apple to fix bugs.

The longer Apple waits between releases, the more bugs are exploited.
If none of that matters to you, then, sure, there is no drawback to you.

But almost all of that above is due to the primitive monolith that is iOS.
--
This is posted because I have two goals on this newsgroup, one of which is
to learn about & disseminate useful information - which are fact that most
people don't appear to own the mental capacity to even begin to comprehend.

On 2023-02-04 20:29, Andy Burnelli wrote:
> badgolferman wrote:
>
>> As the end user what is the drawback to me? A few minutes or something
>> else?
>
> Hi badgolferman,
>
> Have I ever told a mistruth?  Have I ever steered you wrong?

Do either of those questions answer his?

I'm just going to start snipping everything that doesn't answer his.

Oops! Nothing left!

In article <trn77a$2b46q$1@dont-email.me>, sms
<scharf.steven@geemail.com> wrote:

> >>> The big difference is that, unless they've recently changed the way iOS
> >>> is updated, every time they roll the rev, for just a minor fix, it's a
> >>> full update.
> >>
> >> very much false.
> >>
> >> ios updates are incremental and have been for nearly 15 years.
> >>
> >> those who actually have ios devices know this because the download time
> >> per update varies, sometimes very quick to download.
> >>
> >
> > I¹d have to agree with nospam here. Minor versions can take just a few
> > minutes to download and install.
>
> The update from 16.2 to 16.3 was 600MB.

unless your router logs data usage, you have no way to know that.

a web search (which is what you likely did) is not accurate because the
actual size can vary depending on which device it's for.

not that it matters, because you previously said:

In article <trmnpe$25f7f$1@dont-email.me>, sms
<scharf.steven@geemail.com> wrote:
> iOS 16.3 is 2.8GB.

even assuming 600 mb, it's a lot less than 2.8 gig, which is clear
proof of *incremental* updates and that you were wrong.

> At 10MB/s or so (100Mb/s) it
> would take only 60 seconds. The install is what takes a long time on my
> iPhones, but perhaps it's faster on the latest Bionic processor-equipped
> phones.

plural? you supposedly traded in your previous iphone for a newer one,
versus keeping both.

> 16.0 to 16.3 was much larger, and 15.x to 16.0 larger still.

that's because those are bigger increments.

> But
> it does appear that they've figured out how to not have to update the
> entire OS which is good.

they figured it out a few decades ago for mac os.

In article <trnba8$39eml$1@paganini.bofh.team>, Andy Burnelli
<nospam@nospam.net> wrote:

> Have I ever told a mistruth?

yes. very frequently.

Andy Burnelli <nospam@nospam.net> wrote:
> badgolferman wrote:
>
>> As the end user what is the drawback to me? A few minutes or something
>> else?
>
> Hi badgolferman,
>
> Have I ever told a mistruth? Have I ever steered you wrong?
> Keep that in mind because what I say below is _why_ you might want to care.
>
> Note that most iKooks, and Steve, are completely ignorant of everything I
> say below - but that's only because they have never read the news, nor do
> they comprehend how iOS is supported, built, and released.
>
> Clearly none of them understand how a normal (i.e., not iOS) common
> consumer operating system is built & supported (e.g., layers).
>
> With that in mind... to faithfully and good heartedly answer your query...
>
> I wouldn't claim that the horrible problems people have habitually
> experienced with iOS releases is a big deal overall, just as I wouldn't
> claim the lack of A/B releases in non-Pixel Androids is a big deal.
>
> What _is_ a big deal is that the iPhone has the absolute _worst_ record
> (for years on end) in terms of zero-day exploits for _all_ smartphones.
>
> Bear in mind Apple has _never_ in its entire history ever found these
> zero-day exploits (by definition so that's just a fact); which means Apple
> is extremely dependent on other people _telling them_ what holes exist.
>
> Do you care that your iPhone has the worst zero-day record of all phones?
>
> If you don't care that *your iPhone has more zero-day holes* than any other
> smartphone, you might _begin_ to care when you find out that nearly _half_
> those zero-day exploits were rampant in the wild _before_ Apple had any
> idea that you, the supposed valuable customer, was being pwned by hackers.
>
> Do you care that your iPhone is so vulnerable, half have been exploited?
>
> You also may care that *your iPhone has the _shortest_ lifespan* in terms
> of support for flagship phones, in that Apple's primitive iOS monolith is
> such a burden to support, even for Apple, that Apple dropped iOS 15 hotfix
> support like a hot potato. (Note I am well aware Apple made a token fix to
> iOS 15, and even further down - but anyone calling that token bugfix a full
> hotfix release would be proving how ignorant they are of how iOS is fixed.)
>
> Do you care that your iPhone has the shortest full hotfix support lifespan?
>
> Sure, if you don't care that it takes Apple weeks, and sometimes months to
> get around to fixing bugs, then you won't care _how_ Apple builds and
> supports its releases.
>
> But the fact iOS is a monolith sets how long it takes Apple to fix bugs.
>
> The longer Apple waits between releases, the more bugs are exploited.
> If none of that matters to you, then, sure, there is no drawback to you.
>
> But almost all of that above is due to the primitive monolith that is iOS.

So does Android release these updates faster and directly to the end user
or must they wait for the phone manufacturer to perform their tests before
it gets installed? In other words, is there a real life difference in how
quickly the end user receives a security patch?

badgolferman wrote:

> So does Android release these updates faster and directly to the end user
> or must they wait for the phone manufacturer to perform their tests before
> it gets installed?

Hi badgolferman,

To answer your question, of course Google patches huge portions of the core
systems of Android *WITHOUT the carriers* being involved in that update,
and without needing to get software from the phone manufacturers either.

*It's all done seamlessly over the Internet*, badgolferman.

Haven't you read any of the many discussions we've had on this topic?

Please look up "Project Mainstream" (which changes names periodically).
And also look up "Project Treble" (which is for similar firmware updates).

*Unlike iOS, Android patches most of the operating system asynchronously*
*Over the Internet*

Haven't you been reading the technical news for the past decade or so?

Suffice to say that Android is updated in _layers_ badgolferman, some of
which are updated _forever_ and completely seamlessly badgolferman.
*The user doesn't even realize two dozen modules were updated*

These two dozen core modules, in fact, are _completely_ updated by Google.
*Not the carrier. Not the manufacturer. Google.*
*Seamlessly too!*
*Over the Internet.*

It's been happening since Android 10, badgolferman.
They expanded it in Android 11. Then 12. And then more in Android 13.

We've been discussing this topic for years, badgolferman.
Where have you been? :)

And that's just _one_ of the major Android layers that are quickly updated.

> In other words, is there a real life difference in how
> quickly the end user receives a security patch?

OMG. The "real life difference" is astoundingly fast for Android,
badgolferman, particularly compared to how inexorably slow iOS updates are.

It's now done over the Internet.
Seamlessly.

We've had endless detailed discussions about this on the Android group for
years running badgolferman. You just don't read the news papers, I guess.

The updates are so seamless and so quick that the _only_ way you can tell
is you have to check the versions of dozens upon dozens of core modules.

Ask Andy Burns, for example. He and I spent weeks discussing how to tell
which modules Google has updated. There are many. And it's all seamless.

And that's only _one_ layer of Android that is seamlessly updated, almost
instantly, the moment Google has the bug identified and a fix prepared.

If you don't read the news, you won't understand a word I said above
because I can't update you on a decade of progress in a single post.

Suffice to say I choose my words sagaciously when I term the iOS release
mechanism as a throwback to the Paleolithic Stone Age of smartphone OSs.

It's no wonder the iPhone has more zero day bugs than any smartphone in
history, half of which are exploited long before Apple gets around to
releasing its primitive monolithic static operating system updates.

We've covered this _many times_ on the Apple newsgroups, even.
So it's odd that you don't remember what we've covered many times.

Intelligent people have the innate capacity to comprehend details.

Andy Burnelli wrote:

> I remember you initially questioned my
> characterization of "forever" as the length of time the mainstream/treble
> updates occurred - where we concluded - at that time - there were _layers_
> of updates for Android, some of which have no known stated end of life.

[...]

> The main question, always though, is how do we even _know_ when Google is
> updating our phones, because it's hard to tell since it's done seamlessly.
>
> Can you tell when Google updates your project mainstream components?
> I can't.

I'm glad I read ahead, as that was mainly what I was going to reply above.

I do still own my older Pixel3, it stopped getting "version upgrades" in
october 2021 with android 12, it did receive a "supposedly final" minor
update in january 2022, then another in february 2022, afaik that's the
last update I installed on it, but now it seems there was an even later
update in june 2022 to add VoLTE support.

I expect that june update will be the normal A/B seamless type as that's
what I've always seen Pixels use, I'll see if it gets any APEX style
"component upgrades" newer than last june ... now where did I put the phone?

Am 05.02.23 um 09:20 schrieb Andy Burns:
> I do still own my older Pixel3, it stopped getting "version upgrades" in
> october 2021 with android 12, it did receive a "supposedly final" minor
> update in january 2022, then another in february 2022, afaik that's the
> last update I installed on it, but now it seems there was an even later
> update in june 2022 to add VoLTE support.
>
> I expect that june update will be the normal A/B seamless type as that's
> what I've always seen Pixels use, I'll see if it gets any APEX style
> "component upgrades" newer than last june ... now where did I put the phone?

You must live in a completely different Pixel-world than I do. All
OS-updates are a pain even very small ones. That already started under
my Pixel 4 with Android 11 or 12 roughly two years ago. My Pixel 7 is
not better at all.

What is seamless are app-updates.

--
Gutta cavat lapidem (Ovid)

Joerg Lorenz wrote:

> You must live in a completely different Pixel-world than I do. All
> OS-updates are a pain even very small ones.

Do you mean problems caused by an upgrade, or problems with the upgrade
mechanism?

I had the former where november's update caused my battery life to
plummet and had to live with more frequent charging for a month until
the december update fixed the issue, and improved battery monitoring.

I find the mechanism really is painless, let it download by itself when
one is available, it "preinstalls" into the relevant A/B slot in the
background then it prompts you to reboot to activate the opposite slot,
which takes what, 30 seconds?

Older Nexus updates were not seamless, they only got installed during
the reboot, then the phone spent ages optimising APKs.

If feeling impatient to receive an update, go to
settings/system/systeupdate and force it to check if one is there ...

It does seem to download the "Play System" upgdates in the background,
but never prompts to reboot for them, I have to go
settings/aboutphone/androidversion/playsystem to get it to tell me that
a reboot is required. But I never notice anything earth-shattering from
applying those, though google describe some of them as critical most months.

Am 05.02.23 um 11:35 schrieb Andy Burns:
> Joerg Lorenz wrote:
>
>> You must live in a completely different Pixel-world than I do. All
>> OS-updates are a pain even very small ones.
>
> Do you mean problems caused by an upgrade, or problems with the upgrade
> mechanism?

Everything. The pain is caused by the "optimisation" after extremely
small OS-updates. That can easily take 20 minutes.

--
Gutta cavat lapidem (Ovid)