Announcement

Collapse
No announcement yet.

Linux Looks To Retire Itanium/IA64 Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by coder View Post
    The people I knew who actually used OS/2 liked it! These included the first person I knew who ever ran Linux (back in the pre-1.0 days) and the software development team at my first job.
    That includes me as well. I dual booted Warp 4 with Windows 98 way back when. It was a great OS for audio, video, and non-gaming desktop usage, but by the very early 2000s it was obvious that Linux and other FOSS were starting to take off.

    Comment


    • #52
      Originally posted by toves View Post

      I can confirm HPUX 8.X ran on M68000 based HP hardware. I had such a system attached to an old mass spec in the mid '90s. From memory it was BSD based compared with HPUX 9.X running on the Apollo Domain PARISC 1.X (700 series) workstations which was more System V.3 and more so with HPUX 10.X. The M68000 might have been HP1000 hardware?

      All a bit vague now - only remember it because I rolled up with a HPUX 10 install CD to upgrade the OS
      Not a 1000 - those were technical minicomputers running an HP-proprietary instruction set and OS (RTE.) 68k systems running UX would be the 9000/[200,300,400]; the 700 was PA, as you note, and the 500 was the FOCUS processor HP built off of HP3000 commercial minicomputer bits.

      I never had the fortune of touching the pre-PA UX systems. I have a little exposure to the 1000, though, and a lot of quality time with both PA and IPF.

      Comment


      • #53
        Originally posted by EphemeralEft View Post
        Damn, 65k lines?! Isn’t it the compiler’s job to port architecture-agnostic code to architecture-specific instructions? Or is all that code just drivers?
        Yes but kernel operates directly on hardware and it needs to deal with low level things. There are some things that you can't do that from higher level code and you need to use assembly for that. Assembler is not portable so every architecture needs its own assembly code. For example if you do some operation that puts result into register and you want to get it, on one architecture it will be available in register A and on other architecture in register B. So you need two codes to get same result. Aside from that there are many differences on how architectures deals with several things (like memory management etc.) and even if you can deal with them with C or other higher level language code, you need to do it differently for each architecture. If you sum those things you can easily get thousands of code specific for some architecture.

        Generally portable kernels separate those architecture specific things from common code, they wrap them into functions that common code can use in the same way no matter on what architecture it's running. If you check Linux source code you will find "arch" directory. This is where architecture specific code lands. Inside this directory you will find directories named like architectures, each for supported architecture.

        Comment


        • #54
          Originally posted by skeevy420 View Post
          It was a great OS for audio, video, and non-gaming desktop usage, but by the very early 2000s it was obvious that Linux and other FOSS were starting to take off.
          Once IBM lost the legal battle with Microsoft over natively executing Windows executables, IBM pulled the plug on it very quickly.

          I had first installed Linux 0.9 on a 386, back in the mid-90's. But, I didn't really use Linux @ home seriously until I was in my second job, where we used it for software development. That was the level of immersion I needed, in order to fully adapt from Windows. And having grown up on DOS, that's probably saying something.
          Last edited by coder; 15 February 2023, 10:01 PM.

          Comment


          • #55
            Originally posted by coder View Post
            Once IBM lost the legal battle with Microsoft over natively executing Windows executables, IBM pulled the plug on it very quickly.

            I had first installed Linux 0.9 on a 386, back in the mid-90's. But, I didn't really use Linux @ home seriously until I was in my second job, where we used it for software development. That was the level of immersion I needed, in order to fully adapt from Windows. And having grown up on DOS, that's probably saying something.
            The joke's on them. I didn't leave due to lackluster Windows compatibility. I left because GNOME had a kickass desktop. Ironically, Windows compatibility is a necessity these days.

            While I don't remember the exact software versions of everything, Debian 3.0 was the first Linux distribution that I really liked and stuck with. While I had dabbled with Slackware, Red Hat (pre-RHEL), and a bunch of other random operating systems Debian circa 2002, junior in high school, is when I made the switch for good and ditched Windows. It was really damn easy since I didn't game on PC nor was I tied to any specific program. Back in those days long as I had worth a shit audio, video (including DVD), and picture viewers I could make an OS work.

            Comment


            • #56
              If they release the first Itanium in 2021 not 2001, would everything goes better? Because in HPC field one of which Itanium promised to conquer, pure 64 software environment is popular(or ubiquitous if I'm right) nowadays.

              Comment


              • #57
                Originally posted by coder View Post
                All that means is that you're not a low-hanging fruit for ransomware gangs. However, people running it might be sufficiently juicy targets that it's worth attackers' time to put in the work. Government agencies, likely on both sides.
                Possibly. But you have to have someone well versed in OpenVMS to exploit OpenVMS along with the hardware to poke. You don't turn those up easy. Like I said, the security threat assessment changes to those with real resources (which won't be most criminal gangs, script kiddies, Iran, North Korea, panhandlers masquerading as security researchers, etc). This leaves you better able to concentrate on identity & communications security, and credentials management with your employees and less on worrying if the current patch series will break something critical when you roll it out before kiddies get their hands on off-the-shelf exploit kits in a few hours at most.

                There is some security in obscurity. It just shouldn't be one's only defense.

                That doesn't mean I'd walk back my recommendation to my employer. But I would be advising similar considerations if the business can afford it, the software exists to make it work in the current business environment or can be created, and there's a way forward on the platform while maintaining a stable foundation without trying to follow every computing fad that comes along ( which is what Microsoft, Apple, Google, Intel, etc... are largely doing; pushing fads and gimmicks to make sales). Those platforms do exist, but they aren't cheap. Which is why they exist: the client pays not to be the product and has enough power to enforce contractual privacy guarantees.

                Comment


                • #58
                  Originally posted by coder View Post
                  These claim to support Linux, but I haven't investigated to see which kernels/distros/etc.:
                  I'd imagine "which kernels" is up to Linux upstream. Those are what you use to build a Weecee, IIRC, they're something like "i486 implemented in microcode" and compatible enough to run vintage DOS or Windows for the purpose of non-3D-accelerated gaming. (Just don't expect to get anywhere near the performance the raw clock speed would imply.)

                  My guess is that the niche they're targeting is providing non-aging hardware for business-critical software that the business has lost the source code for.

                  Comment


                  • #59
                    Originally posted by coder View Post
                    Probably the worst legacy of IA64 is the lesson Intel seems to have taken to stay away from anything non-x86. I suspect that influenced their decision to base Larrabee on x86, rather than their iGPU ISA. Had they made a different choice, the past decade of GPU development might've looked very different.

                    The curse of IA64 might still haunt Intel. I predict they'll keep all their CPU eggs in the x86 basket for too long.
                    To be fair though, it was like the third time Intel tried to move to something non-x86 and the third time it blew up in their face.

                    Comment


                    • #60
                      Originally posted by coder View Post
                      The people I knew who actually used OS/2 liked it! These included the first person I knew who ever ran Linux (back in the pre-1.0 days) and the software development team at my first job.
                      Yep it was awesome, cheap and stable. Just too bad nothing supported it.

                      Comment

                      Working...
                      X