back to article Debian dev to the rescue after proposal to remove Itanium from Linux kernel

Linux kernel developers have debated removing support for Intel and HP's now officially defunct Itanium/IA64 platform from the project, with the outcome appearing to be a proposal to keep it alive. A Wednesday post by Arm principal software developer Ard Biesheuvel pointed out that "The IA64 port of Linux has no maintainer, …

  1. coredump
    Pint

    Alpha > Itanium ?

    > [Linus] opined that keeping IA64 alive isn't much more onerous than the effort to keep another long-dead architecture – DEC's Alpha

    Granted, since he would probably know best; but if it came down to it, and I'm not saying it does, then I'd rather see Alpha support than Itanium. It's probably difficult to take headcount, but I wouldn't be that surprised to find the DEC Alpha population still ticking along out in the world outnumbers the Itaniums, for that matter.

    In any case, cheers to Glaubitz for volunteering to pitch in -- well done!

    1. Roland6 Silver badge

      Re: Alpha > Itanium ?

      Linus also said:

      "So I *really* don't think i486 class hardware is relevant any more. Yes, I'm sure it exists (Maciej being an example), but from a kernel development standpoint I don't think they are really relevant. At some point, people have them as museum pieces. They might as well run museum kernels."

      The question is thus how much should be in the actively developed kernel, primarily intended to run on modern architectures (*) and how much really is a downstream porting and maintenance activity, as seen with the maintenance of 32-bit Linux distributions.

      (*) Where "modern" is some intersection and compromise between usage and age and thus will change over time.

      1. Wzrd1 Silver badge

        Re: Alpha > Itanium ?

        Most distros have long dropped 32 bit support.

    2. chasil

      Alpha != Itanium

      Alpha had several problems that precluded its adoption as a mainstream ISA.

      The first was power, and DEC ended up choosing the winner themselves.

      https://en.wikipedia.org/wiki/StrongARM

      "According to Allen Baum, the StrongARM traces its history to attempts to make a low-power version of the DEC Alpha, which DEC's engineers quickly concluded was not possible."

      The second was the weak memory barriers.

      https://redvice.org/2021/memory-barriers-alpha/

      "Of relevance to this piece, however, is Alpha’s exceedingly lax memory model. Unlike ARM, which will respect data dependencies for reordering, Alpha can reorder reads regardless. This is really hard to reason about, even for people comfortable with lock-free programming."

      The third was their own software licensing, which was outrageously expensive.

      An AIX license for a single user was included in an RS/6000 purchase (participated in a 43p purchase in the mid-90s), while OSF/1 was over $40k, ruling the Alpha out. Third-party Alpha resellers with beta versions of Linux and Windows were not sufficient to overcome this.

      ARM definitely deserved to be the survivor.

      1. Mike_R
        Linux

        Re: Alpha != Itanium

        There are still several versions of Alpha emulators available capable of running (on Windows mainly, but IIRC also Linux) and at least until fairly recently a hobby site which provided OpenVMS licenses - of course not relevant for Linux.

      2. Roo
        Windows

        Re: Alpha != Itanium

        The Alpha didn't die because it was slow or had a weak memory model, it died because the folks who bought DEC had no interest in developing it - their main business was punting Intel processors - they bought DEC for the IP and customer base. Also with respect to the website memory barriers aren't "hard" to understand at all IMO, sprinkle them like confetti if you want - or just let the compiler sort it out for you. Literally was never ever a problem in the decade of cutting code for Alphas, and you could be fairly sure they'd run whatever you threw at them --ing quick - even the 5 year old dusty boxes at the back of the server room. Just speaking as someone who actually wrote code for ARM, Intel and Alpha and had to care about performance...

  2. ChoHag Silver badge

    > I always have an Itanium server ready for testing kernels that I can power on and control remotely via its built-in management system.

    So you can turn the system on to perform a build which is distributed to the other Itanium user who can turn *his* system on to verify it?

    Stage 3 is profit?

    1. Roland6 Silver badge

      I note he did not volunteer any Debian itanium download numbers…

      Or is he holding out for job in some computer museum as the maintainer of the itanium exhibit.

    2. seven of five Silver badge

      Which one is which?

      And which of them would have been the one around here by the handle of matt bryant?

  3. MarcoV

    GCC

    I assume that the team most happy to see Itanic go would be GCC, not the kernel :-) Itanium required a lot of work in the compiler.

    1. sail4sea

      Re: GCC

      Funny, but the Itanium ran three pipelines in parallel. We would write code as command/noop/noop because an optimized compiler wasn't written yet. The Itanium was a magnificent and large server though. I still have my Lion shirt from the Intel team I was on when we worked on this.

  4. DaemonProcess

    I reckon the explicit branch prediction and parallelism instruction bits took a hammering from the speculative execution bug workarounds.

    Probably runs slower than it's predecessor now.

    1. druck Silver badge

      Couldn't have got much slower!

      Back in the mid 2010s I got bored and compiled a puzzle solving problem I'd written with gcc for the many different tests machines we had in the lab, which were a verity of old Xeon E5v2s, Opteron, Sparc 64X, Power 8 and Itanium 9540 boxes. The Itanium's were the slowest of the lot, only quicker than a few ancient Atom netbooks and and the Raspberry Pi3 I had at home. My desktop machines an i5-760 and i7-4770 beat all of them.

  5. VoiceOfTruth

    This is called technical debt

    In other circumstances it would be removed. People would be told to move on (see the LibreOffice fans telling people to dump OpenOffice). This technical debt "maintained" by an army of one should be given the boot.

    1. Will Godfrey Silver badge

      Re: This is called technical debt

      If someone is actually maintaining it where is the debt?

      1. VoiceOfTruth

        Re: This is called technical debt

        Having somebody maintain software for a dead architecture is technical debt. Itanium is dead. There are good reasons why Red Hat stopped supporting it back in 2009. There is no good reason why a dead architecture should be in the main Linux kernel = technical debt waiting for the day that somebody can't be bothered to maintain it any longer.

        1. Uplink

          Re: This is called technical debt

          That someone isn't forced to do this maintenance work. They choose to do it. And it's not affecting the general product in any negative way. It's not debt. It's legacy, which is a related but different paradigm.

          When all willing maintainers go away, then of course it's a good candidate for removal if it breaks or gets in the way. Even without maintainers though, if nothing breaks or gets in the way, it's perfectly fine to have it zombie along.

        2. Michael Wojcik Silver badge

          Re: This is called technical debt

          Your two posts are the only two instances I have ever seen of someone using this peculiar meaning of "technical debt". If you're going to invent problems, perhaps you'd like to coin new terms for them, rather than using exiting ones inappropriately?

    2. Anonymous Coward
      Anonymous Coward

      Re: This is called technical debt

      To qualify as technical debt, it's presence must slow down the maintenance and development of the kernel as a whole. I would guess that the kernel is well enough designed that Itanium support is a module that does not interfere with maintenance and development of the kernel as a whole. Hence Linus saying it is not a burden just to carry it on, other than the maintenance to support that module.

  6. Stoneshop
    Boffin

    Itanic

    I always have an Itanium server ready

    Yes, electrical heating is the future, but is better done using heat pumps anyway.

    1. Michael Wojcik Silver badge

      Re: Itanic

      Hell, we not only have an Itanium HP-UX machine running pretty much all the time, we still have a PA-RISC one.

      Some of our customers take a long time to abandon platforms.

      I'll miss PA-RISC. I won't miss Itanium. Horrible for the compiler, horrible to debug at the assembly level, and things like trap representations for registers sound like a good idea, but in practice diagnosing the failures they catch is very difficult.

  7. Guy 2

    Itanium

    In mid-late noughties I ran an internal test suite on a big red database on an HP-ux itanium server and in most conditions it blew the incumbent HP-UX box/os combo out of the water! It was a vanilla Install of the os and database no tweaking. No idea how it would.have performed when tweaked. Left the role shortly after. So no idea what would have been

  8. Grogan Silver badge

    I'm always sad to hear of support for anything removed from the Linux kernel. I've always been kind of proud of its "swiss army knife" nature. It always impressed me when going through configuration categories how much old stuff it supports, not only hardware but stuff like ancient filesystems, ancient protocols etc.

    I'd have to recompile a kernel to get support for foreign partitions and filesystems, but I like that I could access just about any disk that's handed to me. It made me a hero once... a local shop had a business customer that had an old NAS with a BSD OS on it that died. They needed to get data, so he jobbed it out to me. It was just a mirror, so it wasn't hard. I even already had BSD disklabel partition support and UFS (I actually always enable those because I may have FreeBSD filesystems) on the box I use for data recovery. He had no idea what filesystem it even used. A black box, to them.

  9. quadibloc2

    Sad to See

    In a way, I was sad to see Intel dropping support for the Itanium architecture. But once that happened, this was inevitable.

    The DEC Alpha and the reasons for its being dropped have already been noted.

    But the architecture I'm most sad about losing is the 680x0; I'm still very sad that we don't still have new chips being made to this day with the full 68020 architecture - not just ColdFire - and chips which implement a 64-bit extension to the 680x0 architecture, so as to make it a fully current architecture, still competing head-to-head with x86.

    1. Anonymous Coward
      Anonymous Coward

      Re: Sad to See

      Um... is that not what these are? https://www.rocelec.com/search?q=MC68020%20MC68EC020&manufacturers=REI

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like