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.
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.
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.
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: