(Note that this is about the kernel and 32-bit hardware, I'm not aware of any good cause to start dropping 32-bit applications and libraries.)
There are many good reasons to go 64-bit. Here are a few:
- Support for 32-bit SPARC hardware never existed (Sun dropped it with Solaris 10, before OpenSolaris)
- Most new hardware is 64-bit, new 32-bit systems are very rare
- Even "old" x86 hardware is now 64-bit
- DragonFly BSD went 64-bit
- Solaris 11 dropped 32-bit
- SmartOS is 64-bit only
- Applications - or runtimes such as GO and Java 8 - are starting to only exist in 64-bit versions
- We're maintaining, building, and shipping code that effectively nobody uses, and is therefore effectively untested
- The time_t problem (traditional 32-bit time runs out in 2038)
So, I know I'm retro and all, but it's getting very hard to justify keeping 32-bit support.
Going to a model where we just support 64-bit hardware has other advantages:
- It makes SPARC and x86 equivalent
- We can make userland 64-bit by default
- ...which makes solving the time_t problem easier
- ...and any remaining issues with large files and 64-bit inode numbers go away
- We can avoid isaexec
- At least on x86, 64-bit applications perform better
- Eliminating 32-bit drivers and kernel makes packages and install images smaller
Are there any arguments for keeping 32-bit hardware support?
- It's a possible differentiator - a feature we have that others don't. On the other hand, if the potential additional user base is zero then it makes no difference
- There is still some existence of 32-bit hardware (mainly in embedded contexts)
My own plan for Tribblix was that once I had got to releasing version 1 then version 2 would drop 32-bit hardware support. (I don't need illumos to drop it, I can remove the support as I postprocess the illumos build and create packages.) As time goes on, I'm starting to wonder whether to drop 32-bit earlier.