7 ms·
Maybe because nobody uses 32-bit x86 anymore?
by human_banana 7y ago
Maybe because nobody uses 32-bit x86 anymore?
- heavyset_go 7y agoThere were 32-bit netbooks being sold the last time I looked in 2015.
- peteradio 7y agoJesus was closer to dinosaur times than we are to 2015.
- grmn 7y agoAre you Him?
- heavyset_go 7y agoCasual computer users don't buy new computers each year. Pretty sure set top boxes and routers with 32-bit x86 processors have been sold since then, too.
- gdxhyrd 7y agoSure, but the ones that pay the bills are servers and companies which don't care one bit about i386.
- heavyset_go 7y agoAgreed, however open source has always relied on enthusiasts for consumer-grade hardware support.
- opencl 7y agoThe really fun part was when they launched the first 64 bit Atom CPUs (Bay Trail) and then a bunch of them got shipped with only 32 bit UEFI and cannot boot in 64 bit mode.
- zozbot234 7y agoThey have to _boot_ with a 32-bit UEFI bootloader, but can run a 64-bit kernel and userland. Fedora Linux even allows for this while keeping secure boot on; Debian supports it as well but the interaction with secure boot is buggy, so you need to turn it off. Not sure about other distros, however.
- heavyset_go 7y agoEarly 64-bit Intel Macs also shipped with a 32-bit UEFI limitation, but they were able to boot into a 64-bit system.
- makomk 7y agoUnfortunately, upstream doesn't really notice if 32-bit x86 breaks. This isn't just a kernel problem; glibc managed to push out a release back in 2017 that broke memchr on 32-bit Atom in a way that tended to cause programs calling it to segfault. It turns out that amongst a few other things, including Python, the glibc build process itself relies on memchr working... I don't think they actually tested the code path in question after modifying it.
- exikyut 7y agoOf course it was tested [on the developers' x86_64 laptop(s)]!
- bryanlarsen 7y agoNo, that's the i386 architecture, which is still well supported AFAICT. x86_32 is a funny architecture that requires 64 bit chips but uses 32 bit pointers. http://www.h-online.com/open/features/Kernel-Log-x32-ABI-gets-around-64-bit-drawbacks-1342061.html http://www.h-online.com/open/features/Kernel-Log-x32-ABI-get...
- comex 7y agoNo, that’s “x32”. “x86_32” is not an official name for anything, but based on the contents of the post, I believe Andy Lutomirski is using it to refer to 32-bit x86, aka i386.
- treeform 7y agoYour comment should be the top comment. I had no clue i386 and x86_32 where different. I though the article was saying 32bit linux is broken.... but no some strange "alternative" mode on linux is broken.... who cares.
- comex 7y agoThe comment is wrong. It is about i386.
- geofft 7y agoThis post is about i386 / x86_32. What you're referring to is "x32," a different thing entirely, which uses the x86-64 instruction set. You can tell this post is not about "x32" because it talks about "segments, gates, and other delights from the i386 era," which don't exist on the x86-64 architecture regardless of how long your pointers are, and it says things are "fine on a 64-bit kernel" (x32 uses a 64-bit kernel, it's a userspace ABI only).
- thrower123 7y agoIf only... I have been hoping for a native x64 version of Visual Studio for almost a decade, and signs do not look good for that ever coming to fruition. As it is, loading up solutions that consume nearly 2GB of RAM are still bringing the IDE to its knees and making it thrash and page.
- mike_hock 7y agoMy old Atom laptops still run perfectly fine. Thanks, Debian.