Slashdot Mirror

Gotta love those guys from SUN logging in as AC's and posting these slams.

Of course, this poor misguided individual may not know about the SGI freeware site. But then again, after reading this rant, well, you'd sorta expect that even if they knew about it, they wouldn't tell you.

So, ignore the FUDders from SUN. Enjoy the GNUware.

DMF is an SGI/Cray product that does transparent file migration between disk and tape. We make pretty extensive use of it on our mass storage server (8 CPU Origin 2000 + ~1TB FC RAID + ~40TB tapes in an IBM 3494 robot).

Unfortunately, I don't think there's anything like that just yet for Linux. SGI's OpenVault may do some of the things you want, but it's mostly the device communication layer and not a complete solution.

--Troy

XFS
Originally made by SGI for their IRIX OS, XFS is one awesome filesystem. Read this white paper (http://www.sgi.com/Technology/xfs -whitepaper.html). This white paper describes all of its cool features. The main features of XFS make it a super scalable, very reliable, ultra fast journalling filesystem utilizing many cool FS technologies like B-trees and other cool stuff.

Unfortunately, it seems that currently there are many problems with the Linux implementation of XFS. I don't know any details of this, but I guess it is safe to say that XFS will some day become available for Linux. This would be great.

ext3fs
I've only read about this in the linux mailing lists. ext3 appears to be a standard ext2fs implementation with journalling data, allowing backward compatibility with ext2, although one of the authors hinted that they may not make it backwards compatible in some later version. It is currently in super early alpha testing and definately not anywhere close to usable, stable and reliable.

In my opinion this project is very new, and holds much promise. From their README, they appear to be done basic journalling code, and what remains to be done is error handling contingencies, metadata only journalling, performance tuning and lots of other coding. As a result, it may take some time but this could hold much promise and give another viable option for a journalling FS for Linux. Choices are always good.

Ext3 Site - ftp://ftp.linux.org.uk/pub/linux/sct/f s/jfs/

Reiserfs - http://devlinux.com/namesys/
I've been following reiserfs for a few months now. Its actually been available for quite some time now as a very stable, reliable and quick filesystem for Linux, but it was only recently when journalling was added to the code. Apparently this new addition is supposed to make it faster.

In "releasing" reiserfs, SuSE doesn't mean that it is the first journalling filesystem for Linux. It is the first journalling FS for Linux to be dubbed reliable and suitable for normal use. This is great as journalling has long been a stumbling block for enterprise adoption of Linux. Alan Cox hinted that he may include reiserfs in the standard kernels soon. Excellent =)

Warren Togami
warren@togami.com

114,000 lines of C code.

It's not a license problem, I think it's because xfs is such a huge project (>100k lines of code). Look at the xfs web site if you need details.

http://oss.sgi.com/projects/kgdb/

We actually ran into very few crashes, so we added code to the kernel to crash it for us with user level commands. The code for crashing the kernel is listed on the LKCD FAQ page: http://oss.sgi.com/projects/lkcd/faq.html

The SCSI partition requirement is only because raw I/O only works for SCSI right now. As soon as an IDE driver works for raw I/O under linux2.X.Y, the LKCD project should be very easy to make work with IDE swap partitions. Please review http://oss.sgi.com/projects/lkcd/faq.html for more information about restrictions.

Unicos runs on the Cray family of supercomputers such as the T90 and SV1 families of vector processing supercomputers (which use custom designed vector processors) or the T3E family of massively parallel supercomputers (which use DEC Alpha processors). SGI is spinning off Cray or something effectively similar to that. SGI won't be releasing any Unicos running computers in the future.

SGI also makes massively parallel computers, which if properly configured (read lots and lots of processors) are supercomputer class machines. These machines presently run, hold on to your hats, IRIX. These machines presently use MIPS processors. One of these machines is part of the ASCI contract (Accelerated Strategic Computing Initiative) and is based on an Origin 2000 system.

Right now SGI is developing CC-NUMA computers (the same multiprocessing technology behind the Origin 2000 computers) using Intel IA-64 processors. Rather than attempting to port IRIX to an Intel processor or pretending that Windows NT will scale SGI is relying on Linux. Right now Linux can't do it, but SGI is working on improving that aspect of Linux. This is all stuff thats been posted to slashdot before. Here's a blurb to that effect.

Do you suppose if we formed a co-op, and all chipped in a small amount, we could pay him not to write? Hey, it's one solution. Come to think of it, on the subject of money, I guess it's nice for andover.net to know that if they ever hit hard times, they can save money by sacking Katz (why not? Practically everyone else has!) and replacing him with a "Katzdot Generator", along the lines of this thing.

This book is about Jim Clark, the founder of Silicon Graphics. It is reviewed by Jon Katz, who, since being fired from Wired, has tried to make a living by sensationalising adolescent angst. Do we see any discrepancy here? The first rule of book reviews is that the reviewer should know something about the area the book deals with. Now, Katz knows shit about computers, shit about business, and shit about Jim : so why is he reviewing this book? Oh, yeah, I nearly forgot: isn't it about time we were told whether he is on the andover.net pay- roll or not?

I agree. TurboLinux can take whatever business tact they want, as long as they stick to their licensing.

But I don't like the paragraph..

There is precedent for Torvalds quickly deciding to incorporate changes to the kernel produced by commercial developers, Iams said. Engineers at Siemens and Linux distributor SuSE Inc. provided a 4G-byte memory extension that Torvalds incorporated.

This seems to be a backhanded swipe at Linus. They make it seem as if Linus should do it because he did it for someone else. Well, SGI has had a bunch of patches rejected( http://oss.sgi.com/projects/ linuxsgi/download/patches/ ). So have ALOT of others. Tough luck... But A Precedent?

Media Pressure on Linux is dirty, ignorant, and non-productive when you say someone should be doing this. Computerworld sucks and blows at the same time.

A doom-like interface is much cooler than FSN.

ftp://ftp.sgi.com/sgi/fsn/fsn.tar.Z

ftp://ftp.sgi.com/sgi/fsn/fsn.tar.Z

Accually
it exist

But it only runs on IRIX.

"3D File System Navigator for IRIX 4.0.1+ - As seen in 'Jurassic Park'!"

Actually the correct term for 'Jurassic Park Unix' is Irix which is the standard SGI operating system.

And a Unix, of course. "I know this, this is a Unix system". The german translation is even better: "Das ist ein Unix-System, damit kenne ich mich aus".

The computer in Jurassic Park is definitely an SGI.

An SGI Indigo AFAIK.

Flying around your file system is actually possible with the
software that came with our SGI Indigo2 workstations. I think it is called 'File Flyer' but I'm not 100% sure.Flying around your file system is actually possible with the
software that came with our SGI Indigo2 workstations. I think it is called 'File Flyer' but I'm not 100% sure.

The Program's called fsn and it's available here at SGI. Sadly, it only works on Irix 5.3 and below.


Kirth

where did you read the announcement?

AFAIK, Alias|Wavefront has only officially announced an IA32 Linux port of the Maya rendering software. I've only heard rumors of them porting the rest. I'd be a very happy camper if they ported the entire Maya package to Linux IA32, IA64, Alpha and PPC.

where did you read the announcement?

AFAIK, Alias|Wavefront has only officially announced an IA32 Linux port of the Maya rendering software. I've only heard rumors of them porting the rest. I'd be a very happy camper if they ported the entire Maya package to Linux IA32, IA64, Alpha and PPC.

I assume there are some basic sound tools available, but I would be surprised if they are equal to the best windows or mac tools. That is probably the most approachable sector to work on improving.

Certainly, hacking on a sound tools sounds a lot easier than creating a Maya clone.

Take care for the little green heat sink

Check your SDRAMS for memory errors. I had the
same problems for about eight weeks until I found
out that some SDRAM memory cells were unstable.
Memtest is quite good in finding broken memory
chips which other memory testers cannot find.


--

Makes many exercises in Origami look clumsy by comparison. Some of those folds he did are an amazing piece of art unto themselves- they're unbelievably beautiful. If you haven't followed up that link, http://www.sgi.com/grafica/huffman/ do so now- if you like geometric artforms, you're in for a treat.

of Dr. Huffman doing what he loved can be found here.

Dr. Huffman was another modest genius whose work doesn't fit in the hoary pigeonholes of Nobel candidates but is as ubiquitous as the DSP. It's no surprise he seems anonymous; these are the sort of stories that make me so often grateful for /.

Thanks David.

Definition:
NURBS, Non-Uniform Rational B-Splines, are mathematical representations of 3-D geometry that can accurately describe any shape from a simple 2-D line, circle, arc, or curve to the most complex 3-D organic free-form surface or solid. Because of their flexibility and accuracy, NURBS models can be used in any process from illustration and animation to manufacturing.

I know the use of NURBS are really easy and flexible as they are simply splines which can be ajusted by certain control points and different wieghting. They have easily replaced charachter modelling from polygons in the past 2 years.

I remeber speculation on hardware which could render/raytrace NURBS and other spline based modelling, directly w/o conversion to polys. However i've yet to see it materiealize.

Some of the Better NURBS modeller's avalible are:
Maya A linux port of this is supposedly floating around SGI and some of the larger software houses.

Rhino3D Shame its windows only, yet there's some reports of it successful in Wine.

Enjoy, Oblisk

------------------------------------

Well, the readme file for it gives me the impression that FSN was around before the movie, and was what was used in the movie.

Because you don't have a SGI with a copy of this program.

Unfortunetly, it only works under Irix 5.3 and below, so I can't run it at work.

Yes, there are women in open source. Yes, there are female hackers. (And I mean hackers in the true old-guard sense of the word for people who love to write code for its own sake and are very good at it, not people who break into someone else's box.)

Normally I don't go too overboard in the ubergeek oneupsmanship, but I think it's called for here to counter the prevailing winds.

I've been hacking open source since before that phrase was fashionable, we used to just call it "free software". Or even "public domain" if we felt like using big words. Most of it runs on Irix (although some has been ported to Linux) because I got addicted to SGIs when they were the only game in town for fast graphics.

I started playing with computers when I was ten, wrote software on my own time for a while, got my first paying computer job when I was 16. I was the youngest employee at ETA systems, a supercomputer company that's now bankrupt (like all the rest of them). I literally remember when I thought Unix was for wimps, an insane waste of expensive supercomputer cycles. If batch job control was good enough for me, it should be good enough for everybody! (So I did see the light on that one, now I'm a rabid Unix fanatic.)

Got a CS degree at Stanford (while taking quite a few feminist studies classes along the way). Went off to work at The Geometry Center, a research group where developing free software was a major part of our mission. Came back to Stanford to get a PhD in CS. Along the way I adapted some research software for use in a free SGI visualization product.

I am used to almost always being the only or one of the few women in the room. One of the few sports I enjoy doing is kickboxing, which is at least as male dominated. I probably wouldn't have chosen to either start or continue with that if I hadn't built up reserves of confidence from my experiences in CS.

I do believe the low percentage of women in CS is due to cultural conditioning, and that the gender imbalance causes professional difficulties ranging from extreme to subtle. Ellen Spertus has several essays on this (which are worthwhile enough that I'll add yet another pointer to them). In my case most of the difficulties have been subtle, and I've benefitted from many mentors from many people over the years. Most of them have been male, but it's worth pointing out that at my first computer job my boss was female as was hers.

-- Tamara

Don't get me wrong...I'm not saying that Toy Story wasn't impressive, its just that it fit the example of what I was saying.

Onyx's are SGI's gift to the movie industry. They are large servers that do very well with graphics/special effects rendering. Most of the movies with heavy fx in them use Onyx's, for example Twister.

With the example of Toy Story, and the amount of machines they had to use (I remember when Sun had a story on their site about it, they were using Sparc 20's which at the time of the movie with the options they had would cost about $20000). Using 200 sparc 20's at US$20000 would cost about US$4million. You could probably do the same thing with 3 to five Onyx's which at that time cost around US$200000, so figure 5 and you still are at half the budget of the sparcs.

I am sure that Pixar got some good kickback from Sun on the machinery because Sun used that as a huge advertising gimic, so that would save the budget on that movie, but it still doesn't account for the fact that if you were just to go out and buy the machinery, you wouldn't be saving anything.

I talked to someone who used to do film remastering at one of the imaging giants here in Rochester. He said that they used three SGI Onyx's and it was more power than they would ever need for removing the dust and scratches off the last master of the movies turning it into the final master. They didn't do any special fx with them, but they did remaster every single frame for a large number of movies (any movie shot on this company's film) and they Onyx's work much more efficiently than any Sun solution they could get that competed in price with buy the three Onyx's (I think he said they paid US$200000 a machine).

Here's a link to the new Onyx's. So that you can read the specs on them.
---

Oh yeah, don't be put off OpenGL if you're doing a 2D game -- although it excels at 3D, it's just as good in 2 dimensions, too!

Reverse engineering is just like science. You pose hypotheses about the system you are reverse engineering, then you find ways to test those hypotheses.

Like Raphael, I have been involved in reverse engineering a number of fun systems -- Quake network protocols, Quake map formats, OpenGL programs, LEGO Mindstorms. All of these systems required the same general strategy but different tools and background knowledge.

My experience has been that the hardest step of reverse engineering a system is getting started. You typically find yourself needing some tool to analyze a system that you just don't have.

For the Quake network protocol, that tool was a UDP proxy that dumped data in a format I could understand. For OpenGL programs, getting a tracing infrastructure set up was required before meaningful analysis of how programs use OpenGL could proceed.

For LEGO Mindstorms, the hardest part would have been figuring out the baud and bit encoding of a serial stream, since I didn't have easy access to an oscilloscope at the time, and I do not like trial and error when something unrelated -- like my serial port setup -- could go wrong; however, somebody had figured out the serial encoding already, and the starting hump ended up being obtaining a serial line data analyzer. (I ended up using a SGI Indy as a serial proxy.) Later Mindstorms reverse engineering required a disassembler/assembler/compiler tool suite.

Quake map files were easy; the tools were a hexdump program, a program to factor numbers to find strides, an HP calculator, and some programs to convert number formats.

The second part of reverse engineering something is finding useful ways to sort through the data that gets collected or generated. A lot of times I found that this boiled down to writing a program to analyze and print out the data, which I could then look over and study.

For example, the Quake 2 network protocol included some compressed information whose presence or absence was indicated by a bit vector; to figure out which bits mapped to which data, I used a program that tabularized and printed out the data in a really wide format; I then looked for patterns in the compressed data across many, many packets. By lining up columns of numbers that were clearly the same data, it was possible to infer which bits mapped to that data. Kind of like playing a really long game of Mastermind where somebody else gets to choose most of the guesses.

For Quake map files, after figuring out the basic layout of the records in the file (which hasn't changed much from version to version), the important part was figuring out the meaning of all the data. Early on, a useful tool was one that started at a given offset and printed out the range of numbers located at a particular stride from the starting point; this helped associate records of different types to one another. Later, and by far the most useful tool for analyzing Quake map files, was a level renderer used to verify the meaning of the map data. Related tools verified not only the meaning of certain data structures, but also high-level aspects of the algorithms that used these data structures, e.g. collision detection.

A single-stepping, single-buffered OpenGL trace player helps enormously when trying to figure out what algorithms an OpenGL program uses.

In any event, along with these common aspects of reverse engineering (getting started, developing the right tools), the general strategy of posing hypotheses and testing them holds throughout. Once you think you have figured out something new, you need to come up with a way of testing and verifying (or rejecting) the new idea. Unverified knowledge is just a guess, it's not really valid until you have confirmed it with at least one test; the more independent tests the better, as this leads to more confidence in both the new and the established knowledge. Hacking is of the essence here; the faster you can test an idea, the faster you can move on to testing new ones. Not only that, but the results of testing one new idea often opens up more questions and leads to further progress, at least early on.

This is just like science. The only difference is that when you are reverse engineering something, presumably the underlying mechanisms are already known by others -- the original engineers.

Since the original poster was interested in graphics, I will add that for OpenGL programs, I use a "DLL proxy" replacement for SGI's OpenGL Stream Codec based on ideas from a program called gltrace. The proxy dumps a trace of OpenGL/GLX/WGL calls that can later be replayed, single-stepped, run through a simulator, etc.

-Kekoa

Reverse engineering is just like science. You pose hypotheses about the system you are reverse engineering, then you find ways to test those hypotheses.

Like Raphael, I have been involved in reverse engineering a number of fun systems -- Quake network protocols, Quake map formats, OpenGL programs, LEGO Mindstorms. All of these systems required the same general strategy but different tools and background knowledge.

My experience has been that the hardest step of reverse engineering a system is getting started. You typically find yourself needing some tool to analyze a system that you just don't have.

For the Quake network protocol, that tool was a UDP proxy that dumped data in a format I could understand. For OpenGL programs, getting a tracing infrastructure set up was required before meaningful analysis of how programs use OpenGL could proceed.

For LEGO Mindstorms, the hardest part would have been figuring out the baud and bit encoding of a serial stream, since I didn't have easy access to an oscilloscope at the time, and I do not like trial and error when something unrelated -- like my serial port setup -- could go wrong; however, somebody had figured out the serial encoding already, and the starting hump ended up being obtaining a serial line data analyzer. (I ended up using a SGI Indy as a serial proxy.) Later Mindstorms reverse engineering required a disassembler/assembler/compiler tool suite.

Quake map files were easy; the tools were a hexdump program, a program to factor numbers to find strides, an HP calculator, and some programs to convert number formats.

The second part of reverse engineering something is finding useful ways to sort through the data that gets collected or generated. A lot of times I found that this boiled down to writing a program to analyze and print out the data, which I could then look over and study.

For example, the Quake 2 network protocol included some compressed information whose presence or absence was indicated by a bit vector; to figure out which bits mapped to which data, I used a program that tabularized and printed out the data in a really wide format; I then looked for patterns in the compressed data across many, many packets. By lining up columns of numbers that were clearly the same data, it was possible to infer which bits mapped to that data. Kind of like playing a really long game of Mastermind where somebody else gets to choose most of the guesses.

For Quake map files, after figuring out the basic layout of the records in the file (which hasn't changed much from version to version), the important part was figuring out the meaning of all the data. Early on, a useful tool was one that started at a given offset and printed out the range of numbers located at a particular stride from the starting point; this helped associate records of different types to one another. Later, and by far the most useful tool for analyzing Quake map files, was a level renderer used to verify the meaning of the map data. Related tools verified not only the meaning of certain data structures, but also high-level aspects of the algorithms that used these data structures, e.g. collision detection.

A single-stepping, single-buffered OpenGL trace player helps enormously when trying to figure out what algorithms an OpenGL program uses.

In any event, along with these common aspects of reverse engineering (getting started, developing the right tools), the general strategy of posing hypotheses and testing them holds throughout. Once you think you have figured out something new, you need to come up with a way of testing and verifying (or rejecting) the new idea. Unverified knowledge is just a guess, it's not really valid until you have confirmed it with at least one test; the more independent tests the better, as this leads to more confidence in both the new and the established knowledge. Hacking is of the essence here; the faster you can test an idea, the faster you can move on to testing new ones. Not only that, but the results of testing one new idea often opens up more questions and leads to further progress, at least early on.

This is just like science. The only difference is that when you are reverse engineering something, presumably the underlying mechanisms are already known by others -- the original engineers.

Since the original poster was interested in graphics, I will add that for OpenGL programs, I use a "DLL proxy" replacement for SGI's OpenGL Stream Codec based on ideas from a program called gltrace. The proxy dumps a trace of OpenGL/GLX/WGL calls that can later be replayed, single-stepped, run through a simulator, etc.

-Kekoa

The Mac OS has always been for me a tool of maximum efficiency - it's about as clean and fast a GUI as one could hope for, mostly thanks to its carefully thought out placement of icons, menus, buttons and so forth. Linux - tho' I've not been working on it for too long - is efficient as any unixesque system through the CLI (and I'm sure enjoying Enlightenment!)

I've been working on macs almost my whole life, and love them. But because the sort of work I do has been changing, I've found a text-based interface more efficient. My mac advocacy hasn't slackened though!

I thought the Salon article made a good point, though - that (and I am paraphrasing cruelly to make my point) people become advocates of the system they find the most efficient. Personally I wish that Alias | Wavefront would write a window manager - Maya is simply the best ``OS'' I've ever used. Irix is fun, too.
*N

The Mac OS has always been for me a tool of maximum efficiency - it's about as clean and fast a GUI as one could hope for, mostly thanks to its carefully thought out placement of icons, menus, buttons and so forth. Linux - tho' I've not been working on it for too long - is efficient as any unixesque system through the CLI (and I'm sure enjoying Enlightenment!)

I've been working on macs almost my whole life, and love them. But because the sort of work I do has been changing, I've found a text-based interface more efficient. My mac advocacy hasn't slackened though!

I thought the Salon article made a good point, though - that (and I am paraphrasing cruelly to make my point) people become advocates of the system they find the most efficient. Personally I wish that Alias | Wavefront would write a window manager - Maya is simply the best ``OS'' I've ever used. Irix is fun, too.
*N

It seems like whenever SGI is mentioned in a forum there's someone (posting mostly as Anonymous Coward) that will jump in to bash SGI for remote-past issues. Please get on with the program: there's no major Unix commercial system vendor that is as open and friendly to Linux and free software as SGI is today. Unlike others who pay lip service to free software and maybe bundling other people's work, SGI is actually actively contributing significant pieces of free software to the world and this includes multiple patches to the Linux kernel. The work continues.

Check out oss.sgi.com for some details.

And finally: why are you bringing up IRIX when SGI has been providing major support for Linux, shipping Linux systems, and when the subject matter (jessie) can run on any system including on SGI competitor systems?

Get on with the program, either don't use jessie and stay out of this discussion, or try jessie, enjoy it and thank SGI for making it in the first place.

> - The data displayer does not look as powerful as in i.e. DDD.

Not yet anyways ;-) We are putting alot of our development resources into that portion right now.

If you are interested in keeping up with our data display advances, please consider grabbing from the source tree.

Also, please feel free to send us your data display requirements AND wishes. Data display is a key area because of its importance in the development of serious scientific software.

-Dean

> - The data displayer does not look as powerful as in i.e. DDD.

Not yet anyways ;-) We are putting alot of our development resources into that portion right now.

If you are interested in keeping up with our data display advances, please consider grabbing from the source tree.

Also, please feel free to send us your data display requirements AND wishes. Data display is a key area because of its importance in the development of serious scientific software.

-Dean

1. It is very difficult to retrofit non-debugger functionality into a debugger and come up with an IDE that is intuitive and extensible. Our team has tried it before and lived with code that has had that happen to it. Not a pretty sight.
   
2. We wanted this to be truly cross-platform, including NT and non-*nix platforms. Qt vs. Gtk wars were raging then and they are raging still, albeit with more civility. I personally evaluated Gtk and found it to be quite reasonable. Qt was dismissed because of its licensing issues at the time. Java and Swing provided a very rich and consistent GUI toolkit.
   
3. We have spent literally years designing the infrastructure to create a powerful, intuitive, and extensible environment. It isn't fully filled out yet, but the missing parts will come.
   
4. Scaling was of the utmost importance to us. Like trying to retrofit IDE stuff onto a debugger,
   retrofitting scalability is just as bad. Ask any debugger folks that have added things like thread support and other SMP constructs.
   
5. We wanted to build an infrastructure that was usable for other complex tools. Look at VA Linux's VACM product and think of what it would be like using the Jessie infrastructure.
   

http://oss.sgi.com/projects/jessie/

It's in there for several languages (C, C++, Java, and Ada). If you aren't seeing it, please send us the particulars to jessie@sgi.com. That's my code and I am committed to fixing it.

Also, please send us your required AND desired features list. If you would like to help make those features a reality, please check out the How to Contribute section.

-Dean

It's in there for several languages (C, C++, Java, and Ada). If you aren't seeing it, please send us the particulars to jessie@sgi.com. That's my code and I am committed to fixing it.

Also, please send us your required AND desired features list. If you would like to help make those features a reality, please check out the How to Contribute section.

-Dean

Jessie Download
Jessie project page
SGI OSS project page

Enjoy!

Jessie Download
Jessie project page
SGI OSS project page

Enjoy!

Jessie Download
Jessie project page
SGI OSS project page

Enjoy!

Try this and see if it works any better.

-Dean

From the FAQ:

Is Jessie named after Jessie Ventura, the Governor of Minnesota?

No. While it is true that most of the work on Jessie was done in Minnesota, the name is a variation on the code name of its predecessor, Nessie, denoting the switch to Java as the primary implementation language. Besides, his name is spelled "Jesse" and not "Jessie".

• Jessie Home
• FTP Download
• CVS Source instructions
• License

A bit of the license opening material (trimmed):

SGI grants permission to use, copy, modify, merge, publish, distribute, sublicense and/or sell copies of the Original Software in both source code and executable form...

• Jessie Home
• FTP Download
• CVS Source instructions
• License

A bit of the license opening material (trimmed):

SGI grants permission to use, copy, modify, merge, publish, distribute, sublicense and/or sell copies of the Original Software in both source code and executable form...

• Jessie Home
• FTP Download
• CVS Source instructions
• License

A bit of the license opening material (trimmed):

SGI grants permission to use, copy, modify, merge, publish, distribute, sublicense and/or sell copies of the Original Software in both source code and executable form...

• Jessie Home
• FTP Download
• CVS Source instructions
• License

A bit of the license opening material (trimmed):

SGI grants permission to use, copy, modify, merge, publish, distribute, sublicense and/or sell copies of the Original Software in both source code and executable form...