Slashdot Mirror

Please note that there are some gaps (spaces) in the middle of the two URLs I pasted. They need to be removed in order for the URL to play nice with your web browser.

SGI MIPS/IRIX Roadmap

The Mandate of Application Compatibility in SGI IRIX 6.5 (An excellent whitepaper on the goals and future of IRIX 6.5, written by an IRIX 6.5 engineer

11 quarters = 2.75 years. IIRC, NT 4.0 was released in 1996 or so, and 6+ service packs later we have Win2K :)

IRIX 6.5 was a major release - a lot changed from 6.2, which was their previous major release.

I'm not sure if SGI is planning any major new releases for IRIX in the immediate future - you can read about their roadmap here (pdf). My nick is irix becuase it is the first UNIX I used back when. I'd change it now if I could ;)

The only SGI systems that run Linux right now are the low-end Intel workstations

balderdash... SGI have people working on MIPS and they have linux running on Origin2000 with *128* CPUs. Granted, the work seems primarily intended to develop linux so that it can be suitable for use on the IA64 O3000s, but you're still talking bollocks.

See:

http://oss.sgi.com/projects/LinuxScalability/downl oad/mips128.announce

and

http://oss.sgi.com/projects/LinuxScalability/downl oad/mips64.announce

And linux also runs fine on many /low-end/ MIPS boxen too. Eg, handhelds, embedded boards, etc. Also runs fine on my MIPS R4k Indy...

--paulj

The only SGI systems that run Linux right now are the low-end Intel workstations

balderdash... SGI have people working on MIPS and they have linux running on Origin2000 with *128* CPUs. Granted, the work seems primarily intended to develop linux so that it can be suitable for use on the IA64 O3000s, but you're still talking bollocks.

See:

http://oss.sgi.com/projects/LinuxScalability/downl oad/mips128.announce

and

http://oss.sgi.com/projects/LinuxScalability/downl oad/mips64.announce

And linux also runs fine on many /low-end/ MIPS boxen too. Eg, handhelds, embedded boards, etc. Also runs fine on my MIPS R4k Indy...

--paulj

All this moderation is getting bad posts modded up waaay too much...

As it stands right now the majority of their hardware run Linux

Umm, not really. And the hardware that does run Linux runs it with beta-type quality.

the last version of Irix released was to mainly fix bugs.

No shit. They release quarterly maintenance releases - in the 6.5.X series - up to 6.5.11 now.

They will probably drop IRIX someday down the road. But since the workstation marked imploded on them, SGI is trying to make money off of servers. I don't think that Linux is going to be running (release quality) 256-way Origin servers any time in the "near future".

I wonder if folks over at SGI plan on dropping Irix in the near future for Linux entirely. As it stands right now the majority of their hardware run Linux, and the last version of Irix released was to mainly fix bugs.

The only SGI systems that run Linux right now are the low-end Intel workstations (230, 330, and 550) and the Intel rack-mount servers (1100, 1200, 1400, 1450) - certainly not a "majority of [our] hardware.

IRIX on MIPS is not going anywhere. Take a look at SGI's IRIX/MIPS roadmap.

The difference is that Reiser is NOT a journaling filesystem (well, not any more that, say, NT or BSD UFS filesystems are), since it only journals the meta data

So does XFS. From one of SGI's own presentations:

5.6. Supporting Fast Crash Recovery
...To avoid these problems, XFS uses a write ahead logging scheme that enables atomic updates of the file system. This scheme is very similar to the one described very thoroughly in [Hisgen93].
XFS logs all structural updates to the file system metadata. This includes inodes, directory blocks, free extent tree blocks, inode allocation tree blocks, file extent map blocks, AG header blocks, and the superblock. XFS does not log user data.

[emphasis added]

This is *normal* for a journaling filesystem. Very very few actually log or otherwise protect file data, because of the cost. Maintaining a metadata-only log is already a significant performance limiter, and journaling data as well would just be prohibitively expensive. Most users wouldn't even want it, if they had to pay the performance cost.

(I don't count NTFS, because that is hard-pushed enough to be called a genuine filesystem, never mind a journalling one.)

Feel free to reply to this, adding any that I've missed.

The Logging filesystem does much the same thing as Ext3 - it is an extension to Ext2 - but it looks like it would be a lot more useful than Ext3. IMHO, it'd be much better if neither of them were so FS-specific and could be used as a generic wrapper. SnapFS does exactly this, for example.

Anyway, on with the list of Journalling Filling systems...

... -IN- the main kernel tree:

• ReiserFS

... at a stable release:

• XFS

... at a developmental release:

• JFS
• Ext3FS

... currently abandoned:

• LogFS

... extensions for:

• SnapFS - versioning for journalling filesystems

My favorite utility of the xfs distribution. Where else could you find so much joy about a program that does nothing?

Some basic info and a couple of links for folks:

• file system - basic defition -the general name given to the logical structures and software routines used to control access to the storage on a hard disk system. Operating systems use different ways of organizing and controlling access to data on the hard disk, and this choice is basically independent of the specific hardware being used--the same hard disk can be arranged in many different ways, and even multiple ways in different areas of the same disk.

• Journaled file system - Basic definition (as seen here)

  A file system in which the hard disk maintains data integrity in the event of a system crash or if the system is otherwise halted abnormally. The journaled file system (JFS) maintains a log, or journal, of what activity has taken place in the main data areas of the disk; if a crash occurs, any lost data can be recreated because updates to the metadata in directories and bit maps have been written to a serial log. The JFS not only returns the data to the pre-crash configuration but also recovers unsaved data and stores it in the location it would have been stored in if the system had not been unexpectedly interrupted.

• IBMs JFS webpage on their system, along with links for for downloads and turtorials online,etc

As far as the question about how to choose file systems, that is often a matter of what the OS will let you get away with, and your needs. Using FAT 16 is recommended if you need to maintain compatibility with MSDOS, for example. Usually, this is something like if you have a multi boot scenario, and which OSen can mount which partitions with which partitions. MS is notoriously picky in this regard, with a "My way or the Highway approach". For example, if you have a single hard drive hooked up to your computer for configuration purposes, You cannot just create anextended partition unless that drive is a salve with another master. If you want to create just an extended partition it will not permit, and tell you that you can only create a primary dos partition instead.

So you Live and you Learn

Check out the Vinny the Vampire comic strip

- A.P.

--
Forget Napster. Why not really break the law?

Your wish is my command.
--

ACL's are in XFS . its super simple to build a new system with redhat 7.1 and XFS

just look here you can get a bootable ISO that will insstall the XFS kernal and then ask you for your redhat-7.1 cd's to install the rest, as I said this if for a new system. but go for it

• Using Test Suites to Validate the Linux Kernel

Suggestions for other test suites, strategies for testing the Linux kernel or other things I can write about on the general topic of quality assurance and better software practice are appreciated.

One test that's not mentioned in the article yet is memtester. It is a user-space program that will run on Linux or other Unix-like OS and will test as much of the memory as it can mlock; I found that I could test about half of my installed memory on a debian PPC macintosh.

Memtest86 is advantageous in that it will test all of the installed memory, but memtester will run on non-PC clone and non-x86 hardware.

Mike

The (new) Hayden Planetarium has a *very cool* projection system on a hemispherical dome. Combines output from a 28-CPU, 7-GFX-pipe SGI Onyx2 (~1999 technology) with some computer controlled lasers and a new computer controlled Zeiss star projector. *Very* impressive stuff. This ain't the planetarium that your parents took you to as a kid, it'll blow you away.

http://www.sgi.com/features/2000/feb/hayden/index. html

http://www.amnh.org/rose/digitaldome.html

Yeah, yeah, I know the jokes... Plane-Arium. And yeah, yeah, SGI doesn't include their compilers with thier OS... but it's still the coolest thing I have ever visited.

Dont you need it if you want XFS? According to XFS Cavaets it says

Required Compiler and Library Releases gcc version 2.91.66 required Due to known problems with later versions of gcc, gcc version 2.91.66 (aka egcs-1.1.2) must be used when compiling XFS and the associated kernel. This is the default compiler on Red Hat Linux 6.2 systems, and is provided as "kgcc" for Red Hat Linux 7.0 and higher (see the next item for more information). Other distributions may be using a later version. The easiest way to check what version is in use is by running gcc -v.

Concurrent AGP would be a great idea for several purposes:

As a faster way to do Ultra-320 SCSI (maybe) than 66MHz 64bit PCI.

Well i tried to.

i went to SGI's feedback page. and i told them politely that i did not think that there behavior was acceptable. Perhaps if we politely inform them that we are not impresseses, maybe they will listen


How every version of MICROS~1 Windows(TM) comes to exist.

Email the CEO of SGI, Robert Bishop. Let *HIM* know how you feel.

bbishop@sgi.com

Please post your replies here on Slashdot so we can see if the top brass is even aware of this.

Search the web, there are probably other SGI execs with email addresses known to the public.

"ImageVision Library (IL) is a toolkit for creating, processing and displaying images on all SGI visual workstations. The library provides image processing application developers with a complete, robust framework for manipulating and managing images."

I'll bet it's this connection that is the source of concern at SGI.

I'm suprised they weren't more concerned that IL sounds a lot like their ImageVision library (also called IL.) OpenIL could be construed to be a version of their Image Library, ImageVision.

http://www.sgi.com/cgi-bin/feedback/index.cgi?entr y=compinfo_community_rel&LEVEL=2&last_url=

I doubt it will help, but it sure as hell can't hurt.

I'm using the CVS tree version, just because the patches tend to run a bit too far behind for my tasts.

Here are the instructions for grabbing the tree via CVS:

Linux XFS CVS Instructions

I really hope Linus changes his opinion on the relative urgency of merging XFS. It is something that I think the kernel could really benefit from, given the kinds of things people are using Linux for these days. I'd like to see it in 2.5.x ASAP, and hopefully backported to 2.4.x.

OpenGL extensions ARE a viable way to access the pixel shaders. For game programming, a lot of the OpenGL API is obsolete. Using glLight* calls to light a scene is just not done. People commonly prefer to use GL_ARB_MULTITEXTURE and blend another texture pass with lighting.

Likewise, the GL calls for the new pixel shaders are reputedly supported by the Nvidia drivers under Linux already. John Carmack stated that when Doom 3 comes out, it's going to only work with all it's features under Nvidia's drivers. However, he's going to lend some code to get the other drivers for the operating system up to speed.

OpenGL is not a lost cause. Dx8 is getting a lot of hype right now. Lots of developers are preferring it because, imo, Microsoft has very timely, large and helpful responses to game develpers, whereas OpenGL has to also cater to those CAD guys.

For a list and description of all the OpenGL extensions, see this URL.

Sure, we have OpenGL, but with the release of DirectX 8, the cross-platform API just doesn't cut it anymore. Lacking universal support for vertex and pixel shaders, developers are forced into the situation where they can either reduce the quality of their titles by ignoring the improved features that the newer releases of DirectX offer, or by ignoring Linux.

Take a look here for all the extensions available to you (including shaders) right now.

Take a look here for NVidia's OpenGL SDK which includes, yup, vertex shaders.

In the DX8 world developer's will also need to cripple their software if the card doesn't support the shaders in hardware. So I really fail to see what the argument is here.

Ryan T. Sammartino

Remember that XFS is a fairly maure journeling FS, compared to Reiserfs which started for Linux.

I've been playing with XFS (in Wolverine), and XFS rocks!
Grab a tarball/patches from ftp://oss.sgi.com/projects/xfs/download/
Now if only knfsd would play nice ..... :-(

Actually, they still are. (Press release from before they were sold).

Let's see what's bull. If you look at the extensions carefully, you'll see NV in their names. There is a reason to it - the extensions are NVIDIA-specific. Only patent-free extensions have gone into the ARB extensions - and they are for all to implement.

Then howcome the OpenGL implementation I use lists some non-trivial ammount of non ARB non EXT extensions? But don't take my word for it:

Promoting an extension refers to moving it from single-vendor to multi-vendor or ARB-approved status, usually by changing the vendor tag attached to the extension name string, enumerants and API entry points. This is sometimes done when an extension is successful and more licensees want to support it. This document describes the steps to follow when promoting an extension.

The fact that the extension is called GL_NV_foo doesn't mean, alone, that it can't be implemented by other vendors. In fact, other vendors are encouraged to implement those extensions. The problem is they can not do it without entering into an IP problem. You can get a license and blah blah blah, but that's not the point. The point is why is there are patent in the first place? Afraid someone comes up with a better idea, uh?

OpenGL is a low-level API but not a touch-the-metal API. The NV extensions is so close to the chip it is almost not possible to port it to another chip.

Well, duh! That's the whole point, isn't it? You don't want this to be implemented in software, do you?

Are you expecting the driver to recognize this and that sequence of calls

Of course not. Why would I want to do such a thing if there are proper ways to do it?

OpenGL -->**HAS**-- to be extended to support most new hardware features.

OpenGL has to be extended... funny, that sounds awfully like extensions to me, doesn't it? The one thing you can't do with extensions is changing the order of the pipeline. Your triangles will be transformed before they are discarded by a depth test. You can turn things on and off, but you can't change the order of the pipeline. Other than that, you are pretty much free to do whatever you want.

Adobe Dimensions (wireframe and other 3D to postscript)

An SGI Article on how to render OpenGL to postscript (with examples and source)

GLP (another OpenGL to PostScript app w/ source)

Adobe Dimensions is probably your best bet. Hope one of them works for you.
--
He had come like a thief in the night,

Second, it's a fairly safe bet that to achieve even reasonable performance, MS compiles vertex shaders into SSE, SSE2, 3DNow! or standard floating point code at runtime. Who do you think out there is willing and capable of spending the time required to write that kind of code?

Hey, don't blame this on NVIDIA. ATI does it too. The reason they have to do this is because OpenGL doesn't implement any cool features in the core API. Because Microsoft works with vendors to release a new version of DirectX every year or so, it supports the latest technologies

That's bull. The core OpenGL doesn't have to be changed in order to support new hardware features. The OpenGL extension mechanism is perfectly capable of exposing the features in a portable way. It is not necessary for OpenGL to go arround chaning the pipeline every other release. And I'm complaining about the fact that other vendors can't implement certain registered extensions because the vendor has patents covering them.

http://reality.sgi.com/opengl/tips/Feedback.html

http://www.easysw.com/~mike/opengl/

A lot of the overhead has to do with (un)packing X requests gazillions of times, which, the author claims, also happens in the shm case.
--
Change is inevitable.

> (i.e. you couldn't plug that nice LCD screen
> on anything else, so you were stucked with a
> cheezy card)

Or you can use a MultiLink adapter and connect to something like the Hercules Prophet DDR/DVI or Prophet2 Ultra running Linux or Windows.

MultiLink adapter

Try the early 90's. For instance, SGI's OpenGL and X: An Introduction documentation from 1994 discusses GLX and refers back to papers presented at conferences in 1992 about running OpenGL apps under X.

What happened "a few years ago" (1999 to be exact) was SGI open sourcing their GLX implementation.

Given this strategy, the rest of the system is very predicatable. They're not going to abandon their other supercomputer hardware technology, so the architecture has to look like an Origin with Itania instead of MIPS. And it's a lot cheaper to subsidize efforts to scale up Linux than to port IRIX. IRIX die-hards will mostly stick with the MIPS systems anyway.

What's new here is yet another round of SGI rebranding. They dropped "Silicon Graphics" so their server customers would stop thinking of them as the Jurasic Park company. They phased out most model brands because there were too damn many of them. There were going to phase out all model brands (one extreme to another!), but somebody realized that just putting a "2" in the model number wasn't enough to distinguish their servers from their workstations.

__________________

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

If you read the notes under some projects, you'll see that they already have a mips64 port in-house that they are running today on the O3K which they are using as a testbed for the stuff they want to run on Itanic.

What seems odd to me is that it is pretty clear that Itanic will not be cost nor performance competitive when it finally ships - all the other big boys have said they aren't going to bother with Itanic for anything but 1-4 way type boxes. McKinley (the successor to Itanic) is looking pretty good, recent reports say that it will debut at 1.4GHz around the end of the year (whereas Itanic can barely do 800MHz today).

oss.sgi.com

Why does Slashdot use the Old Silicon Graphics logo? Silicon Graphics effectively became SGI as of april 99. So is this just graphics trolling? Or should slashdot reflect the current branding strategy of a corporation? Wasn't this a News site once?

LAVARAND. The coolest random number generator on the web since 1996!

It is always good seeing SGI at the forefront of technology:)


Frog51

I remember reading a long time ago about a couple of programmers who needed a strong encryption routine so they improvised one.

They pointed a web cam at a lava lamp(!). The pictures are the hash source for the random number generator. Their theory was something like, "What could be more random then a Lava Lamp?!" Here's a link to something similar but I won't say it's -the- one I'm talking about since I honestly cant remember where I saw it originally.
"Me Ted"

Point a webcam at a lava lamp.

Take a hash of the image.

There you go.

The (non-)argument about computational generation of randomness is kind of silly, because it's totally unessecary to do so. Computers can get ahold of truly random numbers if we need them to. Next.

(you can now start to argue that the universe is completley predictable based on past events, etc, but you might as well just head over to the arts department 'cause you're in Philosophy now...)

While this is ever-so-slightly off-topic, it's still extremely interesting.

Check out D11. It's a spec that calls for a major restructuring of X-Windows, but it works thusly: Speeds up local accesses to an X-Win server (running the X server and client on the same machine). The thought's been around a while, but this is some really good stuff.

• Sony PAL TV with s-video and dual SCART input (G4xx supports both PAL and NTSC output)
• AMD Athlon 700
• Matrox G400 MAX (any G4xx dualhead will do)
• Hollywood+ / DXR3 MPEG decoder card
• Trident 4DWave NX
• Wireless SK7100 keyboard (full Linux support using 'hotkeys')
• Logitech wireless mouse (PS/2)

• Linux 2.4.0-XFS (80Gig *bloody fast*, journalled XFS data partition)
• Debian Woody (the best :)
• XFree 4.0.2 + Matrox mga.o binary with HAL
• WMaker 0.60.4, for proper Xinerama support
• aviplay + plaympeg for fullscreeen DivX ;-) / MPEG2 playback
• AlsaPlayer for music *grin*
• ROX for cool desktop icons and File browsing
• Anything else that runs OK at 640x480 or 800x600

XRender will be supported in the upcoming 0.9-7 release. Full hardware support for XRender should make it in 0.9-8. When that happens the NVidia cards will probably be the fastest and most feature rich you can get for Linux. Given, this will be for x86 only for now, but as an AMD x86 user I can't complain.

This info comes from a reliable source. And since NVidia has hired this X guru, I can only conclude that they're very serious about Linux/XFree support (Think SGI).

Posted from an AA'd konqueror browser (driver "nv" for now :)

-adnans

Has anyone managed to modify the latest Accelerating Apache Patches (1.3.14) to cleanly apply atop the Apache 1.3.19 source?

While Fahrenheit is officially dead, there are alternatives. Open Inventor was the predecessor to Fahrenheit and is now available under the GPL. It has been ported to Linux, Windows, and of course runs on Irix. It's good stuff. And the people on the mailing list (very low volume) are quick to respond and very helpful.

Jurassic Park File System

A colleague of mine drives his SGI 1600SW at 1600x1024 using DVI from his Nvidia and Matrox g400 cards (using XFree 4.0.2 and drivers downloaded from the manufacturers). The flat panel itself uses a proprietary SGI digital interface, however, the panel he bought (circa $1400) came with a multilink adapter allowing DVI or analog input. The analog didn't look all that great, but the DVI was excellent.

So, in short, 1600x1024 works perfectly, meaning that while there may be a 1024 limit on the vertical resolution DVI can drive, there is not a 1280 limitation on the horizontal resolution.

Still, the standard is already showing its age now that even higher res monitors are shipping.

A colleague of mine drives his SGI 1600SW at 1600x1024 using DVI from his Nvidia and Matrox g400 cards (using XFree 4.0.2 and drivers downloaded from the manufacturers). The flat panel itself uses a proprietary SGI digital interface, however, the panel he bought (circa $1400) came with a multilink adapter allowing DVI or analog input. The analog didn't look all that great, but the DVI was excellent.

So, in short, 1600x1024 works perfectly, meaning that while there may be a 1024 limit on the vertical resolution DVI can drive, there is not a 1280 limitation on the horizontal resolution.

Still, the standard is already showing its age now that even higher res monitors are shipping.