While that seems like a convincing explanation, 750Hz is a rather odd value to use for a timer, and more importantly the overflow would be at 66d6h43m43s instead of the reported ~66d12h.

It is indeed the explanation: https://github.com/NVIDIA/open-gpu-kernel-modules/pull/1014

66 days 12 hours would put it at 747.5 Hz. A different report had 66 days 10 hours 16 minutes which works out to 748 Hz.

Maybe the clock was just feeling a little sluggish? /s

You mean number of seconds, but yes, I think everyone looking at this would be converting units to see if there was a particular boundary being met.

There's a HUGE difference between "you can use HTML" and "JS all the things, because we can".

Windows 98 used webpages as core components for Explorer. Literally browsing your files involved J(ava)Script… in 1998.

"Active desktop"? Most people turned that off, and the explorer was pure native code otherwise.

Even without MS' support it'll still work fine.

In fact, it's arguably better that way.

The old saying about known unknowns vs. unknown unknowns comes to mind.

As someone mentioned upthread, that's fine until some software you rely upon starts using something not present on older versions. It's one of the points that I keep in mind with most "what OS?" discussions, the OS by itself isn't really that useful but what it lets you do is. When win7 +3 year extended support ended that was the time chromium framework dropped support, and when projects using it updated then they would also need to drop win7 support (or "your mileage may vary" territory). I expect 2028 onwards may see another gradual win10 migration wave.

The support you're paying for is security updates against 0-day attacks. Once you stop receiving those then your machine becomes open season for botnets

By definition no support protects you from a zero day attack, A one day attack? sure if the supporting org is on their toes. Most of the time it will be weeks to months. if it is patched at all.

That is pure FUD. Machines behind a firewall are not going to be affected at all.

I’m not so sure if you are using a web browser. Even the best enterprise firewall with SSL decryption and the best whizz bang features probably wouldn’t stop some novel zero day RCE. WannaCry was so bad that even WinXP and Server 2000/2003 got updates.

As long as you don’t run that one file.

Microsoft security patches doesn’t protect you from doing that. Unsupported Win 10 behind firewall is perfectly fine, as long as you use an updated browser

Even that won't last forever. Notably, Edge is only guaranteeing updates until October 2028 [1], coinciding with the end of Windows 10's 3-year ESU period. Previously, Chromium ended support for Windows 7 at the end of its ESU period (which was also the end of support for Windows 8.1) [2]. However, Firefox continues to support Windows 7/8.1 by providing security updates for an older ESR version of Firefox 115; they appear to be re-evaluating whether to continue support every 6 months, currently set to end in March 2026.

[1]: https://learn.microsoft.com/en-us/deployedge/microsoft-edge-...

[2]: https://support.google.com/chrome/thread/185534985/sunsettin...

[3]: https://whattrainisitnow.com/release/?version=esr

I have patched Firefox 115 to run on XP, so no doubt it would be much easier to continue doing it for something as new as Win10.

The Indian outsourcing long predated Nadella. Now it's outsourcing to AI.

I think it's an overflow of a scaled counter.

Also, who else immediately noticed the AI-generated comment?

I don't want Boot Guard or any of that DRM crap. I want freedom.

I want to make a persistent implant/malware that survives OS reinstalls.

Look up Absolute Computrace Persistence. It's there by default in a lot of BIOS images, but won't survive a BIOS reflash with an image that has the module stripped out (unless you have the "security" of Boot Guard, which will effectively make this malware mandatory!)

I’m more interested in demonstrating how important hardware root of trust is.

You mean more interested in toeing the line of corporate authoritarianism.

Well, this project is literally about me circumventing/removing Boot Guard so I don’t know how it’s corporate authoritarianism. I’m literally getting rid of it. In doing so I get complete control of the BIOS/firmware down to the reset vector. I can disable ME. To me, that’s ultimate freedom.

As a power user, do I want boot guard on my personal PC? Honestly, no. And we’re in luck because a huge amount of consumer motherboards have a Boot Guard profile so insecure it’s basically disabled. But do I want our laptops at work to have it, or the server I have at a colocation facility to have it? Yes I do. Because I don’t want my server to have a bootkit installed by someone with an SPI flasher. I don’t want my HR rep getting hidden, persistent malware because they ran an exe disguised as a pdf. It’s valuable in some contexts.

I want an equivalent of boot guard that I hold the keys to. Presented only with a binary choice certainly having boot guard is better than not having it if physical device security is in question. But that ought to be a false dichotomy. Regulation has failed us here.

that defeats the point, having the "keys" allows malicious actors to perform the same kind of attacks... trust is protected by trusted companies...

certificate companies sell trust, not certificates.

Me managing my own (for example) secure boot keys does not inherently enable malicious actors. Obviously unauthorized access to the keys is an attack vector that whoever holds them needs to account for. Obviously it's not risk free. There's always the potential that a user could mismanage his keys.

There's absolutely no excuse for hardware vendors not to provide end users the choice.

> trust is protected by trusted companies...

The less control of and visibility into their product you have the less trustworthy they are.

Some days you’re the anarchist, some days you’re the corporate authority. :D

> You mean more interested in toeing the line of corporate authoritarianism.

That’s not what I got from their post. After all, they’re putting in some effort to hardware backdoor their motherboard, physically removing BootGuard. I read it as “if your hardware is rooted then your software is, no matter what you do.”

After they infamously started going after clones, anything branded FTDI is automatically suspicious.

USB-serial adapters are not particularly special. Dozens of other manufacturers make them.

This was a huge own-goal for their brand image.

If I buy a FTDI based adapter, it might brick, and I lack the detection skill or supply chain control to be sure that it won't happen.

If I buy a CH340 or PLwhatever based adapter, that doesn't enter the calculus.

Unless I had some explicit "only FTDI can possibly do it" need, I'm going elsewhere.

It sounds like his phone lines were already cat5, which is not surprisingly capable of 1Gbps.

However, I wonder why it seems G.hn is only available in the form of adapters, and not as e.g. a PCIe NIC.

Then they would need to deal with drivers.

Yeah the era of non-Ethernet/Wi-Fi NICs died off decades ago with the last ADSL cards. Nowadays I'm not sure if OSes even support creating drivers for anything non-Ethernet (especially where to provide the config UI for your non-standard protocol).

What I've seen done recently to work around this is to combine your custom chip with a standard Ethernet NIC on the same board. The computer just sees an (off-the-shelf) NIC that's always connected, and all configuration happens via IP by browsing to a specific private IP (this kinda insists on NAT though).

Linux would support it for sure. It even still has support for several old NICs (it was only the other day I saw a news item about some old protocol from the early 90s finally being removed). But I can imagine no one wants to develop a new such driver.

And if you want to sell to consumers you need Windows and Mac support, and then it easier to just adapt to existing interfaces.

You could have a regular single-chip Ethernet NIC on the same card.

Even simpler, you can do something like this to have length-delimited AND null-terminated strings (written from memory, no guarantees of correctness etc.):

    char *lenstrdup(char *s) {
       int n = strlen(s);
       char *p = malloc(n + sizeof(int) + 1);
       if(p) {
          strcpy(p + sizeof(int), s);
          *(int*)p = n;
          p += sizeof(int);
       }
       return p;
    }

    void lenstrfree(char *s) {
        free(s-sizeof(int));
    }

One of the advantages to the pointer + length approach is free substrings. This inline approach doesn't allow that.

The ability to slice substrings results in a massive speed increase for string handling.