Slashdot Mirror

Czech Republic

ftp://mandrake.redbox.cz/ Mandrake/iso/
France

ftp://fr2.rpmfind.net/ linux/Mandrake/iso/ (Lyon)

ftp://ftp.ciril.fr/pub/linux/mandrake/iso/ (Nancy)
Germany

ftp:// ftp-stud.fht-esslingen.de/pub/Mirrors/Mandrake/iso / (Esslingen)
Iceland

ftp://ftp.mbl.is/pub/mandrake/ iso/ (Reykjavik)
Italy

ftp://bo.mirror. garr.it/mirrors/Mandrake/iso/ (Bologna)

http://bo.mirror. garr.it/mirrors/Mandrake/iso/ (Bologna)
Slovakia

ftp://hq. alert.sk/pub/linux/distributions/mandrake/iso/

ftp://spirit. profinet.sk/mirrors/Mandrake/iso/ (Bratislava)
Taiwan

ftp://mdk.linux.org.tw/ pub/mandrake/iso/
United States

ftp://distro.ibiblio.org/pub/Linux/distributions/m andrake/Mandrake/iso/ (North Carolina)

ftp://ftp-linux.cc.gatech.edu/pub/linux/distributi ons/mandrake/iso/ (Georgia)

ftp://ftp.math. utah.edu/pub/linux/Mandrake/iso/ (Utah)

ftp://mirror.mcs.anl. gov/pub/Mandrake/iso/ (Illinois)

...and somebody (I suppose you know who you are) modded it "Offtopic". Given that the topic was the interaction between the earth's temp. and rotation, and that the effect 1010011010 pointed out is

much more pronounced than the one mentioned in the article (though of course not as dramatic as 1010011010 makes it sound)

much more likely than the one mentioned in the article

much more interesting than the one mentioned in the article

much more established than the one mentioned in the article

...it is hard to see how you could consider it "Offtopic". For that matter, the strength of the data for pole reversals causing major climate shifts is about as strong (or I should say, as weak) as the data for global warming (whether caused by humans or an unrelated trend in the global climate).

-- MarkusQ

P.S. There was a very interesting comparison floating around a few years back (it was cited against me in an argument about my shorting idiodic dot com stocks) between the global warming data and the exponential growth of the internet economy. I replied that I agreed, and that I thought both "trends" were drawing conclussions far in excess of the data.

Boy, did I get flamed.

If anybody has the article I'd love to have a link/copy.

you are only right on this:

they add their own tech too, which is why they get different results.

quote

Now, the Athlon processor is made by a rival company, AMD. They have
basically reverse engineered the Intel processors and tried to make a
processor that operates just like Intel's processors, and then sell them
cheaper than Intel does.

This makes it a little more difficult to compare them to the Pentium
processors. Some things the AMD Athlon actually does faster than a Pentium
III, some things it does a little slower, and some things it can't do at
all, while other things the Intel can't do, the Athlon does do.

quote

Had AMD had a design ready when Intel released their Pentium, their market share
wouldn't have dropped to 10%. In the days of the 286, 386, and 486, AMD, Cyrix, and other "clones"
reverse-engineered the Intel chips. In a sense, it was Intel's design (with maybe a few improvments),
but it was reverse-engineered so it did not violate patents.

quote

But nothing lasts forever. The companies that had built Intel chips under license eventually reverse-engineered the chips and built them license-free. Intel copycats including Advanced Micro Devices (AMD) and Cyrix (a division of National Semiconductor) used the courts to validate their right to copy Intel's chip architectures. And PC manufacturers like Compaq and IBM used these clone chips as a weapon to force Intel prices down. Now the best way for Intel to stay ahead is to simply run faster. Running faster means shrinking product cycles from three years to 18 months by running parallel product development teams and spending more money faster than the other guys. Since Intel has more money to spend, this keeps them in command, but shorter product cycles mean less time to recoup R&D expenses. Hence, those lower margins.

someone better mod me up for all my work

• NIST Center for Neutron Research
• Los Alamos Neutron Science Center, Los Alamos
• High Flux Isotope Reactor, Oak Ridge National Lab
• Advanced Photon Source, Argonne National Lab
• Advanced Light Source, Lawrence Berkley Lab

I've found this one to be more than sufficient. Runs on Java.

http://www.iit.edu/~gawojar/ldap
http://www.mcs.anl.gov/~gawor/ldap

Mike

If you can't find LDAP tools, you havn't been looking hard enough. Here (http://www.dbaseiv.net/code/cpu.phtml) is a tool for doing unix style user management with an LDAP directory. Here (http://www-unix-mcs.anl.gov/~gawor/ldap/index.htm l) is a fully functional, really awesome ldap browser that I have used extensively. These are just a tiny sample of all the software for directly working with an LDAP directory. Check the OpenLDAP and IETF lists for more tools, OpenLDAP comes with quite a few as well.
If you have paid careful attention, you will notice that LDAP support has crept into hundreds and hundreds (of not thousands) of applications over the last year. The API's for doing LDAP programming yourself are also extremely well developed imho. You have options for C, PERL, C++, Python and a slew of other programming languages. Search Freshmeat or Sourceforge for LDAP and see what you come up with, I think you'll be surprised.
I don't think LDAP is dead, I think it's one of those protocols like TCP that just sneaks up on you with it's usefulness :)

I'm an engineer who programmed for many years in Fortran, was interested in OO languages, but always reverted to Fortran for real work. My first real OO code was a library to do Automatic Differentiation for uncertainty analysis. This has been done very successfully in Fortran 77 (ADIFOR for example), but the result is essential a preprocessor that reads a Fortran code and outputs new code Fortran code with extra statements for calculating derivatives. In an OO language that supports operator overloading, such as C++ or Python (not Java), no preprocessing step is needed, you just redefine math operations and functions to include the calculation of derivatives. In all, a much cleaner, easier and more elegant solution. Functions and operators for matrices and even more complicated data structures are relatively easy to develop and can really simplify programs that are written to solve engineering problems.

Since this first effort at using an OO language I have since given up on Fortran to write engineering code. I mostly use Python (which has a very good numerics library) and occasionally use C or C++ when extra speed is needed. I really hate going back to Fortran because it now seems so restricting. I personally would recommend looking at Python as very nice OO language for engineering calculations.

Perhaps this might be of some use?

I work in grid computing and we have some needs that push this idea forward. Over at Argonne labs the Globus team has put forward this draft of extensions for some of what you talk about (i.e. it's secure and multi-path). Code exists under yet another open source license the "Globus Toolkit Public License".

I work in grid computing and we have some needs that push this idea forward. Over at Argonne labs the Globus team has put forward this draft of extensions for some of what you talk about (i.e. it's secure and multi-path). Code exists under yet another open source license the "Globus Toolkit Public License".

There are some saprophytic, true (ie non-fungal) plants that don't rely on photosynthesis (and therefore light) to grow. It seems that GM technology could be used to modify existing food plants to grow without light, recycling the 'compost' created by the passengers into food. The same could be done with fungi without any GM, but I expect it result in a rather boring (and probably nutritionally poor) diet if this was their only food supply (wasn't there a some SciFi movie where they lived off mushrooms?).

A drawback is that the other major product of photosynthesis is the breaking down of CO2 to free up oxygen for the crew to breath. But current spacecraft and stations instead rely on CO2 'scrubbers' (ala Apollo 13 & duct tape fame) to do this. So for deep space exploration, where light is either not available, or requires too much energy, I think GM'd saprophytic plants would be a good alternative.

NCSA is certainly an important part of this partnership, but they're neither the only part nor the lead site.

Introduction to Building Projection-based Tiled Display Systems

Nice pictures inside, but of course it can't compare to actually seeing a massive OpenGL fractal bouncing around a huge crisp display...

Introduction to Building Projection-based Tiled Display Systems

Nice pictures inside, but of course it can't compare to actually seeing a massive OpenGL fractal bouncing around a huge crisp display...

If the Americans would suck it up and learn to use their amazingly fast IBMs we would hear whining from the other side of both ponds.

Great, what the hell do you think we are doing over at Argonne National Labs? I mean, have you tried to paralellize an atmospheric climate modeler? I don't think so. Coding for a vector-based machine is pretty straight forward. You concentrate on once machine as if it had one processor and one bank of memory, and code away, occasionally noting if your loops are not easily vectorized. The compiler magically does the rest, and your program runs really fast. That's why the Japanese machines are nice.

On the other hand, imagine designing an atmospheric climate modeler on a large cluster. The current paradigm being used and developed is MPI Let's see what you have to worry about. One, since the processors are not sharing memory, messages have to be passed between them to share memory. No biggie. But now consider that the whole atmosphere has to be broken up into pieces of a grid. On the boundaries, grid points must be shared by two or more processors. At each timestep, those points must be synchronized. Code must exist to know the processors that border one another and that know which points to share.

Now what happens if you want to combine different models together, as in the atmosphere, ocean, land, and sea-ice models. This is known as a climate coupler. Well, now you have differing grids for each of the models because they were developed independently. Now your program must handle interpolation of the grid points and must again know which processors border one another so that data is efficiently transfered. Finally, there must be decent load handling so that each processor is doing its fair share of the work.

I'm now working on the climate coupler project here at Argonne. Vector machines are quite easy to program, but we do know that they will lose out to massively parallelized clusters. It's just that the programming is much more difficult, since the messaging is always the bottle neck. Communications development follows a rate similar Moore's Law, but with a longer doubling time. For maximum efficiency, the programmer must handle the messaging model directly.

The modeling group here at Argonne understands the issue, and we are working on a general climate system to run quickly on parallized machines. No you know why you can't just do a simple code rewrite. You need to redesign the whole system.

Accelerated Climate Prediction Initiative.

If the Americans would suck it up and learn to use their amazingly fast IBMs we would hear whining from the other side of both ponds.

Great, what the hell do you think we are doing over at Argonne National Labs? I mean, have you tried to paralellize an atmospheric climate modeler? I don't think so. Coding for a vector-based machine is pretty straight forward. You concentrate on once machine as if it had one processor and one bank of memory, and code away, occasionally noting if your loops are not easily vectorized. The compiler magically does the rest, and your program runs really fast. That's why the Japanese machines are nice.

On the other hand, imagine designing an atmospheric climate modeler on a large cluster. The current paradigm being used and developed is MPI Let's see what you have to worry about. One, since the processors are not sharing memory, messages have to be passed between them to share memory. No biggie. But now consider that the whole atmosphere has to be broken up into pieces of a grid. On the boundaries, grid points must be shared by two or more processors. At each timestep, those points must be synchronized. Code must exist to know the processors that border one another and that know which points to share.

Now what happens if you want to combine different models together, as in the atmosphere, ocean, land, and sea-ice models. This is known as a climate coupler. Well, now you have differing grids for each of the models because they were developed independently. Now your program must handle interpolation of the grid points and must again know which processors border one another so that data is efficiently transfered. Finally, there must be decent load handling so that each processor is doing its fair share of the work.

I'm now working on the climate coupler project here at Argonne. Vector machines are quite easy to program, but we do know that they will lose out to massively parallelized clusters. It's just that the programming is much more difficult, since the messaging is always the bottle neck. Communications development follows a rate similar Moore's Law, but with a longer doubling time. For maximum efficiency, the programmer must handle the messaging model directly.

The modeling group here at Argonne understands the issue, and we are working on a general climate system to run quickly on parallized machines. No you know why you can't just do a simple code rewrite. You need to redesign the whole system.

Accelerated Climate Prediction Initiative.

If the Americans would suck it up and learn to use their amazingly fast IBMs we would hear whining from the other side of both ponds.

Great, what the hell do you think we are doing over at Argonne National Labs? I mean, have you tried to paralellize an atmospheric climate modeler? I don't think so. Coding for a vector-based machine is pretty straight forward. You concentrate on once machine as if it had one processor and one bank of memory, and code away, occasionally noting if your loops are not easily vectorized. The compiler magically does the rest, and your program runs really fast. That's why the Japanese machines are nice.

On the other hand, imagine designing an atmospheric climate modeler on a large cluster. The current paradigm being used and developed is MPI Let's see what you have to worry about. One, since the processors are not sharing memory, messages have to be passed between them to share memory. No biggie. But now consider that the whole atmosphere has to be broken up into pieces of a grid. On the boundaries, grid points must be shared by two or more processors. At each timestep, those points must be synchronized. Code must exist to know the processors that border one another and that know which points to share.

Now what happens if you want to combine different models together, as in the atmosphere, ocean, land, and sea-ice models. This is known as a climate coupler. Well, now you have differing grids for each of the models because they were developed independently. Now your program must handle interpolation of the grid points and must again know which processors border one another so that data is efficiently transfered. Finally, there must be decent load handling so that each processor is doing its fair share of the work.

I'm now working on the climate coupler project here at Argonne. Vector machines are quite easy to program, but we do know that they will lose out to massively parallelized clusters. It's just that the programming is much more difficult, since the messaging is always the bottle neck. Communications development follows a rate similar Moore's Law, but with a longer doubling time. For maximum efficiency, the programmer must handle the messaging model directly.

The modeling group here at Argonne understands the issue, and we are working on a general climate system to run quickly on parallized machines. No you know why you can't just do a simple code rewrite. You need to redesign the whole system.

Accelerated Climate Prediction Initiative.

If the Americans would suck it up and learn to use their amazingly fast IBMs we would hear whining from the other side of both ponds.

Great, what the hell do you think we are doing over at Argonne National Labs? I mean, have you tried to paralellize an atmospheric climate modeler? I don't think so. Coding for a vector-based machine is pretty straight forward. You concentrate on once machine as if it had one processor and one bank of memory, and code away, occasionally noting if your loops are not easily vectorized. The compiler magically does the rest, and your program runs really fast. That's why the Japanese machines are nice.

On the other hand, imagine designing an atmospheric climate modeler on a large cluster. The current paradigm being used and developed is MPI Let's see what you have to worry about. One, since the processors are not sharing memory, messages have to be passed between them to share memory. No biggie. But now consider that the whole atmosphere has to be broken up into pieces of a grid. On the boundaries, grid points must be shared by two or more processors. At each timestep, those points must be synchronized. Code must exist to know the processors that border one another and that know which points to share.

Now what happens if you want to combine different models together, as in the atmosphere, ocean, land, and sea-ice models. This is known as a climate coupler. Well, now you have differing grids for each of the models because they were developed independently. Now your program must handle interpolation of the grid points and must again know which processors border one another so that data is efficiently transfered. Finally, there must be decent load handling so that each processor is doing its fair share of the work.

I'm now working on the climate coupler project here at Argonne. Vector machines are quite easy to program, but we do know that they will lose out to massively parallelized clusters. It's just that the programming is much more difficult, since the messaging is always the bottle neck. Communications development follows a rate similar Moore's Law, but with a longer doubling time. For maximum efficiency, the programmer must handle the messaging model directly.

The modeling group here at Argonne understands the issue, and we are working on a general climate system to run quickly on parallized machines. No you know why you can't just do a simple code rewrite. You need to redesign the whole system.

Accelerated Climate Prediction Initiative.

Depends on how you define "important". If I need the answer to a really tricky or obscure problem, the web is next to useless. Oh sure, I could go to google and do a search and hope that one of the 200 results that come up has something useful. But the best chance of finding an answer is to post to comp.whatever, where thousands of people can read my message.

Just this week I found the solution to a maddening problem I was having with a complicated MPI program. After searching the web (and finding nothing), I posted to comp.parallel.mpi. A fellow in the UK read it and sent me a mail saying he was having the same problem. We traded some info back and forth about what we had tried and what hadn't worked. A day later he had figured it out and sent me the info on how to fix it. If it wasn't for Usenet, I'd probably still be banging my head against the wall.

The difference between the web and Usenet is that when I post a question to a newsgroup, it gets distributed to the people who know how to help; but with the web, I have to go rummaging around trying to find a needle in a giant haystack.

The linked page also spelled "otter" wrong. Although I didn't know anyone was making casings for otters.

http://k2k.physics.sunysb.edu/k2k/

http://www.hep.anl.gov/ndk/hypertext/numi.html

And if I remember the study on tape adhesives, duct tape failed badly compared to the average masking tape (duct tape doesn't stand up well when subjected to the high temperatures of a furnace's air flow). The biggest problem is in the level of stickyness on the adhesive is much lower than it should be. No insult on Red Green's comedy staple, but duct tape is probably best used for taping ducks.

http://www.lbl.gov/Science-Articles/Archive/duct-t ape-HVAC.html
Can Duct Tape Take the Heat?
http://hem.dis.anl.gov/eehem/98/980710.html

The story... Chicago, at University of Chicago, a group of students creates a nuclear reactor on the football field. The first uncontrolled nuclear reaction ever (1942)...had to be stopped by a guy running up with an ax.

The first nuclear reactor. Oddly, it looks like a toolshed.

History likes repeating itself. :)


Here is a look at the early Chicago reactors.

The story... Chicago, at University of Chicago, a group of students creates a nuclear reactor on the football field. The first uncontrolled nuclear reaction ever (1942)...had to be stopped by a guy running up with an ax.

The first nuclear reactor. Oddly, it looks like a toolshed.

History likes repeating itself. :)


Here is a look at the early Chicago reactors.

I've been working on a project at Georgia Tech called FutureTruck, which is sponsored by the Department of Energy and some major automobile manufacturers. If you're interested, the website is here. GT is one of 15 schools from around the US and Canada that were tasked with taking a GM Suburban, a rather poor MPG performer but popular in today's market, and making it cleaner, more efficient, and (if possible) even more consumer-attractive.

Just a couple things I've noticed over the past 2 years of this project:

1. Fuel cell vehicles are still a ways off. The hydrogen containers are bulky and heavy, and a system still costs around $1 million.

2. Diesel/biodiesel looks promising but a few problems remain - more polluting than normal gasoline, different performance issues, and such. However, they are more efficient overall. Paired with an electric motor, diesel engines could turn out to be cleaner and more effective than gasoline-only vehicles.

3. Electric-only vehicles are very limited in range and scope. Batteries are still heavy, even the 'new' kinds of batteries like Lithium-Ion. Combined with the need for a charging/recharging infrastructure, and the (at least) American desire for power, the electric-only vehicle will likely be relegated to shuttle cars on a set path.

4. Hybrids, like diesel-electric or gasoline-electric, seem to be the wave of the near future. I believe all the schools participating in FutureTruck are using a hybrid system of some sort. The Honda Insight is a good example of a production car that is a hybrid vehicle. It can reach about 70 MPG after a bit of driver training/getting-used-to. There are an array of configurations and methodologies for hybrid systems that I won't get into here, due to space considerations. But I believe, and so do a lot of other schools and even car manufacturers, that hybrids will pave the way in the near future. Beyond that... maybe they'll have fusion power worked out by then. ;)

I hope this helps some of you out with what's going on in the alternative fuels/powertrain area. I am by no means an authority on this subject, so visit the Department of Energy, the Argonne National Laboratories, and the Society for Automotive Engineers websites for much more detailed information. Those websites are here, here, and here respectively.

Thus was The Punnetizer born. Once I had the basic functionality working, I went hog-wild with output formats. So you can have your Punnet squares in ASCII text, HTML, LaTeX, and CSV. What was really fun was running it on a StarFire with 2GB of RAM with the maximum number of traits. The output HTML was something like 347MB. :P

Anyway, that was one of the few times we impressed Cowell. He actually volunteered to give us extra credit. Of course, he graded our next assignment extra tough, but oh well. :P

--

The other day I found a nice listing of them at www-fp.mcs.anl.gov/~gaasterland/genomes.html

If the guy jumped over California and rode the Jet Stream, he would probably end up... in California!

The average speed of Jet Stream is 110 to 140 knots (source here). So let's take 140 knots, which is around 4 km/min (to give you a better idea, that's 260 km/h, or 160 mi/h). According to the article, the fall should last around 10 minutes. The horizontal drift of the guy would then be:

4 km/min * 10 min = 40 km (27 miles)

Note: I did not forget the guy's relative horizontal speed (horizontal speed within the wind, as the guy "surfs" on the airflow). That speed is just not significant compared to the speed of the Jet Stream.

See this link for the real story on this... http://www.hep.anl.gov/ndk/hypertext/numi.html

How much not very often?

Something like one in ten to the thirty-odd neutrinos will interact.

So, that's enough to see a few of if you if you build a really big detector - Super-Kamiokande in Japan or MINOS in Minnnesota being the experiments I work on.

But, even if you are a fifty-kiloton person and a few neutrinos interact in your chest, that's not enough interactions to pose a danger to you.

Note that this is why these experiments are all deep underground - the cosmic rays bombarding the surface of the earth produce many times more interactions than do the neutrinos. Going underground shields you from a lot of the CR's, so you can actually see the neutrinos.

Batch systems have been around a long time in the HPC world. Gridware was orginally developed by GENIAS Software GmbH. GENIAS produced a batch scheduler called Codine, which was a commercial version of DQS. In fact, Sun's Grid Engine FAQ even states that Sun Grid Engine is a new name for CODINE.

Of course, DQS/Codine/Grid isn't the only batch-scheduling/cycle-scavenging game around. Other players are:

• Condor
• openPBS and it's commercial version PBS Pro
• Load Leveler (which IIRC is IBM's commercial implementation derived from Condor)
• LSF which is the product Sun was previously co-marketing until they purchased Gridware (probably because of the high per CPU cost of LSF).
• and lots of others that I've forgotten, many based on the once-common NQS/NQE batch system.
• There are also systems like Legion that represent a sort of ``next step'' computing enviroment.

Many of these predate newcomers like SETI@home and Mosix by serveral years. Most also provide hooks into parallel computing APIs like MPI, PVM, openMP, or something similar.

Batch scheduling and cycle-scavening are old concepts. Having wasted away my years as a graduate student submitting large quantum chem jobs to Crays, it's nice to see lots of groups continuing to squeeze every useful cycle out of existing hardware. Sun's recent annoucements are just the latest update to an old product---not a new idea, and not a Mosix/SETI rip-off.

You *have* to look at the cheapness and safety. Had the Soviet Union cared at all about safety Chernobyl wouldn't have happened at all or would have had a much smaller impact than it had. We're supposed to hide our heads in the sand and just forget about a clean source of power because the Soviets were dumbasses? Please. I don't disregard anything except people trying to use the fear factor instead of rational thought.

You may call it FUD if you like, but reading whitepapers won't teach you anything useful about the product. Try reading independent reviews, and you get another picture. I believe this is true both for software and nuclear power.

How about looking at a project like IFR here in the US by Argonne National Labs to see what *could* be out there if the fear factor of nuclear power weren't the deciding factor on whether funding is available (that and the probable problems with the coal industry for fear of losing money)? Here is the URL. That project should still be being funded but its not.

Hmm. Not right off. I put all that stuff away when I put away the nuclear advocacy in favor of actually getting a job in computers.

ANL has quite a bit of old info on the IFR project. A search scores about 120 hits. Then there's always the American Nuclear Society.

Argonne National Lab
ANL History-Reactors

American Nuclear Society

Hmm. Not right off. I put all that stuff away when I put away the nuclear advocacy in favor of actually getting a job in computers.

ANL has quite a bit of old info on the IFR project. A search scores about 120 hits. Then there's always the American Nuclear Society.

Argonne National Lab
ANL History-Reactors

American Nuclear Society

Back in 1986, Argonne National Labs tested an inherently safe reactor; one that easily survived the Chernobyl and the Three Mile Island error conditions without human intervention, and without any negative consequences. It uses metallic Uranium for the fuel, instead of UF6 (Uranium HexaFluoride). Read more about this important development at Argonne's site yourself (look for EBR-II on the page).

Yes and Trees Cause Pollution

Now before anyone misinterprets my words to mean "ocean dumping of nuclear waste" or says something nonsensical like "what if it 'comes up' in a volcano somewhere else", recall that ALL of the Earth's current internal heat is generated by the natural radioactive elements present in the Earth (see: http://www.newton.dep.anl.gov/askasci/env99/env087 .htm).

And since most radioactive elements are heavy, they tend to sink and not come back up. Those that do reemerge to the surface are diffused across the globe and are indistinguishable from natural radioactivity.

Support subduction zone dumping of nuclear waste now! Write your legislators! Get funding allocated to research this at your local University. It *is* a good idea. And far better than anything else yet conceived of what to do with the waste.

"Why not just quit making the waste? You overlook world energy shortages."

One of the interesting things that went on at SC2000 was Netchallenge competition with cash prizes.

Its winners have all shown something of interest to the public (disclaimer: our application is one of them, so I am not a neutral party).

Our demo included, we think, the first ever demonstration of interdomain operation of DiffServ-based IP QoS (more on this to come on the QBone web site) as well as an interesting application developed by Computer Music Center folks from Stanford. The application (audio teleportation) allows one to be teleported into a space with different acoustics (with CD-quality sound). During SC2000, two musicians gave a live performance from two different places with their sound being mixed in the air in the acoustics of a marble hall in Stanford.

One of the interesting things that went on at SC2000 was Netchallenge competition with cash prizes.

Its winners have all shown something of interest to the public (disclaimer: our application is one of them, so I am not a neutral party).

Our demo included, we think, the first ever demonstration of interdomain operation of DiffServ-based IP QoS (more on this to come on the QBone web site) as well as an interesting application developed by Computer Music Center folks from Stanford. The application (audio teleportation) allows one to be teleported into a space with different acoustics (with CD-quality sound). During SC2000, two musicians gave a live performance from two different places with their sound being mixed in the air in the acoustics of a marble hall in Stanford.

Each OS will only run 16 processors which make up a "node" of shared memory. There are hundreds of these nodes which are completely distributed memory over a high performance network.

The idea is to run a large problem using message passing (usually MPI), across nodes, and multi-threaded (often using OpenMP compiler directives - easier than Pthreads for scientific computing) inside a node. I am a developer on one of the large ASCI codes, and this is the model we are targetting, although currently we usually run using all MPI (no threads) just because the threads performance is not as good.

See the bottom of this for the phase diagram, which indicates that at room temperature you need 30 plus atmospheres of pressure, or more than 450 lbs per square inch.

Here is a demo/video of dry ice turning into liquid CO2! (get rid of the space after the L near the end of the URL. Sorry, the submission form is wrapping it.)
Ask A Scientist - Liquid CO2
Liquid Carbon Dioxide (CO2) Surfactant System For Garment Care

Why CO2 in Fire Suppression Systems
CO2 Snow Cleaning and what it's best used for.

I want to know how they know that liquid CO2 has a slightly acidic taste and odor!! Did they get inside a 30 atmosphere room temperature container with some liquid CO2 and take a taste?

And finally - test your knowledge of Liquid CO2

The U.S. National Labs offer lots of internships/positions for computer scientists involving Linux or Unix. Here is an incomplete set links for the curious:

• Lawrence Livermore National Laboratory
• Sandia National Laboratory
• Sandia's California site
• Los Alamos National Laboratory
• Argonne National Laboratory

http://www.techtransfer.a nl.gov/techtour/diamondmems.html

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

4:If this is true, then why didnt the soviets shoot down our spy satellites? Why dont the iraquis? why dont we shoot down the russians?clearly we have the capability.National territory only goes up so far, something like 160 km, since there will be a tower 50km of that way, there isnt too much room for movement, and even then, why would you want to do it?

National territory extends upwards indefinitely, to the limit of the ability of the nation in question to enforce it. We do _not_ have the ability to shoot down satellites, and even if we developed it, the Iraqis and Russians would still be a loong way from having that tech trickle down to them. Before Francis Gary Powers got shot down, the Soviet Union couldn't call U2 flights incursions into their territory. Later, the UN passed an Outer Space Treaty which placed some Antarctica-style limits on the uses of orbital and outer space. (Note that any variants of the Strategic Defense Initiative that involve orbiting ABM nukes violate this treaty as well as the 1972 ABM treaty, and in this case, the argument that the USSR has ceased to exist doesn't invalidate the treaty, since it's a U.N. agreement.)

Anyway, the original point about being allowed to shoot down anything within ten miles of your border is fatuous to begin with. At sea national boundaries extend twelve miles out, wnd then only when they don't conlict with anyone else's limit. On land and in the air, a border is a border.

With proprietary software they could be in the same situation again if the vendor moved to some unfriendly country.

A valid point, underscored by Toshiba Machine's, gaff several years ago, of actually selling silent submarine technology to Russia. People have been executed in the US for less.

Vote Naked 2000

You ALSO need to allow anonymous LDAP/SAM lookup access in AD. This can be done on a per-container and per-object basis if you wish.

The general rule is: if you must run Windows 2000 clients and services with Kerberos authentication then your KDCs had better AD.

The whole [technical] point of Microsoft's profile-in-Kerberos tickets extension is to allow them to deny anonymous lookups. This is because the servers you connect to won't need to lookup your user profile data if it's provided in the Kerberos ticket.

Of course, MS's extension stinks for a number of reasons.

I suggest you search the krb-protocol and ietf-krb-wg mailing list archives. (Most posters cross-post to both lists. I don't know where there might be archives for the IETF list).

There was a thread in those lists, earlier this summer, about this whole issue.

My opinion is that MS is right to want to make it possible to deny anonymous lookups that previously had to be allowed. I think they're approach is wrong. I have proposed more than one alternative on the krb-protocol list.

Unfortunately, there is much too much interest in whining about MS' extension and not enough interest in putting forward a better alternative. Yes, MS is abusing the good will of those who dreamed up and made Kerberos possible; I know. I hope we don't degenerate into yet another debate about MS/antitrust/etc.

Another problem is that there is a strong aversion to mixing any authorization features with an authentication protocol. This is quite understandable, though I submit that with SSO systems there is an authorization issue: how to, practically, control delegation of impersonation OR, in other words, how do you authorize remote services to act on your behalf to other services while not giving those services the rights to impersonate you completely.

Nick

Anyway, a little teeny tiny effort and of course comprehension is necessary to find out about Condor and Globus. Condor utilizes idle workstation resources for parallel applications. Kind of like PVM or MPI, but designed for clusters of workstations. It provides a mechanism to link several computers together. Globus, built on Nexus, it is a GPL system that runs on just about any grid (such as what Condor/MPI/PVM can be). It provides a consistent API and is useful for much more than standard parallel work. It is still being developed, but you can get the tools and server stuff.

Most people around here including the asker of the question obviously don't know a parallel app from Microsoft Word. I see this alot. "I will run SETI in parallel!" Huh? Not exactly.

I'll explain... I am all for running process independent stuff by rsh script, but it is not a true use of distribution. That is the whole point. SETI is allocated chunks of non-dependent data out to systems. You then send back results, no messaging. It is simplicity and not a multipurpose distributed system. It is pre-distributed and requires only a yes or no result. This is fine and great for embarassingly parallel applications such as number searches. Your adding more monkeys on typewriters, but they're only monkeys.

Real message passing like that of a Beowulf class server is when there is boundary data required between processes. One computer changes a row on a matrix that row is the boundary so it must send the process it shares the boundary with the updated row. This is usually the real crap, what people buy 100's of nodes to do. See MPI and PVM. These programs must be explicitly written in parallel to be efficient and utilize parallel code structures. They are built on top of message passing libraries (MPI/PVM) that are pre-ported to systems.

Systems like Mosix are OK and they exist now. They give you use of a network of linux workstations with process migration. However, it is very low level and will remain so since it works on x86 process explicitly. It also must have non-I/O bound process to export or it will be limited in utilization. A great project they are working on is the utilization of the networks memory space for large processes. If you ran a 2000x2000 matrix you could solve it using just plain Matlab and 4 256MB systems. It distributes the process state to where the data is. Mosix also is quite useful in dynamic scheduling. PVM and MPI both have very limited use of dynamic scheduling, but thanks to Mosix's peer to peer load balancing it can be utilized as a dynamic scheduler. PVM and MPI issue static process allocation to the nodes, as usage fluxes (finished or waiting process nodes) Mosix can move loads to increase efficiency.

Condor is used on groups of workstations and is heterogenous (NT is getting a port). You can build parallel apps for it just like MPI or PVM, it uses other technologies than them however.

Now Globus, Globus is a huge project utilizing a message passing/thread library called Nexus it can run on any grid. That grid then will connect to other distributed grid resources across the net. The user is presented with a web interface and a secure login. They upload the program and request an allocation of resources. They get the results back when done. It uses whatever servers are availible and can use explicit parallelism through the thread library to make it faster. It is for all purposes a worldwide supercomputer. It goes beyond this to also share all data resources available to the system by database through its directory system. This system allows anyone to join, but you have to be allowed to use other peoples resources.

So if you seriously are thinking about playing with this stuff, figure a real use, figure how much power usage you will be using (NODESx250W 24x7 can be quite a power bill). Then decide what parallel system PVM/MPI/Mosix/Condor you want to use. If you have a whole department of computers Condor might be good, if you have a specific parallel app and a few non-workstation nodes use pvm/mpi. If you run lots of processes or have lots of people logging on, Mosix code be useful. Also, Mosix on MPI/PVM would give probably an efficient cluster. Then you could submit it to Globus so others could utilize it. However, it sounds rather elitest and probably won't use two P133s when they got Cray T3Ds. Also, don't think about actually using Globus yourself. Hey, I guess it would be just about like SETI and others. You could be helping science or at least some grad-student piddle around.

I really don't care for their choices at all. A lot of them are more like general approaches than algorthms, and I'm not at all sure they are the most influential. I think they are supposed to be "the cleverest of the common fancy methods"

Simple algorithms for common problems are much more widely used, and have far more impact and influence, but try telling *them* that!

I hope these links help. (Warning: many are technical) If anyone has personal favorites that are less dry than many of these, please post!.

10. 1987: Fast Multipole Method. A breakthrough in dealing with the complexity of n-body calculations, applied in problems ranging from celestial mechanics to protein folding. [Overview] [A math/visual approach]

9. 1977: Integer Relation Detection. A fast method for spotting simple equations satisfied by collections of seemingly unrelated numbers. [Nice article with links]

8. 1965: Fast Fourier Transform. Perhaps the most ubiquitous algorithm in use today, it breaks down waveforms (like sound) into periodic components. Everyone knows this one (or should) [Part II of my personal favorite FFT and wavelet tutorial]

7. 1962: Quicksort Algorithms for Sorting. For the efficient handling of large databases. [Definition][Basic Method][Mathworld][More technical explanation][A lecture with animations and simulations]

6. 1959: QR Algorithm for Computing Eigenvalues. Another crucial matrix operation made swift and practical. [Math] [Algorithm

5. 1957: The Fortran Optimizing Compiler. Turns high-level code into efficient computer-readable code. (pretty much self-explanatory) [History and lots of info]

4. 1951: The Decompositional Approach to Matrix Computations. A suite of techniques for numerical linear algebra. [matrix decomposition theorem] [Strategies]

3. 1950: Krylov Subspace Iteration Method. A technique for rapidly solving the linear equations that abound in scientific computation. [History] [various Krylov subspace iterative methods]

2. 1947: Simplex Method for Linear Programming. An elegant solution to a common problem in planning and decision-making. [English} [Explanation with Java simulator] [An interactive teaching tool

1. 1946: The Metropolis Algorithm for Monte Carlo. Through the use of random processes, this algorithm offers an efficient way to stumble toward answers to problems that are too complicated to solve exactly. [English] [Code and Math] [Math explained]

I really don't care for their choices at all. A lot of them are more like general approaches than algorthms, and I'm not at all sure they are the most influential. I think they are supposed to be "the cleverest of the common fancy methods"

Simple algorithms for common problems are much more widely used, and have far more impact and influence, but try telling *them* that!

I hope these links help. (Warning: many are technical) If anyone has personal favorites that are less dry than many of these, please post!.

10. 1987: Fast Multipole Method. A breakthrough in dealing with the complexity of n-body calculations, applied in problems ranging from celestial mechanics to protein folding. [Overview] [A math/visual approach]

9. 1977: Integer Relation Detection. A fast method for spotting simple equations satisfied by collections of seemingly unrelated numbers. [Nice article with links]

8. 1965: Fast Fourier Transform. Perhaps the most ubiquitous algorithm in use today, it breaks down waveforms (like sound) into periodic components. Everyone knows this one (or should) [Part II of my personal favorite FFT and wavelet tutorial]

7. 1962: Quicksort Algorithms for Sorting. For the efficient handling of large databases. [Definition][Basic Method][Mathworld][More technical explanation][A lecture with animations and simulations]

6. 1959: QR Algorithm for Computing Eigenvalues. Another crucial matrix operation made swift and practical. [Math] [Algorithm

5. 1957: The Fortran Optimizing Compiler. Turns high-level code into efficient computer-readable code. (pretty much self-explanatory) [History and lots of info]

4. 1951: The Decompositional Approach to Matrix Computations. A suite of techniques for numerical linear algebra. [matrix decomposition theorem] [Strategies]

3. 1950: Krylov Subspace Iteration Method. A technique for rapidly solving the linear equations that abound in scientific computation. [History] [various Krylov subspace iterative methods]

2. 1947: Simplex Method for Linear Programming. An elegant solution to a common problem in planning and decision-making. [English} [Explanation with Java simulator] [An interactive teaching tool

1. 1946: The Metropolis Algorithm for Monte Carlo. Through the use of random processes, this algorithm offers an efficient way to stumble toward answers to problems that are too complicated to solve exactly. [English] [Code and Math] [Math explained]

If you are interested in neutrinos, there's quite a lot going on. Check:
Fermilab's MINOS;
CERN's NGS;
more in general, a page on Neutrino oscillation