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.

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

You should look at the CVE list that's fixed every month. Surely you agree it's important to have those exploits patched, especially since baddies can reverse engineer the patches to find the original exploits?

Yes, but they can only be analyzed, patched and distributed "After" the attack is known.

A zero day attack is where there have been zero days since the attack mechanism is discovered(by the victim, not the attacker obviously), there is no after. There is no time for a fix to be developed. When you get hit one day after the attack vector is known that would be a one day attack. if you get a fix one day after the attack that would be a one day patch. If the vulnerability gets discovered and patched before the attack occurs, then there is no zero day attack. only multi day ones on people who did not get or apply the patch.

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.

Ah yes, everyone knows that a firewall is the ultimate defense against malware and software vulnerabilities. I'll see your firewall and raise you one web browser.

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.

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

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.

the hardware is made by asus, asus signs with their key backed by a trusted company.

asus gives out keys to sign bios firmware, now aliexpress can not only counterfeit, but provide tampered hardware.

you can enroll your own secure boot keys so that's not really relevant.

Secureboot was being used as an example to illustrate the issue with your claim that a user controlling the keys must necessarily undermine security.

I'll grant that if the user is given control then compromise within the supply chain does become possible. However the same hypothetical malicious aliexpress vendor could also enroll a custom secure boot key, install "definitely totally legit windows", and unless the user inspects he might well never realize the deception. Or the supply chain could embed a keylogger. Or ...

you don't have to trust software, but you have to trust your firmware and hardware.

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

Exactly - the FTDI drivers refusing to work would have been reasonable and emitting a log or error message that my device was counterfeit would have actually been helpful. Instead, they vandalized end user equipment by permanently bricking the devices which is arguably illegal.

I am not nearly sophisticated enough as an end user to spot a counterfeit FTDI usb-to-serial device so I am not going to risk buying that brand and end up with their drivers intentionally bricking the device.

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.

No discussion of these instructions on the 386 would be complete without mentioning that early revisions had a bug in the 32-bit multiply: https://retrocomputing.stackexchange.com/questions/17803/int...

I wonder if anyone outside of Intel has discovered the actual bug in the circuitry yet.

Yes, one can only hope Ken Shirriff eventually happens to come across one of those models, but I guess they are probably very rare these days.

Besides the multiplication, the 386 had quite a number of teething problems[1], including occasionally broken addressing modes, unrecoverable exceptions, virtual address resolution bugs around the 2G mark, etc...

A while ago, there was also an article posted here that analyzed the inner workings of the Windows/386 loader[2]. Interestingly, Windows simply checks a pair of instruction (XBTS/IBTS) that early 386 steppings had, but was later removed, raising an invalid opcode exception instead.

Raymond Chen also wrote a blog post describing a few workarounds that Windows 95 had implemented[3].

[1] https://www.pcjs.org/documents/manuals/intel/80386/

[2] https://virtuallyfun.com/2025/09/06/unauthorized-windows-386...

[3] https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11...

From what I've read, the 386 multiplication bug was a semi-analog problem, so the fix was probably making a transistor larger. As a result, it would probably be hard to find the fix on the die and wouldn't be as interesting as, say, the Pentium division bug.

This reminds me of a problem from undergrad computer architecture: how can you validate the multiplier without checking all possible N squared inputs? (Which would take forever.)

I read later in a TI DRAM report about which bit pairs to exercise, based on proximity in silicon layout, to verify the part. I suppose something like that to stress-test the ALU.

Are you referring to 2M/2MGUI? That didn't change the track spacing (which is fixed) but used bigger sector sizes (similar to how HDDs went from 512B to 4K physical sectors):

https://retrocomputing.stackexchange.com/questions/27412/how...

(Big fuckings to Wikipedia for erasing history, and kudos to archive.org for preserving it: https://web.archive.org/web/20241203124243/https://en.wikipe... )

No they definitely did more tracks, but it seems to be a smaller multiplier than I recalled.

https://retrocomputing.stackexchange.com/questions/12768/wha...

2-5% more tracks, 12.5% more sectors.

The track spacing didn't change, but yes, many if not all floppy drives could step the head slightly past the officially supported number of tracks.

Not that poster but I can also tell the difference in sound between filesystems, likely due to how they store their metadata and the resulting seek patterns. This is my subjective experience:

Linux ext* series - mostly silent, but even periods of high disk usage tend to be on the quieter side - probably due to lots of caching

MacOS - continuous, low-pitched "gritty" sound

Windows FAT - periods of silence punctuated by occasional intermittent groans

Windows NTFS - low rhythmic grunting, more continuous than FAT

Windows 9x - rather quiet, although periods of heavy activity can produce quite high-pitched seeking sounds