Stories
Slash Boxes
Comments

SoylentNews is people

posted by FatPhil on Thursday January 26 2017, @11:46AM   Printer-friendly
from the all-the-world's-a-Cray dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by LoRdTAW on Thursday January 26 2017, @06:13PM

    by LoRdTAW (3755) on Thursday January 26 2017, @06:13PM (#459028) Journal

    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).

    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by Scruffy Beard 2 on Thursday January 26 2017, @09:54PM

    by Scruffy Beard 2 (6030) on Thursday January 26 2017, @09:54PM (#459160)

    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)).