SoylentNews is people
SoylentNews
Arch Linux is moving ahead with preparing to deprecate i686 (x86 32-bit) support in their distribution.
Due to declining usage of Arch Linux i686, they will be phasing out official support for the architecture. Next month's ISO spin will be the last for offering a 32-bit Arch Linux install. Following that will be a nine month deprecation period where i686 packages will still see updates.
Any Soylentils still making major use of 32-bit x86? And any of you using Arch Linux? Distrowatch still lists Arch Linux as a top 10 distribution.
This discussion has been archived.
No new comments can be posted.
Arch Linux Preparing To Deprecate i686 Support
|
Log In/Create an Account
| Top
| 77 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
belief, n:
Something you do not believe.
(Score: 1, Informative) by Anonymous Coward on Thursday January 26 2017, @04:15PM
You can use more than 4GB of ram on any common 32-bit OS without having to do anything yourself (they all use PAE out of the box).
Thus your post contains absolutely no argument for 64 and comes across as completely clueless.
(Score: 1) by Scruffy Beard 2 on Thursday January 26 2017, @05:03PM
The Redmond OS does not support PAE, apparently.
(Score: 3, Informative) by LoRdTAW on Thursday January 26 2017, @06:13PM
The higher end datacenter and enterprise versions of Win 2k and 2003 supported the full 36 bit PAE address space of 64GB. There were hacks and settings you could change in 2k workstation/server and XP Pro/2003 to get PAE working since they all used the same kernel.
tl;dr Thank god we have 64 bit.
For a windows application to use more than 2GB of RAM (virtual addressing was limited to a 32 bit space of 4GB with half reserved for the system, a 2-2 split) you had to use Address Windowing Extensions (AWE) in your application to let your application use more than the 2-4GB 32 bit limit. There were settings to allow for a 3-1GB split if your application needed the extra gig. Though that was all dependent on your application and less system RAM meant less cache for disk and network I/O.
Linux supported PAE and you used shm with mmap() to map files into memory. You could use over 4GB but you implemented your memory as a file and you had to fseek()/fread()/fwrite() to locations where you stored your data. Not easy or friendly to use as you built a memory manager using this system which as you can imagine how much of a bitch it would be to debug.
Both solution were very difficult to implement as you had to pay damn good attention to your memory management design. Both solutions didn't afford you the ability to call malloc()/realloc()/new/etc in your process to get over 2-3GB RAM; you were still stuck with a 32 bit process memory space. You had to implement your own goofy memory system or use a library if they existed (I think memcached is one).
(Score: 2) by Scruffy Beard 2 on Thursday January 26 2017, @09:54PM
My PentiumII-350 is running an SMP kernel with PAE support because it is recommended for that machine (debian).
Never mind that it only physically supports 384MB of RAM.
I guess we may not even be disagreeing since my use-case does not have any programs using more than 2GB of memory. (I do have that much swap available -- but the system would be unusable (more than it already is)).
(Score: 2) by ledow on Friday January 27 2017, @01:04AM
And still no single process can use more than 4GB. Which is kind of a killer if, as indicated, single programs are using more than that already, demanding x64 instructions sets to even load (I've seen drivers, games, and other applications all demand such), and not supporting other configurations.
PAE is a paging hack, just like "expanded memory", "extended memory", "swap" or anything else that gets in the way of just asking for an amount of RAM from the memory allocator and getting it. Do you remember what happened to those terms?
Anyone can write a program on any -bit OS that accesses as much as you like, so long as you don't care about speed, complexity, managing it yourself and have direct access to hardware in ANY way. Hell, you just read and write a 2Tb file and you're done, or memory mapping on anything you can physically access (which can be a file or a remote network for all you know).
But bog-standard malloc support for stuff like that isn't present. You require software designed with that in mind. And, as I say, software like that is on the way out because application developers don't care about jumping through hoops when they can just say "Use hardware and software that's been standard for over a decade".
The argument for 64? You can jump through hoops like people did for a few years in the DOS days, the early Windows days, the early Linux days (I can remember LBA hacks and drive overlay support in Linux for hardware that didn't support it), and all had to be replaced eventually by just using a sane system with larger addressable memory directly. Or you can expect that to happen and next time you build something for yourself just select the 64-bit option, rather than having to do all that.
Literally - lose nothing, gain ongoing support forever.
Distros are dropping 32-bit left, right and centre.
Microsoft granted it some relief with Windows 10 after two years of threatening to remove support, you think the next version will have it? Server 2012 - 2016 are already 64-bit only.
The Linux kernel lists have talked about dropping it for years, and the bodge of x32 isn't going to be supported forever.
I'm not suggesting OH MY GOD BURN ALL THE 32'S! I'm saying its days are numbered. Like pre-Pentium support, like ISA bus drivers, like BIOS instead of UEFI. These things are dying off, dropping off supported hardware and software lists, and slowly disappearing. And the impact of 64-bit on systems you have NOW is likely nil past a reinstall or upgrade, or at worst a virtualisation of what you have.
So rather than coast along until one day the machines just don't work or have to be kept on insecure and unmaintained software, drivers or OS, the next time something happens, install the 64-bit version and save yourself the hassle.
Or join that one guy who still has an MCA bus in his machine and keeps trying to port the patches to Linux 3.0...