Slashdot Mirror

If you want a damn good techie white paper on the basic physics and engineering of LCD technology, I recommend the mildly dated but still highly informative SGI 1600SW white paper.

Their display used to have the unique advantage of a very low pixel response rate, great for avoiding ghosting in video, but I can't seem to confirm that in their specs nowdays.

--LP

If you're on an SGI, use the ImageVision libraries/tools. We were using it to process big images (60K x 20K x 5, 16 bits per channel) nearly 10 years ago. It will read as much of the image that is needed and will cache some of the tiles so going back over an area won't require another disk read. If the output is to an SGI video card, some image processing operations will be hardware accellerated. ImageVision homepage

If we ever really want to see Linux on the desktop, we need to resolve exactly these issues and a few others

And with regard to Linux file systems, I think XFS is a good cool punk rock solid journaling FS. Though their website seems to be down now.

• Compaq
• HP
• IBM
• Silicon Graphics
• Sun

Karma-hungry? Never :-)

But anyway, according to SGI's site, Shrek was produced using '168 SGI 1200 2U dual-processor Linux OS-based machines'... and some SGI Origin 200 servers... though the characters were designed using Silicon Graphics® O2® desktop workstations. Excuse the trademarks.
I haven't got the faintest idea why they used Linux, though they say it was 'to bring more horsepower to the making of great films', which of course ought to explain everything(?).

XFS is also "database-like". But BFS seems to be rather more ambititous an effort -- and very intriguing.

This is one of several BeOS features that the Open Source community should reall consider stealing. But let's consider these features individually, with one eye on whether they're likely to achieve acceptance outside the ranks of BeOS enthusiasts. Let's not waste time on wholesale BeOS clones and compatibility layers. Those are exercises in denial. BeOS was a nice piece of work, but it's as dead as CP/M. Deal with it.

>>I find it impossible to believe that a bytecode program, which runs on top of a VM (written, by the way, in C++ or in an equivalent imperative language) could be faster than C++ unless the programmer is absolutely clueless. But I'll even be satisfied with "only 50% slower" if I see an example.

The Java VM is written in C.

There are many assemblers out there written in C, C++ and Pascal yet the production language is faster. What is your point ?

>>So we basically have this guy saying that Java can be faster than C++, which can be as fast as assembly and still admitting that Java uses garbage collection (an inherently slow task).

For C++ garbage collection and the benefits of GC in systems, I suggest that you read:

GC issues

give me a huge freaking tower any day

It's not really a huge freaking tower unless it's at least six feet tall. My all-time favorite workstation is the SGI Onyx 2 rack*. Six feet tall, bright purple, noisy as can be. The Onyx 3000 systems are okay, but there's just something inherently cool about the Onyx 2. It's what the French call, "I don't know what."

And the shipping crate is big enough for two people to stand up in. Well, for me anyway. I'm about 5'6".

* Scroll down a bit to find Onyx 2 pics. I didn't think anybody would appreciate it if I linked directly to an 11 MB TIFF.

Here's a press release from SGI.

But much older, at least as old as 1993 (speaking of the original version here)

The original: http://www.sgi.com/fun/freeware/3d_navigator.html
The re-implementation: http://fsv.sourceforge.net/

I really should get to try out the SGI version some time, though it claims to run on 5.3 and less only.

SGI has been offering those headers and libraries you speak of for free for several years now.

IRIX 5.3 IDO

IRIX 6.2 IDF/IDL

Alex

SGI has been offering those headers and libraries you speak of for free for several years now.

IRIX 5.3 IDO

IRIX 6.2 IDF/IDL

Alex

You can get similarly shaped server cases from most hi end PC parts manufacturers, in a variety of colors.

What I'd really like to see is a case mod with an O2 case. There's lot of low end, sub 200Mhz ones that are salvageable from dotcom auctions.

Whilst 16 Exobytes might sound like a BIGNUM for RAM, it isn't that much of a bignum for large scale disk arrays.

Actually, it is a very large number for disk arrays.

I'm unaware of a filesystem that can scale as large as XFS; there may be others, though. XFS uses 64-bit addressing, allowing the filesystem to scale to 18 million terabytes (or 18 exabytes, if you prefer). No filesystem in the world has ever remotely approached that size. According to this nifty site, total worldwide disk drive production for the year 2000 only totalled 2.5 million terabytes. So to build a filesystem that's 18 million TB big, you'd have to commandeer all hard drive production, worldwide, for about 12 years.

They estimate that the total amount of data stored on hard drives in the entire world is only about 4 million TB. That means you could theoretically put all the data in the world that is currently stored on hard drives-- all the pr0n, all the MP3s, all the source code, all the PowerPoints, everything-- on one server with one big filesystem, and only use about 1/4 of the filesystem's capacity. Mount it under /earth and set the permissions to 700, please.

Of course, this fact fails to address your basic premise, which seems to be that assigning unique integer addresses to every byte that a computer can access would be a reasonable thing to do.

Even if there were a reason to do such a thing, don't forget that increasing your pointer size decreases your cache efficiency; you can fit twice as many 32-bit pointers in your cache as you can 64-bit pointers, which results in fewer cache misses and overall better performance. (How much better depends on how cache-friendly your task is in the first place, but 32-bit will never be less cache-friendly than 64-bit.)

Apple will never go back to generic looking cases.

Apple doesn't have to go back to generic-looking cases. A one- or two-rack-unit case doesn't leave a ton of room to be creative, but it's still possible to make 'em distinctive.

Look at the SGI Origin 300 and Origin 3000* for an example of a rackmount system that's distinctive and cool.

* Underneath the rack skins, the bricks in an Origin 3000 are 19-inch rackmount components, between one and four units high. SGI racks come with extra hardware in the back for managing all the cables the system requires, but other than that they're not special.

Apple will never go back to generic looking cases.

Apple doesn't have to go back to generic-looking cases. A one- or two-rack-unit case doesn't leave a ton of room to be creative, but it's still possible to make 'em distinctive.

Look at the SGI Origin 300 and Origin 3000* for an example of a rackmount system that's distinctive and cool.

* Underneath the rack skins, the bricks in an Origin 3000 are 19-inch rackmount components, between one and four units high. SGI racks come with extra hardware in the back for managing all the cables the system requires, but other than that they're not special.

The software manager on IRIX does exactly this. It also displays a list of conflicts (if any) which gives the user an option to either install the requried packages or not install the "offending" package. The software manager is also used to manage installed packages. If you start the software manager from the toolchest menu as non-root you're prompted with a box asking for the root password.

On freeware.sgi.com you can download precompiled binaries for a lot of popular freeware tools, like Apache and GCC. Just press the install-button for the application you want to install (using netscape), and the package is downloaded and software manager is started when the download is done.

Shame they never really caught on outside of DG machines.

Although this one throws in a few SPARC and VAX machines...

http://www.newsforge.com/article.pl?sid=02/02/19/0 49208

And it seems the MIPS-based versions of the respective OSes are coming along; NetBSD will run on your O2. SGI's work on Linux for MIPS is as far as "only Indys have a working XFree86" although a few other machines will boot Linux.

An interesting question is what about the Cobalt MIPS-based appliances? Don't they run Linux as the x86 ones do? So where's the source code for those?

That was an SGI system running the 3d file manager which they borrowed from SGI.
You can download the source code for it and compile the program yourself. FSV. File System Viewer A Remake of FSN. The original from jurassic park

Hrm, well, I do seem to recall reading on Usenet more than once that the SGI Origin 2000 double stacks had a little space between the two nodes and that said space got pretty toasty when the cabinet was closed... Of course, this wouldn't be the first time that SGI hardware was abused in some form or fashion...

I believe C++ templates are one of the most powerful features in C++ but also one of the most misunderstood and (unjustly) maligned. I think a really well written and thought out text would go a long way to unlocking for many the power of templates.

This is a non-trivial book. A very rough contents outline might look something like this:

• Part 1: Introduction to writing templates
  • About templates: a review of syntax, ending with a fairly trivial container example.
  • Template style: stylistic guidelines for using templates: typedefs, template argument naming and ordering, etc.
  • Template practice: when should something be a template, how to decide on template arguments, etc.
  • Templates playing nice: interaction of templates with other C++ features such as virtual functions and inheritence.
• Part 2: The STL, a case study for template library design
  • The STL: an introduction to the _concepts_ behind the STL: iterators, allocators, functors, design by contract using templates, etc. (maybe a chapter or so on each of these concepts.)
  • Example: In depth examination of an existing STL template class.
  • Example: implementing an STL compatible splay tree template class from scratch. (or, better yet, pick some other data structure that's less like something already in the STL.)
• Part 3: A Template Pattern Library
  • I'm not sure exactly what these patterns are, but I'm sure they're out there. Here's a few I've seen:
  • Template conversion/casting: using a template to wrap a complicated or ugly conversion or casting operation.
  • Template factories: using templates to automate coding of factories to create objects.
  • Maybe look at tie classes in CORBA.

If you write this book, I will buy it. If you offer me money, I might write this book. I'd need a co-author though.

-c

--

rofl, u assume someone is using ms just cos they dont like linux? thats kind of egocentric aint it?

Of course not! Everyone knows there are only two operating systems in existance, linux (may Allah bless it's name), and Windows.

Do you need to be sent to a re-education camp?

C-X C-S

I work for a company developing a filesystem which is truly symmetric, and hence does not suffer from these issues.

How is your product different from CXFS?

...and a PCI bus (finally).

Hate to nit-pick, but what does that mean? As far as I can see, every machine SGI has produced since (and including) the
O2 has PCI slots, either standard or as an option.

Interesting to me is that SGI have promised to release a whole slew of new graphics machines in the near future, of which this seems to be the first.

I've got to admit that while the Fuel looks reasonable, I'm hanging out to see what real innovations come out of this. Maybe
this?

...and a PCI bus (finally).

Hate to nit-pick, but what does that mean? As far as I can see, every machine SGI has produced since (and including) the
O2 has PCI slots, either standard or as an option.

Interesting to me is that SGI have promised to release a whole slew of new graphics machines in the near future, of which this seems to be the first.

I've got to admit that while the Fuel looks reasonable, I'm hanging out to see what real innovations come out of this. Maybe
this?

SGI are still producing fantastic graphics architectures with next-to-nothing processing power behind them... Sheesh. What are they on ?
...
SGI get most of their money from government and research contracts. This machine will not cut the mustard in those areas - it's just too damn slow.

I spent 1999 working as a contractor for SGI. Was there for the launch of their first NT product, which only stayed on the market for a few months. After that debacle, the party line was that it was time to concede the low-end graphics workstation market to companies that specialized in commodity hardware. SGI would concentrate on markets that need a lot of computing power, like the high-end graphics workstation market, where the margins are higher and commodity hardware doesn't cut it.

I don't see any flaw in this strategy. So why have the abandoned it? Did George Lucas throw a snit or something?

Well, it's not the first time Slashdot misses the point. :-( SGI didn't released just the Fuel workstation today. In fact, that the smallest and most insignificant part of their announcement.
The actual announcement reffers to the so-called Visual Area Networking - a concept that, basically, boils down to distributed visualising and data processing over a network.
With VAN, a user can interact with an InfinitePerformance supercomputer (usually an Onyx 3000 with several hundred processors), let the big iron do the data processing, and receive the resulting images over a network to a thin client. That "thin" client may be a Fuel workstation, a PDA, some device used by US troops to get realtime maps of the enemy positions, whatever.

The point is, many people, working from many different locations, can work together using their thin clients, but manipulating data on the same supercomputer. I've seen some impressive demos, where two people were immersed into the same VR environment, and were manipulating objects on the same scene, at the same time, over the network. Given the fact that the scene was not just a pure graphical computer-games scene, but an actual simulation with real physical laws and everything, that was pretty damn cool.

I tried to submit the actual story, but it was rejected. Instead, Slashdot caught this ridiculous story about "yet another workstation from SGI". Come on people, get real...

Indeed.

One thing that immediately struck me when browsing the tech specs, was that the only mention of audio was this:
Digital Audio Through USB ports
Now, I'm not sure how many of you are familiar with this, but SGI workstations are known for their great audio capabilities. Even the humble O2 has 8-channel 24-bit ADAT optical audio I/O; that's quite something! It seems SGI has decided that this level of audio support is no longer desired, though... Too bad. I'm not sure if USB can be pushed to support this; at 48kHz sampling rate, 8 channels of 24-bit audio requires a minimum of 9 Mbps of bandwidth, which is less than the 12 Mbps theoretical maximum. *Shrug*. Of course, there's PCI slots, but having it integrated was very convenient. And cool, too.

First of all, the Fuel workstation is sort of a cool new evolution... it uses the existing V10 and V12 graphics from Octane2, and the chipset from a single Origin 3000 node. This means instant software compatibility and one hell of an awesome base to run future graphics and CPU offerings. Compared to a single CPU Octane2... Fuel has *half* the latency, *3.2x* the RAM thruput, and *twice* the CPU interconnect thruput. And it run the same OS and the same apps. All for about 1/3 to about 1/2 the price. Sounds like a pretty resonable update to me. And an Octane2 ain't too shabby for real-time interactive apps, either. If you haven't already, find one to play with. A VPro-based Octane running IRIX 6.5.12 or newer is a 3D beast, and yet rock solid stable. Even makes for one hell of an uncompressed, realtime HD video solution, if you can afford the RAID and HD interface. I've never seen a PC or Mac HD solution come even close to Octane2. And Fuel is that much better...

Folks run IRIX for HD video editing, effects compositing, and 3D modeling for a reason -- it works and it doesn't have the "crap out" effect when working under a huge load. Sure the CPUs in an SGI aren't extremely powerful, but that doesn't matter much -- it's the crossbar switch architecture (Octane/Octane2 is based on Origin 2000, Fuel is based on Origin 3000) and wide busses that make the difference. Batch jobs and long haul rendering is all done on a farm of cheap PC's anyway (unless you're ILM, which owns six Origin 2000s, each with 128 CPUs).

Secondly, SGI is coming up with some way cool graphics offerings. In my opinion, the new Onyx InfinitePerformance graphics is bigger news than the new workstation:http://www.sgi.com/visualization/onyx/ 3000/ip/tech_info.html.

SGI screwed up big time in the past, but they're working on fixing the situation. They can't do everything at once, but they're working as hard as they can. They're a pretty wide spread company. Hell, they even own Alias-Wavefront (ever heard of Maya?). They're doing some other cool things, too. Their developer program is now free to commercial developers, but hobbyists with a real project are invited as well in a case-by-case basis. They're even giving away a Fuel workstation at the SGI Global Developer Conference next month. And it's not just a drawing, either. The winner of the machine will be a hobbyist with an attendee-voted best project. Very, very cool stuff.

http://www.sgi.com/developers
http://www.sgievents.com/developer2002/

First of all, the Fuel workstation is sort of a cool new evolution... it uses the existing V10 and V12 graphics from Octane2, and the chipset from a single Origin 3000 node. This means instant software compatibility and one hell of an awesome base to run future graphics and CPU offerings. Compared to a single CPU Octane2... Fuel has *half* the latency, *3.2x* the RAM thruput, and *twice* the CPU interconnect thruput. And it run the same OS and the same apps. All for about 1/3 to about 1/2 the price. Sounds like a pretty resonable update to me. And an Octane2 ain't too shabby for real-time interactive apps, either. If you haven't already, find one to play with. A VPro-based Octane running IRIX 6.5.12 or newer is a 3D beast, and yet rock solid stable. Even makes for one hell of an uncompressed, realtime HD video solution, if you can afford the RAID and HD interface. I've never seen a PC or Mac HD solution come even close to Octane2. And Fuel is that much better...

Folks run IRIX for HD video editing, effects compositing, and 3D modeling for a reason -- it works and it doesn't have the "crap out" effect when working under a huge load. Sure the CPUs in an SGI aren't extremely powerful, but that doesn't matter much -- it's the crossbar switch architecture (Octane/Octane2 is based on Origin 2000, Fuel is based on Origin 3000) and wide busses that make the difference. Batch jobs and long haul rendering is all done on a farm of cheap PC's anyway (unless you're ILM, which owns six Origin 2000s, each with 128 CPUs).

Secondly, SGI is coming up with some way cool graphics offerings. In my opinion, the new Onyx InfinitePerformance graphics is bigger news than the new workstation:http://www.sgi.com/visualization/onyx/ 3000/ip/tech_info.html.

SGI screwed up big time in the past, but they're working on fixing the situation. They can't do everything at once, but they're working as hard as they can. They're a pretty wide spread company. Hell, they even own Alias-Wavefront (ever heard of Maya?). They're doing some other cool things, too. Their developer program is now free to commercial developers, but hobbyists with a real project are invited as well in a case-by-case basis. They're even giving away a Fuel workstation at the SGI Global Developer Conference next month. And it's not just a drawing, either. The winner of the machine will be a hobbyist with an attendee-voted best project. Very, very cool stuff.

http://www.sgi.com/developers
http://www.sgievents.com/developer2002/

Apple is claiming 7.5GFlop per processor, 15GFlop total for the new dual 1GHz G4.

SGI's Vpro V12 can put out 448 Mpix/sec. But The Geforce 4 runs at 1000 Mpix/sec

I'd guess the prices are not exactly at parity either. It's not a big surprise that Apple is winning these accounts.

Apple is claiming 7.5GFlop per processor, 15GFlop total for the new dual 1GHz G4.

SGI's Vpro V12 can put out 448 Mpix/sec. But The Geforce 4 runs at 1000 Mpix/sec

I'd guess the prices are not exactly at parity either. It's not a big surprise that Apple is winning these accounts.

The new Fuel is only part of what they just announced. The Visual Area Networking/VizServer stuff looks pretty spiff too.

I only see IRIX listed

That's becuase this is their latest MIPS system, not some x86 box. Despite some progress, Linux does not really run on SGI MIPS boxes. And some of us like IRIX just fine, thank you :-)

...if only they would bring back my beloved 1600SW, my life would be complete...

Itanium is hardly vaporware:
IBM
SGI
HP
eBay

In a few years Itanium will be crushing PowerPC. Why am I so confident? Where do you think former DEC Alpha and PA-RISC engineers are working? Hint.

Yes, most of the major 3D type tools exist for win2k. But you miss out on one big one: Maya for OS X. Yea, it's pricy. It's different. BUT it's factors of times better than 3DS (much much more powerful with native NURBS support (who likes that kind of plugins anyway?))

Then, you have the Adobe suite of schtuff (not to mention that Maya now operate on some layer with the rest of the OS). I don't see it as having all the creative tools over on win2k at all anymore. The feture set and number of tools on Mac platforms are quite impressive. (just like always, really.)

Go to http://techpubs.sgi.com and search for cpr. For example, see http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc .cgi?coll=0650&db=bks&fname=/SGI_Admin/CPR_OG/330& srch=cpr

SGI's IRIX has had this for a while. Ironically engough it's called CPR.

IRIX Checkpoint and Restart (CPR) is a facility for saving the state of running processes, and for later resuming execution where the checkpoint occurred.

See the IRIX Checkpoint and Restart Operation Guide for more details. see

As the poster said, there are plenty of others:

• SGI IRIX and Cray UNICOS provide kernel-level checkpoint-restart.
• Condor provides user-level checkpoint restart and process migration by manipulating libraries at runtime.
• esky provides user-level checkpoint restart under Solaris and Linux via runtime library manipulation.
• crak provides kernel-level checkpoint restart for linux.
• cocheck provides user-level checkpoint-restart.
• libckpt provides user-level checkpoint-restart.

I have several high-end (multiprocessor) Linux machines. I did have significant problems configuring the first 2.4 kernels for the machines. They have shown slightly poorer resource utilization than the 2.2 kernels did, but they support all of the system (my biggest system has 8 processors and 3+GB RAM). It has been up for 120 days and is using the 2.4.1 kernel (We had to relocate back then). So, despite the poorer resource allocation performance, my hefty resources make that a non-issue.

As I mentioned, it took me a while to find a stable configuration (I custom compile my kernels). I am not using a kernel beyond 2.4.2.

Perhaps the instability can be corrected if you actively seek lean kernel configurations. With one exception the only downtime that the machine has had in 2001 was scheduled. The one unscheduled service outage was because of a random person turning the machine off (oops, wrong power cable). I use the 2.4 kernels because they are the only mainline kernels that provide for both high memory (> 2GB) and SMP. The alternative is to use the 2.2 kernel with SGI Patches.

Last I looked at it, almost every serious game was done in Direct3D immediate mode, and most recent changes to the API are there.

OpenGL is perhaps only better for games in that it is a thin C layer on top of the hardware rather than a thicker COM layer. One can always write OO scene graph frameworks on top of OpenGL like Performer.

Most importantly, though, is that every computing platform other than Windows that supports hardware 3D acceleration does so through OpenGL. I expect it to outlive Direct3D. :-)

299,792,458 m/s...not just a good idea, its the law!

Ignoring how feasible either options are...

XFS, formerly of SGI's IRIX OS, is a journaling file system for use with Linux (and soon *BSD).

Another option is to run BeOS, with its BFS file system, though as we all know, Be was bought our by Palm and the BeOS is in limbo, future development a dream of only the most rabid Beophile.

Looks like XFS is still not about to be included in the main development tree, which is too bad since it is a great filesystem. I guess that I am going to have to continue getting my updates from SGI.

(Getting a kernel via CVS is SOOOO nice) :-)

I used to live in a place that was right next to a line of high-voltage power lines. And while that isn't a problem to my health, (a few fradulent scientific studies to the contrary), I was close enough that the magnetic induction would give every CRT in my house a 60 Hz signal on the display, so that the screen would move back and forth according to the beat-signal created with regard to the refresh rate.

While this isn't a problem with TVs (which refresh at 60Hz), it was a MAJOR problem with my 21" Viewsonic CRT display, which, in order to get the benefit of the 1800x1400 display, had to be refreshed at 75Hz (going at 60Hz caused too much flicker on that huge display). Needless to say, trying to read tiny text, when the whole screen is shimmying back and forth at 15Hz was headache-inducing at the very least.

This was when I shelled out the big $$$ and got a nice new SGI LCD (SGI 1600SW. It has a good viewing angle, good contrast ratio, runs at 1600x1024 (enough to display two web pages side-by-side), is light-weight and compact (especially compared to my 75 pound Viewsonic P815), and best of all, had no electron beam!

So if, like me, you have a problem with ambient magnetic fields, then I think that the only solution (until OLEDs come out, of course), is to get an LCD. And they're nice. Really nice. In fact, after seeing my display, all my friends went out and got LCDs as well. The only problem is that they're not nearly as cheap as CRT displays.

"Since they rarely use a standard VGA connector, they require a proprietary video card which sometimes will not have open source driver support."

This is absolutely untrue. Most LCD monitors are either driven through analog VGA or through a standard digital interface (DVI.) Of course, the DVI-driven displays will provide higher-quality images.

And what makes you think that OLED cards will have open-source driver support, anyway? IMHO, if the drivers work well, does it really matter if you have the source code? It seems good to try for the utopia of all-open-source, but not purchasing a great monitor just because the drivers aren't open-source seems a bit overboard.

"...dropping an LCD results in a sloppy mess and a couple hundred dollars down the tubes."

Whoa. Stop there. If you spent $200 on an LCD monitor, no wonder you're complaining. The low-end monitors are crappy. I have an SGI 1600SW with Multilink Adapter that will soon be driven by a Geforce3. I spent over $1000 on it, which is more than I have spent on most of my computers. However, it is worth every penny. I would not trade it for any other LCD and I certainly wouldn't wait for a still-vapor technology.

Yes, LCDs are pricey! No, LCDs are not for everyone. But for those of us who want an absolutely gorgeous display -- one that every person who walks into your house will say "Wow!" about, and one that never makes your eyes hurt -- we are more than happy to pay for an LCD.

BTW, I thought this Tom's Hardware article was horrible. Instead of focusing on the wonderful high-end LCDs, this article is dueling the low-end LCDs. Most of these monitors are awful. I would recommend that anyone who is in the market check out the following:

Low-end: IBM T-Series 15" analog
Midrange: Samsung 17" 170MP with built-in TV tuner and PIP
High-end: The SGI 1600SW with Multilink, since discontinued; any Apple LCD

Whatever you do, I wouldn't recommend paying less than $600 for an LCD. Also, definitely read the shopper.com reviews before purchasing. Their thumbs up / thumbs down system is a good way to figure out what people actually thought of the product after bringing it home.

Good luck...

Algorithms, problem-solving functions, and procedures such as you're talking about

...can also be objects. See SGI's STL Manual for some examples.

I'm not arguing in favor of using OO for everything, just pointing out that "objects" can be more broadly defined that the typical C++ intro depicts them.