When you buy alcohol in a shop, the cashier ID check won't form a centralized purchase record database for hackers to exploit. Online age check as of today all eagerly create such database, with your ID tied to all major social platform online speech.

If you read the articles, you will see that the Linux kernel has retired strlcpy() 2 years ago. strlcpy() was introduced into Linux kernel code later than strncpy(), thus get eliminated more easily.

The major issue of strlcpy() is, it needs to check the source string length, then decide whether to do the string copy or not. So in effect the computer needs to parse the source string twice unnecessarily, and introduces a timing gap, making the function not thread safe.

strscpy() is thread safe because it always tries to copy the source string regardless it will truncate or not. Thus a change of content of source string in the middle of strscpy() operation is not going to cause any undefined behaviour. The implementation can be thread safe.

Try the group policy method
https://support.mozilla.org/en...

I am talking about "pure" 32-bit systems, not "x32" the special hybrid of 64-bit and 32-bit.

There are still some old 32 bit devices lurking around in the world, be it running x86, ARM or MIPS.

Sadly the situation is a lot more messy, likely due to some people in charge of the API/ABI seemed to have assumed by the time of Y2038, all 32-bit systems would have been retired.

https://blogs.gentoo.org/mgorn...
https://blogs.gentoo.org/mgorn...
They didn't create a time64_t. They set time_t to be 64-bit if you compile for 64-bit target.

Because of Y2038, "pure" 32-bit systems need to upgrade their time_t to 64-bit too.

You don't need to mess with the clock to achieve those so called advantages. One can just set up 2 timetables, one for summer and one for winter. Then let the clock run the same around the year.

The decision to mess with the clock instead of issuing 2 timetables is an insult to everyone's intelligence. Sadly there are many people too stupid to feel the insult.

Alright I look it up. The latest situation is EU and Japan force Apple to allow "alternative app marketplaces". So it is great if you live there. For others, there isn't any clean way to do so. All those solutions are hacks and tricks, with their own quirks and limits.

Apple doesn't allow sideloading in iOS. Google is adding restrictions to "unverified" sideloading too. https://developers.slashdot.or...

And then you face a lot of banking and/or government stuff that support iOS/Android only. Some guard against rooting or jailbreaking. Some even guard against 3rd party app stores and sideloading.

Using an "app" instead of SMS for 2-factor authentication is legit. But when that "app" dictates what phone you can buy, the situation changes. Ideally, banks and government shall either be regulated to be friendly to smartphone competitors outside Android-iOS duopoly, or Android and iOS be regulated to allow unconstrained sideloading unless an app is known to be malware. In reality, both sides are cooperating together and tighten their grip to commoners.

The issue is as of 2026, too many things are iOS+Android only. This duopoly means that if they decide to ban an app together, your software will be banned from the "smartphone" ecosystem. This is not the case of a normal "brick and mortar store". A normal "brick and mortar store" isn't capable of banning a good from sales worldwide.

To get the old system information corpus, press the "copy" button and paste it into a text editor or anywhere that can type text.

You mean https://github.com/orgs/linuxm... ?

Fortunately Clement Lefebvre didn't go full blown the GNOME style anti-user attitude, and recognized the issue is valid at the end. A damage control from JosephMcc calling it "isn't a bug" and "no plans to change it" in https://github.com/linuxmint/c...

In my proposed system, there is never a record of who bought which age verification card. Only a promise from shops that the cards are always sold to adults, not children. Where is the "they already have your data" come from?

Our society is never capable of stopping an adult buying cigarette then hand off them to underage.

Stop support Nanny State. The exploit you mentioned is a necessary compromise to protect freedom of speech. If banning social platform or restricting social platform feature from underage is *solely* for protecting children, we shouldn't need to care "could we trace which adult break the verification system and let a child watch porn or read/write foul languages". It isn't a crime big enough to worth the time and cost of arrest + prosecution.