It would be interesting to see a real census of the folks who want to keep ia64 support in Linux, with some breakdown of their motivations. Cases like "Control software for our factory's special $Millions-dollar machine only exists for ia64" seem far more sympathetic than "I love my basement collection of archaic computer hardware".
In the enterprise software space, a ton of work goes into maintaining old platforms and backporting security patches and the like to old versions of software. That a not small part of what you're paying those companies to do.
Just because some of the hardware and its control software may be stuck in ancient times doesn't mean that they wouldn't want to upgrade other software or add other hardware that requires a newer kernel to function.
They wouldn't, its too much of a risk. The update could break the control software and bring everything down. If its working don't touch it, otherwise you might bring down production and lose lots of money. A new kernel brings no value to a currently working system.
Yep. I'm very curious to know who actually use itanium cpus anymore. I've only seen it referenced in a couple of research papers that are from... 2015-2016? I even went out of my way to see if a local refurbished electronics seller had itaniums many months ago and they said, "Itanium, huh. Haven't heard that name in a long time".
AFAIK they were contractually obliged to produce a new generation.
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.
We got 4 from that last batch that Intel ran. Our cloud migration project is way behind schedule and we needed the insurance. Support for the VMS version we’re running on them goes until 2028 I think.
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)
Yes, it's an expensive paperweight by the time you have it.
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!!
Whatever remaining notable demand isn't directly for Itanium, but rather for legacy installations of HPUX and VMS. Where Itanium, despite the age, is still the most current platform.
My last employer ran custom COBOL applications on HP-UX. Last I knew they were working on a migration but they had custom rolled their entire system so it is going to take a while to migrate completely.
> "I love my basement collection of archaic computer hardware"
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.
Yes, but most retro computing enthusiasts are more than happy to run retro software as well, because that's where the fun is. Running a 2023 OS on 1993 hardware is going to be a frustrating experience anyway even if you get it to work because of the relative change in performance since then. Hardware is usually best matched with software from roughly the same era if you want anything close to acceptable performance.
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.
> The Linux m68k port is probably a good example of this, hard to see it having any kind of commercial value these days
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.
68k support in Linux and GCC includes NXP Coldfire, a family of microcontrollers that are the last living descendents of the 68k. There are products being made right now that run on Coldfire so it is quite relevant to a lot of people to keep support going.
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)
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.
> 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.
...unless you are developing for the JRE or CLR. Abstract emulation has its uses.
>Nothing wrong with retro-computing enthusiasts, per se.
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.
The only reasonable thing would be having exotic architectures around to ensure the kernel is as portable as possible and doesn't make any weird assumptions. I think that's OpenBSD's reasoning for some of the CPUs supported. No idea though if itanium brings anything interesting to the table in that regard. If it's just EFI woes, not much is gained really.
> The only reasonable thing would be having exotic architectures around to ensure the kernel is as portable as possible and doesn't make any weird assumptions.
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.
Fascinatingly, ARM (aarch64) can also do either; while the only operating system I know about that uses this fact is NetBSD, I have actually run that in big endian mode on a Raspberry Pi (3b) and it does actually work.
Right? I honestly don't yet understand why ARM designed BE mode into their shiny new architecture, but it's sweet that we have easily-available hardware that supports it.
"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.
That's not entirely correct, the 386 simply lacked features and required cumbersome workarounds. I was more thinking of things like weaker memory models which can uncover concurrency issues.
I expect there are people out there who were in the right place at the right time when the company they work for was decommissioning some IA64 kit, and got it for nothing or close to. So there will be at least some hobbyists who haven't paid silly money. Because of the niche it ended up in, and how small that niche was, you either get the kit for very little that way or a lot by buying it from someone who got it that way, there is not much in between.
Back in the day, we reluctantly abandoned PowerPC, UltraSPARC, PA-RISC, Alpha AXP, MIPS... because the bright future was Intel Itanium. Bye, bye, SUN, Silicon Graphics, Acorn, DEC/Compaq, Hewlett Packard, Sony NEWS.
About the only real "success" of Itanium was wiping out the competing architectures. ARM only survived because its low power consumption was perfect for mobile and embedded use. Once Acorn was gone, we didn't see a mainstream ARM-based personal computer again until the M1 Mac.
Most likely, yes. But without Itanium, the competing architectures would have had several more years of development before x86-64 was released. While the end result would probably be similar, it is interesting to think about what improvements may have been made in competing architectures in those interim years.
Yeah, the big question I have is whether PowerPC or maybe Alpha would have done better. Both had competitive chips but a lot of companies were waiting for Itanium since the analysts were saying that was the future. PPC survived for a while on Macs but it’s interesting to consider hope many extra millions shipped per year it would have taken to make it a profitable and more competitive business. Microsoft had NT running on the hardware so a switch could have been relatively quick.
Worth noting - PA-RISC was Hewlett Packard's own baby, which they used for their higher-end systems. And, at least in Wikipedia's account of things ( https://en.wikipedia.org/wiki/Itanium#Inception:_1989%E2%80%... ), Itanium was born when HP approached Intel about collaborating on a new architecture, and Intel happily accepted a load of fundamental design ideas from HP.
Maybe...but Itanium was a join announcement by A-listers Intel and HP in June '94. Vs. C-lister AMD didn't announce x86-64 until 1999, didn't release the full spec. until Aug'00, and didn't ship an actual product until Apr'03.
Without Itanium, those other architectures could easily have had an extra decade or more, and things might have turned out quite differently.
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.
I got one from ebay for basically the price of shipping (£58, that thing weighs a lot). They are less available now than they used to be though. The era of decommissioning data centers with Itanic in them is over. https://rwmj.wordpress.com/2014/09/08/raise-the-itanic/
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.
I have to disappoint you then. There is no such thing as a sufficiently good compiler for the Itanium architecture. The software that was worth turning on the hardware for never existed.
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.
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).
That's the question I was asking myself too when I read quotes such as:
> 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?
>Anything you can run on Itanium is almost certainly going to work better on AMD64.
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.
HP wasn't just involved, it was their baby from the beginning. But they realized that the investment was too large and risky and Intel needed a 64-bit arch. So they partnered up.
I have nothing useful to comment other than hope and whimsy.
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.
Such traveller can use a snapshot of a Linux distro from 2010. Just because it is out of mainline, it doesn't mean that the past disappeared.
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.
Itanium never had much potential to begin with, and the amount of systems that ever made it out of corporate vaults can probably be counted on two hands. If those companies want to fix their decades of neglect, they can pay kernel maintainers for the upkeep.
When it started, there was concern that CISC x86 was hitting a performance wall and Intel really wanted something which was locked up so other companies like AMD, Cyrix, etc. couldn’t clone it.
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.
Intel released the final version of Itanium in February 2017. They stopped taking orders in January 2020. They stopped shipping chips in July 2021. Long before that, the only real remaining enterprise solution using Itanium was Oracle on HP. Oracle wanted out and tried to end development on the platform around 2011-2012 but HP sued them and won, forcing them to continue support. I believe Oracle finally EOL'ed the platform at the end of 2021 and HP intends to EOL it at the end of 2025. So short answer is no, there is no point, it's a dead end platform.
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.
What uses? Even a raspberry pi 5 has better specs than all itaniums. Except maybe the last one, but obviously I don't have it at hand to test. And not many people do, considering that intel begrudgingly released it and didn't make an effort to sell it.
my inexpensive modern pc could also be replaced by a slightly newer inexpensive modern pc, so what?
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
That's fair. I've got some fully capable 32-bit x86 hardware that doesn't get the support which, it seems to me, it completely deserves. But like the enterprises that are almost fully transitioned away from Itanium, it's not like I'm actually willing to pay anyone to do the work.
It is exactly because of the hardware: Itaniums are pretty much unobtainable these days. This makes supporting software for these machines difficult and very expensive. This is the natural consequence of the manufacturer also having obsoleted it.
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.
In 5 years it will be an 11+ year old CPU running on 7+ year old servers. These are enterprise database servers sitting in data centers not embedded machines sitting on a factory floor. The few still out there will be replaced over the next 2 years.
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 would expect that Fedora has done the same as rhel.
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."
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.
Yeah, I would expect Fedora to be more aggressive about it than RHEL. IIRC SUSE was also talking about doing something similar. And sure, it's likely to be more common with time, but I expect some of the major distros to hold out for quite a long time - Debian and Slackware, in particular - but even if the big players all start requiring newer hardware there will be a long tail of distros like puppy linux to support old machines so long as the kernel and core software keep working.
"We need more time to fix the problems" seems a bit late. Itanium is not a new architecture.
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!)
Also, if there is commercial interest for Linux on IA-64, someone should be able to pay someone to maintain kernel support and perform extensive tests. The fact that this hasn't yet happened yet is at least potentially a signal.
Say there is commercial interest… it’s all custom work. Having support in the mainline kernel is a fairly small piece of the equation, there aren’t active distributions that support it. At best you’d be putting a newer kernel on an ancient distribution, worse you’d be building a hand made distribution.
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.
From this perspective, SPARC is almost equally exotic as Itanium, and provides sufficient architectural diversity in the unlikely case that it is needed in the future.
SPARC also actually had market success, which cannot be said for Itanium.
Also you can buy a SPARC server for very cheap on eBay, less than a hundred bucks in many cases. Shipping is usually more expensive than the item itself. There are thousands or more of those things out there.
Is this some kind of joke? Why waste time on Itanium support when RISC-V will result in the end of the ISA wars? Sure you might argue that in the future there will be an even better ISA, but nothing prevents those future processors to simply support RISC-V for legacy applications.
They can. But bugfixes may not be packported due to lack of developers. Same with drivers for newer hardware which (potentially) could be plugged into an Itanium system.
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.
That depends on what you mean by production. The only Itanium server I ever used was at a supercomputing center where it was considered production as a service for researchers, and that ran Linux.
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.
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.
Looking at the archives of the netbsd-ia64 mailing list, it doesn't seem like the netbsd ia64 port is particularly healthy. The most recent discussion thread is a thread that was cross-posted to various ia64 related mailing lists, by the person that now removed the Linux kernel support. And AFAICS with no comments from any people involved in the netbsd port. Before that, the previous activity on that mailing list was a few message back in 2020. And before that, a few messages in 2016.
My inner compulsive optimist would say that means they'd be especially happy about volunteers with access to actual hardware.
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.
Doesn't ring as true as you appear to be "weeping" for simplicity here. Others must be, as well, as this plea is an appeal to the Linux project's decision to simplify by deprecating Itanium support.
More than 20 years ago, a company was hired by Intel to develop an automated migration of 32-bit C++ code to 64-bit C++ code specifically for the Itanium.
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 do not want to comment in particular about Itanium. But I have a slew of concerns around old hardware removal, especially drivers like the QLogic 10GBE NICs gone[1]. It means that old software that could potentially virtualize Linux with these adapters are no more useful and that Linux is actually leading to deprecation of older computers in the field.
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.
* 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.
Lack of maintenance suggests that stable working drivers were never there?
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.
I can understand the Itanium community feeling like they are trying to do The Open Source Thing by volunteering to keep it alive, only to be (what might feel like being) summarily dismissed by the rest of the community.
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.
128 comments
[ 2.9 ms ] story [ 211 ms ] threadMust 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...
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.
Here is how I set it up:
https://news.ycombinator.com/item?id=38276518#38282424
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.
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...
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.
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.
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.
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.
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.
Without Itanium, those other architectures could easily have had an extra decade or more, and things might have turned out quite differently.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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:
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.
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.
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.
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:
https://www.top500.org/statistics/sublist/
https://en.wikipedia.org/wiki/Columbia_(supercomputer)
https://en.wikipedia.org/wiki/Altix
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.
http://mail-index.netbsd.org/port-ia64/
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.
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.
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 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.
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.