That's incorrect. Windows LTSC rights are included into Windows Enterprise E3 subscription as well as a VL (EA, MPSA etc.) perpetual license. [1]
1. https://learn.microsoft.com/en-us/windows/whats-new/windows-...
16 karma · joined February 22, 2023
1. https://learn.microsoft.com/en-us/windows/whats-new/windows-...
Microsoft isn't that into you either. With Windows 11 you are not a customer, you and your data are the products.
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.
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.
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.
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.
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.
1. https://vimeo.com/801331428 2. https://www.autometer.de/unix4fun/z80pack/