Tweet flexes about upgrading to x86, misunderstands x64 naming joke
Why is this Hardware meme funny?
Level 1: Numbers Can Fool You
Imagine you have two video game systems: one is called the Nintendo 64 and another is the PlayStation 4. If you just look at those numbers, 64 is a lot bigger than 4, right? Now, what if a kid bragged, “Haha, you’re still playing on a PlayStation 4, but I’m already on a Nintendo 64 – keep up!” If you know a bit about games, you’ll find that funny because the Nintendo 64 is actually a much older console from the 1990s, while the PlayStation 4 is a newer, far more advanced machine. The kid got tricked by the numbers in the names and thought 64 must be newer or better than 4, when it’s not in this case.
That’s exactly what’s going on in this meme. The person is saying, “Most people are still on x64 machines while I’m on an x86 machine. Keep up!” In simple terms, they’re claiming to use a type of computer (x86) that is actually older and less powerful, and acting like it’s the newest thing. It’s like someone proudly saying they’re using a 32-inch TV and telling people with a 64-inch TV to catch up – it sounds upside-down. The humor comes from us knowing that the bigger number in the name doesn’t always mean newer or better, but the person speaking in the meme doesn’t seem to know that. It’s a playful joke about how confusing names can be. Even though “86” is a bigger number than “64,” when it comes to these computer terms, x64 is the newer tech and x86 is the older tech. So the guy telling everyone to “keep up” is actually the one behind the times. We find it funny because he’s basically showing off the wrong thing – he thinks he’s ahead, but he’s really far behind, and he doesn’t realize it. It’s a bit of silly, geeky humor that even if you’re not into computers, you can relate to as “someone got fooled by a name.”
Level 2: When 86 < 64
Let’s break down the key terms and why this tweet is funny in simpler terms. The meme is about CPUArchitecture and a common confusion around it:
- x86: This label typically refers to 32-bit computing in the context of PCs. Historically, “x86” is a family of computer processors and the set of instructions they use. The very first was the Intel 8086, and many later ones had names ending in “86” (80286, 80386...). Over time, people just said “x86” to mean any processor compatible with that family (all the way through the 1990s, this meant 16-bit and 32-bit PCs).
- x64: This isn’t the name of a specific chip but a shorthand for 64-bit PCs that use an extension of the x86 architecture. The more precise name is x86-64 (or AMD64, since the company AMD created the first 64-bit x86 processor). When we say a computer is “x64,” we mean it has a 64-bit processor and usually running a 64-bit operating system.
What’s the difference between 32-bit and 64-bit? It mostly comes down to how the computer’s processor handles information. A 32-bit (x86) processor can work with 32-bit numbers natively. One practical effect of this is it can only directly use about 4 GB of memory (RAM) because 2^32 bytes ≈ 4.29 billion, and that’s the maximum unique addresses you can have with 32 bits. A 64-bit (x64) processor, on the other hand, can handle much larger numbers – 64-bit numbers – and can theoretically use mind-boggling amounts of RAM (2^64 addresses, which is over 18 quintillion, far beyond what today’s hardware provides). It also can do 32-bit tasks, but it has the ability to work with larger chunks of data and more memory at once. In everyday terms, a 64-bit system can run both 64-bit and 32-bit applications (it’s backwards compatible), while a 32-bit system is stuck with 32-bit apps and limitations.
Now, why would “most people still be on x64” and someone brag about being “on x86”? Today, virtually all modern PCs and laptops are 64-bit (x64). You’d have to go out of your way to use a 32-bit system – typically only older computers or specialized scenarios use x86-only. When you download software, you might notice it sometimes offers two versions: one labeled x86 (for 32-bit Windows, for example) and one labeled x64 (for 64-bit Windows). This is to ensure you download the version that matches your system’s capability. Since almost everyone now has a 64-bit system, the x64 version is the one you’d pick. The x86 version is there mostly for legacy (older) machines or compatibility.
The tweet’s humor comes from flipping the expectation. Normally, you’d brag if you had newer hardware or software than others. For example, saying “I’ve got a 64-core CPU, while everyone else has 8 cores – keep up.” Here it’s the opposite: the person is either clueless or jokingly pretending to be, by saying they have an x86 machine (which implies a 32-bit system – older tech) and expressing shock that others are “still on x64” (which is actually newer tech). It’s like if someone said, “I can’t believe you all are still using modern smartphones when I’m already on a flip phone… keep up!” It sounds absurd because it is backward – they’re touting something outdated as if it were ahead of the curve.
Key concept: Instruction set naming – The terms x86 and x64 are names for these architectures (designs of how a CPU works at a low level). They are not simple version numbers. The confusion (and the joke) arises because x86 has a number “86” in it, which is higher than “64”. But that 86 isn’t a version; it’s part of a historical naming scheme. After the 80486 chip, Intel stopped using numbers and started using names (Pentium, etc.), so “x86” just stayed as a generic label. When 64-bit extensions came, people informally said “x64” to mean 64-bit x86. It might help to think of it this way: x86 and x64 are more like codes or categories, not sequential versions. x64 came after x86, even though 64 is less than 86 — because the 86 in x86 doesn’t denote “86-bit” or anything sequential relative to 64.
Let’s relate this to something familiar: imagine you have two gaming consoles – one called the GameBox 64 and a newer one called the GameBox 86. You might automatically think the GameBox 86 is newer because 86 > 64. But what if I told you the number in “GameBox 64” actually stood for something else (say, it could handle 64-bit graphics) and the “GameBox 86” name is actually an old series name that stuck around? In reality, the GameBox 64 is newer and more powerful, and the GameBox 86 is the older model series. That’s essentially what’s going on with x64 (newer) vs x86 (older). The tweet is funny to developers because the person got this exactly reversed and is flaunting it.
We also should explain why developers find this funny:
- Developers working in low-level programming or just dealing with software installation encounter these terms regularly. They know that x64 is the one you want for a modern system. So, hearing someone brag about x86 implies that person has missed something very fundamental.
- It’s a bit of insider humor. If you’re new and not aware of the naming conventions, this tweet might be confusing or not funny – you might think “What’s the difference? 86 vs 64, I don’t get it.” But once you know that x86 is basically the older tech and x64 is the newer tech, the idea of telling others to “keep up” while using the older tech becomes clearly a joke.
- It also taps into the stereotype of the overconfident tech enthusiast who uses jargon without fully understanding it. Many of us have met someone who throws around terms like “I have a 64-bit processor” without context, or someone who might say “I’m using a quantum CPU” just to sound cutting-edge, even if it’s nonsense in context. This tweet mocks that behavior by example.
In short, x86 vs x64 confusion is the crux. The meme creator is assuming the persona of someone who confuses the two and comically acting superior about it. The tags like CPUArchitecture and HardwareHumor apply because the joke revolves around the architecture of CPUs and how they’re labeled. Knowing that x86 is basically the older 32-bit platform and x64 is the 64-bit platform (and current standard) lets you in on why this brag is laughably backwards. The phrase “keep up” is particularly cheeky – it’s what you’d say if you truly had something more advanced and wanted to poke fun at others for lagging. Here, it underscores the sarcasm, because in reality everyone else is ahead.
So if you’re a junior developer or just someone learning about computer architecture, remember: x64 > x86 in terms of capability and newness. The tweet intentionally messes this up for comedic effect. It’s a bit like joking that you’re on a “new” system called i386 (which is actually an old Intel 386 processor designation) and marveling that others haven’t caught on to it. The humor lands once you understand that context. Essentially, the joke is a play on words and tech naming — the person brags about what is actually a downgrade, confusing “bigger number in name” with “newer technology.”
Level 3: Legacy Flex
From a seasoned developer’s perspective, this tweet is a textbook tech humor scenario: someone flexing their “advanced” setup while inadvertently revealing they’ve got it completely backwards. The poster says, “shocking to me that most people are still on x64 machines when I’m already on an x86 machine – keep up,” essentially bragging about running a 32-bit system as if it’s a cutting-edge achievement. This is hilarious to anyone familiar with PC hardware because it satirizes a know-it-all who actually knows just enough to be dangerously wrong. It’s the reverse of what a real upgrade would be. Today, almost everyone is using 64-bit operating systems and CPUs (that’s what x64 indicates) – it’s been the standard for well over a decade. In fact, by 2025, pure 32-bit (x86) machines are practically museum pieces or niche embedded devices. So the tweet’s boast comes off as delightfully absurd: “I’m ahead of you guys, I downgraded my architecture!”
This humorous reversal plays on the trope of false superiority we often see in developer communities. It’s reminiscent of the classic "works on my machine" gag or the newbie sysadmin who claims complete expertise after running a single script. Here the brag is about hardware. The author is mimicking the tone of tech influencers who humblebrag about having the latest and greatest gear – except he’s got his generations mixed up. The line “keep up” adds that perfect touch of smugness; it’s the equivalent of a developer patting themselves on the back for using a technology that, unknown to them, is outdated. This hits close to home for many veteran devs who’ve seen Dunning-Kruger moments in real life: someone assumes a bigger number in a name means a newer version. The seasoned folks share a collective chuckle because we’ve encountered this exact confusion with architecture labels. In config menus, downloads, or IDE settings, the option for x86 vs x64 can trip up newcomers. For instance, a junior dev might wonder why a 64-bit installer is labeled “x64” and the 32-bit one “x86” – isn’t 86 larger than 64? It’s an easy mistake if you don’t know the backstory. The meme exaggerates this misunderstanding into an ostentatious tweet. It’s the perennial meme of boasting about technical superiority while actually downgrading.
Historically aware engineers get an extra layer of giggles here. Referring to a “machine” as x86 or x64 suggests the tweeter thinks these are like model numbers or product lines, when in reality they denote instruction set compatibility. It’s as if someone said, “I don’t use those fancy modern AMD Ryzen 64-bit CPUs, I’m rocking an old Intel 80386, get on my level.” That notion is patently ridiculous – a 80386 (i386) chip from the mid-1980s runs at ~33 MHz and can’t handle anywhere near the memory or speed of a modern 64-bit processor. A cheeky commenter even riffed on this with the phrase “We are from future: i386 band,” jokingly framing the 1985-era 32-bit CPU as if it’s a cool futuristic club to be in. It’s pure irony. Seasoned devs also recall that the transition from 32-bit to 64-bit computing was a one-way street for progress: more bits meant the ability to use more RAM, improved performance for certain classes of software (thanks to additional CPU registers and instruction optimizations), and generally leaving behind the constraints of the older world. By 2025, many platforms (like newer versions of macOS, some Linux distros, even modern Windows) have dropped support for 32-bit apps or OS installs entirely. Claiming you’re “already on x86” is like bragging about using an OS that can’t even run a lot of modern software. That’s why this resonates as a facepalm moment – every senior dev knows that if you’re stuck on an x86-only machine today, it’s usually a limitation, not a flex.
The humor also touches on instruction_set_naming oddities. Over the years, we’ve seen plenty of confusing labels: Intel went from numbers (486) to names (Pentium) to phrases (Core i7), and AMD’s “x86-64” extension became popularly known as just “64-bit”. The tweet gleefully weaponizes one of these oddities: that we abbreviate x86-64 as x64 but still call the older platform x86. In everyday dev life, you see this in folder names like Program Files (x86) (which on a 64-bit Windows is where 32-bit programs go) or download pages offering an x86 vs x64 version of an app. It’s a bit counterintuitive until someone explains, “x86 basically means 32-bit here, x64 means 64-bit.” If that detail slips by, a person might literally think x86 is a higher tier than x64. The tweet lampoons precisely that slip. It’s funny because it’s plausible someone could think that, yet it’s such a nerd faux pas. It almost reads like an inside joke among hardware and low-level programming enthusiasts: we all know that one guy who’d try to one-up others with technical jargon and end up exposing their ignorance. This tweet is written as if by that guy – with tongue firmly in cheek.
Another angle: There’s an implicit pun in bragging about being on a “machine” labeled x86. Developers might recall the term “machine code”, or that we refer to platform architectures as different machines (the Java Virtual Machine abstracts away actual machine differences like x86 vs ARM, etc.). Saying “I’m on an x86 machine” is a quirky phrasing we’d usually only use when specifying architecture compatibility (like, “I have to build this code for an x86 machine vs an ARM machine”). It’s not how you’d typically boast about your personal computer’s specs. That odd phrasing itself hints that the tweet is a joke – it’s deliberately using semi-technical lingo incorrectly. It reads like someone only half understanding the terms from a spec sheet. Seasoned readers pick up on that and laugh because they’re in on the gag.
In summary, the senior dev perspective enjoys this meme on multiple levels:
- Irony of the brag: Turning a downgrade into a boast. We love how blatantly wrong it is; it’s a comedic self-own.
- Shared experience: Many of us have had to correct or educate others on the x86 vs x64 difference. It’s a rite of passage in IT support or mentoring juniors. This tweet encapsulates that confusion in a one-liner.
- Historical nod: It nods to the legacy of x86. Older devs remember when 32-bit was the hot new thing (the i386 band was indeed the future… in 1986). There’s a nostalgic chuckle that now someone might think going back to that is being ahead.
- Tech lingo parody: It pokes fun at buzzwords and labels. In an industry where product names and acronyms are often non-intuitive, mistakes like this are at once cringe-worthy and comic. It’s a gentle reminder not to take version numbers at face value.
The combination of these elements makes the meme land perfectly in developer humor circles. It’s the kind of joke you’d share in the team chat and everyone from the sysadmin to the backend coder will reply with a knowing 😂 or a groan — because we’ve all seen “that person” who misunderstands the tech hierarchy. This time, luckily, it’s deliberate and for laughs.
Level 4: Bitness Backfire
At the cutting edge of CPU architecture humor lies a subtle sleight-of-hand with naming conventions. The tweet plays on the confusion between architectural lineage and bit-width progression in processor design. In technical terms, x86 refers to the long-lived family of CISC instruction set architectures stemming from Intel’s original 16-bit 8086 CPU (1978) and its successors (80286, 80386, etc.), which eventually evolved into 32-bit IA-32 (often just called x86 for short). By contrast, x64 is an informal moniker for the x86-64 architecture – the 64-bit extension of x86 introduced by AMD in 2003 (also known as AMD64). The joke hinges on interpreting these labels as though they were sequential versions where a higher number means “newer.” The poster quips about being on an "x86 machine" as if 86 > 64 were an upgrade, when in reality x86-64 supersedes x86. This is a classic case of mistaking nomenclature for numeric hierarchy.
Under the hood, a 64-bit x86-64 processor is a strict superset of the older 32-bit x86. It retains backward compatibility (able to run x86 code in legacy mode) while extending capabilities: larger registers, more registers, and a vastly bigger address space. In fact, an x86-64 CPU is an x86 CPU that has been extended – you might say it's x86 dialed up to 64 bits. This means a "64-bit machine" can do everything a 32-bit machine can (often faster, thanks to architectural improvements), plus handle data and memory sizes the 32-bit machine could only dream of. For example, x86-64 introduced 64-bit general-purpose registers (RAX, RBX, etc.), widening the 32-bit registers (EAX, EBX...) inherited from classic x86. It also expanded the addressable memory from 4 GB (the 2^32 limit of a 32-bit address bus) to a theoretical 16 exabytes (2^64). So when someone boasts they've moved “beyond x64 to x86,” it's akin to saying they've traded in a superset for a subset – a technological downgrade. The humor is cerebral: it exploits our knowledge of how instruction set naming doesn’t follow simple numeric order. In computing history, naming is often governed by historical accident and marketing. The term “x86” itself is a retro-futuristic artifact: originally derived from the Intel 8086 and its successors ending in “86,” it stuck as a catch-all for 32-bit PC architecture even after numeric model names (like 80586) gave way to brand names (Pentium, Core, etc.). Meanwhile, “x64” emerged colloquially to distinguish 64-bit capable systems, because calling it “x86-64” everywhere was clunky. Ironically, that shorthand can mislead folks into thinking x64 and x86 are two distinct lines racing each other, rather than one being the extension of the other.
In the low-level programming world, this misunderstanding is almost poetic. Consider that we still use the label x86_64 in compiler flags and OS identifiers (x86_64-pc-linux-gnu, anyone?), explicitly reminding us 64-bit PC CPUs are built on the x86 legacy. A seasoned systems programmer will chuckle at the tweet because it’s effectively saying “I’m on the older i386 bandwagon from the future, you all are stuck in the modern world.” This paradox tickles our nerdy love for backward compatibility and the absurdity that an Intel 386 (i386 from 1985) could be portrayed as futuristic. It’s as if someone claimed Moore’s Law works in reverse for them. The bitness backfire here is grounded in technical reality: the numbering in CPU naming isn’t ordinal. x86-64’s name preserves the x86 prefix to signify continuity, not to indicate an 86-bit architecture (no, there’s no “86-bit” CPU). The tweet’s author either feigns ignorance or satirically role-plays a tech poser who got tripped up by this naming quandary. The result is a meme that resonates with those who understand the instruction set architecture (ISA) lineage – highlighting how a 64-bit evolution got labeled in a way that can befuddle the uninitiated.
To drill down even further, let’s briefly illustrate the technical difference that the jokester is glossing over. In assembly terms, moving from x86 to x86-64 introduced not just bigger registers but also more of them, and new instruction-pointer-relative data access among other enhancements. In 32-bit mode, you had 8 general-purpose registers (EAX, EBX, … EDI) each 32 bits wide. In 64-bit mode, you get 16 general-purpose registers (RAX, RBX, … R15) each 64 bits wide, with the old 32-bit registers now acting as the lower halves of the new ones. For example:
; 32-bit x86 assembly (IA-32)
mov eax, 42 ; EAX is a 32-bit register
mov ebx, 10 ; EBX is another 32-bit register
add eax, ebx ; compute 42 + 10, result in EAX (32-bit result)
; 64-bit x86-64 assembly
mov rax, 42 ; RAX is a 64-bit register (extends EAX)
mov rbx, 10 ; RBX is a 64-bit register (extends EBX)
add rax, rbx ; compute 42 + 10, result in RAX (64-bit capable result)
In the 64-bit version above, RAX and RBX are the extended registers that can hold much larger values than their 32-bit counterparts EAX and EBX. A program running in 64-bit mode can directly address vastly more memory and use new instruction forms; it’s a more powerful machine architecture in every sense. Thus, a claim of being “on x86” while others are “on x64” is, in cold engineering terms, asserting preference for a less capable mode of the same architecture. It’s like claiming you run your server in 32-bit mode intentionally to outperform everyone’s 64-bit servers – a proposition that provokes grins and head shakes from hardware aficionados. The meme cleverly counts on our understanding of this architectural backwardness: by phrasing it as a boast, it underlines the absurdity. On a theoretical note, it’s a reminder of how backward compatibility shapes tech evolution. The very reason we have the confusing term x86-64 is because jettisoning the x86 lineage (as Intel attempted with IA-64 Itanium) proved commercially disastrous. Instead, the industry doubled down on extending the old architecture – forever binding the “86” moniker to both 32-bit and 64-bit eras. Consequently, we’re stuck with a naming where x86 (32-bit) and x86-64 (64-bit) coexist, ripe for exactly this kind of tongue-in-cheek misinterpretation. In summary, at this deepest level the humor emerges from a confluence of historical context, technical nuance, and the perennial truth that bigger numbers in tech names don’t always mean what one might assume. The tweet is a geeky facepalm at how non-linear tech progression can appear to the uninformed, and a celebration of the fact that knowing the backstory turns a potential mistake into a punchline.
Description
Screenshot of a dark-mode tweet UI. The profile picture shows a monochrome anime character, name reads “ronin” with a blue verification badge, handle “@seatedro”, timestamp “· 1d”. Tweet text: “shocking to me that most people are still on x64 machines when i'm already on an x86 machine” followed by a blank line and the standalone line “keep up”. The humor relies on confusing CPU architecture labels - thinking “x86” (historically 32-bit) is somehow newer or more advanced than “x64” (64-bit extension of the x86 family). Developers will recognize the playful misunderstanding of instruction-set naming conventions and the perennial meme of boasting about technical superiority while actually downgrading
Comments
25Comment deleted
Bragging you’re on x86 is adorable - nothing says “cutting-edge” like a 4 GB address space and a JVM running on PAE life-support
Wait until they discover the i286 crowd - we're so far ahead we've wrapped around and are approaching from behind
Ah yes, the classic 'upgrade' from 64-bit to 32-bit architecture - because who needs more than 4GB of addressable memory anyway? It's like bragging about migrating from Kubernetes back to manually SSH-ing into servers. Nothing says 'cutting edge' quite like PAE flags and the constant fear of hitting memory limits. Keep up indeed - just make sure you're running in the right direction
Announcing you’re “already on x86” is like bragging about moving to ILP32 - great cache density, but you just lost long mode, eight extra GPRs, and most modern distro support
Bragging you’re “already on x86” is like boasting prod still fits in a 32‑bit address space - adorable, right up until Chrome opens one tab
x86 in 2024: Peak optimization - half the bits, double the pointer arithmetic nostalgia
i stands for imaginary unit Comment deleted
Already using 128-bit pointers... Comment deleted
I use 512 bit vectors where u at Comment deleted
SIMD operations, regardless of their register width (which may easily be as large as 4096 bits these days), are used to process the very same 8 to 64-bit pieces of data as general-purpose scalar registers do. I was referring to pointers, which are handled by scalar registers and traditionally limited to 16, 32 and currently 64 bits, thus being able to address 64 kilobytes, 4 gigabytes and 16 exabytes of [virtual] memory. In some processor architectures, those pointers may be extended to descriptors that store extra metadata needed to protect memory access from programmatic errors and vulnerabilities; for example, if regular pointer occupies 64 bits, the corresponding descriptor may have 128 bits. That metadata can be handled by conventional 64-bit registers, but it is obviously faster when a hardware acceleration is implemented for this purpose — to minimize overhead the very same way as SIMD does for processing bulk data. Comment deleted
This thing really exists? It sounds obsolete because operating systems already do it on a program level. If it really does improve performance then it has to become a new standard Comment deleted
pac/bti on arm exists for a while already, but it is not about perf, its about preventing ROPs Comment deleted
program level does nothing as it is always way too easy to smash the stack even by one improperly handled byte Comment deleted
Regular memory protection (that one at the OS level) concerns page access — that is 4096-byte granularity at most, not to mention huge pages of 2 megabytes or more — at process, so that other programs / users cannot use memory that is not their. I was referring to memory protection that has byte or word granularity (for example, 1-byte granularity for object boundaries and 4-byte granularity for uninitialized values) that protects the program against itself — such as off-by-one index errors. It's not about performance — it's about security and debugging, because the program is trapped instantly the very moment it attempts incorrect action, rather than when the memory is corrupted so badly that it is nearly impossible to trace back to the root cause. When paired with memory tagging (e. g. "this word contains uninitialuzed data / numeric data / function address / memory descriptir") and implemented in CPU hardware, it provides bulletproif protection against most common programmatic errors, that the program itself cannot bypass, as descriptors and tags cannot be forged programmatically like regular pointers. it has to become the new standard It's not that simple, though. • The whole program must run in this mode, including all the libraries. • Many optimization tricks violate the strict access rules — for example, fast implementations of strlen() that analyze multiple bytes at once. • While some protections have near zero performance penalty, others may be expensive — for example, use-after-free protection against "zombie" references. • Each 128-bit descriptor uses twice as much memory than a regular 64-bit pointer, which exhausts L1 and L2 caches twice as fast. • There are tons of poorly written programs that store pointers in generic integer variables, falsely assuming that it is always possible to convert an integer number back to a pointer — that is not possible with descriptors, as type casting removes their tag that cannot be forged back later. • There are tons of poorly written programs that falsely assume that pointer size is the same as a corresponding integer number size — that is obviously not true for descriptors that store extra metadata beyond that of a pointer visible to application. As a consequence, most software that we use today and that would benefit the most from such kind of protection, can hardly be ported to secure mode, — bur rather the most critical programs with clean code, those that are worth huge efforts. Comment deleted
Thanks for clarification. I didn't know it is a separate layer of protection than OS level. I was a little bit puzzled when seeing discussions about large register size advantages when "larger means slower" in computer architecture. I thought that if this allows to transfer burdens of OS to CPU then it would rather pay off, but surely it is not that straightforward Comment deleted
https://www.arm.com/architecture/cpu/morello https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ Comment deleted
8086 is the future Comment deleted
Have you heard 'bout transistors? They say they are hot stuff Comment deleted
nah 64-bit access is already too wide Comment deleted
That's what big 64 wants you to believe Comment deleted
nah nintendo64 is awesome Comment deleted
that's a MIPS-based architecture, mostly 32-bit with 64-bit characteristics Comment deleted
x87 exists, but he's still on x86... Comment deleted
In My college they are using 88💀 Comment deleted
68k anyone? Comment deleted