"Something which caught my attention while reading this question was the requirement for a 32-bit operating system with newer software than Red Hat Enterprise Linux 6 offers. It seems unusual that someone would want new software versions, enterprise support and a 32-bit operating system. New software and legacy hardware (or new software and enterprise environments) rarely go together and it might be worth looking into whether these criteria are really necessary."While I certainly understand Jesse's point about 32-bit being legacy hardware, there are still many use cases where 32-bit and current enterprise quality software and OS are necessary. Many current Linux apps are still very light and can run very well on rather old hardware, both in the server room and on the desktop.
I've done a lot of support of government servers and they run for about forever, as in until they serve no further use. Even retired, old servers are often repurposed and put back into service due to budget restrictions and/or long lead times to order new equipment under the required procedures for government procurement. In the United States this is especially true at the state level. When a server is repurposed it is usually reloaded with the current enterprise standard Linux distrubution release and applications, not legacy releases. That's one common use case.
Non-profits and small businesses often get by with older equipment as well, and in the case of non-profits it may even be donated second hand equipment that was no longer useful in it's former commercial enterprise home. Once again, a 32-bit OS and current software makes sense in cases like this.
My personal hope is that the free enterprise Linux clones will take Red Hat's 64-bit sources and create a 32-bit version. It isn't hard to do but it is time consuming. CentOS has already made clear they will release a 32-bit build(see comment by developer Johnny Hughes below), which leaves Scientific Linux and Springdale Linux.
[Note: This article was expanded from my comments on DistroWatch Weekly, Issue 560.]
I work for a small software company and we are testing the waters here by only providing 64-bit applications for our new products. It's quite a burden to do GUI testing across all platforms (Linux/Mac/Windows), all OS versions (e.g. XP/Vista/7/8), and all architectures. We've also dropped Windows XP support.
ReplyDeleteHi Caitlyn, two points regarding your post:
ReplyDelete1- Another 32-bit use case I think could be VPSs, as those usually have lower specs than (even some vintage) servers. Think Amazon's and Openstack's m1.small offerings.
2- I don't find anything definitive regarding no 32 bit support for CentOS 7 in the post you linked. In fact, this other post indicates that they actually might release a 32 bit spin:
http://seven.centos.org/2014/01/i686-effort-is-kicking-off/
At least they're still building 32 bit packages (there are a lot of fails at the start of May but a lot of dones at the end of the month):
http://lists.centos.org/pipermail/centos-build-reports/
So, let's hope they release it at some point :)
Cheers.
Ricardo, I appreciate your comments. The links on CentOS 7 and i686 you sent date from January. The comment I referred to, dated yesterday, by one of the CentOS developers stated: "no 32-bit for RHEL7 (and consequently centos) as far as I know". I hope your more optimistic view prevails. VPSs are another good use case. Thank you for pointing that out.
DeleteI know the post I linked is old (and I didn't realize the post you mentioned was from a CentOS developer), that's why I also linked to the build reports mailing list, sorry I wasn't clear on that.
DeleteAnyway, I guess Johnny Hughes' comment below clarifies things.
We intend to have a 32 bit port available for CentOS.. But it will be best effort and may lag the official effort as it will be a secondary effort.
ReplyDeleteThank you for letting us know. Great news! I've updated the article and will also do a follow up story.
Deleteummm.....its called debian...if your stuck on RHEL then ver6 is supported until 2020.
ReplyDeletesometimes you have to cut the umbilical cord and move forward....besides almost all of the modern 32bit kernels require PAE...even debian dropped non-pae so I have to use slitaz on super old stuff anyway.
No, it's not called Debian. Did you even read the article? It was a response to a section of DistroWatch Weekly written by Jesse Smith who questioned the need for a 32-bit enterprise distro with commercial support. Since when does Debian have commercial support? For many enterprises the lack of commercial support is an absolute no go.
DeleteSecond, how many servers or even recent desktops and notebooks that are still in service or are likely to be repurposed have a non-PAE kernel? "Really old stuff" doesn't need enterprise support, but machines that are as a little as 5 years old still do.
Finally, Debian may have dropped non-PAE (pity, that) but anyone running Red Hat, Centos or other clones can use the non-PAE kernel from ELRepo, so those machines are better supported without cutting any cords.
Slitaz? In an enterprise? In any business? Are you joking?
It really helps to understand the topic being discussed before commenting.
I should also add that Red Hat have been known to support officially unsupported things for large enterprise customers on a case by case basis. All software companies have to do this. There is a much greater chance of that happening with CentOS, which is now an in house project (as in Red Hat pays the developers) than with anything else other than RHEL.
DeleteCaitlyn
ReplyDeleteRHEL6 is supported until 2020 with extended until 2023. If you need 32Bit this should be sufficient to satisfy your needs.
At some point we have to bite the bullet and move on. I see absolutely no reason spending the time, money or effort on a commercial RHEL7 version, and think that RedHat are doing the right thing here.
Correct me if im wrong but don't we have a date (epoch) issue when we get to 2038 with 32bit.. Y2k all over again so i would think moving towards 64bit before 2023 will make sense surely. Anyway.. we might even not be talking about bits by then with the future of computing.. who knows!!...
ReplyDeleteAFAIK, the epoch issue is a 32 bit struct, not the architecture so you'd have the same problem in a 64 bit distro.
DeleteIt definitely still has sense to use 32bit OS even on nowadays powerfull machines, as in a 64bit mode *everything* is bigger (takes up more memory). A 32bit VPS with 256 MB RAM will definitely provide more memory for apps, than a 64bit one. Not mentioning the memory-hungriness of the apps itself. A 64bit OS/db/app stack can be as much as 60% more memory hungry than a 32bit one!
ReplyDeleteI know that a majority of people in a developed world does not care of a memory as it is cheap, but beside a top 1 bn men of a developed world, there is also another 6 bn men, for whom it may be hard to spend even $500 for a new computer. In a SOHO segment, notebooks with 2 GB RAM are truly not ucommon nowadays, even in a developed world. Not everybody throws away a 5 year old computers just for the sake of beeing "IN". There are even rigs with 1 GB RAM. Running a 64bit (host) OS on such a computer, and inside it trying to virtualize three or four another guest instances (also 64bit) quickly exhausts all the available memory. Not so with 32bit OSes. There is noticably more headroom for playing with virtualization when everything is 32bit.
For computers (or virtual computers) with 4 GB or less RAM, using a 32bit OS is more rational choice than a 64bit one. No matter how "legacy" or "dumb" it can look, the opposite is true.
And mainly: Except for a big enterprise environment or media processing workstations, there is no practical need for 64bit memory model, nor for an average Joe's home computer (well, Firefox is a story on it's own), nor for a small to medium loaded servers. A plenty of servers do not need even 4 GB of RAM, as they serve some lightly used application with tiny or medium size database and 2/3 of their memory is used just for caching most of the time.
You make a very good point, but don't forget that 64 bits is not only about memory but also for example new instructions and more registers, which in many cases mean faster execution of software.
DeleteIf you're memory constrained probably 32 bits makes more sense to you and that's fine (e.g. embeded world is mainly 32 bits AFAIK).
There's also the x32 ABI support in Linux triyng to provide the best of both worlds but I don't know if there is much uptake:
https://sites.google.com/site/x32abi/
http://lwn.net/Articles/548838/ (x32 ABI support by distributions)
Cheers.