aboringusername (u/aboringusername)

aboringusername commented on Ubuntu LTS releases to 15 years with Legacy add-on canonical.com/blog/canoni... · Posted by u/taubek

JackSlateur · 21 days ago

The LTS, long support version and stuff are all confessions of a technical and organisational failures

If you are not able to upgrade your stuff every 2 to 3 years, then you will not be able to upgrade your stuff after 5, 10 or 15 years. After so long time, that untouched pill of cruft will be considered as legacy, built by people gone long ago. It will be a massive project, an entire rebuild/refactor/migration of whatever you have.

"If you do not know how to do planned maintenance, then you will learn with incidents"

aboringusername · 21 days ago

I'm not sure why there's a need to update anything every 2-3 years. In fact, the pace of change becomes exhausting in itself. In my day-to-day life, things are mostly well designed systems and processes; there's a stable code of practice when driving cars, going to the shops, picking up the shopping, paying for the items and then storing them.

What part of that process needs to change every 2-3 years? Because some 'angel investor' says we need growth which means pushing updates to make it appear like you're doing something?

old.reddit has worked the same for the last 10 years now, new.reddit is absolutely awful. That's what 2-3 years of 'change' gets you.

In fact, this website itself remains largely the same. Why change for the sake of it?

aboringusername commented on McDonald's is losing its low-income customers latimes.com/business/stor... · Posted by u/PaulHoule

jrm4 · 23 days ago

It's very odd there are few comments in the realm of, "Maybe McDonald's has grown to be bad at 'fast-fooding.'"

aboringusername · 23 days ago

Agreed. Food now is made to order, rather than being ready and waiting (likely to reduce stock waste). Last time I went there was hardly a queue, wasn't rush-hour (was quite dead actually, few staff, fewer customers).

Food still took 15 minutes, fries were cold, the main meal was nice but was overall disappointing for the eye-watering cost compared to days gone by.

And a few guys collecting for delivery which has split their focus from in-resturant customers.

Can see why people have moved on.

aboringusername commented on McDonald's is losing its low-income customers latimes.com/business/stor... · Posted by u/PaulHoule

aboringusername · 23 days ago

This is a trend that's probably going to continue and widen the rich-poor divide. Take airlines, there's only so many seats they can offer day to day, and with planes retiring from service and new planes slow to be delivered the inequality will only increase, and the market will shift to more affluential customers.

The likes of McDonald's will need to understand who their new customer base is quite carefully and market around that if they are to stay relevant. Sadly their products to me are garbage now; slow service, cold fries, awful oil. Obviously they've had to adapt but it's just expensive slop.

And in the UK they have had scandals around sexual harassment, which hasn't helped their image/branding.

aboringusername commented on Android 16 QPR1 is being pushed to the Android Open Source Project grapheneos.social/@Graphe... · Posted by u/uneven9434

0zymandiass · a month ago

You've explicitly quoted that source releases are not relevant:

> or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider

They have not released the source code, but they have released an update of their operating system on their reference Pixel hardware.

Therefore, all devices must update within 4 months of that Pixel release, regardless of source drops, per this law

aboringusername · a month ago

I would argue QPR updates are functionality and subject to the 6 month test.

I would also argue a closed source release in August 2025 would start the first 6 month timer (February 2026) and the source code release to trigger another timer (if they differed in any way between the closed source release).

A lot of this law is abstract and only if the EU challenges Google's approach would it be decided how it's meant to be applied in reality.

aboringusername commented on Android 16 QPR1 is being pushed to the Android Open Source Project grapheneos.social/@Graphe... · Posted by u/uneven9434

codethief · a month ago

Doesn't the embargo concern the source code of the patches (and detailed information about the CVEs), not the release of the patched binaries?

Either way, I don't understand what point you're trying to make. Even after reading your other comments here in this subtree, I don't see anything in the regulation you linked that would have delayed the source code release of Android 16 QPR1, given that the QPR1 binaries had already been released.

aboringusername · a month ago

It's a rather intriguing concept, because it can be the case that the binaries Google released in QPR1 and their source code are different in some way. OEMs must ship QPR1 as Google released publicly within 6 months.

If this open-source release was to contain new patches, they must now ship these changes within 6 months. The Pixel OS release counts as the first 6 month timer. The source code release, by definition, now counts as the 2nd timer.

I expect the closed source binaries and public source code to be the same, but that may not always be the case. So OEMs are expected to at least in 6 months ship an update with the open-source code.

aboringusername commented on Android 16 QPR1 is being pushed to the Android Open Source Project grapheneos.social/@Graphe... · Posted by u/uneven9434

fph · a month ago

> This EU law has made security far worse.

Stop blaming the EU. They didn't make security worse. It's Google and the other manufacturers who decided to respond to this law by using a loophole that made security far worse.

aboringusername · a month ago

Before the EU law, Android would release monthly bulletins, and patches would take about a month before being released on Pixel devices, once known as 'best in class' security. GrapheneOS have themselves admitted this has changed from 1 month to 4. This has been done to comply with this new EU law.

Now, we have patches already for March 2026 in November 2025. Once the March 2025 patches are shipped by Google, OEMs have 4 months for all OEMs to ship it (deadline being July 2026).

Consider this scenario:

Patch for bug lands January 2026. Google decides to either release a Pixel OS update or release the source code in 8 months time containing this patch for whatever reason. Then a 4 month timer starts for all OEMs to ship that patch. Meaning a patch that has existed from January 2026 can now be shipped by January 2027 under this system and fully comply with the law. This patch may be under active exploit as OEMs have leaked it which again, GrapheneOS have admitted is happening.

Previously, patches would be landing within the month. All google must do is ensure this patch is not included in any pixel OS update or public source code release.

Yes, Google is responsible, but when the EU touts laws as fining 4% of global turnover (in the case of GDPR), then they are going to be taken seriously, which means OEMs demanding Google not release the update for Pixel/source code until they are ready and use this loophole as they are doing.

The loser is ultimately the end user who has a weaker more exploitable device for months.

aboringusername commented on Android 16 QPR1 is being pushed to the Android Open Source Project grapheneos.social/@Graphe... · Posted by u/uneven9434

codethief · a month ago

> 2: Every OEM would be required to release those same patches 4 months to the day GrapheneOS releases them.

I don't think that's true since the regulation you linked says:

> (c) security updates or corrective updates mentioned under point (a) need to be available to the user at the latest 4 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;

(emphasis mine)

GrapheneOS is not the OS provider in this context, Google is.

aboringusername · a month ago

You're not reading the interpretation correctly:

> at the latest 4 months after the public release of the source code of an update of the underlying operating system

So if somebody reverse engineers the patch, or releases the patch under embargo (which the OEMs would have the source code) that would count as a 'public release'. So GrapheneOS can ship closed source patches as you are right, they are not the provider. If GrapheneOS released the source code they are getting from their OEM then it would count as a 'public release of the source code'.

A patch in itself can be considered an 'update of the underlying operating system' and therefore the moment it becomes public it needs to be patched by all OEMs within 4 months.

GrapheneOS have themselves said that if somebody did reverse engineer the closed source blobs and posted them publicly they could then ship the patches openly at that point but not until.

It must be stated a lot of the wording of this clause and interperetation of what is/is not considered 'publicly releasing source code' is up for debate/courts to settle.

aboringusername commented on Android 16 QPR1 is being pushed to the Android Open Source Project grapheneos.social/@Graphe... · Posted by u/uneven9434

xzjis · a month ago

This has absolutely nothing to do with that law, and even Google doesn't dare use it as an excuse for its behavior (as they did with GDPR by deliberately creating user friction that the European regulation did not require, and even partially forbids).

In reality, it's a purely political decision to curb the development of third-party ROMs, because the AOSP source code exists with all the merges and is distributed to vendors (like Samsung). However, it's not necessarily just to target GrapheneOS and LineageOS; it might also be to target the Chinese market, particularly Huawei, which uses this source code for HarmonyOS.

aboringusername · a month ago

It absolutely has everything to do with this new law. For the first time, depending on when Google releases source code, or releases a Pixel update, the timer (4 months for security, 6 months functionality) starts. This has never existed before in Android OS' history that updates are timed (in law) according to Pixel updates/software updates or open source releases. This law also applies to Apple but they will have no problems as they are compliant anyway as they control software/hardware entirely and it's closed source.

This is the entire reason AOSP went private/closed source, and why Google is delaying security patches as per GrapheneOS. The March 2026 patches are already released by GrapheneOS as closed source blobs. They are not allowed to release them as open source by embargo (essentially NDA). Why do you think Pixel hasn't shipped security patches earmarked for March 2026? There are some critical bugs those patches fix, why not release them today, right now or next month? Because if Pixel releases just a single patch, via a Pixel update or posts it on AOSP, the 4 month timer begins for every single OEM with a phone in the EU. By making the patches under embargo, Google gets to control exactly when the timer starts to coordinate with their OEMs. So the slowest OEM gets to control the entirety of Androids security model.

Ask yourself, why doesn't GrapheneOS just release their patches publicly/open source? Why have different 'security releases' with closed source blobs?

Because if they did:

1: They lose their partner OEM access to these patches

2: Every OEM would be required to release those same patches 4 months to the day GrapheneOS releases them.

aboringusername commented on Android 16 QPR1 is being pushed to the Android Open Source Project grapheneos.social/@Graphe... · Posted by u/uneven9434

phoronixrly · a month ago

So EU mandates that security updates in either source OR binary form must hit all users in at most 4 months after they are first published, therefore Google started delaying releasing source code and will start delaying it even more?

A more correct expectation would be that now Google will start delaying all security updates (both binary and source) until all their important downstream vendors are able to release in time.

Even that is doubtful, as Google would have to take the reputational damage for an ongoing exploitation of a security issue.

The functional updates though might get slowed down.

aboringusername · a month ago

See my comment [1]. This is already happening with security patches and GrapheneOS has already commented on their socials about the situation.

It's quite bad as security patches used to take around a month, now it's around 4 months and the patches are being leaked to threat actors who can exploit the bugs until the patches are released.

Example: A patch is fixed on September 1st, released under embargo/closed source to all OEMs. Pixel issues the patch in December 1st publicly (either source code/software update), they now have until April 1st (4 months) to release it according to the law. So the patch is 7 months old before it has to be released according to the law.

All the march 2026 updates are done, now, today, and ready/waiting, but they are not released by Pixel/open source. Once that happens the timer will begin.

This EU law has made security far worse.

[1]: https://news.ycombinator.com/item?id=45914692

aboringusername commented on Android 16 QPR1 is being pushed to the Android Open Source Project grapheneos.social/@Graphe... · Posted by u/uneven9434

codethief · a month ago

> certain commitments they need to make depending on when the source code is released

…or when OS updates are released, see Annex II B 1.2 (6) (c) and (d) ("Smartphones" > "Design for reliability" > "Operating system updates")

So given that the updates were already released months ago, the release of the source code is irrelevant.

aboringusername · a month ago

And what does 'released' mean in this context? GrapheneOS has very publicly stated that security patches are under embargo, and they already have patches for the March 2026 release. See [1]:

> 2025110800: All of the Android 16 security patches from the current December 2025, January 2026, February 2026 and March 2026 Android Security Bulletins are included in the 2025110801 security preview release. List of additional fixed CVEs:

So, have they been released? No. So the clock hasn't started ticking yet. This EU law made security worse for everyone as patches that are done today are not released for 4+ months.

Note: These are CLOSED source blobs GrapheneOS is shipping. If they were open source, the 4 months clock would trigger immediately but they are not allowed to do this themselves as they get the patches from an OEM partner. GrapheneOS shipping these CLOSED source blobs, that Google has NOT released does not trigger the timer.

I do accept that QPR1 was 'released' by Google on Pixel months ago, and therefore the timer started, however, Google will likely pick and chose what is best for OS updates/security patches. It explains why AOSP is now private/closed source and embargos are being used to get around the laws requirements.

[1]: https://grapheneos.org/releases#2025110800

From the EU law:

> (c) security updates or corrective updates mentioned under point (a) need to be available to the user at the latest 4 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;

> (d) functionality updates mentioned under point (a) need to be available to the user at the latest 6 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;