Slashdot Mirror

Thanks to some of the folks from SGI for sending us some information about their latest project. Pretty interesting project -- the largest configuration has 10 PCI busses (busi?) with 24 scsi controllers and 10 disks. And wait'll you see the rest of the stats.

Hi all,

Just thought I would send out a note outlining the state of the mips64 port. Ralf, Ulf and I have been actively working past few months to bring up Linux on the SGI ccNUMA machines.

The executive summary: we have achieved multiuser boot on o200 and o2000s. The largest configuration is a 32p, 16node machine (only approx 4G worth of memory was populated over the 16 nodes, the system can take 4G * 16 node worth of memory). This machine has 10 PCI busses, with 24 scsi controllers and 10 disks. (Sample output is at

OSS SGI

If you are interested in the system architecture and details of the port, read on. The o2000s use R10000 series of MIPS processors. Each machine is comprised of modules, each module has 4 node boards with max 2 cpus and 4G memory on each node, and IO boards and routers. In a module, the two alternate node boards are each connected to a XBOW. Each XBOW possibly is connected on the other side to a number of PCI busses, which is what the IO boards connect to. Apart from this, there are routers in the system that provide connection paths between all memory to all cpus, to create a true CC-NUMA architecture.

On the software side, we are still struggling with compiler and binutils issues. The kernel itself is 64 bits, created by cross compiling on an ia32 box. We have not attempted 64 bit user program compilation or execution. The root disk is currently very close to the MIPS/Indy root disks. The architecture specific code uses the CONFIG_DISCONTIGMEM code to support memory on all nodes. The architecture specific NUMA features currently are: 1. replicate the kernel text on all nodes, so that no one node becomes a memory hot spot (unfortunately, the kernel data has to reside on only one node). 2. replicate low level excpetion handler code on all nodes. The architecture code also turns on CONFIG_NUMA to take advantage of node-local page allocations. (A CONFIG_NUMA patch that I have been submitting to Linus was put into the kernel in test6-pre1). For more information on NUMA and ongoing work, refer to

this document

The purpose of doing this port is to boot Linux on bigger systems that we have, in order to do cpu/memory scalability studies. This also lets us do NUMA performance work in the future. Another advantage is to be able to leverage this work on the upcoming SGI CC-NUMA Itanium boxes, which will be an SGI supported product. Initial results from scalability studies using mips64 is documented at

The OSS SGI site.

Kanoj

Thanks to some of the folks from SGI for sending us some information about their latest project. Pretty interesting project -- the largest configuration has 10 PCI busses (busi?) with 24 scsi controllers and 10 disks. And wait'll you see the rest of the stats.

Hi all,

Just thought I would send out a note outlining the state of the mips64 port. Ralf, Ulf and I have been actively working past few months to bring up Linux on the SGI ccNUMA machines.

The executive summary: we have achieved multiuser boot on o200 and o2000s. The largest configuration is a 32p, 16node machine (only approx 4G worth of memory was populated over the 16 nodes, the system can take 4G * 16 node worth of memory). This machine has 10 PCI busses, with 24 scsi controllers and 10 disks. (Sample output is at

OSS SGI

If you are interested in the system architecture and details of the port, read on. The o2000s use R10000 series of MIPS processors. Each machine is comprised of modules, each module has 4 node boards with max 2 cpus and 4G memory on each node, and IO boards and routers. In a module, the two alternate node boards are each connected to a XBOW. Each XBOW possibly is connected on the other side to a number of PCI busses, which is what the IO boards connect to. Apart from this, there are routers in the system that provide connection paths between all memory to all cpus, to create a true CC-NUMA architecture.

On the software side, we are still struggling with compiler and binutils issues. The kernel itself is 64 bits, created by cross compiling on an ia32 box. We have not attempted 64 bit user program compilation or execution. The root disk is currently very close to the MIPS/Indy root disks. The architecture specific code uses the CONFIG_DISCONTIGMEM code to support memory on all nodes. The architecture specific NUMA features currently are: 1. replicate the kernel text on all nodes, so that no one node becomes a memory hot spot (unfortunately, the kernel data has to reside on only one node). 2. replicate low level excpetion handler code on all nodes. The architecture code also turns on CONFIG_NUMA to take advantage of node-local page allocations. (A CONFIG_NUMA patch that I have been submitting to Linus was put into the kernel in test6-pre1). For more information on NUMA and ongoing work, refer to

this document

The purpose of doing this port is to boot Linux on bigger systems that we have, in order to do cpu/memory scalability studies. This also lets us do NUMA performance work in the future. Another advantage is to be able to leverage this work on the upcoming SGI CC-NUMA Itanium boxes, which will be an SGI supported product. Initial results from scalability studies using mips64 is documented at

The OSS SGI site.

Kanoj

Thanks to some of the folks from SGI for sending us some information about their latest project. Pretty interesting project -- the largest configuration has 10 PCI busses (busi?) with 24 scsi controllers and 10 disks. And wait'll you see the rest of the stats.

Hi all,

Just thought I would send out a note outlining the state of the mips64 port. Ralf, Ulf and I have been actively working past few months to bring up Linux on the SGI ccNUMA machines.

The executive summary: we have achieved multiuser boot on o200 and o2000s. The largest configuration is a 32p, 16node machine (only approx 4G worth of memory was populated over the 16 nodes, the system can take 4G * 16 node worth of memory). This machine has 10 PCI busses, with 24 scsi controllers and 10 disks. (Sample output is at

OSS SGI

If you are interested in the system architecture and details of the port, read on. The o2000s use R10000 series of MIPS processors. Each machine is comprised of modules, each module has 4 node boards with max 2 cpus and 4G memory on each node, and IO boards and routers. In a module, the two alternate node boards are each connected to a XBOW. Each XBOW possibly is connected on the other side to a number of PCI busses, which is what the IO boards connect to. Apart from this, there are routers in the system that provide connection paths between all memory to all cpus, to create a true CC-NUMA architecture.

On the software side, we are still struggling with compiler and binutils issues. The kernel itself is 64 bits, created by cross compiling on an ia32 box. We have not attempted 64 bit user program compilation or execution. The root disk is currently very close to the MIPS/Indy root disks. The architecture specific code uses the CONFIG_DISCONTIGMEM code to support memory on all nodes. The architecture specific NUMA features currently are: 1. replicate the kernel text on all nodes, so that no one node becomes a memory hot spot (unfortunately, the kernel data has to reside on only one node). 2. replicate low level excpetion handler code on all nodes. The architecture code also turns on CONFIG_NUMA to take advantage of node-local page allocations. (A CONFIG_NUMA patch that I have been submitting to Linus was put into the kernel in test6-pre1). For more information on NUMA and ongoing work, refer to

this document

The purpose of doing this port is to boot Linux on bigger systems that we have, in order to do cpu/memory scalability studies. This also lets us do NUMA performance work in the future. Another advantage is to be able to leverage this work on the upcoming SGI CC-NUMA Itanium boxes, which will be an SGI supported product. Initial results from scalability studies using mips64 is documented at

The OSS SGI site.

Kanoj

Thanks to some of the folks from SGI for sending us some information about their latest project. Pretty interesting project -- the largest configuration has 10 PCI busses (busi?) with 24 scsi controllers and 10 disks. And wait'll you see the rest of the stats.

Hi all,

Just thought I would send out a note outlining the state of the mips64 port. Ralf, Ulf and I have been actively working past few months to bring up Linux on the SGI ccNUMA machines.

The executive summary: we have achieved multiuser boot on o200 and o2000s. The largest configuration is a 32p, 16node machine (only approx 4G worth of memory was populated over the 16 nodes, the system can take 4G * 16 node worth of memory). This machine has 10 PCI busses, with 24 scsi controllers and 10 disks. (Sample output is at

OSS SGI

If you are interested in the system architecture and details of the port, read on. The o2000s use R10000 series of MIPS processors. Each machine is comprised of modules, each module has 4 node boards with max 2 cpus and 4G memory on each node, and IO boards and routers. In a module, the two alternate node boards are each connected to a XBOW. Each XBOW possibly is connected on the other side to a number of PCI busses, which is what the IO boards connect to. Apart from this, there are routers in the system that provide connection paths between all memory to all cpus, to create a true CC-NUMA architecture.

On the software side, we are still struggling with compiler and binutils issues. The kernel itself is 64 bits, created by cross compiling on an ia32 box. We have not attempted 64 bit user program compilation or execution. The root disk is currently very close to the MIPS/Indy root disks. The architecture specific code uses the CONFIG_DISCONTIGMEM code to support memory on all nodes. The architecture specific NUMA features currently are: 1. replicate the kernel text on all nodes, so that no one node becomes a memory hot spot (unfortunately, the kernel data has to reside on only one node). 2. replicate low level excpetion handler code on all nodes. The architecture code also turns on CONFIG_NUMA to take advantage of node-local page allocations. (A CONFIG_NUMA patch that I have been submitting to Linus was put into the kernel in test6-pre1). For more information on NUMA and ongoing work, refer to

this document

The purpose of doing this port is to boot Linux on bigger systems that we have, in order to do cpu/memory scalability studies. This also lets us do NUMA performance work in the future. Another advantage is to be able to leverage this work on the upcoming SGI CC-NUMA Itanium boxes, which will be an SGI supported product. Initial results from scalability studies using mips64 is documented at

The OSS SGI site.

Kanoj

An anonymous reader wrote in to tell us that SGI has announced their latest and greatest MIPS-based computers, the Onyx and Origin 3000 line. Up to 1 TB RAM and 512 processors, all on a single system (not a cluster). Beyond Boxes has a nice summary, too. This is definitely a great system for anyone who wants to have their computer be the size of several refrigerators ;)

nicktook writes: "ZDNet has this story that RedHat has released a full alpha distribution for the 64-bit Itanium processor. Can Itanium hardware even be bought yet?" Not by jes folks, that's for sure. cnoe also sent a link to the official announcement from Red Hat as well. Coupled with SGI's release of Pro64 compilers for Itanium, it seems like Intel's Next Big Chip keeps whispering "penguins." Stunning news from MS on this front is long overdue.

An anonymous reader noted that SGI has announced their latest Linux Workstation. It ships with the new VPro graphics board... you can also look at some specific configurations for the boxes. As always, it's SGI so it's priced in the stratosphere, but at least it's purple and oh-so-lustworthy.

An anonymous reader noted that SGI has announced their latest Linux Workstation. It ships with the new VPro graphics board... you can also look at some specific configurations for the boxes. As always, it's SGI so it's priced in the stratosphere, but at least it's purple and oh-so-lustworthy.

An anonymous reader noted that SGI has announced their latest Linux Workstation. It ships with the new VPro graphics board... you can also look at some specific configurations for the boxes. As always, it's SGI so it's priced in the stratosphere, but at least it's purple and oh-so-lustworthy.

jd writes, "It's been rumoured for some time, but no code was shown and no announcements were made. Well, they actually did it. The first drop of the necessary code to bring Linux to B1 standards is on their Web site. The code is essentially a rip of their IRIX code, and isn't fully Linuxified, yet, but it's all there and ready." Update: 04/12 05:52 by E : We got mail from Richard, who maintains these pages... He says: "It is true that SGI are working on making Linux C2/B1 as anyone who has been to a SGI Linux University event will attest, and we are working with a number of others to that end. But to say that we have released a patch for Linux is very misleading and is setting expectations way above what is currently available." So, take this with a grain of salt.

Everybody and Their Dog writes, "SGI announced the availability of XFS for linux 2.3.99pre2, via their CVS. Timely in light of the Journaling ReiserFS controversy, and ext3 delays. " A lot of people sent this in -- good to see SGI following through on their promise.

Jeremy is a leading Samba maintainer, and therefore one of the world's leading experts on Samba, which is often held up (along with Apache and the Gimp) as a sterling example of efficient and useful Open Source development. In the interest of full disclosure, we must mention that Jeremy is now employed by VA Linux, but that his primary responsibility is still Samba, just as it was when he worked for SGI. Look for Jeremy's answers to your questions within the next week.

NumberCruncher wrote to us from the rendering front, where Alias|Wavefront has announced that it has shipped Maya Batch Renderer for Linux. The software does optimized tile-based rendering and selective ray-tracing.

Moo-ha-ha. CmdrTaco is on vacation (and sending his e-mail to /dev/null, so please don't even try), so I'm doing Quickies this week. On to the good stuff. DigitalDaedalus wrote in to tell us about the SGI 404 pages. Cute. For those with that not-so-fresh feeling, dodobh wrote in to tell us about the Slashdot Purity Test. No, I won't tell you my score. In the 'ear candy' bin, casret told us that they posted the results of the XMMS plugin contest. Time for some stuff from the 'exploding stuff' bin. Aardappel wrote in about Fisheye Quake, and Kintanon caught my eye with Fun With Grapes. Charles Helfenstein told us about the anti-cubicle. Very cool. Fanmail used the force and wrote in about George Lucas In Love. With all the X-Men hype going on, Link wrote in about Mutant Watch. Smurfy cared to share AIEEE, the Acronym Interaction, Expansion and Extrapolation Engine. fwfr told us about the Sim-William Shatner. You'll need Flash. Last but certainly not least, The Welcome Rain wrote in to tell us about your friend and mine, Robot Frank.

Eric^2 asks: "We have an old NT server that we are going to replace sometime this year. It has Diskeeper on it to do disk defragmentation. I remember from DOS that this was also a BIG problem, and am curious how the EXT2FS handles file fragmentation. Whatever we put in to replace that NT box needs to be fairly resiliant, and I was thinking either FreeBSD, or maybe Linux with the XFS file system, as it's supposed to be more fault tolerant. I would appreciate any suggestions that you may have! Is there a more robust solution than XFS for Linux? FreeBSD? Should I stick with NT and Diskeeper? "

Syn Ack writes, "SGI and SuSE announced at CEBIT that they are going to team up to bring Iris FailSafe to Linux. Linus is quoted as saying that this is a "piece of the puzzle" that Linux is missing. Here is SGI's press release." The press release says FailSafe for Linux will be open source, but doesn't say under what license.

Syn Ack writes, "SGI and SuSE announced at CEBIT that they are going to team up to bring Iris FailSafe to Linux. Linus is quoted as saying that this is a "piece of the puzzle" that Linux is missing. Here is SGI's press release." The press release says FailSafe for Linux will be open source, but doesn't say under what license.

Doctor Bob writes "Just saw this press release from SGI. I think this quote sums it up: "With today's release, all of the necessary components to implement hardware-accelerated OpenGL drivers will be available to the open source community." " The implementation from SGI is ready for download from SGI. Have fun.

CloneRanger writes "SGI announced that it has released version 1.1 of SGI Linux (derived from RH6.0). Major new enhancements include: raw I/O to disk for SQL database systems, Parallel I/O to keep disks busy, POSIX-compliant Asynchronous I/O Interfaces, and development tools. Read more in the press release."

bendawg writes "I was reading the 2.2.13ac2 patch summary on Freshmeat, and I was intrigued by the mention of ext3. I tried to find more specific information on this to no avail. Does anyone know what new features this filesystem is supposed to have? Also, anyone know the status of SGI's XFS journaling filesystem? " Yes, I know 2.2.13ac2 is old, but I have yet to hear ext3 mentioned in the geek conversations I participate in. What new features does this next iteration give us over good ol' ext2?

Thanks to Allan over at SGI for letting me know that SGI has just released IRIS Performer for Linux. It's version 2.3 and it's free for download. If you want the program or more information, they've IRIS page for Linux up and running.

Thanks to Allan over at SGI for letting me know that SGI has just released IRIS Performer for Linux. It's version 2.3 and it's free for download. If you want the program or more information, they've IRIS page for Linux up and running.

Alphix writes "SGI has announced their Linux Kernel Crash Dumps project - and it's gone to release. It's intended to simplify the examination of system crashes thru saving the kernel memory image when the system dies due to a software failure, recovering the kernel memory image when the system is rebooted and then examining the memory image to determine what happened when the failure occurred."

Alphix writes "SGI has announced their Linux Kernel Crash Dumps project - and it's gone to release. It's intended to simplify the examination of system crashes thru saving the kernel memory image when the system dies due to a software failure, recovering the kernel memory image when the system is rebooted and then examining the memory image to determine what happened when the failure occurred."

Alphix writes "SGI has announced their Linux Kernel Crash Dumps project - and it's gone to release. It's intended to simplify the examination of system crashes thru saving the kernel memory image when the system dies due to a software failure, recovering the kernel memory image when the system is rebooted and then examining the memory image to determine what happened when the failure occurred."

xinit was one of the people who pointed us to the CNET story running about the possibility that a current bid by SGI for a supercomputer could be run on Linux. The supercomputer could be the fastest in the world at time of its production. SGI has confirmed the bid, saying it's being targeted for 2001, if the bid is accepted. The placement would be Los Alamos National Laboratory.

Anonymous Coward writes "According to this News.com article. VA Linux Systems, O'Reilly and Associates, and SGI. Will be co-sponsoring a retail box version of Debian GNU/Linux. In addition VA will be helping to setup toll free technical support for Debian."

haakon writes "The New scientist have a story about getting LCD screens to produce sound. I wonder if I can hack a X server to do that on my laptop? " Mmm...with this SGI flatscreen, and Rob's as well, I think we're to be having a concert - tickets go on sale Friday.

Durinia writes "SGI has announced a few details on their next Cray vector supercomputer. The press release is mostly about them getting government support for the R&D. It does, however, mention that it will be combining the powerful Cray vector processors with SGI's ccNUMA architecture for big-time scalability."

johnrpenner writes " SGI has released "Jessie" - an open source development environment for Linux. It provides an advanced IDE (integrated application environment) with comprehensive debugging tools and a highly graphical interface that eliminates the need for employing older command-line tools." However there doesn't seem to be linkage to anything more than a press release.Update: 09/21 11:41 by H : Check SGI's Jessie site for more information.

A couple months ago, SGI announced that they would be porting IRIS Performer to Linux. Thanks to Allan Schaffer for pointing us over to the first beta version that's ready for the public.

An anonymous reader sent us an interesting linke over to SGI on their new Linux/OpenGL Base. Its a project to standardize OpenGL on Linux, but Mesa Compatibility is actually part of the plan. Nice strong Linux push for one of SGIs most important technologies. Very cool. Also, but not linux related, is their new Reality Center. Dibs on one of those "Walls".

An anonymous reader sent us an interesting linke over to SGI on their new Linux/OpenGL Base. Its a project to standardize OpenGL on Linux, but Mesa Compatibility is actually part of the plan. Nice strong Linux push for one of SGIs most important technologies. Very cool. Also, but not linux related, is their new Reality Center. Dibs on one of those "Walls".

Thanks to Scott Elyard, who has returned and has written a "second chapter" to his original piece about SGI. Once again he's debunking mysteries, and discussing changes within SGI. Click below to read more.

Myth of the Fall of SGI, Part Two -
the Mystery of IRIX

When I last addressed this topic, more than a year ago, I was hoping to clarify and settle the notion of SGI's supposedly then-imminent demise. I did hope it would work.

However, there is still a peculiar occlusion perceived in SGI's future, particularly by those that do not understand what SGI does; and now, more recently, with SGI's logo change and Linux embrace, the former faithful question SGIs existence as well, possibly because of the recent layoffs (despite a strong quarter for profitability), the corporate image makeover, the MIPS stock divestiture, and the spinning off of Cray and their NT division into separate (but still quite owned) companies.

That these perceptions are still unfounded, and have been unfounded for more than a year, that SGI has posted profit recently, and that SGI continues to be a strong seller of UNIX systems despite the disappointing performance of the NT machines. Some people just can't let go of their own bad ideas. It's like the flat earthers, who continue to insist the earth is not round: I expect to run into people who will continue to insist SGI is going out of business any day now for the next ten years and beyond.

I have, at last, accepted this: that I cannot change everyone's mind with reason or facts. But you can get some of them here.

Common Mistakes and Misinformation That doesn't mean I have to let the FUD slide. Therefore, I have a list of common errors and mistakes people make when discussing SGI.

1. SGI tried to convert customers to Windows NT (or Linux).

This is obviously false, as even the most casual visit to their website shows. OSes supported by SGI are UNICOS (Cray), IRIX (MIPS), Linux (IA32/64), and Windows NT (Visual Workstation).

I find it interesting that anytime SGI adds an OS to its roster of supported platforms (UNICOS, IRIX, Linux, and NT), people assume everything will be rolled over into that one at an unspecified date. This is simply not going to happen. IRIX will remain on their MIPS-based desktop workstations, and it will continue to be upgraded as the best technical high-end UNIX out there.

2. SGI has a gloomy future. (SGI is dying, losing all its customers &c.)

This one's my favorite, simply because it can't be proved or disproved. There's no best response to this one, because it's primarily FUD, since asking for proof is generally ignored.

3. IRIX is being abandoned.

Again, another falsehood. SGI never claimed this, and SGI's IRIX support has actually remained unchanged. The only possible difference is looking like IRIX might not make it to Merced after all. Big deal. I have little faith that porting Solaris to Merced, for example, will do much to Solaris's overall market share.

3a. IRIX is unstable/insecure/unreliable.

I don't think these sorts of comments are relevant. ANY UNIX can be unstable, insecure, and unreliable, so why should IRIX be any different? Competently administered, IRIX is an extremely stable, secure, and reliable UNIX. People seem to forget we still do need people behind the console to keep things working smoothly, and a great deal depends on how well that person knows his or her system and how good she or he is with it.

Like any UNIX, IRIX isn't idiot-proof. Nor is it meant to be; most UNIX operating systems aren't meant to be run by even incredibly smart NASA monkeys, but by competent professionals.

4. Adopting Linux is the sign of a dying, desperate company.

Really? Red Hat must beg to differ. As must, to some extent, IBM, Caldera, Penguin Computing, VA Linux Systems, and indeed any business that has adopted Linux in one form or another as a part of its operating model.

5. SGI's graphics performance isn't cost effective compared with gaming cards for PCs.

I have to raise this issue. Tim Sweeny of Unreal (www.unreal.com) made comments in early July about the future of SGI, and how it doesn't stand a chance against gaming PCs. This is absolutely laughable, and Sweeny ought to have known better than make such statements.

Quoth he on his website: Now, a $2000 Pentium III PC with a Voodoo3 or TNT2 card eclipses the performance of a $30,000 SGI for real-time rendering. The CPU is faster, the fill rate is faster. When I first saw an SGI Reality Engine, my impression was, "Holy cow, I can't believe how much better this is than my '286!" But nowadays, the best 3D games look far cooler than anything you see running on a Reality Engine. When I first read that paragraph, I wondered how a veteran of the game authoring industry could make such a carelessly crafted statement without thinking about it. First, nobody buys an SGI Crimson or Onyx for gaming. Never have, never will. Second, nobody makes games for the SGI--people create games *on* the SGI, not for it, because there would be no point in doing so. Third, I'm nonplussed by the notion of any company in the computer industry has to make as many workstations as Dell makes PCs to stay in business, when the last ten years have shown that you can, and most do.

PCs that have OpenGL cards used primarily for gaming are good a small numbers of polygons, and fast pixel-fill rates. Even on the PC, cards good at large-poly-count geometry transformations tend to suck at pixel-fill (2d) operations (check out any decent card for the PC manufactured by Evans and Sutherland if you dispute this). Why this is even confused with SGI's machines is beyond me, since no PC has even been able to match the aging Reality Engine gfx first made available on the original Onyx in 1994, much less the 88 million polys/second (shaded, textured, and antialiased) of the Infinite Reality on the Onyx, introduced two years later.

But, to the lower end. If you're playing games, you're not buying an SGI. If you're creating them, you're probably not buying an SGI, unless you want to create something along the lines of Myst or Riven, the latter of which was generated on SGI machines running Softimage. But, I have noticed SGI usage popping up in more realtime-oriented titles like Spyro the Dragon (my favorite; from Insomniac Games, check 'em out) for modeling.

Most consumer gaming cards are better than all but the highest-end SGI systems for pixel fill rate. But that's all. The instant anyone needs to transform, rotate, or scale more than a few thousand polygons per second while working with unoptimised geometry (for example, during modeling), any modern SGI will beat any consumer card, period.

Just looking at the behind-the-scenes creation of any major motion picture that involved special effects to any degree reveals that SGI is still the first fallback. Why? Probably because that's where the workstation grew up: in high-demand production environments like ILM, Boss Film Studios, Pixar, and Disney (to say nothing of NASA and other supercomputing institutions nearly everywhere). 6. SGI's new logo is just another example of how SGI is dying.

This one is purely subjective. It's based purely on the espouser's opinion, which I contend is largely useless as a legitimate means of examining a corporation's health.. SGI changing its name to SGI was probably a good move, and I like the new logo only somewhat less than the old one.

To be honest, though, I don't care what the silly thing looks like. I don't see the logo as having much impact on the speed of the systems themselves, the stability of the OS, or the price of tea in China.

This sort of comment reminds me of the people who used to post flames to Usenet about how lame Apple was because they had a fruit for a logo. Yeah. Right.

What's Up Next?

SGI is headed in a different direction than any other UNIX hardware vendor thus far: SGI has actually embraced Linux and promised significant enhancements, enhancements that may actually bring Linux into the realm of viability for some of us.

IRIX is a rock-solid OS, and I cannot imagine using Linux on a production workstation at this point. But, should some fatherly organization pick Linux up, clean it up, and ensure the interface is one I'm familiar with (ksh and Indigo Magic), and applications suddenly find themselves ported to it, I don't see how it would make much of a difference if I don't notice a performance drop.

Obviously, this will take time. Unlike SGI's impending death any second now (two years and still counting, waiting for the big shoe to drop at any moment), it takes time to truly polish an OS and bring it in line with a production effort. My business is 3D graphics. I work with huge files, huge scenes, and immense amounts of data. The aplomb that an SGI running IRIX demonstrates on my workload is unmatched by any other platform or OS, so much so that I have declined purchasing 'faster' PCs and Macintoshes in favor of Indys and Indigos, simply because the responsiveness wasn't there on the PC/Mac hardware with my typical workload tests.

But if Linux can be brought in line on the low-end on SGI hardware with a comparable SGI running IRIX today, and the only real way of telling the difference is to run uname -a at the prompt, who will care?

Certainly not me, or my work.

SGI has released "Jessie" to the Open Source World. Jessie is an IDE for use on top of current development tools in the Linux OS. Here is a screenshot of Jessie. Note: The page is a bit outdated (it doesn't mention that there are some IDE for Linux such as CodeWarrior of CodeFusion). Thanks for Linux Today for the story.

SGI has released "Jessie" to the Open Source World. Jessie is an IDE for use on top of current development tools in the Linux OS. Here is a screenshot of Jessie. Note: The page is a bit outdated (it doesn't mention that there are some IDE for Linux such as CodeWarrior of CodeFusion). Thanks for Linux Today for the story.

SGI has released "Jessie" to the Open Source World. Jessie is an IDE for use on top of current development tools in the Linux OS. Here is a screenshot of Jessie. Note: The page is a bit outdated (it doesn't mention that there are some IDE for Linux such as CodeWarrior of CodeFusion). Thanks for Linux Today for the story.

Well, it apparents that on the heels of yesterday's announcement about resigning as CEO of SGI, Belluzzo will be reportedly joining Microsoft's interactive operations units.

hedonick wrote in to let us know that SGI will be releasing XFS under the terms of the GPL. It looks like they want to use it to replace ext2 under Linux. Since XFS is a journaling filesystem, this is something I'm personally looking forward to.

hedonick wrote in to let us know that SGI will be releasing XFS under the terms of the GPL. It looks like they want to use it to replace ext2 under Linux. Since XFS is a journaling filesystem, this is something I'm personally looking forward to.

the_demiurge writes "SGI has three press releases on their site showing the new Positions for the Future. They include making separate divisions for the Cray line and the Visual Workstations and also more details on the 'strategic alliance' with NVIDIA." SGI is also getting into Open Source in a big way. Check this page for all sorts of cool stuff.

the_demiurge writes "SGI has three press releases on their site showing the new Positions for the Future. They include making separate divisions for the Cray line and the Visual Workstations and also more details on the 'strategic alliance' with NVIDIA." SGI is also getting into Open Source in a big way. Check this page for all sorts of cool stuff.

the_demiurge writes "SGI has three press releases on their site showing the new Positions for the Future. They include making separate divisions for the Cray line and the Visual Workstations and also more details on the 'strategic alliance' with NVIDIA." SGI is also getting into Open Source in a big way. Check this page for all sorts of cool stuff.

dewey writes "This article [from Yahoo! News] says that SGI is expected to announce another business restructuring next Tuesday. No details about the reorg yet, but the buzz is that the focus will be away from big customers buying high-end machines and more toward being better able to 'compete on the Web' -- whatever that means." Update: It may mean more Linux support; jho sent in a link to the new SGI Linux page. A ray of hope in SGI's otherwise gloomy future, perhaps?

Durinia writes "Here is the official press release from SGI about their new Linux server. It also looks like they've struck a deal with Red Hat. " SGI continues its support (and perhaps its last hope) with Linux-do you folks think this will be enough to restore them?

SGI just announced a Linux porting effort for IRIS Performer. Performer is an OpenGL-based scene graph library optimized for visual simulation; it's used in areas like military and commercial flight simulation, as well as the rides at DisneyQuest. Release is expected before the end of 1999. Performer is designed to drive the fastest graphics hardware and run the most demanding graphics apps in existence, so this is very good news.

SGI just announced a Linux porting effort for IRIS Performer. Performer is an OpenGL-based scene graph library optimized for visual simulation; it's used in areas like military and commercial flight simulation, as well as the rides at DisneyQuest. Release is expected before the end of 1999. Performer is designed to drive the fastest graphics hardware and run the most demanding graphics apps in existence, so this is very good news.

SGI just announced a Linux porting effort for IRIS Performer. Performer is an OpenGL-based scene graph library optimized for visual simulation; it's used in areas like military and commercial flight simulation, as well as the rides at DisneyQuest. Release is expected before the end of 1999. Performer is designed to drive the fastest graphics hardware and run the most demanding graphics apps in existence, so this is very good news.

Silly-G writes "SGI's free DevCentral web site features a story called "SGI Invests in OS Technology" that "updates information about recent developments" on SGI's four supported operating systems: Linux, IRIX, UNICOS and that other operating system. Perhaps nothing new is discussed but at least it's clearly described in one breath. Tons of interesting info including delivering intellectual property to the open source community, the upcoming IA-32 Linux server, the relationship with VA Linx Systems, the IA-64 Linux port, and the accelerated OpenGL graphics environment for Linux. "

Matt sent us the story over at SGI, officially confirming that they have worked with Number Nine to release the drivers for their uber-cool flat screen 1600SW into 3.3.3.1 of XFree86. The two will also be working more closely together in the future as well.