It is always about "how about drift can we tolerate before we adjust the clock".

If the problem of negative leap second is we would have to rush out new code, we can define the leap second scheme to tolerate up to 2 seconds, 3 seconds or even 5 seconds before we have to apply the negative leap second. Then there will be sufficient time to write the new code, meanwhile not *too much* time such that people get lazy and delay the necessary work.

They can announce a elimination of negative leap second, without removing the leap second scheme altogether.

"Hundreds or even thousands of years to figure out" is an illusion. Software and hardware fix budget and planning won't be granted until the situation is close to deadline. Also, currently we pretend leap second doesn't exist in UNIX timestamp and a lot of other internal timestamp format in filesystems. We can't pretend the same when leap hour comes.

If your worry is about how to handle negative leap second, we can explicitly eliminate negative leap second but keep the existence of positive leap second. In long term the Earth is not going to rotate faster and faster. Speed ups are temporary.

Standardizing a leap smear scheme is extremely easy, if we compare with the horror of implementing a leap hour solution. I am suspicious those politicians support leap hour because they wrongly imagine leap hour implementation as something as simple as DST implementation.

Leap second is far better than leap hour. Google invented leap smear for the leap second because leap smear is subtle enough outside science usage. But you can't do that for leap hour. If you think software system can't cope with leap second, it will be far more difficult for them to cope with leap hour. Those politicians confuse DST vs leap hour and wrongly assume leap hour will be as easy to handle as DST. Or they think human civilization is going to collapse completely before we need leap hour?

Another nice thing of leap second is, outside internet connected devices or scientific devices, clocks and watches are inaccurate enough such that the existence of leap second doesn't matter to them. They can't maintain accuracy to within 1 second per year anyway. Leap hour forces everyone to face it and handle it explicitly.

"Stay on Summer Time permanently" should not even exist as an option. If your town want the clock to be 1 hour faster permanently, you can put your town into an earlier timezone.

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.