Slashdot Mirror

One might also visit SGI's investor relations page to witness their release on the subject. I'm subscribed to the conference call, and if windows and firefox both stay running until 2:00 PM I expect to have some suits blathering in the background.

How are filesystems that were designed from the ground up to be journaled filesystems "essentially bolt journaling to the traditional file system UNIX layout"?

Did you actually bother to look at the layout of an XFS filesystem?

You refer to a Debian article on XFS CPU usage, but fail to mention that the conclusion of the aritcle is "Based on all testing done for this benchmark essay, XFS appears to be the most appropriate filesystem to install on a file server for home or small-business needs" and "Personally, I still choose XFS for filesystem performance and scalability".

You then go on to continue the myth about XFS corrupting your data, a myth that has been debunked countless times. Changes were made to XFS some time ago so that it behaves in a way that user's were expecting.

It's a somewhat half hearted blog in my opinion and I'm surprised that slashdot picked it up.

How are filesystems that were designed from the ground up to be journaled filesystems "essentially bolt journaling to the traditional file system UNIX layout"?

Did you actually bother to look at the layout of an XFS filesystem?

You refer to a Debian article on XFS CPU usage, but fail to mention that the conclusion of the aritcle is "Based on all testing done for this benchmark essay, XFS appears to be the most appropriate filesystem to install on a file server for home or small-business needs" and "Personally, I still choose XFS for filesystem performance and scalability".

You then go on to continue the myth about XFS corrupting your data, a myth that has been debunked countless times. Changes were made to XFS some time ago so that it behaves in a way that user's were expecting.

It's a somewhat half hearted blog in my opinion and I'm surprised that slashdot picked it up.

SGI's NUMA systems did support 1024 processors in 2006 running Linux and on IRIX way before that.

This post is somewhat redundant now but I have been wondering about the same thing and then I found out about NUMA:

http://lse.sourceforge.net/numa/

If you are looking for a NUMA machine running Linux have a look at this.

http://www.sgi.com/products/servers/altix/4000/

If you check out citeseer you might find that the name NUMA came up around 1989. I couldn't find it any earlier. So whatever a 256 core processor will look like, it doesn't have to be something new.

It seems like it should be possible to use already existing parallel architectures in those multi core processors. Although I could imagine that integrating multiple cores on one chip could support architectures which make use of that different type of platform. I don't know how this could look like, but I wouldn't want to rule out that we are going to see something new.

Please check exactly what is covered by the SGI B and GLX licenses before you shout "Awesome!". The truth is, very little is covered.

All they've really tidied up to the FSF's satisfaction are the licenses on the GL and GLX headers and machine-readable specification documents, which are used in many FOSS bindings. It has also fully freed up SGI's sample OpenGL implementation, but that is 8-year old abandonware, and not used by anyone for anything.

This improvement in the license is undoubtedly helpful, but mainly to license Nazis, not to engineers.

It provides nothing new to anyone actually working with OpenGL, since the only working FOSS implementation of OpenGL (but unvalidated) is still Mesa 3D, which isn't dependent on SGI's license. nVidia's OpenGL implementation appears to be their own and not licensed from SGI (as far as we know), so nVidia OpenGL is not freed up by this relicensing --- they probably only license the OpenGL trademark from SGI (and that's a code-free SGI license).

So no, it's substantially less than awesome, since we still have no fully-accelerated OpenGL. And nothing changes, in practice, as a result of this announcement. (Check out #OpenGL on freeenode to see how underwhelmed everyone in the GL community is.)

What we really have here then is just a "PR success" which helps SGI and helps the FSF, but doesn't really do anything of significance.

What will definitely be "awesome" news for OpenGL+FOSS is when the FOSS community finally turns all that documentation we received from AMD and Intel and Via (but not from nVidia) into accelerated 3D drivers to work with a Mesa-based OpenGL. But that's a shitload of work (and our guys *ARE* working very hard at it), and so working systems won't be with us for several years yet.

So, sorry, not awesome, just PR.

I was tempted to post: "Holy crap, this is big news!! SGI is still in business!!!"

Surprisingly enough, not only is SGI still in business, but they'll even sell you a workstation with a MIPS processor (if you really want one).

C
    The GNU C Library
    http://www.gnu.org/software/libc/manual/

C++
    Standard Template Library Programmer's Guide
    http://www.sgi.com/tech/stl/

    Boost C++ Libraries
    http://www.boost.org/doc/libs

Java
    Java(TM) Platform, Standard Edition 6 API Specification
    http://java.sun.com/javase/6/docs/api/

Perl
    Perl version 5.10.0 documentation
    http://perldoc.perl.org/

Python
    Python Library Reference
    http://docs.python.org/lib/lib.html

For learning C and C++, I recommend these books:

    Kernighan, Ritchie: The C Programming language
    Kernighan, Pike: The Practice Of Programming
    Koenig, Moo: Accelerated C++: Practical Programming by Example
    Sutter, Alexandrescu: C++ Coding Standards

Standard Template Library:

• SGI reference - readable, comes with informative explanations of concepts
• libstdc++ reference - less readable, but it may have some non-standard things that aren't in the SGI docs, useful if you're using libstd++

Boost libraries:
For anything not present in the standard library, these are the next place to check. They're freely usable in commercial projects.

SGI's STL site is excellent, though I'm not not sure how up-to-date it is.

The C++ Programming Language , by Bjarne Stroustrup, is the only essential and authoritative language reference, other than the standard itself. It isn't a web site, but programming in C++ isn't something you pick up on a whim.

And of course Boost, the first place to look when you think, "There should be a library for this."

The STL reference . Please keep this page open when you are writing your C++....

Sure you can use Ext3 if you want to be conservative, but why not use one that performs much better, such as JFS, XFS, or Reiser3? Read this comparison for example in which Ext3 is mostly bringing up the rear. They recommend XFS overall. I use Reiser3 for most of the filesystems on my MythTV systems and XFS for the recordings.

The data loss on power loss in XFS has been fixed, so as long as you're using Linux 2.6.22-rc1 or newer, there's no reason not to use it. If one's Ubuntu installation still has the bug preventing automatic JFS checking, that might be a reason to avoid it.
 

Boost is created and maintained by, among other people, the people who created and maintained the C++ STL.

Well, yes and no. Although Boost was begun by members of the C++ Standards Committee Library Working Group, participation has expanded to include thousands of programmers from the C++ community at large.

And of course, the STL was originally developed independent of C++ by Alex Stepanov and Meng Lee. When Stepanov was first throwing around the underlying ideas, C++ didn't even have templates yet.

If by "on more than the bleeding edge platforms" you mean "on something other than MSVC," then yes. Microsoft's compiler was tremendously shitty when it came to standards conformance until .NET 2003 edition (I believe).

Your prejudice is showing. Visual C++ has pretty consistently been among the most standard-compliant compilers since forever. It fell behind a little in the early 2000s, since VC++6 was actually released before the C++ standard was finalised, but remember that we're talking about the GCC 2.95 days there, and the average UNIX platform compiler wasn't even on the chart at that point.

You're definitely a Windows developer, aren't you? You're just suffering from the fact that Boost isn't really built with or for MSVC, and the Windows development process is very non-standard with respect to every other OS out there.

Irony #1: My C++ code probably gets compiled on more platforms than code written by most, maybe even all, of the other participants in this discussion.

Irony #2: While Windows may be the "odd one out" relative to the Linux world, the Visual C++ command line compiler and makefiles pretty much work like every other platform.

Irony #3: Visual C++ is the only compiler on which I have actually seen real world code that makes extensive use of Boost compile properly out of the box.

As for the licensing terms, this is the boost software license. It is three (short) paragraphs long.

It doesn't matter what it says. There is a licence, which imposes a restriction. That in itself it enough to trigger a need for approval by the legal people in many companies.

Should I mention the fact that boost is the code base for much of the additions to the next generation of the C++ STL? I know templates can be big and scary, but really...

Do you think adding substandard lambda expressions and a funky parser library using template wizardry are more important than providing, say, standard facilities for working with networking, database interaction, heck, even console I/O? This is what the C++ in-crowd have brought us: an emphasis on using clever tricks to provide facilities that still aren't as good as what numerous other languages do anyway, instead of plugging gaping holes in the basic provisions of the standard library. I don't have anything against templates (well, not on this scale, anyway) but I do have a big problem with directing an entire development community's efforts towards overcoming mostly self-made problems with templates and the rest of C++ rather than getting the basics into the state they should have been in ten years ago.

It seems we kind of agree, actually :)

I guess a lot would become clearer if the OP would actually state what he means by headless. I wonder if he did and I missed it somewhere (it's easy to get lost in the replies, I find).

"I was initially questioning the OP's motives in wanting a headless machine with a better GPU"

Right, that is clear. You said it was nonsensical or something, no? The meaning of that almost entirely depends on what you mean by 'headless'.

"I consider a machine headless if it is used without a monitor, etc."

Ah, so that's a new definition to me; and using that definition, it would be reasonable to question their desire for a GPU of any kind.

However, there could still be value in having a GPU even when you don't *ever* attach a monitor to it :

http://www.sgi.com/products/software/vizserver/

This product uses the graphics pipe purely to accelerate rendering. It reads the framebuffer back (or uses h/w feedback into a PCI card which is much quicker) into the host and sends it onto client machines elsewhere on the network. It can have many clients.

Of course, VizServer is/was an IRIX product, so could/should be considered defunct. However, you can see other such uses, or potential for them at least. Niche, for sure, and probably not what the OP was talking about, but perhaps interesting.

I wonder what the OP did mean....? Will we ever know (or care, particularly) :)

A don't think a lot of gamers (or other consumers) will want this. A more typical application would be visualization. SGI still does business in this area. Eventually, commodity computers will drive them out of this business, just as they did the workstation business. And fancy graphics cards that fit in standard PCIe slots is part of the reason.

I suffer from memory shock on a daily basis. I work in the x64 part of Sun, and I got into a friendly argument with a SPARC guy about whether our half-terabyte server is better than their.

On the downside: just upgraded my tablet to 4GB, only to discover that Win32 can only handle 3 of them.

This just shows how much Slashdot is geared towards software engineers. Mechanical engineers like me have been playing with 2 gigs of video memory since the Onyx 3000. Honestly though 2 gigs of memory would be pretty sweet I use a Firegl 7300 series sometimes and it still lags with some of the more complex assemblies I've tinkered with.

"Microsoft Windows" and "Super Computer" are by definition mutually exclusive. What next, powering a jet fighter using a propeller?

In other news...

Systems with a terabyte of RAM are not unusual in the government installations here in the DC metro area. Putting 16TB of RAM in a server will cost millions dollars right now, but it's by no means out of the question. See this SGI press release for a sample with 28TB of RAM.

I recommend an SGI server :

http://www.sgi.com/products/servers/

They start with the minimal specs you quote (I think) and they tend to scale quite well, so I'm lead to believe, in case you increase the size of your family and/or circle of friends...and they start at a very reasonable price, I'm sure.

It's being done though not on the system level but on the rack level. SGI's ICE platform has water-chilled doors: http://www.sgi.com/products/servers/altix/ice/features.html

This is a great bonus for high density HPC applications. Typically in a datacenter you are blowing air up from the raised floor in front of the servers. However, a good deal of it is taken up by the servers in the lower part of the rack, leaving the top servers running warmer than the lower servers. Supposedly the water chilled doors help a lot in this scenario.

SGI have been doing 128TB for ages - http://www.sgi.com/products/servers/altix/4000//
Here's a 4.1TB system out there (i.e. not just a number on a white paper): http://www.sgi.com/company_info/newsroom/press_releases/2006/september/lite.html/

SGI have been doing 128TB for ages - http://www.sgi.com/products/servers/altix/4000//
Here's a 4.1TB system out there (i.e. not just a number on a white paper): http://www.sgi.com/company_info/newsroom/press_releases/2006/september/lite.html/

The technology is already there. SGI's Altix 4700 (cc-numa) "Scales to 512 sockets or 1024 cores system size and as much as 128 TB globally addressable memory." http://www.sgi.com/products/servers/altix/4000/features.html

Yeah, that's a bit more than 1TB. Imagine a Beowulf... Wait a minute... Imagine a RAM disk.

It's not news that an old system was replaced by a new system. It is interesting that an old supercomputer wasn't replaced by a new supercomputer; a cluster of cheap commodity systems does the job just as well when you don't need real-time performance. This sort of creative use of PCs is what drove SGI into bankruptcy and irrelevance.

This Philipine newspaper story fills in some important details missing from the Australian PC News article: the age of the SGI system (10 years) and the reason it was costing so much to run (expensive to get application support for IRIX, an OS that hasn't had a major update in the same 10-year period).

This last issue is what really killed the SGI system: not its age (these big installations are often around for decades), but the fact that only a few people are working on SGI platforms any more, and those that do can command premium prices. If the system had been from Sun, HP, or IBM, or any company with an OS still under active development, it might have been cost effective to keep it in place. This is particularly relevant on Slashdot, where we're always hearing from folks who just don't understand why there isn't better application support for their favorite platform.

I'm still curious as to what specific SGI system got junked. Best guess: a low-end Origin.

Considering you don't know that the SSI he was (obviously) referring to is "Single System Image", and that he was discussing that the level of SMP for SGI SSI machines (not Beowulf clusters etc.) can go as high as 1024 on Linux http://www.sgi.com/company_info/newsroom/press_releases/2006/june/altix4700.html/ I'm guessing he's not the troll or idiot...

Of course, erase() invalidates iterator. That's one of the first things you read in documentation http://www.sgi.com/tech/stl/Map.html If you don't, it's your own fault. In C++ you can write exception-safe easier than in Java, because of RAII (http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization) concept.

I've written myself a script that tracks certain directories (~/Code, ~/Documents, ~/Work, etc.) using FAM. When a file is modified it grabs it and stores it on a file server on the local network. Also you may want to have a look at Gamin, which is a FAM replacement maintained under the GNOME project.

Silicon Graphics Inc. (SGI) build their systems out of bricks.

SGI bankruptcy is mentioned in the second paragraph of the entry on wikipedia.
The official SGI press release

They are a sad shell of the mighty graphics workstation company they once were.

But SGI stopped selling it's UNIX(R) software & technology earlier this year. IRIX(R) is no longer available thru SGI's normal channels, and support ends in 2013 ("no sooner than 12/2013" is the quote). And all their current hardware runs SUSE or RedHat Linux or even Windows Compute Cluster Server 2003 software now.
My pair of Indy's weep blue tears...

Interestingly enough, Darl McBride and Co. have killed one of the top ten closed-source Unix vendors, strengthened the Linux market, and helped bring about major improvements in how Open Source people document their code contributions. If his goal was destroying Open Source in favor of Closed Source, he achieved pretty much the opposite.

Sun, IBM, HP, and Apple (who all sell Unix on Intel-powered hardware (although HP's Intel hardware of choice is Itanium)) are likely not at all upset that SCO is no longer going to be trying to bill themselves as the premier Intel-compatible Unix. All of these companies of course also sell or have sold Unix on other hardware (Sparc, Power, PA-RISC, Alpha, PowerPC, Motorola 68k to name a few). Sun and IBM are two fairly strong supporters of Linux, too, although they both tout their proprietary Unix platforms as well. HP has business relationships and/or offers support for Red Hat, Oracle, Novell's Suse, Red Flag, Mandriva, and Debian.

SGI used to have IRIX, but they are phasing it out in favor of Linux (but Windows still survives on some SGI lines). SGI, being the class act it is, offers support for existing IRIX customers until at least 2013 (or the company's long-rumored folding, whichever comes first -- they actually came back from Chapter 11). RHEL and SLES are both available, supported options on Altix. SLES seems to be preferred.

It appears most of the closed-source Unix companies know the value Linux can offer. If they're not moving from closed-source solutions to Linux, then they're making it clear that Linux is an option. It's interesting that many of the companies willing to go in big for Linux sell something besides operating systems. Hardware, databases, visualization software, and directory software seem like good compliments to an OS, and vendors selling those items are just who is embracing Linux. Even Apple, who hasn't done much to embrace Linux, isn't adversarial to it. Parallels (third-party, of course) and Boot Camp (Apple) both can give access to any of the x86 or x86-64 Linux distros on the newer Macs, while PowerPC Macs dual-boot with Linux just fine.

Interestingly enough, Darl McBride and Co. have killed one of the top ten closed-source Unix vendors, strengthened the Linux market, and helped bring about major improvements in how Open Source people document their code contributions. If his goal was destroying Open Source in favor of Closed Source, he achieved pretty much the opposite.

Sun, IBM, HP, and Apple (who all sell Unix on Intel-powered hardware (although HP's Intel hardware of choice is Itanium)) are likely not at all upset that SCO is no longer going to be trying to bill themselves as the premier Intel-compatible Unix. All of these companies of course also sell or have sold Unix on other hardware (Sparc, Power, PA-RISC, Alpha, PowerPC, Motorola 68k to name a few). Sun and IBM are two fairly strong supporters of Linux, too, although they both tout their proprietary Unix platforms as well. HP has business relationships and/or offers support for Red Hat, Oracle, Novell's Suse, Red Flag, Mandriva, and Debian.

SGI used to have IRIX, but they are phasing it out in favor of Linux (but Windows still survives on some SGI lines). SGI, being the class act it is, offers support for existing IRIX customers until at least 2013 (or the company's long-rumored folding, whichever comes first -- they actually came back from Chapter 11). RHEL and SLES are both available, supported options on Altix. SLES seems to be preferred.

It appears most of the closed-source Unix companies know the value Linux can offer. If they're not moving from closed-source solutions to Linux, then they're making it clear that Linux is an option. It's interesting that many of the companies willing to go in big for Linux sell something besides operating systems. Hardware, databases, visualization software, and directory software seem like good compliments to an OS, and vendors selling those items are just who is embracing Linux. Even Apple, who hasn't done much to embrace Linux, isn't adversarial to it. Parallels (third-party, of course) and Boot Camp (Apple) both can give access to any of the x86 or x86-64 Linux distros on the newer Macs, while PowerPC Macs dual-boot with Linux just fine.

...no...(I don't remember)

Futuretech was one of my favourite SGI sites, and it has this on Onyx2 RealityMonster

Also found this which says each pipe is 8.3M pixels. So 16 x 8.3M = only 132.8 M pixels. I believe the limit is per pipe, since the DG basically split up the output of the RMs for each display.

However, I'll bet there were some machines with more than 16 pipes out there....probably secret or something, but I bet they're there somewhere.

They don't seem to quote polygons per second; I'd guess because it's somewhat meaningless, though it could also be because they were so much slower than the competition (ie PC cards) on that metric - that is if you don't bother to figure out what 'a polygon' actually means.

Hmmm so let me get this straight, you can make an incorrect statement "the temperature on Earth has been rising for over a century" and demand Mars data to correlate to that. When I show your initial premise was wrong you ignore that and still demand mars data

I must say... NICE!

But here I will do some of your dirty work for you: Before you use dust storms as an excuse consider that weather is driven by the sun on earth and though the makeup of the martian atmosphere differers the same hold true there.

http://www-k12.atmos.washington.edu/k12/resources/ mars_data-information/data.html
http://mars.sgi.com/ops/asimet.html

SGI Volumizer did this like 10 years ago...

http://www.sgi.com/products/software/volumizer/

XFS has at least been partly ported to most operating systems in SGI's CXFS. I have serious doubts that a complete port will ever see the light of day since a fair amount of work would be required to complete the ports, and I can't imagine a business plan to do this that would suit SGI.

SGIs Standard Template Library is always memorable to me as being written in a concise, pragmatic and elegant way. It's the sort of code that is self-explanatory, requiring very little comments. Sorry it's not a larger project, but it left quite an impression on me when I first went through it all those years ago.

perhaps she was running one of these ?
http://www.sgi.com/products/servers/altix/xe/

You don't have the faintest idea what you're talking about. Ever hear of the "AMD Opteron"? Hmm? You know the processor that's in, oh, the SGI Altix ?

Megatexturing is ID's newest rendering thingy. Actually Megatexuring looks to be identical to SGI's cliptexture technique ( http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc .cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/P erf_PG/sgi_html/ch15.html ). Anyhoo, cliptexturing doesn't use repeating textures throughout a level, it arranges the textures on the disc so that they can be streamed in to memory as needed. This gives you worlds where you don't have to repeat textures/objects as often and makes everything more dynamic. The 360 or PS3 will be using at least 300MB or RAM for textures, so it's easy to see how this will eat up drive space. Both consoles natively use compressed textures so you can't save much drive space by trying to compress the textures on the disc further. It looks like cliptexturing really only works well for landscapes, but that is still a large chunk of the textures. Games using cliptexturing are due out for all consoles and Mac/Win sometime in 2008.

Stop trolling, and though I shouldn't feed.. I will.

Where reliability isn't just important, it's critical. Where scalability isn't just important, it's critical. Where maintainability is valued over a hacker's OS because there aren't a bunch of free grad students to do all the damn work.

Hmm reliability, scalability, and critical workloads like perhaps with supercomputers? You'll note how Linux totally dominates this list with over 70% of all supercomputers. Where's Solaris.. oh that's right 1%. Also latest surveys have shown the majority of code commits to the Linux kernel as coming from major corporations like Novell, Red Hat, IBM. I will also say that you can't judge the code quality by the company behind it. I'd probably take most Hacker code over something written by some corporate drone who isn't passionate (as a hacker IS) any day. Grad Students want good code for thesis ;). Corporate employees want acceptable code to get through that 9 - 5.

Show me a Linux kernel that can handle multi-threaded apps running on 144 CPUs and using a terabyte of virtual memory.

What about this? 4096 Itanium2 Processors (64 Bit), 17TB of Ram. This system is multi-partitioned though, so it isn't all one kernel. However, they are using SUSE's Enterprise Server 9 bundled kernel which supports up to 512 Processors. So even there it's beaten your criteria for criticism.

Solaris has been fully 64-bit compliant for over a decade.

Linux has been 64bit for at least 7 years with Itanium and I'm assuming it has been 64 bit for over a decade with MIPS and Alpha architecture support. The majority of development was on i386 arch, however. I'm assuming this is now changing to x86_64 arch (like the majority of the world is running).

This article

http://www.sgi.com/company_info/newsroom/press_rel eases/2006/november/geoeye.html

quotes 16 inches/ 41cm. Last year. It seems VERY likely that 41cm is not as good as it gets. Even 10cm seems easily feasible. 4.1cm does not seem Tinfoil hat time. Even if they aren't there yet,without question they will be - the advantages are just too great.

http://www.sgi.com/fun/freeware/3d_navigator.html

Slow as hell, and not nearly as cool as I thought it'd be though. :(

I found the static analyser in SGI's Prodev Workshop to be quite excellent, though that was a while ago and I am comparing it with nothing - I'm not sure how it stacks up against more recent offerings :

http://www.sgi.com/products/software/irix/tools/pr odev.html#B

Looks like it's IRIX only though, so YMMV, to put it mildly.

They're more or less the same - although features usually arrive in Direct3D first, then they are introduced later into OpenGL as custom extensions. These are documented in SGI's registry.

Usually each extension will appear as a vendor specific extension GL_NV_xxxx, GL_ATI_xxxx, then become introduced as a standard extension GL_ARB_xxxx.