There is no free support, e.g. call center agents for Windows 10 users. As for security vulnerabilities in Windows 10, Microsoft is going to continue fixing them until at least 2032 (probably longer with extended support) anyways, as Windows 10 1809 LTSC end-of-life is 2029 and Windows 10 21H2 IoT LTSC is supported until 2032.
Microsoft isn't that into you either. With Windows 11 you are not a customer, you and your data are the products.
Meh. I'm also a Linux destop user on a second machine. I'll completely switch when Windows 11 becomes a problem for me. Microsoft used to be a OS company, but is now a cloud company that offers Linux on it's cloud services.
Servers don't have Desktop GUI, so there is no way you can run a browser on a real server installation. That's done specifically to limit the attack surface. This applies to almost all Windows Server roles except very few such as ADFS which Microsoft is struggling to migrate for decades. Definitely to the root of all security - AD DC.
If you've elected to create a Frankenstein of a domain controller and a desktop/gaming PC and are using it to browse any websites, all consequences are entirely on you.
Hi! It sounds like you are not a systems engineer! Let me help:
When installing Windows Server, there is a "core" experience and a "desktop" experience option. The former is now the default, but nearly all enterprise software not made by Microsoft (and some that is made by Microsoft) require the latter. Including many tools which expect to run on domain controllers! Some software says it requires the GUI but you can trick into running without if you're clever and adventurous.
No GUI is definitely the future and the way to go when you can, but even the most aggressive environments with avoiding the GUI end up with a mix of both.
Speaking of a gaming PC, Edge on Windows Server is so badly implemented, I have a server that is CPU pegged from a botched install of "Edge Game Mode" a feature for letting you use Edge in an overlay while gaming. I don't think it should have been auto installed on Windows Server, but I guess those engineers at Microsoft making triple my salary know better!
Tell that to all that old .NET Framework and other server code relying on various more or less random Windows features to do their jobs in enterprises.
> As a very senior Intel exec told me at the time, Intel held back on multi-core because their key software partner was extremely nervous about being forced to support a multi-core world.
That's one way to explain it. Alternatively, one might say that FSB-based Netburst servers would not benefit much from multi-core because the architecture (and especially FSB) has hit its limitation. Arguably, Intel had no competitive product on the mass server market until 2006 and Core-based Xeon 5100 introduction. Only enormous market inertia has kept them afloat.
> In the 64-bit server space, which is really what's relevant to this discussion, AMD was pretty much not part of the discussion until Dell (might have been Compaq at the time) and Sun picked them up as a supplier in the fairly late 2000s.
That was one relatively small (servers number-wise) segment of the market. Introduction of Opteron servers and Windows Server 2003 64-bit has created a new segment of mass 64-bit servers which have very quickly taken over entire 32-bit (at that time) mass server market. That was the real market that Intel wanted for themselves with introduction of proprietary Itanium but failed to acquire it because of the compatibility issue. High-end mainframe-adjacent market segment indeed belonged to Itanium for many years after, but that wasn't the goal of Itanium. Intel wanted to be a monopoly on the entire PC&server market with no cross-licensing agreements but failed and had to cross-license AMD64 instead.
> These BBSs were part of the FidoNet7 network, a Russian network of BBSs that used software compatible with FidoNet but independent of its political structure. ... In 1997, a “newsgroup” was established at “fido7.su.hardw.support.arvid”
This is technically incorrect. The BBSes were part of the "official" FidoNet [1] network, Zone 2. Fido7 was mostly post-Soviet (and not just "Russian") project to allow migration from PSTN to InterNet as a carrier. Also many "official" FidoNet nodes had additional InterNet channels which could even prevail traffic-wise over PSTN lines, one couldn't have a purely InterNet-connected FidoNet node without any PSTN presence, as that would violate FidoNet Policy (specifically, adherence to Zone Mail Hour (ZMH) [1]). ZMH was considered a core requirement for a FidoNet node (pretty much everything else was optional) and there was no consensus on dropping this "tradition".
Fido7 project was created with a goal of resolving the issue of ZMH by establishing an additional Zone 7 as an overlay to the existing 6 Zones of FidoNet, that would allow for existence of InterNet-only nodes without modifying Policy for the existing Zones. The project was never accepted as part of the "official" FidoNet structure, but for technological reasons it outlived the "official" FidoNet.
The author is referring to Google mirror of "fido7.su.hardw.support.arvid" "newsgroup". In reality, this was a Fido7-provided mirror of the original "SU.HARDW.SUPPORT.ARVID" ("echomail conference-group" names were traditionally capitalized) where "SU" stands for "Soviet Union". In reality, it was a post-soviet conference-group hosted by backbones of FidoNet Regions that belonged to post-soviet countries. Such mirrors were created by Fido7 project in an effort to promote FidoNet beyond "old school" PSTN-bound community. These newsgroups (with double prefix, such as "fido7.su.") did not belong to Fido7 itself but were forwarded from the "official" FidoNet to Fido7 and then presented as UseNet newsgroups and archived by Google which resulted in confusion that led author to think this was Fido7 content.
From my experience, almost nobody fully understands proper public key distribution practices. Usually, it all ends with "Please find my public key attached to this e-mail." - "Imported. You can log in." No fingerprint check via different means of communication (e.g. over phone) etc.
I can imagine a scenario of an attacker being able to intercept and substitute such e-mail with an identical one that just has the attached public key modified to include the backdoor "command=" modification. There may be numerous other scenarios such as substituting a public key in a shared public key storage/database.
Public keys are often treated as something totally harmless. It's assumed that the worst case scenario is that SSH connection will just fail if a public key was tampered with unless an attacker is also able to intercept and proxy actual SSH connection in real time (which is much more complex and much less feasible).
The attack described should be taken very seriously. Entities that have shared public key repositories may need to review their practices and include an automatic check for "command=" in the public keys uploaded. Of course, proper procedures on SSH server end (such as visually inspecting a key before installing it while confirming the fingerprint over a different medium) should already prevent this attack from succeeding, but they likely rely on additional human intervention which is not always done in real life.
That makes more sense, but then, in any case, you should be transmitting public keys over a medium that is authenticated in some form. Otherwise, an attacker could simple replace the key by theirs.
The advantage of this method is that it works without supervision. If the attacker just replaced the key, they would have to attempt to login in the narrow window between installation and it being replaced because it does not work.
I have actually came up with a similar setup (accidentally with the same typewriter model so I've gratefully used keycode table created by the author of this article). I didn't replace the keyboard though. My chip mod is working in parallel to the existing keyboard. I'm using RP2040 (Raspberry Pi Pico clone) with multiple assembler-programmed PIO state machines doing great job intercepting keyboard signals as well as emulating them in real time.
I've also coupled it with a 1975 vintage IMSAI 8080 computer emulation running Z80pack[2] on a Raspberry Pi 4 with a touchscreen attached.
Here is a short video[1] of my setup running XYBasic.
Microsoft isn't that into you either. With Windows 11 you are not a customer, you and your data are the products.