The push to save the Itanium architecture in Linux
lwn.net
lwn.net
From a previous thread:[1]
> And with the already severely limited choice of current architectures for the masses (x86, arm), it becomes even more important to keep what we have or had in the past, to not end in a 'If all you have is a hammer, everything looks like a nail.' type of future.
Which seems like a rather odd argument, considering Linux supports 18 other architectures, and IA-64 was about as far removed "from the masses" as possible and only ever available in "Call To Get a Quote"-priced server hardware.
I can't see a single good reason to keep it alive: there is extremely limited hobby interest ("a guy in Germany who wants to keep support for ideological reasons and can't even afford the energy costs of turning the servers on too often" is a very weak signal), and commercial production interest is probably close to zero – if not exactly zero: most Itanium server are running HP-UX or VMS, and if you're running Linux you probably don't want to upgrade because it sees so little testing (6.1 is supported until the 2030s!)
[1]: https://lore.kernel.org/all/59a76177-8ed4-e71e-9b11-a673298b...
If they are supporting some old Linux, I think it would be best to patch that kernel if there are flaws or fixes. If there are newer features they are attempting to add, I assert that you probably want more than the kernel like the C library.. maybe a lot more pieces. it’s not easy and it’s a pain but an out of line kernel patch doesn’t seem that bad, whether or not the support is mainlined seems pretty small compared to maintaining the tooling chain and everything else. The support and “new features” is pretty limited too, usb-c isn’t coming, thunderbolt isn’t coming, no advanced power management is coming.
SPARC also actually had market success, which cannot be said for Itanium.
The T2 has vastly better FPU performance than the T1.
https://www.oracle.com/servers/technologies/opensparc-t2-pag...
https://www.oracle.com/servers/technologies/opensparc-t1-pag...
It is doubtful that Intel would ever consider doing such a thing with Itanium.
https://www.fujitsu.com/global/products/computing/servers/un...
I believe they develop their own chip designs.
It looks like those servers use the SPARC64 XII, from 2017-18
"Fujitsu is going to continue Fujitsu SPARC M12 server sales until fiscal 2029 and support services until fiscal 2034." [0]
[0] https://www.fujitsu.com/global/products/computing/servers/un...
Oh sweet summer child…
> Of course 5 years from now that will be different, but 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5.
In my understanding, Itanium never went anywhere other than rare enterprise use, and never been anything more than a minority, inconvenient, uncompetitive architecture. At this point what servers remain will be slow, power hungry and unsupported.
Even if the kernel did support Itanium, how many projects are even building for it anymore, let alone taking care of making sure it still works?
Anything you can run on Itanium is almost certainly going to work better on AMD64.
Unlike something like the Amiga, it never had an enthusiast fanbase, and unlike say, SPARC or SGI hardware I don't think it ever had any fancy weird enterprise features you couldn't get on AMD64. The only motherboards I can find are from Supermicro, and they support up to 16 GB RAM, and have a PCI-X slot (that's the server-type version of PCI, before PCI Express).
> Frank Scheiner complained to the mailing list, saying that he and others had been working to resolve the problems with this architecture and had been rewarded by seeing it removed anyway
That sounds a lot like "sunk costs fallacy" - "we invested a lot of work into this, so we want to go on with it". But it doesn't answer if there are enough actual users left to justify this work?
As far as I can tell, Itanium hardware is boring. It's PCI-X, DDR RAM, Ethernet, SCSI, USB. Stuff that's very common out there.
And software mostly appears to be ports of software available on AMD64.
If you do have some machine running custom built software to operate a factory or something then you wouldn't want to touch it. You'll just keep on replacing parts until it's time to redo it.
unlike raspberry pi 5
say what you will about power efficiency and better options existing, but simply looking at the hardware, these are still capable machines
the point at which a machine becomes unusably obsolete is a judgement call, and I only consider itanium obsolete because every OS has basically given up on it, not because of the hardware
Even quite outdated PC is trivial to obtain and support in comparison. Also for Amigas and C64s software maintenance is vastly easier since there are practical emulators.
The power/performance isn't right, rather quite wrong. You're better off buying a second hand x86-64 which draws less power and has more performance.
My desktop is 12 years old and works completely fine. The major difference being that it's x86_64 so it keeps getting current software.
Under Linux, you can check with this script:
#!/usr/bin/awk -f
BEGIN {
while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1
if(/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) l = 1
if(l==1 &&/cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) l = 2
if(l==2 &&/avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/)
l = 3
if(l==3 &&/avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) l = 4
if(l > 0) { print "CPU supports x86-64-v" l; exit l + 1 }
exit 1
}Edit: I should say, I suppose it's a fair point that some distributions might eventually drop support for the exact CPU or hardware I have, but I expect this hardware to retain some level of support for a much longer period, especially from a kernel that hasn't even dropped 32 bit x86. It helps that if necessary I'm not above just going full Gentoo on it.
I am certain that Intel Clear Linux requires at least v2.
"Clear Linux OS supports 2nd generation Intel Core (Sandy Bridge) CPUs and later, Xeon E3 and later, and Silvermont-based Intel Atom C2000 and E3800 processors... Minimum system requirements are SSE4 and CLMUL (carry-less multiplication), as well as UEFI."
https://en.wikipedia.org/wiki/Clear_Linux_OS
This will probably creep into more distros. I know that rhel8 clones are supported until 2028; that will probably be the time to retire my own Core 2 Duos/Quads.
It looks like the first i3/i5/i7 generation (Clarkdale or Arrandale) was v2.
And replacing the CPU with the very best that the motherboard can handle is probably less than $10 on eBay.
I wish that I could remove unsupported systems after two years. That must be a nice place.
I have kept one Itanium server, just in case.
I worked on a project targeting hp superdomes (PA RISC). When that architecture was on its way out they started looking at amd64 as a replacement though Itaniun was the “successor” to hp risc and could run hpux (HP was involved somehow). It really never took off. The advance compilers that would give itanium software speed never really happened.
Hope: I loved the idea that the linux kernel not only freed new software from the shackles of corporate influence, but elevated old hardware and pushed them to reach their full potential using new CS concepts.
Whimsy: I loved the idea that a time traveller from 2036 could take a modern linux kernel and run it on a 1976 IBM 5100, and debug various legacy program issues that existed in the future. The Linux kernel is the best weapon we can give to such a traveller.
A major part of hardware preservation is software preservation. We can't expect Linux in 2023 to still support i386, but we have several Slackware ISO images that contain everything we need to operate this machine.
The part where it went wrong was a highly speculative bet on the academic argument that a simpler CPU with a smarter compiler was the future. HP and Intel bet the farm on that panning out, but they ran into a number of setbacks and the competition wasn’t giving them time to recover. Itanium was late and slower than predicted, and both RISC and x86 got a lot faster since they could focus on features like speculative execution and SIMD while Intel was pouring resources into fundamentals dealing with all of the perils of a new architecture, especially one which has significantly different performance trade offs. The original pitch was that Itanium would be faster, but most people found it to be significantly slower even on native code – compilers weren’t as good at finding instruction level parallelism as hoped – and once you factored in the cost it was irrecoverable: nobody is paying twice as much for a server which is half as fast on the hope that in years to come improved compilers might get closer to parity.
The real winner was Microsoft, and to a lesser extent Linux: part of this switch involved a lot of RISC vendors giving up and switching to Windows. Companies like HP, SGI, etc. scrubbed their plans to focus on Itanium systems but they didn’t go back to their proprietary Unix variants.
Nothing wrong with retro-computing enthusiasts, per se. From the Linux kernel perspective it's about the architecture having maintainers and not causing pain for the rest of the kernel. The Linux m68k port is probably a good example of this, hard to see it having any kind of commercial value these days, and the maintainers are hobbyists. But with the Itanium port not having anybody willing to maintain it, bye bye.
Probably also helps that qemu has m68k support, so even if you love the idea of running Linux on your old Amiga, you can actually do the development on a mainstream platform.
My oldest still-in-use hardware is now 15 years old and I'm amazed it does as well as it does but I'm also quite aware of the limitations and that stuff was absolutely top-of-the-line when it was bought. Parts are unobtanium and if it goes (which could happen every time it power cycles) we'll probably hold a small service but not cry too much.
Certainly not. But after I left a long ago computer systems company, the occasional request would make its way to me to hook up someone to someone who could help them get BSD or whatever running on some old hardware they had gotten their hands on. I'm glad you have your hobby but you shouldn't, in general, have expectations that engineers with day jobs are going to chase down a bunch of low level hardware and software information (if it even still exists) for your random hardware.
I think that makes sense, both for hobbyists and commercial value. A census is one, but unless someone's willing to pick up the gauntlet...
There's some 500 Eurofighters around with two dozen m68k each for their avionics (though not running Linux – and they're slooowly getting updated to less obsolete architectures), and I suspect they're not the only current use case. Industrial life cycles can be very, very long.
NXP also still makes the original 68000, which undoubtedly is still in demand for industrial and embedded uses. (Although a plain vanilla 68000 is not going to be running Linux due to the lack of an MMU)
https://www.nxp.com/products/processors-and-microcontrollers...
If the point is, as you suggest that you can do the development on modern hardware, and the later move the code from the emulator to actual hardware, then I think it's an overall win.
If all that happens is that code is developed using the emulator and then only ever run in the same emulator, then I question the value of the exercise. It's the same we see with old esoteric filesystems, if it's never checked against anything but itself, is it then really providing value.
Whether or not the developers are hobbyist should matter, having more hardware platforms is good for detecting bugs.
...unless you are developing for the JRE or CLR. Abstract emulation has its uses.
Must also be a little weird being on the HP-UX team, pushing out updates to a dying platform.
Those are delivered and certified as-is and upgrades are a no-go.
Now if they're using a 9-bit serial UART there may be a problem...
Some of these "weird assumptions" are necessary or useful for either performance or maintainability reasons. Having special cases for exotic architectures makes the kernel harder to change, and makes it harder to refactor it to user better code and data structures. That's, for instance, the reason support for the original Intel 386 was removed. Yes, this makes the kernel less portable, but that's a tradeoff.
Both the VAX and x86(-64) are little-endian. The Itanium could run either, but was little-endian by default (HP-UX would toggle to big-endian).
"Through compiler and OS support [HPE NonStop OS] runs in Big Endian from the user’s perspective [ on x86-64 Xeon]" [0]
Big Endian, how does it work? The x86 is little endian, right? • The compilers byte swap data items before placing them into memory for program variables • Does not apply to non-program variables such as return addresses pushed onto the memory stack • The OS along with the debuggers make the view complete • But if you just scroll through memory you can see a mix of Big and Little endian datums • Allows for binary data to be exchanged between Itanium and x86 systems without any special handling • In particular, messages sent via Expand between a NonStop x86 based system and a NonStop Itanium system require no extra handling.
[0] https://dan-lewis-fns9.squarespace.com/s/NonStop-X-Overview-...
Itanium isn’t truly archaic, though. It was only discontinued 3 years ago.
Ultimately, the question is: Is there a community of people willing to maintain it properly? And it appears to me that's Torvalds' position as well.
I was looking for an itanium server for a while and literally couldn't find one that wasn't silly money
That future never materialized.
Arguably x86-64 would have wiped those out anyway, with or without Itanium.
I'd argue what really killed Itanium was the end of dennard scaling. The whole arch was based on clocking faster and faster rather than being a slower, but smarter core. The end of dennard scaling put a ~5GHz cap on CPU speeds, is it's whole value prop didn't make sense against smarter cores that clocked just as high.
IMO, on the technical merits, a lot of those dead archs are just as valid ISAs for slower, smarter cores as x64 is and would have been able to compete. PowerPC and AArch64 are pretty damn comparable.
Without Itanium, those other architectures could easily have had an extra decade or more, and things might have turned out quite differently.
It was difficult hardware to deal with because it had noisy high speed fans that couldn't be disabled. Really, disabling them caused the machine to automatically shut off after 5 minutes even if it was in no danger of overheating. You couldn't be in the same room when it was running.
Here is how I set it up:
However:
> [The 2017 CPU] has no microarchitecture improvements over [the 2012 CPU]; despite nominally having a different stepping, it is functionally identical with the 9500 series, even having exactly the same bugs, the only difference being the 133 MHz higher frequency of 9760 and 9750 over 9560 and 9550 respectively.
So they practically _didn't_.
We’re decommissioning a couple of first-gen Itanium servers in the next few months. I think that the assumption is that we’d have to pay for disposal, so if someone wants them for Linux kernel support and can pick them up in Chicago, reply from an account with contact info and I’d send an email if it’s possible to give them away for free (I can ask).
You may have to destroy the harddrives for legal reasons.
Or secure erase them but then you may as well pull them (still, that would save someone another parts hunt). If you go this route check out to see if there are still any old installation media and hardcopy docs that can go with them, that might be worth almost as much as the machines to the recipient.
Anyway, VMS servers don’t generally have hard drives, they are designed to be run in a cluster, with each server using fiber channel to connect to a SAN. Also, I found that the ones we’re getting rid of aren’t first-gen - they’re 9300 series (3rd or 4th gen)
But we can sex it it up a bit: probably the people who would love to have this system to run Linux on haven't figured out yet that there is GOLD on those circuit boards. Lots of it!!
Free gold, just imagine...
That should do it ;)
https://en.wikipedia.org/wiki/Itanium#Processors
nope, both Poulson (2012) and Kittson (2017) used the same 32nm process.
From a distance I think it should stay gone - nothing is stopping the users from using an older kernel forever-more - plenty of other devices do and it's not like these are going to be used for anything important.
Do hobbyists looking to keep their machines alive actually need Linux or would another FOSS Unixoid system meet their needs as well? I'm sure the NetBSD people would love to welcome some volunteers, especially if they have actual hardware for debugging and testing.
It's dead, Jim.
But it's possible there's just not many people interested in this platform. Hardware was expensive, and most of it is rather large and power-hungry. HP did build Itanium workstations, but I think they stopped a long time ago.
Sadly ChatGPT does a poor job of generating parody lyrics so I won't subject you to them, and I'd probably do even worse unassisted.
Worse if such newer code relies on kernel infrastructure that changed in the meanwhile.
For users that don't ever change their setup, there's no issue really.
I have this feeling that 6.6.x needs a LTS[2] branch and I'd skip running any newer kernels in production until there is a hint that Linux intends to keep compatibility for at least 10 more years. I'm mostly happy with 6.1.x at the moment.
With BSDs offering increasingly better Linux application and driver compatibility, there is a good argument to do away with using the Linux distros in favour of something that works just good enough.
Currently, my stable systems run Debian Bookworm 12.2 (LTS 6.1), yet I'm evaluating FreeBSD 14.0+ to see how much it can run any legacy Linux applications without any issues.
[1] - https://news.ycombinator.com/item?id=37987543
[2] - https://en.wikipedia.org/wiki/Linux_kernel_version_history
* Since it has been abandoned by the vendor and no one has stepped up to maintain it, delete it. *
So all you have to do is commit to maintain it and it wouldn't disappear. Problem solved. You will be stepping up to do the work, right, or sticking with "someone other than me should be compelled to support this thing I want".
The reason we can have nice (weird, antiquated) things like Linux on m68k is there are people actually stepping up to do the work.
Or that means the interfaces are volatile?
The kernel developers are just making things worse if they want no compatibility across the kernel releases unless they have people meddling with the code periodically.
And they will be okay to support the driver for 10 more years as part of 6.1?
None of this put together makes sense. They do not have a good test infrastructure for lots of devices. Most drivers have no regression testbeds today.
That just tells me things will keep breaking more regularly.
It is good that the m68k enthusiasts care, and yet this development model isn't sustainable to begin with.
The CPU was not yet in its final form and we had access to a prototype version , it was an incredible interesting project...that was cancel after some time. Sometimes I reflect about that work and how impossible the end goal really was, but we tried!
I’m afraid that the community has grown so enormously and is subject to such powerful economic forces that if there are more people who need/want better EFI support (or whatever it may be) than who can keep up Itanium support, the Itanium community is probably out of luck.
I daydreamed a bit about picking up some Itanium equipment used just so I could say I’ve experienced it. It looks like a lot of power hungry gear with a lot of unsupported components that was all originally bound to some black-box vendor support contract. It would’ve been a hoot to have a big 90s mainframe running IRC or something, but I decided to allocate my hobby time elsewhere.
At my previous company they had two servers with dual Itanium CPUs. One CPU failed and they bought a spare used one from Germany.
We were informed that there was about 10 CPUs left for spare in the world by our provider.
The company decommisioned the servers in 2019 so now there are probably four more :p
But since it is a failed architecure, there can't be that many production systems ( < 1000 )
The researchers I worked with compiled a few things for it but it was slower than AMD on almost everything so nobody used it. I think the one exception was someone who had an extremely large dataset which could fit in memory on that system.
In addition, there were plenty of Linux Itanium HPC clusters on the Top500, there are 20 listed in June 2006 when I randomly searched:
Simplicity, while it has massive value, has no constituents. Nobody weeps for it.
This is why a “hello world” app is 100X larger than the cumulative storage of a computer 30 years ago.