Slashdot Mirror

I don't know about "realistically", but SGI have a few boxes meant for the desktop, that run Irix, a 64-bit operating system. The O2, for example, or the (newly announced, I think) Octane2... Of course, these machines are not within most people's realistic budgets, but they do exist... ;^)

I don't know about "realistically", but SGI have a few boxes meant for the desktop, that run Irix, a 64-bit operating system. The O2, for example, or the (newly announced, I think) Octane2... Of course, these machines are not within most people's realistic budgets, but they do exist... ;^)

With Linux running on pretty much all of the commodity hardware these days (not as much as NetBSD, though, I think), I think it stands to become the standard Unix.

• Solaris scales better. Mainly becuase its SMP performance is better than Linux's.
• Solaris threads better. Last time I looked, Linux could not properly do core dumps with a multithreaded process.
• Solaris has kernel crash dumps. Linux's kernel crash dumps are not ready for prime time. In other words, you can find out exactly why Solaris crashed.
• Excellent support. Just in case you are not a Solaris kernel guru, you can call up Sun and they can get someone who can tell you why your Solaris box crashed. Sort of like getting Linus Torvalds on the phone after your Linux kernel crashed.
• Solaris has better NFS support. To put it mildly.
• Solaris has a much bigger mindshare among the corporate suits. In fact, I had a hell of a time getting a job as a UNIX sys admin because Solaris people do not consider Linux sys admin experience real UNIX experience.
• Solaris is well documented. With Linux, often times the source code is the only documentation you get.

I believe that Linux will eventually overtake Solaris, especially with SGI, IBM, and soon SCO backing it, but Linux is not there. Yet.

- Sam

http://www.sgi.com/fahrenheit/index.html

gives SGIs take on why they no longer support Fahrenheit.

Gingko

This is of course fast and merely somewhat random. There are a lot of similarities between consecutive frames. An unused channel is also particularly susceptible to intential attack by a nearby transmitter.

For more randomness, this can be run through further randomizing algorithms. The obvious example is the SGI LavaRand.

Linux-privs

SGI's B1 code

So, the benefits of Open Source combined with the trusted security of specifications

Uh, what are you talking about?
From http://www.opengl.org/Documentation/G LUT.html

The GLUT library has both C, C++ (same as C), FORTRAN, and Ada programming bindings. The GLUT source code distribution is portable to nearly all OpenGL implementations for the X Window System and Windows 9x/NT. GLUT also works well with Brian Paul's Mesa, a freely available implementation of the OpenGL API.

The current version of the GLUT API is 3. The current source code distribution is GLUT 3.7.

So, um...it's not opensource? Why can I download the source from here then?


One Microsoft Way

Why use C++ over C? Ignoring the fact that C++ is for all practical purposes a superset of C, I'll list the featured I find most useful, anf the reasons why:

• (Mostly) Strong Typing - A lot of people find this restrictive, but in the long run, proper use of datatypes, enums and consts saves debugging time. I find that I get more things "right the first time" in C++.
• Encapsulaton - Properly protecting your data with private and protected can tell you when you've coded a bad algorithm. It forces you to separate the interface from the implementation. Multiple inheritance can take this one step further, but I don't usually go that route.
• Polymorphism - Ok, this is the obvious one, but it really is extremely useful. It's also the hardest part of C++ for C programmers to "get," as it requires a completely different mode of thinking. I know it took me a couple of years and reading of Design Patterns to really, truly understand it. The Visitor pattern was my gateway to understanding. :)
• Streams - This really goes along with strong typing and includes things like strings and other fundamental library issues. Streaming is a MUCH nicer way of formatting data than printf, mostly because it's well-typed. No more segfaults from passing an int to a %s format.

• Libraries - While C certainly has excellent libraries, C++ includes the STL in the standard, which is a godsend (mostly). I don't want to code hashtables and lists. I did that in college. STL lets me get my work done in a standard way. Now, I have issues with how the STL was standardized (the STL string/iterator/streams interaction really, really bugs me), but overall it is very slick.

Finally, I'd like to address the issue of bloat. C++ does make it much easier to code badly. All of the abstract data types and code hiding can easily turn an O(n) algorithm into an O(n^2) one. As with any language, proper understanding of the code (libraries) is the key. The STL Programmer's Guide is an excellent resource for understanding the limitations and proper use of the STL.

To conclude with a "real world" example, I am currently on a team developing an optimizing compiler in C++. It's been a huge learning process, as any student project is, given that we started out with little compiler experience and only marginally more C++ experience. But throughout the project I have continually improved things by learning just a bit more about how C++ and the STL work. At this point, our compiler has similar functionality to gcc and runs in the same or less memory space. It's quite a bit slower, but I attribute that more to some non-optimal algorithms and more complex dataflow analysis than to C++.

In addition, by using C++'s ability to overload functions, I was able to quickly hack up the LeakTracer tool (which overloads operator new and operator delete), providing many memory debugging features and in the process reducing our memory consumption significantly. All in the span of a week.

--

More technical readers already familiar with programming and at least one C-based language might find the pace slow and the extra explanations unnecessary. Heller's target audience is definitely the neophyte, not the experienced developer. The latter might question the subject matter covered. Why build a vector class instead of using C-style arrays? Why not C-style strings? I suspect the author is more concerned with helping his students avoid the kind of pitfalls C++ was designed to work around. It may not be the traditional approach, but it's valid and it will produce decent programmers, who can learn C++ on its own merits.

I don't understand this comment. Questions such as, "Why build a vector class instead of using C-style arrays?" and, "Why not C-style strings?" are fundamental C++ questions. Now, it's true that the neophyte will not immediately question why a vector class is used, but IMHO it is an issue that should be addressed.

Additionally, the comment that readers can "learn C+ on its own merits" leads me to think that the book doesn't really cover C++, but rather covers "object-based C." Does the book even get into polymorphism?

Good supplements to this book (and essential reading for every C++ programmer, IMHO) would be the C++ FAQ Lite and STL Programmer's Guide. The Design Patterns book by Gamma, et. al. is also essential reading, but is probably a little advanced for the newbie.

--

Can't we also give SGI some credit where credit is due...

SGI's main Linux page

I mean look at their 230 workstation . Cute and Brute like Linus's ledendary penguin.

Chris Welsh

Can't we also give SGI some credit where credit is due...

SGI's main Linux page

I mean look at their 230 workstation . Cute and Brute like Linus's ledendary penguin.

Chris Welsh

Gill gets out his clue-stick. Thwaaack!

The compiler produces native IA64 code.
The compiler runs on Linux.
Since there is currently a somewhat limited supply of IA64 hardware (i.e., none) the SDK includes a simulator so you can test your IA64-compiled programs.

BTW, SGI released their IA64 compilers a month ago.

Actually SGI have been offering linux support for a while. SGI will install and support linux on anyones hardware not just theirs.

No, that sounds about correct. But the author is definitely somewhat confused, as this quote illustrates:
GLX: This is SGI's OpenGL extension. [...]
Um, using the term "extension" in the same sentence as OpenGL really makes people assume that you're talking about an actual API extension, but here this is not the case. GLX is simply the platform-specific glue that connects OpenGL to a platform's particular resources. In the case of GLX, the platform is the X Window System, of course. On Windows there is WGL (pronounced "wiggle"), and on Macs they use something called agl (no link, sorry). GLX also provides network transparancy, since that is a feature of X.

1. Your soundcard has a lowpass filter on it: therefor any data sampled by the soundcard will have a high degree of short-term correlation. Better wait at least 10ms between reads to get good uncorrelated data
2. Unless you are very careful in how you adjust the levels of the signal, it will not cover the whole range of values from the card. You are best off taking the data and gzipping/bzipping it to increase the entropy of the data to maximum.

With so many nations and agencies broadcasting number stations, some of them have to be solely for disinformation purposes.

If these are actual encryptions are using one-time pads as keys, then a brute-force attack (ala distributed.net) would be worthless, unless they're actually using the 'one-time' pads more than once.

What seems more approachable is taking a look at these streams of numbers, looking for the patterns inherient in random number generators. If the method of generating random numbers can be found (which really shouldn't be that hard if the 'disinformation code' is being generated by two guys in a hut and an old PC), then specific stations can be singled out as disinformation stations, sending out 'predictable' random numbers.

Chances are that most of these stations are just that, disinformation beacons.

On the other hand, if they're not, then there must be some header information to identify whether a given broadcast is intended for you (a specific spy) or another agent. This sort of info would likely be the first step of a decryption process, because it would be unlikely that they would force every agent to use up part of a one-time pad at every broadcast just to determine if the broadcast was for them. More likely, there would be some algorithm performed on the header, so an agent can get a reasonably certain idea if the broadcast is meant for them.

My first guess would be something combinitorial, like multiplying the 'agent IDs' of each agent the message applies to, so the agents have only to take the header numbers and see if it's divisable by their number. If so, grab a pen and dig out your one-time pad.

I wonder how many of these sorts of things are already on the net. It makes me want to start a page (that people should mirror, for obfuscation's sake) with random numbers that change every day. Heck, LavaRand is probably doing that right now. Sure they say it's coming from lava lamps, but it could just as easily be messages to spies all over the world, and with 50,000 hits every day, who could trace each one down to find a mobile spy?

Kevin Fox

FWIW, the 3D filemanager she was using (besides being useless) was entirely real. It can be downloaded at http://www.sgi.com/fun/freeware/3 d_navigator.html.

SGI has a linux kernel patch for NUMA since v2.3.30. look here: http://oss.sgi.com/projects/numa/

Really? So you've done this?

I wonder if IBM is actually gonna write a NUMA layer for linux?

SGI has the best in the business, and they're busy putting it into linux as we speak. However, IRIX is _the_ OS as far as NUMA goes, coupled with the sgi Origin. With sgi's massive linux movement, I'm sure linux will be up to par with IRIX in no time at all. Check em out at www.sgi.com/origin. Ever heard of ASCI Blue Mountain? Checkout the top 500 list.

NUMA-Q is the Sequent technology. It is also cache coherent according to this paper, but the details are lacking. It does not appear to scale as well as SGI's NUMA, though.

To be precise, information about SGI's FailSafe software for Linux is at: http://oss.sgi.com/projects/failsafe/ This software has seen much comercial use, including supporting the highest volume of traffic for the Mars lander web site, (Though that was under IRIX). There was even a Slashdot article about SGI's Failsafe: http://slashdot.org/articles/00 /02/26/1224233.shtml

I recently attended the SGI University, and besides recieving a little Tux doll, I sat through some fairly inane discussions about SGI. BUT, this may help you out... they had a session on clustering for high availability. They mainly spoke about being able to hide planned downtime by using 'High Availability, Mission Critical' Clusters where if one failed (or was shutdown for maintenance) the other would automatically pick up the slack... they also spoke of this with regards to Beowulf clusters... you may want to check out their open source area also, and see if any of this software is publicly available yet. It does sound like they are heading in the right direction with getting into Linux...
Hope this helps
regards,
Benjamin Carlson

I recently attended the SGI University, and besides recieving a little Tux doll, I sat through some fairly inane discussions about SGI. BUT, this may help you out... they had a session on clustering for high availability. They mainly spoke about being able to hide planned downtime by using 'High Availability, Mission Critical' Clusters where if one failed (or was shutdown for maintenance) the other would automatically pick up the slack... they also spoke of this with regards to Beowulf clusters... you may want to check out their open source area also, and see if any of this software is publicly available yet. It does sound like they are heading in the right direction with getting into Linux...
Hope this helps
regards,
Benjamin Carlson

So how does this effect the dreams of those of us who dream of having an SGI flat panel display on our linux machines?

Well, the Graphics/Video Cards section of the SGI Flat Panel Q&A on SGI's Web site says:

SGI is committed to continue selling and supporting the digital graphics cards that are bundled with the Silicon Graphics 1600SW flat panel display. Production of the Number Nine cards for SGI continues uninterrupted, and the card will remain part of the 1600SW digital flat panel solution.

(production by whom? S3?) and also says:

Are there any other video adapters that support the 1600SW?
At this time there are not, but we hope to have something to announce by spring or summer of 2000.

and:

When will the 1600SW support DVI?
Keep watching our Web page for more news on this.

XFree86 4.0 doesn't support the Revolution IV-FP, according to the Number Nine page in the XFree86 4.0 driver status stuff:

22. Number Nine

3.3.6:

Support (accelerated) for the Imagine 128, Ticket 2 Ride, Revolution 3D and Revolution IV is provided by the XF86_I128 server.

4.0:

No native support for these chipsets, because the old driver has not been ported.

Summary:

No Number Nine chips are supported in 4.0.

I don't know if this means "has not yet been ported", i.e. that there is a port in progress, or not.

Perhaps the question of when would be more relevant if Linux had better SMP support...

BTW, did you notice that SGI is open-sourcing their Linux IA-64 compiler suite under the GPL? See URL http://oss.sgi.com/projects/Pro64/

"The shortfall to the pseudo-random number sequences you get from your computer is that the numbers are not truely random because they repeat after a (very long) sequence."

That's not really a shortfall of pseudo-random number sequences. Maybe of some poorly implemented sequences, but it's not hard to implement a sequence that repeats only after around 2^1024 elements (Numerical Recipes, Knuth's Art of Computer Programming, etc.). Repetition after such a long time is unlikely to adversely affect any actual use of the sequence. If it does, I would like to borrow your CPU.

The real shortfall of pseudo-random number sequences is that they contain patterns of various kinds. E.g., some of them show up as alignments of points when the pseudo-random elements are used as coordinates of points in a multidimensional space. There are solutions for this (Art, Recipes). Basically, if the patterns in the generator have no relation to your use of the generator, you don't care about them. And for modeling work, that's fine.

However, if you are using the numbers for cryptography, you may care about the distinction between random and pseudo-random, because if you do not have a truly random key, somebody else might be able to find it. E.g., if you generate a key using the current time as part of a seed, somebody might be able to try all keys that could have been generated around the time they think you generated the key. A truly random sequence protects you from this. In such a situation, it is sufficient to generate enough random bits that nobody has the processing power to try many of the possibilities. Those bits can be used as a seed to generate as many pseudo-random numbers as you want, provided your generator and your application do not leak information. So a small quantity of random bits can be useful.

Another interesting method to generate random numbers is to use lava lamps.

First of all, a good PC costs more than you'd think, especially after buying a model with enough CPU, adding a good graphics card, a NIC, a real drive, more RAM... get my point? On the other hand, for the price SGI is asking for these new systems, I sure hope they perform... in many different ways.

As a user of SGI's traditional MIPS processor- and IRIX OS-based Unix workstations, this latest crop of Visual Workstations has me thinking, "hmmmm". As far as pure specs, even the low end model blows my MIPS R10000-based SGI Indigo2 Maximum Impact right out of the water.It's the software, however, that has me a bit concerned. IRIX may look a bit old fashioned and might not have a list of specs as long as that of a typical modern linux distribution, but it is very well designed, supports its hardware quite nicely, and does the job. I have been spoiled with the Insight online manual viewer, swmgr and inst package managers, and other IRIX tools. I work well and am quite efficient with my SGI. The MIPSPro compilers, ProDev Workshop, Inventor, and Performer weren't cheap but they work well and are very well supported with patches and IRIX 6.5.X overlay updates. I have heard the occasional horror story, but problems are rare. SGI is going to have to do a lot of work bringing their linux distribution on par with their current version of IRIX. APIs such as Performer and Inventor will have to be synced up with their IRIX counterparts if they hope to make cross platform development a reality.

I'm happy to see SGI embrace linux, open source, and lower cost hardware, however I hope the transition is smooth and the high-end market still kept on the radar. There are dozens of low-cost 3D packages for PCs and Macs. No longer does one need an SGI to even consider 3D. It's the sheer scalability of their systems that gives SGI their edge. An application can be developed and tested on a (relatively) low-end O2 or the mid-range Octane before being deployed and presented on the high end Onyx2. All without recompiling. The shared architecture and OS makes SGI's lineup like no other. Currently, it appears SGI's top linux system can only be expanded to 2 processors, 2 GB of RAM, and perhaps a future graphics card. Whereas the current Onyx2 supports up to 128 processors, 256 GB RAM, 16 graphics pipes with 4 GB texture RAM total (with InfiniteReality 3 graphics). Not to mention the sheer memory and inter-processor bandwidth as well as the strong, proven hardware support in the OS. All running on the same version of IRIX as that little O2.

There will always be a low end and a high end. There will always be new and old systems about. I'm happy to see SGI moving ahead with new models, faster processors, and updated graphics for their existing machines. From what I understand, the Octane is due for an update soon and the Onyx2 yet again early next year. SGI's future looks bright, I just hope they make the right marketing and public relations decisions. Going after educational and other growing, expanding markets would be a good move, especially if software discounts are offered in certain situations. I welcome SGI to the world of linux, but caution that they have a lot of work to do on both their software and hardware if they are to provide a full solution or even one that will nicely coexist.

C'mon SGI, you can do it. (And please dump that silly new logo on your high-end machines).

canderso@ttacs.ttu.edu

First of all, a good PC costs more than you'd think, especially after buying a model with enough CPU, adding a good graphics card, a NIC, a real drive, more RAM... get my point? On the other hand, for the price SGI is asking for these new systems, I sure hope they perform... in many different ways.

As a user of SGI's traditional MIPS processor- and IRIX OS-based Unix workstations, this latest crop of Visual Workstations has me thinking, "hmmmm". As far as pure specs, even the low end model blows my MIPS R10000-based SGI Indigo2 Maximum Impact right out of the water.It's the software, however, that has me a bit concerned. IRIX may look a bit old fashioned and might not have a list of specs as long as that of a typical modern linux distribution, but it is very well designed, supports its hardware quite nicely, and does the job. I have been spoiled with the Insight online manual viewer, swmgr and inst package managers, and other IRIX tools. I work well and am quite efficient with my SGI. The MIPSPro compilers, ProDev Workshop, Inventor, and Performer weren't cheap but they work well and are very well supported with patches and IRIX 6.5.X overlay updates. I have heard the occasional horror story, but problems are rare. SGI is going to have to do a lot of work bringing their linux distribution on par with their current version of IRIX. APIs such as Performer and Inventor will have to be synced up with their IRIX counterparts if they hope to make cross platform development a reality.

I'm happy to see SGI embrace linux, open source, and lower cost hardware, however I hope the transition is smooth and the high-end market still kept on the radar. There are dozens of low-cost 3D packages for PCs and Macs. No longer does one need an SGI to even consider 3D. It's the sheer scalability of their systems that gives SGI their edge. An application can be developed and tested on a (relatively) low-end O2 or the mid-range Octane before being deployed and presented on the high end Onyx2. All without recompiling. The shared architecture and OS makes SGI's lineup like no other. Currently, it appears SGI's top linux system can only be expanded to 2 processors, 2 GB of RAM, and perhaps a future graphics card. Whereas the current Onyx2 supports up to 128 processors, 256 GB RAM, 16 graphics pipes with 4 GB texture RAM total (with InfiniteReality 3 graphics). Not to mention the sheer memory and inter-processor bandwidth as well as the strong, proven hardware support in the OS. All running on the same version of IRIX as that little O2.

There will always be a low end and a high end. There will always be new and old systems about. I'm happy to see SGI moving ahead with new models, faster processors, and updated graphics for their existing machines. From what I understand, the Octane is due for an update soon and the Onyx2 yet again early next year. SGI's future looks bright, I just hope they make the right marketing and public relations decisions. Going after educational and other growing, expanding markets would be a good move, especially if software discounts are offered in certain situations. I welcome SGI to the world of linux, but caution that they have a lot of work to do on both their software and hardware if they are to provide a full solution or even one that will nicely coexist.

C'mon SGI, you can do it. (And please dump that silly new logo on your high-end machines).

canderso@ttacs.ttu.edu

First of all, a good PC costs more than you'd think, especially after buying a model with enough CPU, adding a good graphics card, a NIC, a real drive, more RAM... get my point? On the other hand, for the price SGI is asking for these new systems, I sure hope they perform... in many different ways.

As a user of SGI's traditional MIPS processor- and IRIX OS-based Unix workstations, this latest crop of Visual Workstations has me thinking, "hmmmm". As far as pure specs, even the low end model blows my MIPS R10000-based SGI Indigo2 Maximum Impact right out of the water.It's the software, however, that has me a bit concerned. IRIX may look a bit old fashioned and might not have a list of specs as long as that of a typical modern linux distribution, but it is very well designed, supports its hardware quite nicely, and does the job. I have been spoiled with the Insight online manual viewer, swmgr and inst package managers, and other IRIX tools. I work well and am quite efficient with my SGI. The MIPSPro compilers, ProDev Workshop, Inventor, and Performer weren't cheap but they work well and are very well supported with patches and IRIX 6.5.X overlay updates. I have heard the occasional horror story, but problems are rare. SGI is going to have to do a lot of work bringing their linux distribution on par with their current version of IRIX. APIs such as Performer and Inventor will have to be synced up with their IRIX counterparts if they hope to make cross platform development a reality.

I'm happy to see SGI embrace linux, open source, and lower cost hardware, however I hope the transition is smooth and the high-end market still kept on the radar. There are dozens of low-cost 3D packages for PCs and Macs. No longer does one need an SGI to even consider 3D. It's the sheer scalability of their systems that gives SGI their edge. An application can be developed and tested on a (relatively) low-end O2 or the mid-range Octane before being deployed and presented on the high end Onyx2. All without recompiling. The shared architecture and OS makes SGI's lineup like no other. Currently, it appears SGI's top linux system can only be expanded to 2 processors, 2 GB of RAM, and perhaps a future graphics card. Whereas the current Onyx2 supports up to 128 processors, 256 GB RAM, 16 graphics pipes with 4 GB texture RAM total (with InfiniteReality 3 graphics). Not to mention the sheer memory and inter-processor bandwidth as well as the strong, proven hardware support in the OS. All running on the same version of IRIX as that little O2.

There will always be a low end and a high end. There will always be new and old systems about. I'm happy to see SGI moving ahead with new models, faster processors, and updated graphics for their existing machines. From what I understand, the Octane is due for an update soon and the Onyx2 yet again early next year. SGI's future looks bright, I just hope they make the right marketing and public relations decisions. Going after educational and other growing, expanding markets would be a good move, especially if software discounts are offered in certain situations. I welcome SGI to the world of linux, but caution that they have a lot of work to do on both their software and hardware if they are to provide a full solution or even one that will nicely coexist.

C'mon SGI, you can do it. (And please dump that silly new logo on your high-end machines).

canderso@ttacs.ttu.edu

First of all, a good PC costs more than you'd think, especially after buying a model with enough CPU, adding a good graphics card, a NIC, a real drive, more RAM... get my point? On the other hand, for the price SGI is asking for these new systems, I sure hope they perform... in many different ways.

As a user of SGI's traditional MIPS processor- and IRIX OS-based Unix workstations, this latest crop of Visual Workstations has me thinking, "hmmmm". As far as pure specs, even the low end model blows my MIPS R10000-based SGI Indigo2 Maximum Impact right out of the water.It's the software, however, that has me a bit concerned. IRIX may look a bit old fashioned and might not have a list of specs as long as that of a typical modern linux distribution, but it is very well designed, supports its hardware quite nicely, and does the job. I have been spoiled with the Insight online manual viewer, swmgr and inst package managers, and other IRIX tools. I work well and am quite efficient with my SGI. The MIPSPro compilers, ProDev Workshop, Inventor, and Performer weren't cheap but they work well and are very well supported with patches and IRIX 6.5.X overlay updates. I have heard the occasional horror story, but problems are rare. SGI is going to have to do a lot of work bringing their linux distribution on par with their current version of IRIX. APIs such as Performer and Inventor will have to be synced up with their IRIX counterparts if they hope to make cross platform development a reality.

I'm happy to see SGI embrace linux, open source, and lower cost hardware, however I hope the transition is smooth and the high-end market still kept on the radar. There are dozens of low-cost 3D packages for PCs and Macs. No longer does one need an SGI to even consider 3D. It's the sheer scalability of their systems that gives SGI their edge. An application can be developed and tested on a (relatively) low-end O2 or the mid-range Octane before being deployed and presented on the high end Onyx2. All without recompiling. The shared architecture and OS makes SGI's lineup like no other. Currently, it appears SGI's top linux system can only be expanded to 2 processors, 2 GB of RAM, and perhaps a future graphics card. Whereas the current Onyx2 supports up to 128 processors, 256 GB RAM, 16 graphics pipes with 4 GB texture RAM total (with InfiniteReality 3 graphics). Not to mention the sheer memory and inter-processor bandwidth as well as the strong, proven hardware support in the OS. All running on the same version of IRIX as that little O2.

There will always be a low end and a high end. There will always be new and old systems about. I'm happy to see SGI moving ahead with new models, faster processors, and updated graphics for their existing machines. From what I understand, the Octane is due for an update soon and the Onyx2 yet again early next year. SGI's future looks bright, I just hope they make the right marketing and public relations decisions. Going after educational and other growing, expanding markets would be a good move, especially if software discounts are offered in certain situations. I welcome SGI to the world of linux, but caution that they have a lot of work to do on both their software and hardware if they are to provide a full solution or even one that will nicely coexist.

C'mon SGI, you can do it. (And please dump that silly new logo on your high-end machines).

canderso@ttacs.ttu.edu

First of all, a good PC costs more than you'd think, especially after buying a model with enough CPU, adding a good graphics card, a NIC, a real drive, more RAM... get my point? On the other hand, for the price SGI is asking for these new systems, I sure hope they perform... in many different ways.

As a user of SGI's traditional MIPS processor- and IRIX OS-based Unix workstations, this latest crop of Visual Workstations has me thinking, "hmmmm". As far as pure specs, even the low end model blows my MIPS R10000-based SGI Indigo2 Maximum Impact right out of the water.It's the software, however, that has me a bit concerned. IRIX may look a bit old fashioned and might not have a list of specs as long as that of a typical modern linux distribution, but it is very well designed, supports its hardware quite nicely, and does the job. I have been spoiled with the Insight online manual viewer, swmgr and inst package managers, and other IRIX tools. I work well and am quite efficient with my SGI. The MIPSPro compilers, ProDev Workshop, Inventor, and Performer weren't cheap but they work well and are very well supported with patches and IRIX 6.5.X overlay updates. I have heard the occasional horror story, but problems are rare. SGI is going to have to do a lot of work bringing their linux distribution on par with their current version of IRIX. APIs such as Performer and Inventor will have to be synced up with their IRIX counterparts if they hope to make cross platform development a reality.

I'm happy to see SGI embrace linux, open source, and lower cost hardware, however I hope the transition is smooth and the high-end market still kept on the radar. There are dozens of low-cost 3D packages for PCs and Macs. No longer does one need an SGI to even consider 3D. It's the sheer scalability of their systems that gives SGI their edge. An application can be developed and tested on a (relatively) low-end O2 or the mid-range Octane before being deployed and presented on the high end Onyx2. All without recompiling. The shared architecture and OS makes SGI's lineup like no other. Currently, it appears SGI's top linux system can only be expanded to 2 processors, 2 GB of RAM, and perhaps a future graphics card. Whereas the current Onyx2 supports up to 128 processors, 256 GB RAM, 16 graphics pipes with 4 GB texture RAM total (with InfiniteReality 3 graphics). Not to mention the sheer memory and inter-processor bandwidth as well as the strong, proven hardware support in the OS. All running on the same version of IRIX as that little O2.

There will always be a low end and a high end. There will always be new and old systems about. I'm happy to see SGI moving ahead with new models, faster processors, and updated graphics for their existing machines. From what I understand, the Octane is due for an update soon and the Onyx2 yet again early next year. SGI's future looks bright, I just hope they make the right marketing and public relations decisions. Going after educational and other growing, expanding markets would be a good move, especially if software discounts are offered in certain situations. I welcome SGI to the world of linux, but caution that they have a lot of work to do on both their software and hardware if they are to provide a full solution or even one that will nicely coexist.

C'mon SGI, you can do it. (And please dump that silly new logo on your high-end machines).

canderso@ttacs.ttu.edu

First of all, a good PC costs more than you'd think, especially after buying a model with enough CPU, adding a good graphics card, a NIC, a real drive, more RAM... get my point? On the other hand, for the price SGI is asking for these new systems, I sure hope they perform... in many different ways.

As a user of SGI's traditional MIPS processor- and IRIX OS-based Unix workstations, this latest crop of Visual Workstations has me thinking, "hmmmm". As far as pure specs, even the low end model blows my MIPS R10000-based SGI Indigo2 Maximum Impact right out of the water.It's the software, however, that has me a bit concerned. IRIX may look a bit old fashioned and might not have a list of specs as long as that of a typical modern linux distribution, but it is very well designed, supports its hardware quite nicely, and does the job. I have been spoiled with the Insight online manual viewer, swmgr and inst package managers, and other IRIX tools. I work well and am quite efficient with my SGI. The MIPSPro compilers, ProDev Workshop, Inventor, and Performer weren't cheap but they work well and are very well supported with patches and IRIX 6.5.X overlay updates. I have heard the occasional horror story, but problems are rare. SGI is going to have to do a lot of work bringing their linux distribution on par with their current version of IRIX. APIs such as Performer and Inventor will have to be synced up with their IRIX counterparts if they hope to make cross platform development a reality.

I'm happy to see SGI embrace linux, open source, and lower cost hardware, however I hope the transition is smooth and the high-end market still kept on the radar. There are dozens of low-cost 3D packages for PCs and Macs. No longer does one need an SGI to even consider 3D. It's the sheer scalability of their systems that gives SGI their edge. An application can be developed and tested on a (relatively) low-end O2 or the mid-range Octane before being deployed and presented on the high end Onyx2. All without recompiling. The shared architecture and OS makes SGI's lineup like no other. Currently, it appears SGI's top linux system can only be expanded to 2 processors, 2 GB of RAM, and perhaps a future graphics card. Whereas the current Onyx2 supports up to 128 processors, 256 GB RAM, 16 graphics pipes with 4 GB texture RAM total (with InfiniteReality 3 graphics). Not to mention the sheer memory and inter-processor bandwidth as well as the strong, proven hardware support in the OS. All running on the same version of IRIX as that little O2.

There will always be a low end and a high end. There will always be new and old systems about. I'm happy to see SGI moving ahead with new models, faster processors, and updated graphics for their existing machines. From what I understand, the Octane is due for an update soon and the Onyx2 yet again early next year. SGI's future looks bright, I just hope they make the right marketing and public relations decisions. Going after educational and other growing, expanding markets would be a good move, especially if software discounts are offered in certain situations. I welcome SGI to the world of linux, but caution that they have a lot of work to do on both their software and hardware if they are to provide a full solution or even one that will nicely coexist.

C'mon SGI, you can do it. (And please dump that silly new logo on your high-end machines).

canderso@ttacs.ttu.edu

I was never too wild about the cases of the Visual Workstations, but then again, they are more PC-like. I personally love the Octane... nice size, great cooling, awesome expansion, and two disk trays that couldn't be easier to use. Plus it looks quite impressive.

It's a darn shame they've gotten rid of the "cube" logo on those systems and have replaced it with "silicon graphics octane" spelled out in an ugly font.

I have one of those nifty SGI 1600SW flatpanel monitors, that comes with a special version of the Number 9 Revolution IV that runs the monitor in 1600x1024, which is 16:10. I also have another monitor attached to an ATI Rage Pro in the same system. Win2k handles the weird ratio and dual monitors without any problems. I have yet to try it under linux or solaris (and don't really want to since I'm spoiled by dual heads, and rather use the unix's via command line, X, or vnc).

Use tar to archive up your system, pass the output tar file through gzip or compress. Then encrypt it with tripple DES using a randomly generated key and then forget the key. For better randomness, skip a random number of bytes into the output stream before using. If you want even better randomness, XOR it against another data set. While not perfect, it does generate a huge data set that is hard to predict. Anywhere you can throw in a randomness into the generation method helps improve the output data set. One possibility would be to randomly select files to archive. Randomly you could drop blocks or XOR them with them with the next block. When building a chaff data set like this it's important to lose input information and bring in other randomness as it's built.

For a truely random number generation method see LavaRand.

Have you ever worked in a heterogeneous environment? Windows users want to open up their "Network Neighborhood" double click on the machine and then double click on the file share.

I maintain several servers (IRIX and Linux - SGI has been a big supporter of samba) and I share the required directory or two on each box. It is easy - no NFS client software to worry about, easy for Windows users, and it works quickly and realiably. Samba also allows printer sharing.

I can see avoiding SMB and Samba if you are primarily a UNIX shop. However, we run about 70% NT and 30% UNIX so the interoperability that Samba provides is excellent.

I think what the author of this article fails to notice is that it still is their project. Being as the nice people at sourceforge have written the software they should have control.

I see a couple of other flaws with the arguments. First of all, it's not always the case that patches are accepted. Look at all the projects SGI has done for the kernel and note how some of them were outright rejected. Yet we magically don't accuse the Kernel of being open source.

about the release cycle thing, I don't see a problem if they take a long time. It takes a large amount of time to do stuff like write documentation, create tar balls and the like. If it's just programmers, most of them would rather program. And access to the CVS for the PHP source, it's been my experience that CVS doesn't serve PHP that well, your mileage may vary.

so while it would be nice to have the SF source code all nice and up to date. If they choose only periodic releases so be it. It's their project. If you think this is a problem, go Xemacs on their ass and fork the code.

• The performance on typical hardware can often be improved by giving it more attention in the driver. However, there is a fundamental problem here: the framebuffer resides across a slow bus (PCI or AGP), so you really don't want to push pixels one by one across it.
• Using e.g. textured quads and OpenGL's wonderful blending, alpha testing, and stenciling modes to express operations is not a nasty trick. If you want to blend two images together, being able to express that at polygon level rather than through tight CPU loops is elegant, not nasty! Also, it conserves bus traffic like crazy, and makes better use of the hardware on your graphics card.
• Doing graphics operations pixel-by-pixel using the host CPU is simply not what today's graphics boards (and machines) are optimized for. This might change in the future, but currently you have tens of millions of transistors in your graphic card's "GPU", so why not use them?

• The performance on typical hardware can often be improved by giving it more attention in the driver. However, there is a fundamental problem here: the framebuffer resides across a slow bus (PCI or AGP), so you really don't want to push pixels one by one across it.
• Using e.g. textured quads and OpenGL's wonderful blending, alpha testing, and stenciling modes to express operations is not a nasty trick. If you want to blend two images together, being able to express that at polygon level rather than through tight CPU loops is elegant, not nasty! Also, it conserves bus traffic like crazy, and makes better use of the hardware on your graphics card.
• Doing graphics operations pixel-by-pixel using the host CPU is simply not what today's graphics boards (and machines) are optimized for. This might change in the future, but currently you have tens of millions of transistors in your graphic card's "GPU", so why not use them?

• The performance on typical hardware can often be improved by giving it more attention in the driver. However, there is a fundamental problem here: the framebuffer resides across a slow bus (PCI or AGP), so you really don't want to push pixels one by one across it.
• Using e.g. textured quads and OpenGL's wonderful blending, alpha testing, and stenciling modes to express operations is not a nasty trick. If you want to blend two images together, being able to express that at polygon level rather than through tight CPU loops is elegant, not nasty! Also, it conserves bus traffic like crazy, and makes better use of the hardware on your graphics card.
• Doing graphics operations pixel-by-pixel using the host CPU is simply not what today's graphics boards (and machines) are optimized for. This might change in the future, but currently you have tens of millions of transistors in your graphic card's "GPU", so why not use them?

this technology allows traditional media (okay, forget about the imperfectness of the system for a moment) to become part of the docuverse. this allows for Nelson's concept of "transclusion" to happen. Basically, transclusion is a way for the integrity of original materials to be maintained. for instance, quotes can often be taken out of context in a journalistic article. transclusion would allow the quote to be linked to the full text. okay, that may not sound so amazing, but for an information junkie like me, it's useful.

there's another important aspect of transclusion Nelson talks about that some other posters touched on - automated royalty payments. if you follow a link, a centralized system can track you and automatically charge you (or the author of the article) for use of their original material.

transclusion
ted nelson

Think this was a joke that circulated on the net. See microsoft customizable BSOD announcement

I there was a freeware program (BSOD Properties) floating around that let you customize BSOD somewhat, but it basically let you change the background and text colors. Doubt this is what you were thinking of but was somewhat related.

BSOD properties

The (really interesting) problem with this is cache coherency and consistency: if you've got (say) 256 independent nodes all accessing the same dataset for CRUD operations (as against straight shared reads with non-interdependent writes), how do you ensure that the data's kept in sync without spending vast amounts of time waiting on locked data. The semantics of transaction processing mandate that your transactions be atomic, consistent, isolated and durable: it's difficult to do this (particularly the consistent and isolated requirements) when you've got lots of nodes each with their own private caches unless you enforce frequent cache flushes and reloads. Even doing this you start seeing a lot of waiting: fundamentally your access to data is serialised, at which point a lot of the benefits of massive parallelisation disappear (this is better known as Amdahl's Law, which states that the potential speed-up offered by massive parallelisation is limited by the fraction of serial work in the problem) - see her e for further discussion.

This is less of a problem with highly read oriented systems (such as DSS) and jobs such as crypto-cracking, but with OLTP this is a fundamental bottleneck.
--
Cheers

I've been to several NASA sites recently, and I can tell you that on the ground most of the machines are SGIs, presumably running IRIX.

As for the shuttle itself, the onboard computers are mostly 386s. If I remember correctly, ESR mentioned in one of his essays that NASA runs trimmed-down Linux on the integrated computers.

The computers that are used for scientific research are different for each mission. If you read Linux Journal, you're familiar with the Metro-X adds which boast that Metro-X X servers are used on the space shuttle. Therefore we can be reasonably sure that either Linux or *BSD runs on these computers at least part of the time.

Also, it should be noted that shuttle crew members are allowed to bring their own laptops onboard for personal use, presumably running whatever they please.

hehehe

Having just purchased a linux render farm, I can really appreciate this article. We went through the process of determining what the best solution was for our system and for the software that we use for rendering (A|W's Maya) and for load balancing (Platorm's LSF) was to expand to linux boxes and use the same software.

We explored Beowulf, but after talking to those that are in the know, Maya's tile renderer is not well suited to a Beowulf system.
I looked at other solutions as well, but due to shared memory and the network bottle neck, nothing could take what we saw as a distributed system and turn it in to a parallel system.

By using a load balancing cluster, we are given the opertunity to render multiple frames at the same time, giving us a speed advanteage. This uses more overall memory than a massively parallel beowulf cluster, but it keeps the speed gain of a parallel system the same. The overhead exists for scene file loading becuase that is done on every machine, but it takes minutes when rendering takes hours. A fair trade.
The distributed system needs horsepower and memory more than network speed or file system speed. It is true that an increase in those will speed up the process, but the money is better spent in CPU and mem concerns. Our systems are all dual 600 mhz with a gig of ram per box. It may seem extreme but from our SGI render benchmarking, the scenes that we render can take over 500-600 mb of system memory.

Is it worth the cost?

We are taking our current render system of SGI boxes, which currently are used as desktops durring the day and render boxes at night and adding full time render boxes as well. The cost comparison of a linux render box can be seen in the hardware price alone. We are using these linux boxes to keep par with boxes that cost at least 3x's as much.
The only disadvantage is that the linux boxes can not be rolled out to desktop systems when new hires arive, where as the SGI boxes can. This is due to Maya's modeler being SGI/NT only and our support of Maya on the SGI only.

All in all, in our situation, a linux cluster is a God send, allowing me to have more horsepower and to allow the company to save money.

Check out this Globe and Mail story about Sick Childrens Hospital in Toronto sorting the map - with a supercomputer. I've seen pictures - SGI Origins all over the place. Cool hardware - now let's hope they "Do no harm" with any knowlege they gain.

Oh wow, they are really moving on template support. I'm so hopelessly out of date.

For the curious, here's SGI's iostreams library:
http://www.sgi.com/Technolo gy/STL/standard_library.html

Now I gotta find some egcs rpms...

What are Koenig lookups?

Where the compiler searches the namespaces of a function's arguments to find the function if it isn't found in the current namespace.

It runs UNICOS/mk, not Linux. Yet :^)

It runs UNICOS/mk, not Linux. Yet :^)