If the manufacturer is ill-intentioned, of course the switch will be in essence fake.

A well intentioned manufacturer can make the switch working and safe. For such implementation, there won't be "OS flag" about the microphone being on or off, because to protect against privacy bypass by hackers, the OS can't interfere with the switch. The OS can only read the camera and microphone muted output, and guess the switch is probably turned off. The switch is also inaccessible from the usual TV remote, for maximum protection.

Those who don't care privacy will keep the switch always on, while those who care will keep the switch always off. Everyone can be happy.

You can't recover anything if the muted output is electronically come from a different set of signal lines.

A TV can be full of useful features without camera and microphone. "Voice control" and "gesture control" are totally unnecessary "smart" features that are in fact dumb.

To cater with those who really want those dumb features, put camera and microphone under guard of physical on-off switch. When the switch is off, the camera and microphone output shall be blank and the OS shall see and hear black and silence.

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