(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.
5 comments:
Yes, by all means. Illumos hardware support is extremely limited anyway, so it's not as if it is the go-to OS for obscure projects or embedded systems. Even ARM is going 64-bit nowadays, so the market for 32-bit is shrinking to very small platforms like routers that will tend to use a stripped-down OS like VxWorks because even Linux leads to too large a bill of materials increase.
As for 64-bit userland, it is way overdue. I cannot count the number of times I typed tail -f instead of tail -f and had it fail over a log file over 2GB in size.
If 32-bit support is ripped out, it will effectively forever bar any possibility of anyone ever porting the SunOS 5.# kernel to any embedded platform, most of which are still 32-bit based.
By killing 32-bit kernel support, one would effectively (very effectively!) dis-incentivize anyone working on an embedded solution to pick the illumos kernel for such a project.
It would be akin to suicide on the embedded front, effectively guaranteeing that there will NEVER be a Solaris powered embedded device for many years, until perhaps 64-bit hardware becomes the only available hardware. We are some years away from that yet. That means that Linux will continue to gain ground, something that should be stopped, prevented, or at least slowed down at all costs, since it is a sub-par technical solution when compared to illumos.
"We can avoid isaexec"
Say what!?! isaexec(3C) is one of the most powerful, killer features in Solaris which no other operating system has, as it allows us to ship packages which contain per-processor, respectively per-processor instruction set architecture optimized binaries, and that is exactly what you want to avoid? isaexec(3C) is trivial to use!
The purpose of isaexec(3C) is not only to provide 32- or 64-bit binaries, it is to provide instruction set timing-optimized binaries, for example, it allows to deliver generic i86pc, then i386 optimized, then i486, then pentium-pro, then pentium-pro+mmx, then amd64 optimized binaries. Yes, most of these are obsolete processors, but think in terms of binaries optimized for ARM instruction sets, or any other processor architecture that illumos might support in the future (not to mention SPARC per-processor optimized binaries).
Why is this so important? Because one of the traditional Solaris, and by extension illumos target markets is high performance and technical computing. Think about finite element analysis, instruction set timing-optimized binaries are the norm, not an exception in that field. isaexec(3C) makes it possible to deliver all those binaries in one convenient package, and let the runtime linker select the most appropriate one!
illumos builds as-is for both 64- and 32-bit targets. As far as I can tell, that requires no extra work, apart from some poorly written / implemented 3rd party applications. So rather than fixing the root cause, the applications, the fix would be to rip out 32-bit kernel support?
That is just not the correct way to solve that particular problem.
"As for 64-bit userland, it is way overdue. I cannot count the number of times I typed tail -f instead of tail -f and had it fail over a log file over 2GB in size."
That must not have been on Solaris (SunOS) or illumos then, because the largefile(5) manual page explicitly states:
"The following /usr/bin utilities are large file aware:
adb aliasadm awk bdiff cat
chgrp chmod chown cksum cmp
compress cp csh csplit cut
dd dircmp du egrep fgrep
file find ftp getconf grep
gzip head join jsh ksh
ksh93 ln ls mailcompat mailstats
mdb mkdir mkfifo more mv
nawk page paste pathchck pg
praliases rcp remsh rksh rksh93
rm rmdir rsh sed sh
sort split sum tail tar
tee test touch tr uncompress
uudcode uuencode vacation wc zcat
The following /usr/xpg4/bin utilities are large file aware:
awk cp chgrp chown du
egrep fgrep file grep ln
ls more mv rm sed
sh sort tail tr".
I actually use Tribblix on a 32-bit machine, and install to a UFS root on that machine... (Thanks for your excellent work by the way.) I personally would like to see 32-bit support stick around a bit longer but I know I'm a corner case.
That's...interesting. And good to know it actually works!
Post a Comment