Slashdot Mirror

Bollocks. This has been around for years. It looks like one vendor, Chilisoft, has been snapped up by Sun.

Here is why Intel is going in this direction now.

http://www.sun.com/processors/UltraSPARC-T1/index. xml

disclaimer: I work for Sun.

Please, stop. You're outdoing yourself.

Have you tried to keep 20 or 30 enterprise RedHat servers in sync for patches? Especially if you can't patch them all at the same time?

Cfengine seems to handle mine just fine. My 150 debian servers also do quite well. If I stick to the standards, I never touch configs after the first time. Ever. My 35 Solaris boxes are a different matter. Single user mode. All the fucking time. Like we have time to waste for that bullshit. RH or debian at most need a reboot post-update. Some load balancing in place allows me to reboot them at my whim.

You don't think that every other OS replaces patches or backs them out once a better one comes along?

By no means is it my intention to imply Solaris is the only turd around, even Debian messes up sometimes. (Which is why CFengine deploys to lab first). A simple perusing at sunsolve yield mountains of articles detailing if/and/else situations for a clusterfuck of patches for any given particular combination of OS, OS minor, Patch level (which is very finely detailed, but the fact that I need to give a flying fuck about exactly all the patches on any box increases overhead, substantially. i.e. SUNW_INCOMPAT), hardware installed (i.e. $foo scsi controller), hardware installed revision (i.e. $foo 1.2 firmware scsi controller), major hardware (i.e. v210), minor hardware (i.e. v210 vs 15k). Guess what? Debian is "apt-get update;apt-get upgrade", and even if I was stupid enough to run sendmail, it would gracefully handle configs.

I've never seen a whitepaper suggesting not patching and throwing behind a firewall


Therefore, beyond ensuring that critical issues are addressed, Sun believes that
you should apply patches only to address specific issues or needs. You should not
apply patches merely to keep current. There is no benefit to applying the latest
revisions of patches without understanding whether those patches provide any
value.


src: http://docs.sun.com/app/docs/doc/817-0574/

Great. So now I should only apply *critical* updates, no moderate or low severity updates like say local exploits, etc?

T1 has crypto acceleration Indeed. Only if:

A. You like grabbing your ankles at Sun's whim on whether they're going to support the libraries/apis on the OS you choose to run.
B. You like your calculations done behind the scenes, where not only do know whats going on in terms of math, you have no control. (hic sunt dragones)

I'm surprised nobody mentioned Sun Studio 12, which just came out recently. This time, the Linux release comes (for the first time) with its own compilers, instead of relying on gcc. It'll be interesting to see how they compare to Intel's, specially on AMD chips...

In other words, you cannot fathom the distinctions posed, and therefor assume that someone is *too stupid* to communicate with.

I'll wait while you work on your education and intelligence quotient. Once your IQ has risen to an even playing field we can continue.

Yes, it actually was making Solaris more like linux, than linux - if you go BACK in time, you'll find where that statement was actually made.

Actually, here...I've done the homework for you. http://www.sun.com/software/solaris/ning.jsp/

And, no, making something more Linux-like, does not equate to making something more like Linux, depending on the context of the term "Linux".

According to some, Linux is not just a kernel, but an ideal.

To make something in accordance with an ideal, does not make something more like a kernel.

However, to go even further... Their meaning behind that phrase is to make Solaris more *familiar* to Linux users. It doesn't necessarily mean, they want to go away from what Solaris is, nor should they.

http://www.zdnet.com.au/news/software/soa/-Sun-hop es-for-Linux-like-Solaris/0,130061733,339276057,00 .htm/

They just want to make some changes so that those familiar with Linux can adjust to Solaris without the huge culture shock that Linux is to those familiar with AIX/HP-UX and yes, even older Solaris versions.

Sometime's Martin, it's better to remain quiet. Try and remember that.

Project Black Box. Just drop it off in the parking lot and plug it in.

http://www.sun.com/emrkt/blackbox/index.jsp

-m

They could also just have bought a couple of Sun Black Box datacenters in a truck container.

*i am laughing at you*

http://java.sun.com/javame/reference/apis.jsp
http://www.microsoft.com/downloads/details.aspx?fa milyid=83A52AF2-F524-4EC5-9155-717CBE5D25ED&displa ylang=en
http://www.access-company.com/developers/downloads /palmostools.html

You say a couple small apps you wrote, so you must be familiar with an SDK. Where have you seen that code you write on one SDK won't work in ANOTHER COUNTRY! Where did you the the PalmOS and Windows Mobile and J2ME came from?

HFS+ may date only from System 8.1, but HFS is considerably older - nearly 22 years now. It's very mature and stable code, even the POSIX stuff they bolted on later for HFS+.

Well, we can wait a bit longer for ZFS. If you can't wait, grab a Solaris 10, Solaris Express, or OpenSolaris distribution and start playing today! I'm not comfortable committing precious data to anything else.

One day most of our day-to-day filesystems will incorporate the ideas in ZFS - one or two have been seen before, but never in such a devastating ensemble. The 'Z' may as well stand for 'Zen': Grokking why ZFS is revolutionary seems to be a Zen-like enlightenment :) Many people still wonder "huh? what's the fuss?", as happens with any generational change...

HFS+ may date only from System 8.1, but HFS is considerably older - nearly 22 years now. It's very mature and stable code, even the POSIX stuff they bolted on later for HFS+.

Well, we can wait a bit longer for ZFS. If you can't wait, grab a Solaris 10, Solaris Express, or OpenSolaris distribution and start playing today! I'm not comfortable committing precious data to anything else.

One day most of our day-to-day filesystems will incorporate the ideas in ZFS - one or two have been seen before, but never in such a devastating ensemble. The 'Z' may as well stand for 'Zen': Grokking why ZFS is revolutionary seems to be a Zen-like enlightenment :) Many people still wonder "huh? what's the fuss?", as happens with any generational change...

HFS+ may date only from System 8.1, but HFS is considerably older - nearly 22 years now. It's very mature and stable code, even the POSIX stuff they bolted on later for HFS+.

Well, we can wait a bit longer for ZFS. If you can't wait, grab a Solaris 10, Solaris Express, or OpenSolaris distribution and start playing today! I'm not comfortable committing precious data to anything else.

One day most of our day-to-day filesystems will incorporate the ideas in ZFS - one or two have been seen before, but never in such a devastating ensemble. The 'Z' may as well stand for 'Zen': Grokking why ZFS is revolutionary seems to be a Zen-like enlightenment :) Many people still wonder "huh? what's the fuss?", as happens with any generational change...

The best reference would be the official Solaris Hardware Compatibility List (HCL). But here is a piece of advice: the whole family of nVidia nForce chipsets is generally well supported by Solaris: any motherboard based on the nForce 4, nForce 500 (and maybe nForce 600) chipset should work flawlessly with Solaris, that includes probably more than half of the market of entry-level and mid-range motherboards. In my case I wanted a cheap, low-power, GbE-enabled fileserver capable of serving files over NFS at a throughput of 70-80% of the bandwidth of a GbE link. So I bought the most inexpensive nForce 4 mobo I found on newegg, with on-board GbE (even entry-level GbE controllers are easily capable of saturating a GbE link nowadays), and with a socket 754 (so I could use it with a low-power 25W Turion processor).

Regarding the SATA controller to use, I would recommend you either the Marvell 88SXxxxx family (such as the 88SX6081: 8-port, PCI-X, about $100), or the Silicon Image 3124 (4 ports, PCI-X, about $60), or an AHCI compatible controller (such as the built-in SATA controller found in modern Intel chipsets: ICH6, ICH7, etc, but you will need to use recent OpenSolaris builds: "Nevada B56" and up). Solaris supports SATA hotplug for these 3 families of SATA controllers.

I kept the list of what I bought 3 months ago:

If you buy this today, prices would be even lower ! I would feel jealous of you having a setup cheaper than mine :-)

Sun site doc on nis+ EOL

If sun is done with it, don't expect it to stick around long in commercial os's. Linux support could stick around longer, but again, if nobody else is using it, why should Linux?

http://blogs.sun.com/jonathan/entry/censoring_free _media_or_fighting

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =6402758

http://www.uwsg.iu.edu/hypermail/linux/net/0205.3/ 0002.html

http://lists.ntp.isc.org/pipermail/questions/2007- April/013854.html

etc...

The problem often is in the OS itself, but sometimes the applications and drivers are the problem. So why is this news? Well, judge by yourself.

I read the license agreement for Java 6u1. I noticed it referenced a file called THIRDPARTYLICENSEREADME.txt. So I read that. All 176 KB of it. Some of those licenses referenced yet more licenses, not all of which were included in the third party license file (and those that were included were included by coincidence, it seems). I've hunted down most of those but at least one may not exist in any place that I could find it anymore. A couple interesting notes from this experience:

1) The file is not formatted to be human readable. It seems that Sun doesn't care about it as anything more than a legal necessity.

2) Preceding each program in that file is the statement "The following software may be included in this product: [Some Software's Name] Use of any of this software is governed by the terms of the license below:" Sun says these things may be included. They don't seem to put enough effort into maintaining it to even be able to say that certain programs are not included.

3) I am not a lawyer, but from my understanding, as I was reading it, I recalled realizing that Sun fails to abide by the letter of some of those EULAs. For example, it is not obvious where I can obtain source code for any of the programs that the distributor is required to make it available for. I believe that there are other problems as well.

4) As I noted above I searched the internet for licenses referenced by the third party license agreements. In omitting those fourth party license agreements Sun, it seems to me, has effectively stolen certain software.

5) (The point that makes this post a relevant response to Parent) There are three W3C licenses that I've found in this process. They all require affirmation that the user has read, understood and will comply with their licenses prior to even obtaining the licensed material. As far as EULAs for free software go, this one certainly requires that it is read. At least one of these licenses is GNU GPL compatible, too, so it is, in fact, a free software license.

So as a Java coder who believes that, before God, he should obey the restrictions that the owners of software put on their property I find these things, especially point number five (since I used Java before I read those licenses) to be troubling.

It seems that they have some built-in redundancy:

http://www.sun.com/emrkt/campaign_docs/expertexcha nge/knowledge/solaris_zfs_perf.html#28

I have not tried this myself (though I suppose it'd be a cool experiment using VMware) but I'm guessing that ultimately you'd probably be SOL for the stuff on the disk, though as I understand it the pool would still be up and running, with some directories and files unavailable.

zfs has been bootable on x86 Solaris using grub for over a month now zfs boot

He's already taken it back, more or less:

"I don't know Apple's product plans for Leopard so it certainly wouldn't be appropriate for me to confirm anything. [...] There certainly have been plenty of published reports from various sources that ZFS is in Leopard, I guess we will all have to wait until it is released to see if ZFS made it as the default, or if they simply announce that it will become the default in a future release."

It seems that the two companies are in the arm race as far as multicore developer tools are concerned. Sun released Sun Studio 12 yesterday and the buzz around release seems to be very similar. It also seem that Sun Studio 12 is a nicer integrated package overall with not just the compilers but a bunch of tools and a pretty convincing IDE.

Why would applications on an Apple-phone accessing the internet via tcp-ip sockets be more harmful than all the existing phones that enable just that?
On my sony-ericsson W810 I've installed things like a webbrowser, a Google-earth-like app, a ssh/telnet-client, a gps-map software, a ICQ/MSN/etc-IM app, all of which access the internet via tcp-ip, none of which has ever brought down the mobile network.

I can see how they'd be nervous about letting 3:rd party software talk directly to the mobile network, but tcp-ip access for 3:rd party software is already common stuff in mainstream, middle-end mobiles via J2ME MIDP 2.0.

I don't think it's fair to suggest that resistance to Solaris is just a matter of prejudice. It's more a matter of not being able to find the tools you need. Linux folk often try Solaris, but quickly give up on it because the administrative tools they're familiar with aren't there, and they don't feel like starting over from scratch.

You might call that laziness, but it's deeper than that. As an example let me cite my own experience with implementing a TWiki for my group. I was given an old Sun V20z to run it on, which already had Solaris 10 installed. I tried very hard to get the TWiki running under Solaris. The TWiki itself wasn't that hard (and there's a lot of helpful Solaris info on twiki.org) but I was utterly defeated when I tried to install all the various TWiki plugins I needed.

The problem is that TWiki plugins are written in Perl, and mostly require that you install additional Perl modules. Now Perl itself runs very nicely on Solaris, but it's pretty obvious that few Perl module developers bother to test their work on Solaris. That seems to include the CPAN module (which provides a shell that most Perl developers use to download and install new modules), so you end up downloading the modules by hand. Fortunately, Perl modules always have neat little install scripts...

Oops! A lot of install scripts don't work on Solaris either. OK, installation is not rocket science, you just have to make sure the module files are in the include path. Easy enough, though the results are disturbingly messy. Oh well, as long as it work. Just need to Make a few more modules...

Oops! Here's a module that uses a library written in C. And the library has to compile on a particular C compiler. Solaris has that compiler, but the Solaris version doesn't have all the features the library needs to compile! That's where I gave up.

So I wiped the Solaris partition (feeling a bit like a murderer) and installed Fedora 6. Now, I'm not happy about the rough edges I saw (unforgivable in a distro that's been under development for 13 years!) but I can't complain about the sheer simplicity of installing Perl modules and TWiki plugins on that platform. You give the CPAN shell a list of Perl modules you need, give it permission to also download and install dependencies, and sit back. Then you download the TWiki plugins and run their installers -- some of which use the CPAN shell to install the Perl modules you forgot. Simple and easy.

So, until ZFS is available "in the box" for Linux, it's just not an option for a lot of Linux people. That's not prejudice, that's practically.

Don't bother with dedicated RAID hardware controllers. I've seen the Linux md disk driver mentioned, and while a viable option, the better option IMO is Solaris x86 using ZFS. Basically you've got an industrial-strength piece of storage software ripe with features begging to be used in this situation....for free.

If you're interested in an industrial strength hardware platform to go with the software, go for one of these.

If you're interested in rolling your own, then simply put together an x86 box with as many SATA controllers and buses you can stuff in a box and set the disk up as JBOD (just make sure the hardware is Solaris x86 compatible of course). Create some ZFS pools of whatever RAID suits your need, and sit back and enjoy data glory.

Oh, and simply pick a protocol of your choosing to serve up the data to your clients...iSCSI, SMB, NFS, whatever.

While you're there, check out how http://en.wikipedia.org/wiki/ZFS can make most of the issues other posters are point out irrelevant, or at least nothing to be worried about.

While Solaris might be a dirty word among the Slashdot crowd, if all the OP needs is a way to store a bunch of files, ZFS is an excellent solution. Check out http://www.opensolaris.org/os/community/zfs/whatis / and in particular the demos linked on the left side.

Then, if you're still not convinced how appropriate ZFS might be for a somewhat clueless user, read about how it can save your ass from flaky hardware and data corruption: http://blogs.sun.com/elowe/entry/zfs_saves_the_day _ta

You may be confusing it with the Community Edition, which is the bleeding-edge unsupported version.

As of June last year, when Eric Shrock added this entry to his blog: ZFS Hot Spares

Hold on. You have just made several obvious errors.

First of all, who said frameworks are designed to "overcome shortcomings"? They're designed to increase productivity. They get most of the plumbing out of the way so you can get started on the interesting parts. Your precious Microsoft .Net IS A FRAMEWORK that exists for this exact reason. Java's frameworks aren't dumbed down for you; Microsoft's are. Java is harder; we get paid more. This is by design.

Second, All a Javabean is is a class that follows certain conventions, including providing get and set methods (PROPERTIES). You can put those in any class you want. Why do you think Java doesn't have them? Maybe you didn't know how to use them.

And how could you miss the fact that Java DOES have iterators:
http://java.sun.com/j2se/1.4.2/docs/api/java/util/ Iterator.html

And what's up with your nutty point about events and AddActionListener??? Google "AddActionListener" sometime and READ IT, by the way -- all it does is give you an easy way to set up a method that handles an event (the SAME THING you do in C# when you create an event handling function, they just call it something else).

I'm not going to go through your laundry list of syntactic sugar, but I will say it's mostly unnecessary. If it turns you on, good for you, but don't preach about it making C# better than Java, because that's a bogus argument. Java has many things that C# does NOT have, which in my view are a bit more significant, like the ability to run (patent UNENCUMBERED) on Linux, the ability to run on Mac OS/X, the fact that it's GPL now, so no company can force its will on the community...

I understand that C# is your new girlfriend and if you don't talk bad about your old girlfriend you won't feel like you're giving the new girl 100%, but please, at least bring up valid points.

One answer, directly from Sun (a non-trivial ZFS subset is already GPL2):

http://blogs.sun.com/darren/entry/zfs_under_gplv2_ already_exists

Another answer direct from the May 14, 2007 blog of Sun CTO Greg Papadopolous:
_____

"We will *never* (yes, I said *never*) sue anyone who uses our ZFS codebase and follows the terms of the license: they publish their improvements, propagate the license, and not sue anyone else who uses the ZFS codebase. And look at the innovation not only with ZFS in OpenSolaris, but its adoption by Mac OS X and BSD.

But under what conditions would we enforce our patents? How would we feel if someone did a cleanroom version of ZFS and kept the resulting code proprietary?

We wouldn't feel good, to be sure. But I'd put the burden back on us (certainly as a large company) that if such a thing were to happen it was because we were failing to *continue to* innovate around our original code. Being sanguine about patent protection as an exclusive right would result in less innovation, not more."
_____

GPL3 will make this all moot, whereby Stallman's GNU/Linux will merge with Solaris
which will disintermediate the Linus GPL2 version, left behind as the
Unix clone it was originally intended to be. Ultimately, a "me too" Unix
such will have little reason to exist, when one can get the real thing
under the new laws of free software, courtesy BSD/GPL3, and Sun's patent peace.

Backups? add a small autoloader (like http://www.sun.com/storagetek/tape_storage/tape_li braries/c2/) + software like bacula. Relying on raid disks alone is stupid.
Multipathing? You want multiple links to your storage especially if you're using cheap unreliable off-the-shelf parts
Scalability? How do you grow this contraption once your greedy users start sucking up every byte you have. And yes, they will.

OK:

• ZFS w/flaky hardware (scary): http://blogs.sun.com/elowe/entry/zfs_saves_the_day _ta

• Self Healing with ZFS: http://www.opensolaris.org/os/community/zfs/demos/ selfheal/

• 100 Mirrored Filesystems in 5 minutes: http://www.opensolaris.org/os/community/zfs/demos/ basics/

A good video (in Real(tm) format) describing how ZFS is contructed and works is available from Sun's web site:

http://www.sun.com/software/solaris/zfs_learning_c enter.jsp

The slides that Bill Moore is showing are also available online:

http://www.sun.com/software/solaris/zfs_lc_preso.p df

A good video (in Real(tm) format) describing how ZFS is contructed and works is available from Sun's web site:

http://www.sun.com/software/solaris/zfs_learning_c enter.jsp

The slides that Bill Moore is showing are also available online:

http://www.sun.com/software/solaris/zfs_lc_preso.p df

It's generally not about the 64- vs 128- vs whatever.

It's about the additional reliability (current bugs aside), and the ease of filesystem/pool management. For example, a Sun developer was developing on a workstation with bad hardware, which occasionally caused incorrect data to be written to disk. After setting up raidz, ZFS automatically detected and corrected the error: http://blogs.sun.com/elowe/entry/zfs_saves_the_day _ta

Scary, yes. Doing that definitely isn't something I'd recommend, but it does show one of the powerful features of ZFS.

http://www.sun.com/storagetek/disk_systems/data_ce nter/9990/

Artima
eWeek
InfoQ
Java home
JavaLobby
JavaWorld
JDJ
The Inquirer
The Register
TheServerSide

You're thinking of how to speed up programs by using parallel execution units. This is closely related, but not exactly the same thing, as the use of concurrent programming techniques to write better organized programs capable of responding flexibly to events from multiple sources while also performing their own "background" computations. Think of a UI program that must simultaneously react to user interaction events, while also performing some computation that's mostly independent of user input. A word processor that does grammar checking in the background while the user interacts with the UI in other ways is a prime example.

The thing is that with mainstream languages, writing programs like this is probably much harder than it needs to be, for several reasons:

1. Many threading mechanisms are built with parallelism in mind rather than concurrency, and make it too expensive to spawn a gazillion concurrent threads to handle each independent thing in your app.
2. Your typical mainstream language of today is an imperative language with threading and shared memory synchronization primitives bolted in. This means that perfectly innocent-looking code often has suprising and confusing behavior when executed concurrently, because the language's bolted-in concurrency exposes low-level details of the hardware like the interaction of cache and main memory. Shared mutable memory between parallel execution units is a hard thing to wrap your head around.
3. The same hard stuff that makes some of your innocent-looking behave in a crassly incorrect way is, in fact, the stuff that you need to exploit for thread synchronization.

Here's one way of solving this problem: (a) lightweight threading mechanisms for concurrency (in addition to the heavyweight ones for parallelism), (b) no shared mutable memory between threads (any shared memory must be immutable), and (c) simpler thread synchronization primitives that do not rely on shared mutable memory, like communication channels between threads.

Ok so Java and Lina aren't multiplatform... o.O

Someone better tell Sun. http://www.sun.com/service/javamultiplatform/index .xml

I suppose the Lina or Java app itself might not be considered multiplatform, but the whole stack is. So its a silly distinction.

VLC recently switched to Qt from "WxWidgets". The last time I played around with it to develop it wasn't much good. Just went to its website right now, on Linux it seems to have decided that Gtk1 is the popular look. Being a KDE guy this is obviously a pretty big turn off. Qt, on the otherhand, has themes to make it blend into Gtk apps and actually has a glib event loop inside it so that you can embed Gtk widgets into Qt. And of course it looks good in KDE. :)

Has anyone played with SAMP (Solaris, Apache 2, MySQL 5, and PHP 5) for Solaris 10 or Solaris Express? http://www.sun.com/bigadmin/features/articles/samp _setup.html

# Lack of support for UNIX-domain sockets
# Lack of support for SysV semaphores
# Lack of support for SysV shared memory
# Lack of support for UNIX signals (other than SIGTERM)
# Lack of any serious UNIX-style job control
# Lack of any interface to map files into memory
# Lack of any API to make system calls
# In fact, the Java implementation suffers from a general lack of support for almost all of the standard UNIX IPC mechanisms, save INET sockets. How lame is that?

Ok. I can write device drivers in Java. I will just need a virtual VM which supports Java device drivers ... something like Squawk http://research.sun.com/projects/dashboard.php?id= 155/

I think they're confused, anyway -- they're writers, not programmers. I bet I can even guess how they did their research: they called up all the recruiters they could find and asked each one to list the languages he/she thought were dead or dying. Then they compared notes on all the responses they got, and built their final list.

I think the list should be called "top 10 languages recruiters don't want to hear about" because that would be more accurate.

Realistically, as far as C goes I think the following factors should be considered before declaring it a dead language:

1. Most of the more popular object oriented languages (Java, C#, C++) use C syntax. C++ is a superset of C.

2. Java can use compiled C modules as an analog to C's old "escape to assembler" technique. In other words, you can call C code from Java when you have something you want to get "close to the metal" on. Thus, a "Java Programmer" may very well ALSO be a C programmer, even if technically that isn't on his resume or job description. I can do this; I imagine most other Java programmers can as well. What's funny is that, once you're calling C code, you can turn around and use the C code to call assembler, Fortran, or whatever else you like! What a weird world this is!

(Links for the skeptical):
http://www.csharp.com/javacfort.html (Ironic that it's on a CSharp site, no?)
http://www.mactech.com/articles/mactech/Vol.13/13. 09/CallingCCodefromJava/index.html
http://java.sun.com/developer/onlineTraining/Progr amming/JDCBook/jniexamp.html

3. Linux is still written in C, I believe. As are its drivers, KDE-related programs, Gnome-related programs, and whatnot.

4. C is the modern version of assembler, isn't it?

ANYway, I don't think C's going anywhere. You might not be able to get PAID for doing it, as your main speciality will probably be something more buzzword-heavy, but you'll probably be doing some of it as a part of whatever other weird and mysterious things you do in the ITU.

Poor journalists... One suspects they're rather easily confused these days.

This post was written on a home built AMD OpenSolaris workstation. No I will not ever go back to MS.

http://blogs.sun.com/jonathan/entry/what_we_did
This gives an interesting insight into Sun's thinking on Microsoft's threats.

That's not "High Productivity Computing" Wire... the HPC in "HPC Wire" stands for High-Performance Computing.

The real story on the ~15PB/year data store is to be found in these two sites:

This outlines the hardware environment supporting the data (IBM 3584 w/ Ultrium and IBM DS4400):
ftp://ftp.software.ibm.com/common/ssi/rep_sp/n/GRC 03001USEN/GRC03001USEN.PDF

This outlines the software environment (layered Tivoli Storage Manager and dCache):
http://www.dcache.org/manuals/tsm-symposium-2005-p aper.pdf

Or is it?
Here, Sun posts how Storagetek supplied the tape storage:
http://www.sun.com/customers/storage/cern.xml

The LCG
Something could certainly be said about their computing backend of going through this data. It's called the LHC LCG (Large Hadron Collider Large Computing Grid) and is described here:
http://lcg.web.cern.ch/LCG/tdr/LCG_TDR_v1_04.pdf