Slashdot Mirror


HP Still Porting Linux to 64 bit PA RISC

Fungai wrote with an update to the on-going HP/Puffin Group story. There'd been some confusion with the recent purchase of Puffin Group by Linuxcare, but HP has confirmed that they will port Linux to their 64 bit PA-RISC chips. HP will still be partnering with Puffin Group to do it, with results expected in the first half of 2000.

51 comments

  1. Just a question by choctaw · · Score: 2

    Has anyone here used a RISC processor? I haven't, and I'm curious as to the performance level of these things running Linux....

    1. Re:Just a question by NYC · · Score: 3
      Apple and SGI computers are some examples of machines that run on RISC processors.

      Apple computers are known for their amazing speed (the latest G3s were not suitable for export) but their inferior OS loses any benefits in speed gained from the hardware. Of course, you can always install a RISC-based version of Linux like mklinux on a Mac.

      SGI machines like the Origin server series are among the fatest computers in commercial use today. My SGI O2 workstation is only 200MHz, but since the processor is a RISC processor, it is comparable to a 300+MHz CICS processor.


      --Ivan, weenie NT4 user: bite me!

      --
      --weenie NT4 user: bite me!
      "Computers are nothing but a perfect illusion of order" -- Iggy Pop
    2. Re:Just a question by Myddrin · · Score: 1

      Well, I've used a 32 bit RISC (the PowerPC 603e), with linux and I'm pretty satisfied. The only problem is that intel is just about the only system that seriously gets supported. So things most closed-source products like Metrowerks or Corel Wordperfect don't work.

      However in terms of the feel of things I'd say my 603e @ 200Mhz "feels" roughly like a Pentium 233-266. (Both on linux, as long as I'm not doing heavy disk access or 3D stuff.... The linuxPPC scsi/ide drivers seem out of whack to me, but I could be wrong)

      As a development machine/webserver, it's great, but like I said if you wanna run a lot of closed-source stuff, that's a different story. (I just got word for Loki that QIIIA won't be available for LinuxPPC for quite a while. sigh, guess I'm gonna have to go buy _another_ computer. :) )

      --
      Myddrin
    3. Re:Just a question by Tower · · Score: 2

      Alphas are RISC, and Linux has run (extremely well) on them for quite some time now. The floating point performance on the alphas is incredble - they work great.

      --
      "It's tough to be bilingual when you get hit in the head."
    4. Re:Just a question by Anonymous Coward · · Score: 0

      Running three Alphas (2 21064A-275, 1 21164A-500) on Linux, NetBSD and Digital Unix 4.0D. Running a Moto MBX (604e-350) on LinuxPPC.

      64-bit binaries are rather large in comparison to 32-bit (and RISC binaries are necessarily larger than x86), but the 128-bit memory bandwidth easily makes up for this...

      The floating point performance of Linux/Alpha absolutely trounces the PPC and x86, despite the poorly optimised libm - Alpha absolutely flies on DU4.0.

      With inexpensive 21164 Alphas available (I've seen 21164A systems under $2K), it's hard to imagine why anyone would consider x86 or PPC where high FP performance is an issue.

      ~AC

      PS - Best of luck to the PA-RISC porting effort!

  2. Pre 64-bit machines by Banshee · · Score: 1

    What does this mean for the 700/800 series machines and the porting effort there? I myself own 2 700 series machines that I would like to have Linux running on. Now true I wouldnt mind buying a J7000 but I think economically isn't there going to be more likeliness of people buying older Nova class and the K,R,D, and B series?

    MaShaun Jones

    1. Re:Pre 64-bit machines by Ranger+Rick · · Score: 1

      It's not necessarily a matter of *buying* old ones... at work we've got a TON of old D classes sitting around doing nothing that I would love to put linux on to play with :)

      --

      WWJD? JWRTFM!!!

    2. Re:Pre 64-bit machines by Anonymous Coward · · Score: 0

      Right-o. I've got a customer that just powered-down a bunch of PA-RISC machines running MPE (a legacy minicomputer OS made by HP). The machines are pretty large and it would be expensive to even get rid of them. Linux would be a perfect way to inexpensively recycle them as departmental servers or whatever.

  3. So Linux is being ported to yet another platform by dodobh · · Score: 1

    The more the merrier. So now we have the Mer^H^H^HItanium, now the HP processor...

    Well, best of luck geeks. Heres hoping that Linux will run on another platform soon.

    On an offtopic note: I tried posting this story earlier, but /. was down (or /.ed). Rob, could you please inform us of possible downtimes before hand. Not all of us have free local calls. :(

    --
    I can throw myself at the ground, and miss.
  4. 64b Linux and 2GB files by MattMann · · Score: 1
    From what I know of the 2GB filesize limitation, it goes away with 64 bit processors, right?

    And the 2038 problem too?

    Are there other interesting things that get cleaned up, or turn out to be gotchas?

    1. Re:64b Linux and 2GB files by met · · Score: 1

      The 2GB limitation has already been fixed in newer kernels, you can use files > 2GB with 32 bit processors now.
      Don't know about the 2038 problem - might be a glibc issue, but I'm not sure...

    2. Re:64b Linux and 2GB files by Anonymous Coward · · Score: 0

      One poster aluded to this, but clarification may be in order. 64bit hardware *allows* a Unix-like OS to extend clock rollover for a looooong time. However, the OS *itself* must take advantage of this capability. Can a kernal guru enlighten us on status of Linux in this regard ?

    3. Re:64b Linux and 2GB files by Anonymous Coward · · Score: 0

      The Linux kernel works in the right way -- on 64 bits there's no problem in 2038.

    4. Re:64b Linux and 2GB files by Anonymous Coward · · Score: 0

      Linux on 64-bit chips already uses a 64 bit time_t, so there is no rollover.

      glibc presently uses a 32-bit time_t on 32-bit platforms, so current i386 programs for instance will rollover at 2038.

      This may be fixed in the next glibc, although you will have to recompile your old applications to take advantage of it. Also, using a 64-bit time_t on a 32-bit platform adds extra overhead.

  5. Links by NYC · · Score: 2
    Here are some links to linux ports on RISC processors:

    Apple Macintosh

    SGI
    --
    --weenie NT4 user: bite me!
    "Computers are nothing but a perfect illusion of order" -- Iggy Pop
  6. Performance kick ass... by krynos · · Score: 1
    I have access to a HP Vizualize workstation, dual 440 Mhz processor, each is somewhat faster than what a Pentium 3 at 800 would give and architecture is somewhat better and it can use PCI cards and USB components (if drivers exist)...

    As for class N machines a recent one will have at least 2 processor (what we have is 2 class N with 4 processors each and a shared Raid Array)... These machine are physically huge, they are extremely fast and extremely expensive. They have much better performance than you can have with any x86-based computer right now. They don't have a great price/performance ratio, but sometime you need the performance they deliver...

  7. Great, but does it matter? by Anonymous Coward · · Score: 0
    Is anyone really in the market for a PA-RISC system these days? It appears that this is more for HP PR than anything else.

    HP needs to generate some sort of buzz for PA-RISC - Merced is late and Sun and IBM are stealing the unix market from them.

    1. Re:Great, but does it matter? by dillon_rinker · · Score: 2

      Isn't it interesting, then, that the way they generate buzz for their box is to port Linux to it?

    2. Re:Great, but does it matter? by Master+Bait · · Score: 1
      HP is smart to continue to develop the PA-RISC.

      Intel's work (adding legacy 386 baggage) has made the Merced/Itanic slow and late.

      If AMD's 64-bit 386 instruction set cpu is a winner, Intel will drop the Itanic like a hot potato and where would that leave HP?

      --
      "Only in their dreams can men truly be free 'twas always thus, and always thus will be."
      --Tom Schulman
  8. Bah Humbug! by The+Variable+Man · · Score: 1
    I posted this story a couple of hours ago but I'd still like to add my thoughts..

    This is a good thing for Linux, but a better one for HP. Just when you thought they'd put all their eggs in the IA64 basket... Out pops Linux on 64-bit PA RISC and a nice new hardware revenue stream for HP.

    The-cynical-but-fond-of-risk-Linux-user
  9. Not blinding speed or price-performance by twit · · Score: 3

    I think (the eternal IMHO) that the major advantage that a PA-RISC port presents is not blinding speed on the desktop or price-performance, but access to a family of mission-critical hardware. Linux, developed on PC's and ported to a wide range of workstation hardware, has historically been short on big iron. Access to PA-RISC hardware, whether legacy or new machines, will go a long way towards remedying that deficit.

    If people (myself among them) spoke out against linux's reliability on commodity hardware, no one can question the reliability and stability of HP's unix hardware. It would be easy to sell me on a HP unix box running Linux - or at least, it would be, if I was still doing that kind of stuff.

    --

    --

    --
    There is no premature anti-fascism. -Ernest Hemingway
  10. The point? by Signal+11 · · Score: 2

    Why can't linux people just accept that their OS' niche is a unix-like OS running on commodity hardware? We've seen another good example of an OS that tries to be all things, and look how it failed. Do we really want to take the industry down that path again? Linux works exceptionally well on the hardware it was designed for: namely, x86 hardware. It runs on macintoshes, HP machines, Alphas, and god only knows what else... but those are all inferior ports.

    Code sharing is good. Code bloat is not. My vote is to fork the existing ports into seperate kernel dev teams and refocus linux. If we spread ourselves too thin, we'll release about as often as Microsoft. *stepping down off the soap box* Mark me down now.

    1. Re:The point? by franl · · Score: 1
      Only a tiny portion of the Linux kernel code is CPU-specific. The filesystem, scheduling, IPC, networking, and terminal subsystems are all CPU-neutral. Forking the entire kernel on a CPU-by-CPU basis isn't necessary.

      It runs on macintoshes, HP machines, Alphas, and god only knows what else... but those are all inferior ports.

      Care to supply some evidence of that alleged inferiority? Even just saying how they're inferior would be a start. They can't all be inferior in the same way.

    2. Re:The point? by Ami+Ganguli · · Score: 2

      I'm not sure how 'code bloat' gets into this. The support for a given platform is compiled in only for that platform so it doesn't really matter how many platforms are supported.

      'Spreading ourselves too thin' might appear to be a valid critisism, except that the same people aren't maintaining all the ports. HP wants a port to their hardware, so they're paying people to do it. The burden on the core developers is minimal, PLUS the HP (actually Puffin Group) staff might find solutions to problems that could benefit everybody.

      The beauty of having lots of platforms is that we can move easily from one 'commodity' platform to another as the economics change. ia32 hardware may provide a nice price point today, but if AMD or Transmeta or Sam's Chip Factory comes up with a fast, cheap platform, we know the transition will be easy and smooth.

      I suspect that the ia64 port would have been far more difficult had 64-bit support not already been in place for Alpha. Similarly, changes introduced for ia64 will probably be good for Alpha, Sparc64, and HP. I just don't see the down side that you you're worried about.

      --
      It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
    3. Re: The point? by rkms · · Score: 1

      Why can't linux people just accept that their OS' niche is a unix-like OS running on commodity hardware?

      Because it isn't?
      Seriously, Linux is the first operating system that I have ever seen that isn't in a niche. True, it has its roots on i386 commodity boxes, but it has been designed properly and runs well (and without nasty compromises) on more stuff that just about any other OS.

      Do we really want to take the industry down that path again?

      Nobody is taking the industry anywhere. The industry is scrabbling to follow.

      Code sharing is good. Code bloat is not.

      While it is true that the Linux codebase will always expand (unless legacy support is elected to be removed) the runtime of any particular port does not have to be that huge.

      My vote is to fork the existing ports into seperate kernel dev teams and refocus linux,

      Separate teams are precisely what the subject of the original post was about: the Puffin Group is one such, working on 64 bit PA-RISC; Trillium is another, working on IA-64. I don't see that there is any lack of focus.

      --
      C-x C-s
    4. Re:The point? by sterwill · · Score: 3

      Inferior ports?! You are just completely wrong! Tell me which "inferior ports" you've actually _used_ (installed, used, and maintained). Projects you've "heard about on Slashdot" do not count. I'll wager you haven't actually used Linux on real hardware (something that's evolved since 1980, like the Alpha, Sparc, or PowerPC, or MIPS, or PA-RISC), or you'd know just how exactly ignorant your assertion is.

      I wrote this comment on a 333 MHz PowerBook running Linux 2.3.22, in X at 1024x768 at 32 bpp, with all the software I need to get all my work done. Every piece of hardware is supported, and it's a better laptop value than any Intel-based offering. The 56K internal modem works, the 10/100 Ethernet works, the 14.1" screen is beautiful, the media bays (batteries, CD-ROM, DVD-ROM) work great, power management is superb (5 hours off a single battery), audio in and out, two completely useful USB ports (one of which runs a Logitech mouse when I'm parked at a desk), and even S-Video _and_ VGA output, and external SCSI. All of this with no "docking stations" -- the ports are right on the back. And they're $2499.

      I also use Linux on the Alpha, and the Alpha architecture is supported as well as, and possibly better, than the PowerPC architecture.

      Have you run any of these?

      --

    5. Re:The point? by Anonymous Coward · · Score: 0

      My vote is to fork the existing ports into seperate kernel dev teams and refocus linux.

      Isn't this effectively what happens now? My understanding is that in any given released kernel, the archs other than x86 might not even compile, much less work properly. Occasionally the different dev teams sync up with Linus. Certainly ports of all of the non-kernel software is handled by outside teams (usually distribution vendors for the various platforms).

      Don't forget, the kernel comes as one big tarball because that way is easier for the dev group, not because that's the best distribution for users. Anyone can repackage it and distribute it anyway they want, and that's exactly what RedHat and others do.

    6. Re:The point? by The+Madpostal+Worker · · Score: 1

      Yes.. sure.. that will happen.. about as soon as M$ realized that their niche is a unstable, bloated OS running on expensive hardware or in a trashcan. I prefer the second. Linux's power (while it is not the only free unix clone) is in its cost and functionality. So that school cant afford IRIX 6.1 for the donated indy2... put linux on it.. need to make a router.. put linux on it.. not start a debate on linux in the enerprise.. but the power of linux is on old and obscure hardware.. and that may include the latest RISC chip. just my thoughts --- rm -rf /* is a good password... just dont type it twice

      --

      /*
      *Not a Sermon, Just a Thought
      */
  11. Why PA Risk? Alpha's are faster and cheaper. by Anonymous Coward · · Score: 0


    And Alpha's have been running Linux almost from
    day one.

    HP should spend some of that money on alpha instead.

    just check out this site.

    www.dcginc.com

    They have a 700Mhz Alpha 21264 system using the
    AMD Irongate chipset for just $5000.


    700Mhz EV6 system

    Or screaming Dual 750Mhz Alpha 21264 system with
    all the frills for just $15000
    mind you thats with 8MB of cache per processor.

    DUAL 750 Mhz Alpha 21264 System with 16MBytes of cache

    looking up the spec site we see that a 700Mhz EV6 gets 39.1 specINT and 68.1 specFP.

    scaling that these 750Mhz 21264's should have
    42 specINT and 72 specFP


    On a side note does HP think IA64 will not
    be as hot as once predicted.
    why are they now pushing linux for PA Risk.
    if they are going to abandon PA Risk in a year or two
    why start now to port linux?

    Or is HP going to pull an SGI :)

    Oops. PA Risk=PA-RISC.

    1. Re:Why PA Risk? Alpha's are faster and cheaper. by Anonymous Coward · · Score: 0

      I am an Alpha booster too but I think you are a bit off base bashing PA-RISC. The HP PA-RISC designers have been the only guys to consistently keep up with Alpha and occasionally snag the lead for a month or two at a time. PA-RISC systems are fine machines (and I writing this on one now albeit under HPUX rather than Linux)

      I am glad HP is always there nipping at team Alpha's heels. We get faster high end RISCs sooner and both Alpha and PA-RISC keep the RISC flag
      comfortably ahead of x86 instead of embarassingly behind like SPARC, MIPS, and PowerPC.

      Given the dismal state of Merced, I wouldn't be suprised if HP doesn't put even more effort into PA-RISC. An eight wide SMT PA-RISC machine might run rings around McKinley. Go for it!

    2. Re:Why PA Risk? Alpha's are faster and cheaper. by Anonymous Coward · · Score: 1

      I was not bashing PA-RISC, (well not very much) just stating the facts. maybe this will prod them to release their PA-8600 sometime. :) MIPS(high end) is already on life support. (the doctors are just talking about when to pull the plug) SPARC just fell down and is pulling its emergency response key. if USIII does not show up soon SPARC may be on its way to the emergency ward. PA-RISC is in a deep coma. Limbo land. The problem I see is that they have allready commited to IA64. most of HP's brain trust is working on Mickinley. and the left over is working on PA-8600. Do they have the resources to start a new design now? and if they did when will it be done? I think a lot of these companies and consumers too. need to wake up and realize that having one company make all the chips is a bad thing. So I still hope for a miracle to revive the alternative cpu market as well as the alternative OS market.

    3. Re:Why PA Risk? Alpha's are faster and cheaper. by Anonymous Coward · · Score: 0

      I was not bashing PA-RISC, (well not very much)
      just stating the facts.
      maybe this will prod them to release their PA-8600
      sometime. :)

      MIPS(high end) is already on life support. (the doctors are
      just talking about when to pull the plug)

      SPARC just fell down and is pulling its emergency response key. if USIII does not show up soon
      SPARC may be on its way to the emergency ward.

      PA-RISC is in a deep coma. Limbo land.
      The problem I see is that they have allready
      commited to IA64. most of HP's brain trust is
      working on Mickinley. and the left over is working
      on PA-8600.

      Do they have the resources to start a new design
      now? and if they did when will it be done?

      I think a lot of these companies and consumers too. need to wake up and realize that having one
      company make all the chips is a bad thing.

      So I still hope for a miracle to revive the
      alternative cpu market as well as the alternative
      OS market.

    4. Re:Why PA Risk? Alpha's are faster and cheaper. by Anonymous Coward · · Score: 0


      Is Merced compatible with PA-RISC? If so, it might give them an entry back into the workstation and low-end server market, especially since customers will be able to run a number of OSes on Merced.

    5. Re:Why PA Risk? Alpha's are faster and cheaper. by corporateSlave · · Score: 2
      PA-RISC is in a deep coma. Limbo land. The problem I see is that they have allready commited to IA64. most of HP's brain trust is working on Mickinley. and the left over is working on PA-8600.

      Do they have the resources to start a new design now? and if they did when will it be done?

      HP corporate press and some analysts (Gartner?) disagree with the death of PA-RISC. If this PR is correct, HP must already be working on at least PA-8700. The .hp.com in my e-mail address means I can't comment further. And even when PA-RISC dies, the ideas aren't completely dead. Does the IA64 instruction set look more like Pentium or PA-RISC?

      Seems to me some people will feel comfortable going to IA-64 right away, and some will probably take a while. Just think how many folks are still running really old OSes. There'll also probably be a short period where the performance of PA-RISC and other current processors overlaps with IA-64 performance, just as there is probably some overlap between Pentium and PA-RISC today.

      Linux on PA-RISC gives people the option to convert to Linux sooner and/or cheaper, either converting their existing HP boxes or purchasing new ones, and then switch to Linux on IA-64 later -- two small steps instead of one large one. (Some will continue using HP-UX of course)

      This sounds like customer choice, which seems like a good idea.

      But the best reason for Linux on PA-RISC is that I have fun helping make it happen!

    6. Re:Why PA Risk? Alpha's are faster and cheaper. by Anonymous Coward · · Score: 0

      If this PR is correct, HP must already be working on at least PA-8700.

      Wow does HP already have the specs for intel's P860 process?

      Nice to know HP is still working on PA, but
      should they put more effort getting PA-8600 out the door first.

      when PA-RISC dies, the ideas aren't completely dead,
      Does the IA64 instruction set look more like Pentium or PA-RISC


      the latter but, HP controls PA-RISC, HP does not
      control IA64.
      my feeling is after Mckinley ships. Intel will
      control both the arch and implementation of all
      future IA64 processors.

      HP can build cool servers and whatnot with its PA-RISC now, and I presume with mckinley too. (to some extent).

      but wait a couple of years and HP will be buying
      and reselling Intel IA64 server hardware building blocks like they do now with IA32.

      this may be good news for HP, or maybe not.

      There'll also probably be a short period where the performance
      of PA-RISC and other current processors overlaps with IA-64 performance


      How short do you think this will be? one year
      or several decades?

      HP's own performance data on the website shows.
      PA-RISC
      with about equal or greater performance than Merced and Mckinley.

      That's 3 years already. for an arch that is in a 'Just shrink me mode'

      Yeah, good luck with linux. and PA-RISC.
      I bet more people will want your big-iron PA systems
      than dell's new IA64-systems.


      Are you working with Merced (erhh iTanium), proto systems?

      -- A bunch or questions you will not answer

      What MHz are they?
      How fast are they?
      How much power do they consume?
      when will HP start selling them?
      will I need take out a second morgadge?
      Can you post some spec marks?
      How fast will Mckinley be?
      What is exactly different between Merced and Mckinley?
      When is Mckinley going to tape out?
      What cool stuff does HP plan to include in
      your chipsets.

    7. Re:Why PA Risk? Alpha's are faster and cheaper. by corporateSlave · · Score: 1
      the latter but, HP controls PA-RISC, HP does not control IA64. my feeling is after Mckinley ships. Intel will control both the arch and implementation of all future IA64 processors.

      That wouldn't seem logical if this earlier announcement is true.

      but wait a couple of years and HP will be buying and reselling Intel IA64 server hardware building blocks like they do now with IA32.

      It wouldn't surprise me if the part of HP currently selling high-end IA32 boxes goes this way.

      There'll also probably be a short period where the performance of PA-RISC and other current processors overlaps with IA-64 performance

      How short do you think this will be? one year or several decades?

      My personal opinion is the longer overlap with existing and new processors the better -- competition is good.

      Yeah, good luck with linux. and PA-RISC. I bet more people will want your big-iron PA systems than dell's new IA64-systems.

      Hope so.

      Are you working with Merced (erhh iTanium), proto systems?
      -- A bunch or questions you will not answer

      Some of my friends are working on IA64 stuff. I've used the IA64 simluator but haven't seen the actual working hardware yet.

  12. 2038 by Anonymous Coward · · Score: 0

    It's not a glibc issue as much as a Unix issue. Unix systems count time with the assumption that 1970 was the beginning of time. The count is stored in a datatype known as "time_t". On 32-bit systems, this value will overflow around 2038.

    64-bit systems will allow time_t to be defined to a larger datatype and will allow for exponentially larger values.

    1. Re:2038 by MattMann · · Score: 1
      shucks, the original 32 bits lasted 68 years, and now that's been multiplied by 4 billion... that's an awfully long time, overkill even. I guess it would introduce too many weird incompatibilities, but wouldn't it be handy if time_t had a few of its 64 bits dedicated to fractional seconds? nah, usleep already confuses me.

      An off-the-64bit topic question: when astronomers and nuclear physicists decide that we need a leap second, what happens to UTC? does Unix-midnight and midnight in Greenwich England no longer coincide because the number of seconds since 1970 no longer evenly arrives at date boundaries?

      BTW, thanks for all of the other answers, everybody.

    2. Re:2038 by Xenu · · Score: 2
      The leap second is normally inserted at the end of the last day in June or December. The last leap second was added to December, 1998. The sequence was:

      1998-12-31 23:59:59
      1998-12-31 23:59:60
      1999-01-01 00:00:00

      Note that there can be 61 seconds in a minute when a leap second is inserted.

      Some Unix systems pretend that leap seconds do not exist, others attept to take them into account, using tables of leap seconds. It might be better to run the system clock on TAI and convert to UTC or local time with a leap second table.

  13. HP3000 too? by otis+wildflower · · Score: 1

    Will the port run on HP3000/MPEiX boxes as well?
    Your Working Boy,

    1. Re:HP3000 too? by Anonymous Coward · · Score: 0

      No, those are based on Motorola 680x0 CPUs, not PA-RISC.

      You can find a Linux port for that hardware at:

      www.linux-m68k.org

      NetBSD also has support for the HP3000.

    2. Re:HP3000 too? by john1 · · Score: 1

      >No, those are based on Motorola 680x0 CPUs, not PA-RISC.

      No, the HP3000's are PA-RISC based (except for the REALLY old ones)
      systems that run HP's MPE OS. You're thinking of the 300 series
      workstations, that pre-dated the motorola based 400 series workstations,
      which in turn predated the pa-risc based 700 series workstations.

      HP3000's are still available today.

    3. Re:HP3000 too? by Anonymous Coward · · Score: 1


      My understanding is that there is little difference between the 3000's and the 9000's, except for the model number sticker. If so, there should be no problem with the Linux port.

  14. mkLinux by Anonymous Coward · · Score: 0


    mkLinux (a version of Linux based on a Mach kernel) is really only used by people with Nubus-based PowerMacs. These were only sold in the 1994-96 time period.

    Modern PCI Macs run the normal Linux kernel. For Mach fans, Apple is distributing the beginnings of an OS based on Mach and BSD called "Darwin".

  15. Cost-Benefit situation by cnflctd · · Score: 1

    I don't know how much HP has paid to Puffin-and-friends to port the kernel (though I bet equipment makes up a big chunk of the total). A few million dollars, at most.

    Now consider all the customers who've spent billions over the years to run their businesses with HP equipment. With the great and growing value of open source, why on earth would you deny them access? How rude!

    This is reason IBM whipped up a custom kernel for their mainframe customers. Negligible cost for ever increasing benefits.

    disclaimer: I've only worked on IA-32, but I saw an HP server cube once (HP9000 IIRC).

    --
    I'm cool like a fool in a swimming p-p-pfft-pool
  16. PA-RISC rox by k00ld00d · · Score: 1
    I have the pleasure to work on PA RISC Systems from time to time, and I absolutely love them. PA-RISC is a beatiful, somehow strange and verrrry fast CPU, the only one to keep up with the Alpha lately.

    All other RISC CPUs (MIPS, USPARC, and esp. Power(PC),...) have fallen behind the Alpha and PA-RISC, and if I had to chose one of the two for my desktop, I think I would chose the PA-RISC. Sure, the Alpha 21264 is a little faster, but the overall Quality of the HP hardware is hard to beat.

    We have some really old PA-RISC Workstations (~1990) and they are still in best condition and fun to work with. These machines are astonishingly fast for their time. An ancient PA-RISC 7100 is as fast (INT) as a PPro at half the clock speed, and competes with a P2/400 at FP - running at a 5th of the clock speed!

    P.S.: Don't be fooled by the PowerPC and Apples stupid "supercomputer" campaign. Even the G4 is horribly slooowwww for a RISC CPU, even in FP. A fast CISC Athlon still beats it any day of the week. And x86 have broken the GFLOP barrier almost a year before Apple with their G4. If you want a real computer, don't go for Apple toys.

  17. Ummm.... by Anonymous Coward · · Score: 0

    Do you actually plan on using your current computer until the year 2038? Don't worry about it.

  18. DVD by Anonymous Coward · · Score: 0

    I bet you can really watch those DVD movies.

  19. Re:BBBBBBBBEEEEEEEEEEEEEEEEOOOOOOOOOOOOCCCCCCCCHHH by A4Joy · · Score: 1

    Beeoooch? What the hell is that?

    Oh, I get it. Object-oriented methodology wrestling.

    Let's get ready to RUMMMMMMM-BAUGH!

    :-)

  20. And there's an error in ANSI-C ! by Anonymous Coward · · Score: 0

    Well, it assumes there can be 62 secs in a minute which is not true. Well, sh** happens ;-) AC

    1. Re:And there's an error in ANSI-C ! by Detritus · · Score: 1

      That might have been thinking about a year with two leap seconds, with both leap seconds inserted at the same time. The literature says that the rule is to keep UTC within 900 ms of UT1 (astronomical time). If multiple leap seconds are needed, they would be inserted on different dates, say the end of June and December.

      --
      Mea navis aericumbens anguillis abundat