Slashdot Mirror

There a couple of projects which add meta data to Linux.

The first can be found here. This project adds ACLs and extended attributes to the ext2 filesystem.

There is also the XFS filesystem. This features extended attributes, ACLs and journaling.

I have also heard that extended attributes and ACLs are planned to be supported in the 2.6 kernel. I hope this is true because I think extended attributes can be used to make the Linux Desktop Enviroments alot better.

here

and here

These links all are by other users who installed linux on the TP701 laptops.

Funny but your comment reminded me of Irix...
What do you think the "roulette" to the left of the file manager window is used for ?
Got it : Zoom in and out.

Honestly, though, if you need that kind of throughput, I can't really see you going with commodity hardware; you're more likely to go with something like this.

Disclaimer: I think that the linked product is really neat, because I work on something similar.

SGI stock quote (August 30, 2001): 47 cents . Are you buying? Perhaps you will make enough money in the stock market to buy an Itanium 3D PDA, with a 64-bit version of WinCE!

btw, it seems they are reconsidering their decision to close it down...

I really wish someone would include BFS-style attributes in an Open Source file system

It's called XFS :-)

XFS supports extended attributes just like BeFS. no wonder, since BeFS is based, at least in part, on ideas originated in XFS. You will need some userland tools to set extended attributes and probably a modified tar if you want to preserve attributes inside archives. The web page on Access Control Lists and Extended Attributes might also prove useful. Now, combined with fam & imon , which provide (i)node monitoring you have everything except indexed searching, all in Open Source (imon is actually a kernel patch that adds node monitoring at the VFS layer)

-adnans

I really wish someone would include BFS-style attributes in an Open Source file system

It's called XFS :-)

XFS supports extended attributes just like BeFS. no wonder, since BeFS is based, at least in part, on ideas originated in XFS. You will need some userland tools to set extended attributes and probably a modified tar if you want to preserve attributes inside archives. The web page on Access Control Lists and Extended Attributes might also prove useful. Now, combined with fam & imon , which provide (i)node monitoring you have everything except indexed searching, all in Open Source (imon is actually a kernel patch that adds node monitoring at the VFS layer)

-adnans

Hick town eh?

Oh yeah, way out there in Fairfax County.

Funny, we have the NRO, one of the largest airports in the US, an 802.11b wireless network, SGI, a linux users group, and an Intel datacenter, not to mention also having a boatload of linux careers. Oh yeah, and don't forget that MAE-East often gets cut by cows chewing on the fiber out here in hickville. Oh, I forgot some little things like ThinkGeek, NSI, and ARIN.
Oh yeah, and that hick high school is getting me my CCNA.

I'm not even going to mention AOL, Erols, or the CIA.

But you get the picture.

- Cary

In fact, I'll link you: System bandwidth: 716GB/sec
Mwahahaha.

Ahh, I remember seeing the early prototype for 3dwm in the first Jurassic Park movie. Dickie Attenborough's granddaughter sits down, proclaims "It's a Unix System! I know this!", and then navigates through 3dwm in order to restart all the correct processes and, sadly, save everyone from being eaten by raptors, which would have been far more entertaining. I remember watching the movie, hoping she would fail and be eaten in a bloody, gore-filled mess, when I realized I had been thwarted by a heretofore unseen graphical window manager which could be intuitively controlled with a mouse.

As long as it doesn't keep saving the lives of actors who really deserve to be chewed into little balls of dripping flesh, I think 3dwm will be "O.K."

BTW, people can get more information about XFS, or download patches or kernel source from the SGI Linux XFS site. CVS is also available.

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Linux Scalability

Kernprof (Kernel Profiling)

SGI kGDB (Remote host Linux kernel debugger via GDB)

NUMA (NUMA support in Linux)

Bigmem (Big Memory support for Linux)

Lockmeter (Linux kernel lock-metering)

Post/Wait (Post/Wait Synchronization)

SGI kdb (Linux kernel debugger)

Raw I/O (Enhancements to Linux raw I/O capabilities)

POSIX Asynchronous I/O (KAIO)

LKCD (Linux Kernel Crash Dumps)

STP (Scheduled Transfer Protocol)

Microsoft is dying? Wow..thats news.
You know with SGI completly owning(both in script kiddy sense and www.m-w.com sense (b.)) the 3d Graphics market ( Alias~Wavefront , SGI's beast of machines)
I'd wonder how you could say the pionears of realtime 3d could be dying.

What a world...

Microsoft is dying? Wow..thats news.
You know with SGI completly owning(both in script kiddy sense and www.m-w.com sense (b.)) the 3d Graphics market ( Alias~Wavefront , SGI's beast of machines)
I'd wonder how you could say the pionears of realtime 3d could be dying.

What a world...

Microsoft is dying? Wow..thats news.
You know with SGI completly owning(both in script kiddy sense and www.m-w.com sense (b.)) the 3d Graphics market ( Alias~Wavefront , SGI's beast of machines)
I'd wonder how you could say the pionears of realtime 3d could be dying.

What a world...

FWW when this article came out we made a demo of our financial planning app in java. at the time we were able to achieve sufficient animation, think active graphs, by sacrificing stability (yes, stability).

lastly, one thing to keep in mind is that Java is very important in the financial world, where being able to get an app (or applet, whatever) that uses new mathematical models onto the traders' desks as quickly as possible is a competitive advantage. in that environment java is superior to VB/VC/etc.

________________________________________________

... project is already doing it. See their Linux Scalability Project.

If your app requires lots of vector crunching, the SV1 is one hellofa machine that'll keep you more than happy. The specs (mentioned above) are staggering... up to 1 TB of RAM, up to 1229 CPUs, air and/or water cooled.

However, it's not alone. There are some other pretty mighty machines out there. The NEC SX-5 has faster RAM and more powerful vector CPUs than the SV1, but does not scale as large. The SGI Origin 3000 series is not vector, but rather a of (somewhat) traditional CPU design. It's available with up to 512 CPUs and 1 TB of RAM. Unlike both the SV1 and SX-5, the Origin can be ordered with graphics (which turns it into an Onyx).

Then, there's the upcoming Cray SV2, which will be a combination of massive parallel & vector processing. Up to several thousand CPUs and a staggering RAM thruput of 250 GB/sec per bank!! (The Origin 3000 mentioned above has a total system bandwidth of 716 GB/sec.... but that's the entire machine. The SV2 will have more than that with just three banks of RAM alone).

Some of these machines are single image systems (in the case of the Origin 3000, SX-5 and >33 CPU SV1)... meaning they are one single machine, not a cluster. Most run very specific OSes made just for their hardware, with the possible exception of the Origin. SGI's big Origin and Onyx 3000 machines run IRIX 6.5, the same OS that runs on a $150 e-bay special SGI Indy workstation. Kinda cool. The compilers and math libraries are also heavily tuned and generally come with lots of example code and performance tips. When my university purchased a 96 CPU Origin 2000 a few years ago, SGI included a *box* of binders and CDs from some past performance computing seminars they had held. Our university still holds a support contract for the Origin, and thus we're still getting significant compiler and library updates.

Sort of belittles dual bank PC2600 DDR-SDRAM (2x 2.6 Gigabyte/sec = 5.2 Gigabyte/sec) and Myrinet (1 Gigabit/sec = 125 Megabyte/sec interconnect), doesn't it.

Of course... a 16 node x86 cluster doesn't cost $500K - $50M either...

You're thinking of "Rocket" Rick Belluzzo, former CEO of SGI. He was responsible for putting MIPS/IRIX on hold, courting the Wintel crowd, and the "sgi" logo. He successfully put SGI in a steep nosedive they'll probably never recover from.

Where is Mr. Belluzzo today?

Hold on to your hat...

http://www.microsoft.com/presspass/exec/belluzzo/d efault.asp

... we get the article about some d00d gutting one of these things and filling the space with a 466mhz celeron based setup, so he can 0wN the next lan party with the cool looking case?

That was insightful? Crikey.

OpenGL is written for a UNIX environment, DX is for a Windows environment

No. OpenGL is an API, with bindings on UNIX platforms, on the Mac, Win32, Linux, PSX2, XBox and so on. Pretty much all 3D hardware of note has an OpenGL driver.

OpenGL does NOT change very much, which has both good and bad sides, for example, this threads discusses pixel shading, which is a feature OpenGL does not natively supports.

OpenGL does change a lot. Hardware vendors are free to add functionality via extensions, something they cannot do with D3D without going through microsoft.

Also, it does support what DX8 calls pixelshading. It exposes it through a quite different interface to DX8 (see here and here), this much more closely represents what the hardware is actually doing.

That was insightful? Crikey.

OpenGL is written for a UNIX environment, DX is for a Windows environment

No. OpenGL is an API, with bindings on UNIX platforms, on the Mac, Win32, Linux, PSX2, XBox and so on. Pretty much all 3D hardware of note has an OpenGL driver.

OpenGL does NOT change very much, which has both good and bad sides, for example, this threads discusses pixel shading, which is a feature OpenGL does not natively supports.

OpenGL does change a lot. Hardware vendors are free to add functionality via extensions, something they cannot do with D3D without going through microsoft.

Also, it does support what DX8 calls pixelshading. It exposes it through a quite different interface to DX8 (see here and here), this much more closely represents what the hardware is actually doing.

That was insightful? Crikey.

OpenGL is written for a UNIX environment, DX is for a Windows environment

No. OpenGL is an API, with bindings on UNIX platforms, on the Mac, Win32, Linux, PSX2, XBox and so on. Pretty much all 3D hardware of note has an OpenGL driver.

OpenGL does NOT change very much, which has both good and bad sides, for example, this threads discusses pixel shading, which is a feature OpenGL does not natively supports.

OpenGL does change a lot. Hardware vendors are free to add functionality via extensions, something they cannot do with D3D without going through microsoft.

Also, it does support what DX8 calls pixelshading. It exposes it through a quite different interface to DX8 (see here and here), this much more closely represents what the hardware is actually doing.

two points:

1. games have always been hardware-specific. dx8 means only x86 compatible hardware & windows. but i assume you mean graphics-hardware, so to address that directly:
2. yes, developers have to write code for one or the other pixel 'shader' api directly, thus excluding them from the other. this is extremely shrewd business - get developers locked-into your platform, then watch the other competitor's hardware perform more poorly, and eat their lunch too. it's how microsoft has done well, and it's what ati & nvidia are competing for right now. it's not the technology, it's the business of technology.
3. ok, i lied, 3 points. bonus point. there are alternatives which are platform neutral, and higher-level. think of pixel-shading apis as writing in assembly. think of high-level shading apis as writing in c or c++. a better idea than writing in 'shader assembly' would be to write in a high-level language. SGI & stanford both have projects which are, at their core, hardware-agnostic:
   • SGIs shading architecture
   • Stanfords shading architecture

but if anyone hasn't yet simply turned their computer off accidently while running Linux....I dare you..

Dare me huh? You got it, but then I run XFS. I can't reccomend running a journaling file system highly enough.

SiliconGraphics has made a lower-resolution "portable" model for awhile now. Not quite the same thing, but neat nontheless.

http://www.sgi.com/realitycenter/rc3300w.html

Seriously, SGI should have provided the plot line as well as the hardware: "See a successful UNIX hardware vendor, driven to irrelevance by demon possesion -- resulting in inexplicable plans to rely on M$! Watch in horror as it is destroyed from within by terrible university relations, the creeping spectre of mismanagement and a bizarre, not-quite-SVR3 operating environment. Will a hero come and save it? No."

~wog

SGI systems cannot run 2K
Hrm, you should check the ol' website before you make that statement again...
but thanks for coming out...

5. Did you see a mention of x86? I sure didn't. All I saw was SGI. SGI systems can run Linux. SGI systems cannot run 2K.

Well, some SGI systems run Windows 2000. And as far as I know, Linux doesn't run on much of the high-end (IRIX) machines SGI offers. It runs with limited framebuffer support on older Indy machines (and probably Challenge series stuff), and Indigo2 machines with serial console support only. Check here for the info. The page is over a year old, but owning an SGI myself, I haven't heard any different.

5. Did you see a mention of x86? I sure didn't. All I saw was SGI. SGI systems can run Linux. SGI systems cannot run 2K.

Well, some SGI systems run Windows 2000. And as far as I know, Linux doesn't run on much of the high-end (IRIX) machines SGI offers. It runs with limited framebuffer support on older Indy machines (and probably Challenge series stuff), and Indigo2 machines with serial console support only. Check here for the info. The page is over a year old, but owning an SGI myself, I haven't heard any different.

A previous SGI press release for the Perfect Storm Stated that ILM had upwards of 1500 SGI processors:

They still do most of their stuff on SGI's, besides the Rebel Mac Unit, but as far as Linux they have stated that actually they are using it for workstations, not servers, they think it's lacking still for server use:

MIPS owns the trademark to MIPS, and owns a lot of the intellectual property. The MIPS design work within SGI is conducted seperately from MIPS though. It's not a matter of buying an ASIC core and slapping some additional logic on it, these processors are designed from the ground up at SGI. It's more of a derivative work I suppose if you consider software design terminology. Sort of like FreeBSD v.s. OpenBSD etc. They share common ancestors but they're more than just enhancements of somebodies intellectual property.

I can't really post more compelling information, I work for SGI and need to be somewhat careful. Essentially when MIPS was spun off SGI retained key intellectual property (R10K and above).

From the Stats Page:

"Automaticly Updated on: 07/09/19101 01:43:07"

As we can see, this is future Reality. 17,100 years from now. SGI has relized the paradox this can create, when we know what will be Reality in the future (we can steer circumstances to modify the future), and they are just tired of rewriting future Reality every time someone goes against The Plan.

Perhaps SGI designed the processor itself, but I believe the intellectual property does actually belong to MIPS. Just as LSI, QED (now PMC Sierra), IDT, etc. design MIPS based processors with MIPS IP. (MIPS does not, of course, actually manufacture any processors; it's an IP only company.)

I did find this page of "MIPS-Based(TM) Products" at MIPS, which lists SGI's machines. That page states "Design efforts utilizing MIPS® intellectual property are continuing for the system and server markets by Silicon Graphics."

Also notice that SGI's R10000 processor page includes the following at the bottom: "R10000, ANDES, and Avalanche are trademarks of MIPS Technologies, Inc."

To me it looks like SGI behaves like any of MIPS licensees; they use intellectual property that (now) belongs to MIPS Technologies Inc., and design their processors using that. Perhaps there is an agreement between MIPS and SGI, but I couldn't find details of it. I'd be very appreciative (really) if you can show evidence to the contrary. I'm not trying to be argumentative; I would actually like to know how this is set up.

Another area where SGI hardware is the industry standard is movie/broadcast post production. With the necessary cards, SGI's hardware (Onyx and Octane) are the only boxen that'll give you realtime HD (1920x1080) video editing. Coupled with Discreet's software and ultra-fast HIPPI networking, the post production houses of the world can get their customers in and out quick. Post production houses make an obsene amount of money, charging approximately $1500USD per hour for an Inferno suite, so I guess they can afford the high prices of SGI's hardware.

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

Another area where SGI hardware is the industry standard is movie/broadcast post production. With the necessary cards, SGI's hardware (Onyx and Octane) are the only boxen that'll give you realtime HD (1920x1080) video editing. Coupled with Discreet's software and ultra-fast HIPPI networking, the post production houses of the world can get their customers in and out quick. Post production houses make an obsene amount of money, charging approximately $1500USD per hour for an Inferno suite, so I guess they can afford the high prices of SGI's hardware.

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

Umm, SGI jumped on the Linux bandwagon too, for example their work on a journalling file system. That hasn't paid off for them either. It remains to be seen if IBM will make any money there either.

I guess the announcement of reality.sgi.com's imminent demise means the Widget FAQ , a primer on widgets in the Intrinsics, Athena and Motif families, will be gone. Several years ago the widget FAQ used to have or point to C source code for several really useful extension widgets for Athena -- does anyone else remember the extremely compact rotary/slider/radio combination widget?