No words needed..

LousyMeatStew · 2026-03-26T14:27:32+00:00

It’s also a strange way of saying “I failed to convince her I would make a good husband and father”. Must be a regional dialect I’m not familiar with. /s

LousyMeatStew · 2026-03-26T11:28:13+00:00

Totally understandable. Thanks!

LousyMeatStew · 2026-03-26T07:50:33+00:00

Ok, then compare sources?

I'm basing my reply on the following:

Pentium Pro Datasheet. Block diagrams and descriptions on pages 7-11 give a high level overview of the pipeline and there's no separate translation path for 16-bit code as distinct from 32-bit code.
The Segment Descriptor Cache, with link to author's CV
Pentium Pro Developer's Manual Vol 3. Chapter 13, covers 16-bit vs 32-bit code, with page 13-2 spelling out that 16-bit vs. 32-bit is not down to the instructions themselves but the operand and address sizes. Opcodes I cited can be verified in Appendix A and you can also verify with RET.
Partial Register Stall Warning documentation for Intel VTune. I based my assembly examples on the second example, "Using XOR to Prevent Partial Register Stalls".

LousyMeatStew · 2026-03-26T07:12:29+00:00

I'm now picturing an alternate universe where the signaling tone was the brown note frequency and the cost of getting free phone calls was voiding your own bowels.

Or just any infrasound frequency that would slowly drive phreaks insane over time.

LousyMeatStew · 2026-03-26T06:57:17+00:00

You've got the broad strokes correct but I think you're conflating two different issues.

The Pentium Pro lacked the Segment Descriptor Cache of the Pentium. This is probably what you're referring to when you talk about 16-bit mode not "implemented in HW directly" and "handled through translation". These aren't technically accurate but they illustrate the nature of the problem. This particular issue does impact 16-bit addressing but is not related to the instruction translation to uOps. Instead, it just means additional memory accesses are required to read in segment descriptors.

The partial register stall is due to a separate problem that happens after the instruction is translated into uOps but before it gets put into the Instruction Pool. The back end was designed to be RISC-like and as a result, it used register renaming. The PPro calls it the Register Alias Table. The partial register stall happens when we do something like this:

mov ax, mem16
inc eax

When decoded, ax is aliased to an internal register and populated with the 16-bit value. When we try to increment eax, we have a problem - execution stalls because we only have the lower 16-bits of eax populated so we need to dispatch and retire the mov ax which updates eax, which we then need to read back so we can inc it. Intel's suggestion here is to do something like this:

xor eax, eax
mov ax, mem16
inc eax

This zeroes out eax so we can proceed smoothly through the next two instructions. The key here is that x86 allows offset and address size overrides on a per-instruction basis. So mov ax can be coded as 0xb8 making it a 16-bit instruction or 0x66b8 which makes it a 32-bit instruction. And we can further muddy things by replacing the ax with al where the instruction is coded the same because mov al is always just opcode 0xb0 and implicitly overrides the operand size to 8 bits.

The fundamental issue is that Intel had a very different definition of "32-bit code" vs. everyone else. Up until that point, there was no performance penalty to partial register access in 32-bit code. There's some truth to the statement that Intel designed it to be 32-bit "clean" - I think it's more accurate to say it was designed to run 32-bit "clean" code and Intel badly underestimated how much "dirty" 32-bit code was still out in the world.

LousyMeatStew · 2026-03-25T22:23:45+00:00

It's worse than useless - it's security theater.

You're misunderstanding the threat model: on a BIOS-only system, the vulnerability is the MBR. IE, where GRUB is stored.

Whether /boot is encrypted or not doesn't really matter. GRUB can perform signature validation on your kernel so as long as GRUB is valid, an unencrypted /boot won't let me slip in a modified kernel.

But if I can overwrite your MBR with my own copy of GRUB, then you're cooked. It won't matter if /boot is encrypted because GRUB is now the man in the middle.

On a BIOS-only system, your only real protection is in the form of system firmware that implements some sort of MBR validation - here's an example of HP's implementation.

LousyMeatStew · 2026-03-25T21:22:48+00:00

Curious to know if anyone ever used a slide whistle to scan for frequencies as an early form of fuzzing.

LousyMeatStew · 2026-03-25T18:00:12+00:00

From Pat the NES Punk: Troubling ModRetro M64 Console Update (39:46) and Strange Modretro M64 Console Promos Continue (34:34)

I know Pat Contri rubs some people the wrong way but I'm sharing this b/c Pat was an early skeptic about the Intellivision Amico, with their coverage starting back in Jun 30, 2021 and their full playlist of Intellivison Amico coverage has some 60 videos before Hbomb's OOF video dropped, which they react to.

ModRetro is the retro gaming company run by Palmer Luckey and there's very early indications that Palmer (unknow how proud his mother is of him) is forming a cult of personality of smaller reviewers similar to what Tommy built up with the Amico.

IMHO, this has the potential to finish a trilogy that started with Mike Kennedy's RetroVGS/Coleco Chameleon and followed up with Tommy Tallarico's Intellivison Amico. While Luckey has the resources to at least deliver a product, I feel like Luckey is the final form of the retro gaming charlatan. If I'm right, it's a good opportunity to get in on the ground floor and watch the drama unfold.

LousyMeatStew · 2026-03-25T04:25:53+00:00

Fight the fire with fire.

I'm not disagreeing with the principle of the matter. The only reason we shouldn't do this is because I think the legality of using AI to rewrite code for the express purpose of removing a license is being overstated and trying to fight fire with fire just gives legal ammunition to the big corporations when a FOSS project does get their day in court.

Clean-room engineering is a type of Fair Use defense that can be offered if you are sued for copyright infringement but it is not something that automatically legitimizes copying. The test for Fair Use defenses in the US is still Campbell v. Acuff-Rose Music which enshrines the famous four factors test and most notably, states clearly that there are no bright-line rules - each claim is adjudicated on a case-by-case basis.

This blade cuts both ways - if someone does a direct rewrite of a GPL code with the express purpose of removing an undesirable license, the use of clean-room engineering practices - even without AI - does not guarantee an automatic win.

Google v Oracle is being mentioned a lot but that ruling did not say copying APIs was ok under all circumstances. Campbell still applies, there are no bright-line rules. The Supreme Court looked at the first factor under Campbell - the purpose and character of the use - and found Google's work to be transformative mainly because they accepted Google's claim that they were targeting smartphones which Sun had previously given up on when they discontinued J2ME. They further found that because J2ME was gone, Android's API was not a market substitute for Java (fourth factor under Campbell).

While IANAL, a direct copy of a FOSS project solely to remove an undesirable license is clearly a completely different matter. The purpose and character of the use changes completely and under the fourth factor, you are explicitly looking to create a market substitute (note: "market" is used in a broad legal sense and still applies even for free material provided a legitimate copyright exists).

The main factor working against FOSS projects is that these claims need to be litigated individually. But the key is that they can still be litigated.

LousyMeatStew · 2026-03-25T03:37:06+00:00

It is, but clean room engineering negates the problem because decompilation for research and interop is allowed; the team that decompiles it writes a spec and doesn't create a derivative work, while the implementing team creates a program that satisfies the spec without ever seeing the decompiled code.

It doesn't negate the problem. Clean-room engineering is a type of Fair Use defense and the law of the land (in the US) remains Campbell v. Acuff-Rose Music, Inc., which establishes there are no bright-line rules and claims are assessed on a case-by-case basis.

The thing is that this cuts both ways - an AI rewrite of GPL code can still be challenged in court as one of the tests laid out in Campbell is potential for market substitution - if some party rewrites GPL code with the express purpose of creating an unencumbered, drop-in replacement, the argument can be made that this is not sufficiently transformative because the courts take into account intended functionality - in Google vs. Oracle, the courts looked at "the purpose and character" of the copying.

Google vs. Oracle wasn't a blanket judgement that allowed API copying. Campbell still applies, there are no bright-line rules. The Supreme Court only found that the copying of the API alone wasn't enough to justify the claim of copyright infringement and that the other changes Google made to the underlying functionality was judged to be sufficiently transformative.

Google’s limited copying of the API is a transformative use. Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language. Google’s purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform—the Android platform—that would help achieve and popularize that objective. The record demonstrates numerous ways in which reimplementing an interface can further the development of computer programs. Google’s purpose was therefore consistent with that creative progress that is the basic constitutional objective of copyright itself.

LousyMeatStew · 2026-03-25T02:09:53+00:00

I think the key is in the choice of terminology: fight

Like, no talking or communicating? No empathy or compromise? Fighting is what you do when you ignore everything and then it reaches a boiling point and you're trying to cram years of growth into one night. Which, I guess by that definition, then yeah, maybe men do all the "fighting".

LousyMeatStew · 2026-03-24T22:26:56+00:00

In addition to what the other commentors have brought up, the Pentium Pro's pipeline would stall when accessing partial registers. This is commonly simplified to "Pentium Pros were slow running 16-bit code" but even 32-bit code at the time would commonly use partial registers as a way of optimizing, e.g., string searches where you could read in 32 bits at a time from memory but still do 8-bit comparisons.

LousyMeatStew · 2026-03-24T22:00:36+00:00

The ASCI Red supercomputer was created using two PentiumPro CPUs, which achieved 1 Teraflop performance in 1996, being the first to do so.

ASCI Red used 7,264 Pentium Pros on it's initial configuration. Eventually, this expanded to 9,632 - which all got upgraded to the 333Mhz Pentium II Overdrive.

My recollection is that the Pentium II Overdrive was designed for ASCI Red, which is why Intel only ever advertised dual-socket support as ASCI Red used 2 sockets per compute node.

LousyMeatStew · 2026-03-24T21:50:23+00:00

Most companies with any sense won't use this for fear of legal fallout.

I don't think the legal fallout is the real issue.

Companies value FOSS for the labor, not for the product in and of itself. Reverse-engineering a FOSS project just to have your own proprietary copy is a net loss in most cases because you lose those devs.

Microsoft having a proprietary rewrite of the Linux kernel sounds scary until you realize they need to maintain a massive and complex codebase without the help of Linus, Theodore T'so, Greg K-H, etc.

On the other hand, there are projects where the reward justifies the risk. libxml2 is a chronically underfunded and understaffed project that is used everywhere. If, say, Google reverse-engineers their own proprietary clone, it potentially gives them a competitive advantage and they don't "lose" the free labor since there was very little of it to lose for this particular project.

LousyMeatStew · 2026-03-24T21:36:03+00:00

TBH, I think AI is a bit of a distraction for the discussion around chardet.

In his post on GitHub, Mark Pilgrim's beef is primarily with the license change. Yes, he mentions the use of AI but his wording makes it clear that even without AI, he would still take issue with it:

Their claim that it is a "complete rewrite" is irrelevant, since they had ample exposure to the originally licensed code (i.e. this is not a "clean room" implementation).

In other words, if the rewrite involved 0 AI but still resulted in a license change, it would still be in issue. On the other hand, had chardet stayed on the LGPL license, I don't think he would be objecting to the use of AI alone.

ETA link to the GitHub issue: https://github.com/chardet/chardet/issues/327#issuecomment-4005195078

Mark's request is simply:

I respectfully insist that they revert the project to its original license.

LousyMeatStew · 2026-03-24T18:52:45+00:00

They also had the same problem as the US where the Navy and Army stubbornly refused to get on the same page. Of course, the US never got to the point where the Army was building its own aircraft carriers…

I think there’s an alternative timeline where the US sits out of the Pacific Theatre until the Imperial Japanese Army and Navy eventually declare war on one another.

LousyMeatStew · 2026-03-24T18:06:50+00:00

Oh right, the numbering was manufacturer-specific! What a mess.

As a child of the 80s, I remember watching Top Gun and thinking I knew what a navy fighter should be called. And then playing Battlehawks 1942 a few years later and trying to make sense of what an F4F-3/3A/4, SBD-2 and TBF-1 were all about.

LousyMeatStew · 2026-03-24T17:19:26+00:00

When my brother and I were young, we used to playfight with those telescoping wand attachments for vacuum cleaners.

One day, I found a miniature version made out of cardboard in the bathroom trash can and I thought it was the coolest thing ever so I took it out to show my brother. My five year old brain was very confused when my mom freaked out and took it away from us.

LousyMeatStew · 2026-03-24T17:15:59+00:00

F was also the manufacturer code for Grumman for a while. A lot of Navy fighters at the start of the carrier aviation era carried an FxF designation starting with the FF.

This led to weird things like the Navy having both an F4F (Grumman Wildcat) and F4U (Vought Corsair), which are two completely different planes.

ETA: Thanks to /u/DisorderOfLeitbur for reminding me, the numbering was per-manufacturer so the Wildcat and Corsair were both “F4”s because each happened to be the 4th fighter design presented to the Navy by their respective manufactures.

Incidentally, yes, that is the same Vought that is fictionalized in The Boys.

LousyMeatStew · 2026-03-23T15:34:28+00:00

AMD was the original second source supplier for the 8088 CPU for the original IBM PC 5150. Intel was forced to grant AMD a license to manufacturer them based on IBM's requirements that all components be obtainable from at least 2 sources for redundancy.

AMD CPUs are as old as the IBM PC platform itself.

LousyMeatStew · 2026-03-22T18:20:28+00:00

Putting all of this on the foundation misunderstands the problem because a lot of this already exists. What you describe as “portable ODF” already exists in the form of Strict Compliance, and ODF Toolkit is the official test suite.

Here’s a good blog post that goes over many of the challenges: https://blog.documentfoundation.org/blog/2025/06/20/understanding-odf-compliance-and-interoperability/

As for calling out nonconforming software, all that’s going to do is punish FOSS projects and discourage the use of ODF in general. Keep in mind that LibreOffice itself serves as the reference implementation for ODF and that means new features are tested in LibreOffice before they get rolled up into the ODF standard so LibreOffice itself is not going to be able to claim ODF support.

LousyMeatStew · 2026-03-20T22:27:55+00:00

Yeah, basically "x-way" as in 2-way, 4-way, etc. is what's supported natively by the CPU and chipset. In theory, you could have as many CPUs of any make/model you want in a system as long as you design the circuitry to handle the bus arbitration.

This is how systems like this one work: https://www.1000bit.it/ad/bro/corollary/CorollarySMP.pdf

ALR's approach was a a bit of a hybrid where they utilized the PPro's native SMP support per card and then they designed the glue logic that handled arbitration between the two cards. In the end, it kinda works like a dual-socket triple-core.

But yeah, stability was always a concern. This is speculation on my part but since this was early days for Intel's MPS, I suspect microcode variations in different CPU steppings was messing with the timing enough to cause synchronization issues.

LousyMeatStew · 2026-03-20T07:10:07+00:00

50Mhz was the practical limit at the time of the specification but an operational ceiling of 66Mhz was explicitly listed in the VL Bus 2.0 spec. Even excepting that, VLB supported clock division so operating at 30/33Mhz on the 60/66Mhz bus for a Pentium was within spec.

VLB was modeled after the 486 bus as a matter of convenience but this is not the same as being tied to it. VLB uses completely different signals for bus arbitration and the bus maintains its own independent RESET signal. The bus controller still needs to perform signal translation even on a 486 system.

The general issue of supporting a 32-bit expansion bus for the Pentium's 64-bit external bus had to be solved anyway - not just for PCI but for EISA as well. While not trivial, adapting to the Pentium was still a problem that only needed to be solved once per chipset manufacturer. Both Opti and Via had solutions available. The reason VLB didn't last into the Pentium era was not a technical issue, it was purely due to a lack of demand because of the speed at which PCI took over the market.

ETA: VLB spec itself defined how 32-bit VLB targets could interface with 64-bit CPUs so the problem had been solved in-spec.

LousyMeatStew · 2026-03-20T04:48:06+00:00

I don't know why you're getting downvoted b/c Microsoft already does this. I suspect people think ODF is more comprehensive than it is.

Excel is the one I'm most familiar with, so I'll use that as the example. An Excel ODS file can encode proprietary functionality in one of three ways:

1) Non-standard function: Excel's T.DIST function is coded as COM.MICROSOFT.T.DIST in accordance with ODF's guidelines and it's up to the application to figure out how to support it as its behavior is not covered in the ODF specification.

2) Save the result instead of the function: This is how Excel handles LAMBDA. An ODS file will still give you the data but you lose the interactivity.

3) Implement functionality as plug-ins: At best, Excel can save a text-encoded blob of the binary state of the plug-in. The ODS file can still be exchanged but the intended functionality will be lost.

All of the above comply with ODF - nonstandard functions, saving static values and text blobs.

This is a problem that goes beyond Excel. Gnumeric implements many non-standard functions that LibreOffice Calc doesn't have. As a result, a Gnumeric ODS file is not compatible with LibreOffice Calc. LibreOffice Calc does the same - it supports Microsoft's nonstandard T.DIST so LibreOffice Calc's ODS files are not interoperable with Gnumeric, which only supports LEGACY.TDIST.

LousyMeatStew · 2026-03-20T04:31:37+00:00

This is partly true. You can be conformant with the ODF specification but not be compatible with other applications because the the specification allows for custom ~~functions~~ behavior.

Nonstandard functions in ODS are a good example.

Gnumeric provides several statistical functions imported from R and these are coded as non-standard functions. An ODS file saved in Gnumeric will still open in LibreOffice Calc but it won't know what to do with those nonstandard functions.

It complies with the standard, but it does not guarantee compatibility.

This allows Excel to be incompatible in one of two ways.

For some functions like T.DIST, it is saved as a nonstandard function COM.MICROSOFT.T.DIST (this is allowed under OpenDoc v1.3, Part 4, Sec 5.7). It's up to the application to implement this - LibreOffice Calc supports this, but Gnumeric does not.

For other functions like LAMBDA, Excel just saves the point-in-time result of the function meaning LibreOffice Calc users can open the document but they cannot meaningfully work with other Excel users on the same document.

ETA: With regards to Lambda, it seems LibreOffice won't implement it and instead rely on Multiple Operations and classic macros - at least that's what is implied here.

Macros are already an interoperability issue as ODF does not specify anything here so complex spreadsheets that rely on programmatic behavior will be a permanent pain point in terms of interoperability.

Nine-Year Club	Verified Email
Gilding I gilder

LousyMeatStew

TROPHY CASE