32 bit x86 Gentoo - still use it?

[Tony0945]

[Zucca]

Since the 17.0 profile is kinda imminent... I thought to ask if one could just disable pie USE -flag globally? Would that work? Since I'm planning to revive my old Pentium 3 laptop sooner or later, I'd like to disable pie there since it seems to cause overhead.
Also would that make it impossible to compile softaware for it on pie enabled 64-bit system (with multilib)? If it's impossible then how about 32-bit non-pie crossdev environment inside qemu?
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

[NeddySeagoon]

Zucca,

That works but there is an extra step as pie is forced on.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Zucca]

Ok. So basically right after untarring stage3, chrooting and editing make.conf I'd run

[miket]

I voted for the last option because it was the most accurate: my last 32-bit machine (yes, on Gentoo) went out of service 7 or 8 years ago, so I have been exclusively 64-bit since then. Things were bumpier in the beginning of 64-bit, but things are good now.

At the same time, I sure am not demanding that everyone "get into the 21st century!" as the poll asks. You could turn that a bit into how I got into the 21st century. I rejoice that Gentoo still supports x86 since, yes indeed, many people still use it and I myself could find myself wanting to use it.

For me, the more fearsome thing is what Intel wants to push onto the world: dropping of support of legacy BIOS in favor of its EFI dog-and-pony show. I am happily in the 16/32-bit world for that!

[eccerr0r]

At least at this point it seems most people have gotten rid of their 32-bit x86 boxes, but still a good holdout. It's great some people other than me still use their x86 boxes on a daily basis so we don't have to worry too much about bit rot... I hope...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[JWJones]

I voted "Yes, main desktop, machine can't run 64-bit" because I am currently installing on an old Dell Dimension 3000, P4, 1GB RAM, 40GB HDD. This will be my first attempt at installing Gentoo, so I thought I'd use an old machine from our "boneyard" here at work. I come from the Slackware world to Gentoo, so it's not too much of a stretch for me, so far. I plan on starting off with a minimal window manager desktop machine on this hardware: probably cwm, i3, or spectrwm, then later I'll build a nice xfce desktop on higher-spec (64-bit) hardware.

I should probably note that I am merely a Linux/BSD hobbyist; I'm neither a developer or IT person. I do this only for my own use/experience. I'm really enjoying the Gentoo way so far!

[eccerr0r]

Now due to meltdown, 32-bit users are currently in limbo, or has someone seen some information about getting PTI ported to x86-32?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[miket]

[eccerr0r]

Yes I tried setting CONFIG_PAGE_TABLE_ISOLATION to Y (actually, removed the Kconfig requirement for X86_64)

It wouldn't even compile (4.14.12).

---

Curiosity to those who are still using 32-bit: My initial guesses is that anyone using before a P4 or Pentium-M, you might be safe because it's not predictable to read the data. It IS vulnerable and a dedicated hacker will get your data, but it requires patience and 100% CPU utilization for long periods of time to get your data (as it'd have to check and check again, and may need to do a "best of 3" type of deal (or possibly more than 3) in order to reliably read information, and by then the possibility the data has changed by then.

A P4 or Pentium-M, as they support SSE2 - since they come with cache operations extensions, they are screwed as they're easier to determine whether they got the right cache line. If you can run 64-bit, now's the time.

The non-speculative, non-out of order Atoms are good to go as far as I know (note: the newer Atoms do use speculation and can run things out of order, so they are affected). These older Atoms may be the only 32-bit x86 CPU that are okay at this point. I think even Spectre won't work because of the lack of speculative execution.. Unfortunately these older Atoms are slow as molasses...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Marcih]

I'll just necro this thread if you don't mind

I don't have many machines but 66.6% are a) laptops, b) pre-2006 (Acer TravelMate 230 and 2414WLMi), therefore x86 it is. As you can imagine, compiling on single-core laptop processors is a pain (my recent emerge -e @world due to changed ${CFLAGS} took 36 hours ). The remaining machine is my main one and is a recent x86_64 desktop, but I do have ABI_X86="32 64" in make.conf for compatibilty. I don't understand the vehement push of everything towards the 64-bit variant of whatever architecture - probably because I don't understand how intruction sets work and the benefits of 64-bit aside from having 64 1s and 0s as opposed to 32 of them!

[eccerr0r]

[Hu]

There is also the technical appeal of reduced workload / testing. If you have the option to support the package on only one architecture (x86_64) instead of two (x86 and x86_64), that reduces your workload. If you want to support only one architecture, dropping x86 makes more sense than dropping x86_64.

[eccerr0r]

ergo lazy software developers
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[miket]

Don't forget about another 64-bit advantage. The AMD64 CPU's have a lot more registers than the 32-bit ones plus new addressing modes. One of those new modes is for data relative to the program counter. This makes it so that AMD64 supports Position-Independent Executables with no overhead. The older 32-bit architecture lacks this mode and takes a performance hit when programs are built as position-independent executables.

PIE not only allows loading shared libraries at any location the OS wants to load them, but it is also necessary for Address Space Layout Randomization, a common and cheap security measure.

[Marcih]

[eccerr0r]

[Hu]

A 32-bit number can represent 2**32 unique values, by definition. If every value is one memory address, a 32-bit number can address 2**32 locations => 4GiB of address space. Exceeding that requires the bank swapping tricks that eccerr0r describes. Those tricks are used less today because you can get so much done in one bank. In practice, Linux/x86 programs have less than 4GiB of accessible address space because the kernel reserves a portion of the address space for itself. Even with a PAE aware kernel, the maximum concurrently addressable memory is 4GiB. PAE describes a standard way to do the bank swapping, so that the kernel can have more than 4GiB of RAM with useful data, although it cannot see all that data all at the same time with a simple 32-bit pointer.

Also, while 3GiB-4GiB seems like a lot, remember that this is all the mapped memory for the program, not just data. Every shared library requires a portion of that address space, and due to layout and alignment issues, even tiny libraries require several pages. Every program stack (minimum one per thread, usually not more than one per thread, although some programs play weird tricks with multiple stacks) requires pages. Every data allocation requires pages, whether that is data read from a file, computed in memory for temporary use (rendering to a screen or sending to the network) or computed in memory for long term use (such as remembering which level of a game you are on, or which areas you have visited). Most non-media allocations are comparatively small, but nothing is free.

Perversely, increased memory sizes have worsened program quality. It's now somewhat common that a program's regular use will not run out of memory, so programmers are less inclined to spend the code complexity and testing time to ensure that a memory allocation failure can be handled in those exceptional cases where it happens. This burned me a while back when a 32-bit program started crashing because a supporting library became less memory efficient, causing the program to exhaust its address space and crash, even though it was not (as far as I could tell) actually leaking memory. It merely needed more than it could get.

[Marcih]

[Hu]

Object-oriented versus not-OO is not really relevant here. All programs need memory to store their work. OO is a style for how to think about that memory, but you still need to store the objects. Languages like Python that take away pointers and handle object lifetime for you will free you from tracking which bank is active, but the language implementer is still obligated to handle that, else your objects won't be available when you try to use them.

Virtual memory addresses and physical memory addresses are logically distinct. In very simple environments, virtual may be mapped 1:1 to physical, but that is not done (except perhaps during early boot) in production systems. The pointer limit applies to memory addressed by the pointer. In most, but not all, cases this will be virtual memory.

Yes, it is common that portions, sometimes very large portions, of virtual memory are unmapped and do not correspond to any physical address. Each process is given a private view of virtual memory (this is part of its appeal relative to physical). Virtual memory can reference a physical page shared with other processes, which is why you can have hundreds of programs load glibc, yet not spend sizeof(glibc) * 100s to store it in physical memory. Typically, such sharing requires that the page not be mutable, else one program could corrupt the glibc of another. Special rules apply to permit lazy unsharing.

[eccerr0r]

[Marcih]

[gordonb3]

Dropping in my $0.02 on this old poll/topic

Yes I still run multiple x86 Gentoo machines. All VMs actually. One is used as a crossdev machine for a 32 bit ARM architecture, which proved to be necessary because crossdev tends to copy the target directory structure from the host OS rather then the target OS. As a result I get libraries installed in lib64 folders if I use a 64 bit host and that obviously does not work on the 32 bit target platform. It doesn't solve all the issues with crossdev - e.g. perl arch dependent modules get installed under i686-linux-thread-multi even though they are armv5tel-linux-thread-multi.

The other machines are more or less conveniently based on this crossdev machine as I required special purpose machines. I actually like 32 bit OS better for this as well, because they tend to have stable memory management out of the box whereas 64 bit systems tend to be very aggressive and cause a lot of swapping.

[Tony0945]

gordonb3,

That's an interesting alternative to my 32-bit partition that builds for k6. I'll have to consider that.

[Aiken]

Have one x86 still running 32 bit user space. An old p4ht that is waiting to be retired. None of the user space on that machine has ever hit the 32 bit memory addressing limit. When it had a 32 bit kernel not even enough ram to bother with PAE. Only reason it has a 64 bit kernel is got fed up with the OOM killer. Between low mem, high mem, swap, the number of times the OOM killer would trigger with low mem full while high mem was mostly free and swap barely touched. Early on the only reason a couple of machines ended up with 64 kernels.

Everything else has been changed from 32 to 64 kernel and user space. Doing 32 bit to 64 conversions of live headless boxes a bit of trepidation when typing reboot.
_________________
Beware the grue.