I worked as a summer intern at Fermilab a few years ago. It was my job to do some dose rate estimations for NUMI project, which was the sister project to MINOS. NUMI (Neutrinos for the Main Injector), was tasked with delivering the neutrino beam which would be used by MINOS.
To answer your concerns about beam divergence, and initial trajectories here is a quick overview, from the abstract of my FINAL PAPER, of how the Neutrino beam is created. The jist of it is that the beam was not steered and focused as a beam of Neutrinos. Initially the beam, consists of very short lived particals called Pions and Kaons. The Pions and Kaons resulted from a proton beam coliding with a carbon target. The Pions and Kaons were directed and focused by 2 electro-magnetic focusing horns. The Pions and Kaons, then rapidly decay into Muons and Muon Neutrinos. The net result is a very tight beam of Muon Nutrinos.
In an effort to verify the Japanese Super-K (Super-Kamiokande) experiment's conclusion that neutrinos have mass Fermilab's MINOS (Main Injector Neutrino Oscillation Search) experiment will attempt to find oscillations in neutrino flavors (muon, electron, & tau). Such oscillations would be definitive proof that neutrinos have mass. NuMI (Neutrinos at the Main Injector) is the Fermilab project that is responsible for providing the beam of muon neutrinos to be used by the MINOS experiment.
A beam of 120 GeV protons will be extracted from Fermilab's "Main Injector" where it will pass through a target hall. In the target hall the beam of protons will collide with a Carbon Target producing a scatter of charged pions and kaons. An electromagnetic horn will re-culminate this beam and a second horn will focus the energy of this beam, which will then pass through a decay pipe where the pion/kaon beam will decay into muons and muon neutrinos. The beam will then pass through an absorber and about 50 ft of rock that will remove unwanted particles still in the beam such as the muons. This leaves a beam of pure muon neutrinos to pass through the MINOS near detector, which will verify the composition of the beam. The beam then passes underground 730 km to the MINOS far detector located half a mile underground in the Soudan mine in Minnesota, which will again look at the composition of the beam.
The data at the far detector will be compared to the data at the near detector, and if electron or tau neutrinos are found in the beam at the MINOS far detector then two things will happen. First there will be a large celebration at Fermilab, and second the NuMI target hall will be reconfigured to deliver a different energy level focus by moving the second horn into a different position along the beam-line. The MINOS experiment will then go on to try to answer other important neutrino questions such as what is the difference in the square of the masses of the oscillating neutrinos ("delta mass squared").
So Aparently I was wrong about the party at Fermilab. I can't see as how a weekend full of meetings is any substitute.;0)
Wow, that was fast. I only posted the page on Sunday evening...
To address questions asked here on Slashdot. The main purpose of this project was to build a wearable debian box. We had a 2 square inch VGA LCD heads up display that we were using. Also we had toyed around with Festival to read output to the user. The application did not require any user input, so no keyboard was nessasary. If someone wanted user input one could use bluetooth and a Linux PDA to run ssh or VNC. Also I have seen some IR remote controls that have a full keyboard (Do a Google search on CarPC's and remote controls), so user input is not out of the question.
Also several people were talking negativly about the battery life. My run time test was conducted under heavy load so the Mac Mini was pulling around 14-20W at the time. The device I used for measuring the power was a Watts Up Pro which was specificly designed for measuring the power draw on consumer electronics, so the readings are accurate. Bear in mind that these batteries are preproduction prototypes that were sent to me for evaluation, and SKC Films informed me after I recieved them that they would not perform optimally do to a mistake in that batch. They also offered to make me another batch, which I declined as my application only needed about 45min runtime and the ones I already had would do fine for proof of concept. The point here is that with further work the battery life can be inproved. Simply using CPUFreq in the Linux Kernel will help strech out the battery life a good deal. To address concerns someone brought up about charging the Li-ion batteries, A power supply with a current limiting knob _is_ a safe method of charging the batteries. The chargers that are designed for charging Li-ion batteries, say for instance in cell phones, do just that. I have recharged my battery pack just fine using a Topward power supply set to 20VDC and limited the current to about 50mA and the batteries didn't even get warm let alone explode in my face;0).
Granted my application was very specific, but this could be used for lots of things. Slashdot has already mentioned quite a few. How about this one: A portable compute brick. In a lab setting one might need to take a part of a Mosics cluster from one lab bench to another to collect and process data. Having a built in UPS on the Mac Mini with a Wifi network interface allows you to move the compute node physicly without having to first remove the node from the cluster and migrate all of it's processes off the node. Please note that Wireless comunications with the Mac Mini need to use a USB or Firewire Wifi card because the Mac airport card uses the broadcom chipset, which Linux users have learned to hate with a passion. Before someone mentions NDISWrappers I would like to state the obvious Mac is non-X86 and the binary drivers that are used with NDIS are compiled for X86.
"Why do this?" was also asked. My response... I am a Geek, and it was fun!
Cheers,
Silas Bennett
P.S. My uname should read Fuzzy_The_Quantum_Duck but Slashdot didn't like the last 2 characters...
... Is also waging war on the student operated Co-ops.
The co-ops are the Che Cafe, a popular counterculture hangout; Groundwork Books, a bookstore with eclectic, leftist selections; the General Store Co-op, which features notebooks, sweat shirts and snacks; and the Food Co-op, which sells organic and health foods.
Each operates as a nonprofit, funneling any profits back into operations.
These Co-ops have been around for 30 years, and are quite popular with the students.
An attorney who has battled the administration on behalf of the co-ops in the past decade, said this is the university's latest attempt to eliminate the co-ops, which are less lucrative for UCSD than commercial businesses.
"This is the third major attempt by the administration to eviscerate the co-ops," said attorney Lottie Cohen of Los Angeles. "The administration wants control and money."
Mod the parent up (Funny). Also if you know who the parent is, tell them they now owe me a new keyboard! Mine is now fried by the stream of chocolate milk that came out of my nose.
Seriously though. Snow Crash is such a great book, I just finished reading it. If you haven't yet read it you should.
I think that has more to do with the bandwidth required to load all of the pictures. If a site only needs to upload 1KB per hit it will likely survive a/.ing unless it is running on junk hardware or on a narrow pipe. If it needs to upload 100MB per hit, it has got to have one hellofa fat pipe and damn decent hardware to avoid being turned to molten slag.
Anyone see a list of changes? I'm particularly interested to know if they've integrated the NTFS read/write libraries.
This release contains the 2.6.5 Kerenl. The 2.6 series kernels all are capable of (Non-Dangerous)This release contains the 2.6.5 Kerenl. The 2.6 series kernels all are capable of (Non-Dangerous) NTFS Read/Write support.
Dropping KOffice just makes sense.
Reading the traffic on the knoppix news forums
http://www.knoppix.net/forum/viewforum.php?f=4 suggests that "Many" people were unhappy about droping Koffice as they don't like OpenOffice. Even I, a fanatic OpenOffice promoter/user, am going to miss Kmail on my new knoppix cd. I guess I could bother to read the docs on how to remaster a version myself. Which remides me... You said:
Give me a version that will build a FreeBSD/KDE3/OpenOffice/Java CD to my specifications and I'll be in heaven.:-D
Obviously you haven't driven with my Mother!;0)
Airplanes definatly do hit 1G, but you are not really supposed to use those during takeoff and landing.
Also from the Original poster: "Active Protection System (APS) is a microchip put on the system board that senses acceleration."
Cheers,
Duck
Even worse. Think about the poor unsusptecting souls that attempt to use this in a car/train/bus/airplane/whatever. You will be accelerating quickly quite often while in a vehicle, and the laptop is not actually in any danger, but you are trying to get your work done. Just have to wait untill the next red-light/airport/train-stop I guess
Fuzzy The Quantum Duck
Debian is as stable as you can get. If they want the support, they can hire someone to do it in house (and in doing so contribute back to the movmement), or pay another company for support. The cost either way will undoubtedly be less then shelling out more than $350K for Red Hat, licenses. I Vote DEBIAN, but I am sure would work as well;0)
Fuzzy_The_Quantum_Duck
=0)
================== Damn Slashdot cut the last 2 Chars from my name!!!
From what I have heard ( By a reputable co-worker/Linux Guru/IEEE Member ) you won't be seing OSS Drivers for 802.11g any time soon. Apparently Uncle Sam doesn't want all the specs made public for 802.11g, due to military interests. From what I undersood (correct me if I am wrong) 802.11g is capable of private chanells (Guessing this is done by slight frequency shifts or something), and U.S. Military is currently using such a private chanell. Henceforth they don't want an army of curious (or malicious) *NIX hackers sniffing around on thier network so they are not allowing the info to be freely available. This doesn't mean that a hardware vendor cannot take pitty on us and make binary drivers available. What I would really like to see are some drivers that split the packet stream and transmit on both 802.11g & 802.11a (Ala-ISDN). 108Mbit/sec Raw Data rate via photons would be very sexy indeed.
Slashdot Mirror
I worked as a summer intern at Fermilab a few years ago. It was my job to do some dose rate estimations for NUMI project, which was the sister project to MINOS. NUMI (Neutrinos for the Main Injector), was tasked with delivering the neutrino beam which would be used by MINOS.
To answer your concerns about beam divergence, and initial trajectories here is a quick overview, from the abstract of my FINAL PAPER , of how the Neutrino beam is created. The jist of it is that the beam was not steered and focused as a beam of Neutrinos. Initially the beam, consists of very short lived particals called Pions and Kaons. The Pions and Kaons resulted from a proton beam coliding with a carbon target. The Pions and Kaons were directed and focused by 2 electro-magnetic focusing horns. The Pions and Kaons, then rapidly decay into Muons and Muon Neutrinos. The net result is a very tight beam of Muon Nutrinos.
So Aparently I was wrong about the party at Fermilab. I can't see as how a weekend full of meetings is any substitute.
Cheers, Fuzzy the Quantum Duck.
=0)
To address questions asked here on Slashdot. The main purpose of this project was to build a wearable debian box. We had a 2 square inch VGA LCD heads up display that we were using. Also we had toyed around with Festival to read output to the user. The application did not require any user input, so no keyboard was nessasary. If someone wanted user input one could use bluetooth and a Linux PDA to run ssh or VNC. Also I have seen some IR remote controls that have a full keyboard (Do a Google search on CarPC's and remote controls), so user input is not out of the question.
Also several people were talking negativly about the battery life. My run time test was conducted under heavy load so the Mac Mini was pulling around 14-20W at the time. The device I used for measuring the power was a Watts Up Pro which was specificly designed for measuring the power draw on consumer electronics, so the readings are accurate. Bear in mind that these batteries are preproduction prototypes that were sent to me for evaluation, and SKC Films informed me after I recieved them that they would not perform optimally do to a mistake in that batch. They also offered to make me another batch, which I declined as my application only needed about 45min runtime and the ones I already had would do fine for proof of concept. The point here is that with further work the battery life can be inproved. Simply using CPUFreq in the Linux Kernel will help strech out the battery life a good deal. To address concerns someone brought up about charging the Li-ion batteries, A power supply with a current limiting knob _is_ a safe method of charging the batteries. The chargers that are designed for charging Li-ion batteries, say for instance in cell phones, do just that. I have recharged my battery pack just fine using a Topward power supply set to 20VDC and limited the current to about 50mA and the batteries didn't even get warm let alone explode in my face ;0).
Granted my application was very specific, but this could be used for lots of things. Slashdot has already mentioned quite a few. How about this one:
A portable compute brick. In a lab setting one might need to take a part of a Mosics cluster from one lab bench to another to collect and process data. Having a built in UPS on the Mac Mini with a Wifi network interface allows you to move the compute node physicly without having to first remove the node from the cluster and migrate all of it's processes off the node. Please note that Wireless comunications with the Mac Mini need to use a USB or Firewire Wifi card because the Mac airport card uses the broadcom chipset, which Linux users have learned to hate with a passion. Before someone mentions NDISWrappers I would like to state the obvious Mac is non-X86 and the binary drivers that are used with NDIS are compiled for X86.
"Why do this?" was also asked. My response...
I am a Geek, and it was fun!
Cheers,
Silas Bennett
P.S. My uname should read Fuzzy_The_Quantum_Duck but Slashdot didn't like the last 2 characters...
If they don't have phone service, then let them get fiber to the premises.
</bad marie antoinette joke>
These Co-ops have been around for 30 years, and are quite popular with the students.
=0) Fuzzy The Quantum Duck
HaHaHa
Mod the parent up (Funny). Also if you know who the parent is, tell them they now owe me a new keyboard! Mine is now fried by the stream of chocolate milk that came out of my nose.
Seriously though. Snow Crash is such a great book, I just finished reading it. If you haven't yet read it you should.
=0)
I think that has more to do with the bandwidth required to load all of the pictures. If a site only needs to upload 1KB per hit it will likely survive a /.ing unless it is running on junk hardware or on a narrow pipe. If it needs to upload 100MB per hit, it has got to have one hellofa fat pipe and damn decent hardware to avoid being turned to molten slag.
=0)
Fuzzy
Reading the traffic on the knoppix news forums http://www.knoppix.net/forum/viewforum.php?f=4 suggests that "Many" people were unhappy about droping Koffice as they don't like OpenOffice. Even I, a fanatic OpenOffice promoter/user, am going to miss Kmail on my new knoppix cd. I guess I could bother to read the docs on how to remaster a version myself. Which remides me... You said: Read the documentation:
http://www.knoppix.net/docs/index.php/FaqCustomis
Cheers,
Fuzzy
=0)
There was an article in the The Register last week that was mentioned here that does a really good job of answering your question.
Cheers,
Fuzzy The Quantum Duck
=0)
Obviously you haven't driven with my Mother! ;0)
Airplanes definatly do hit 1G, but you are not really supposed to use those during takeoff and landing.
Also from the Original poster: "Active Protection System (APS) is a microchip put on the system board that senses acceleration."
Cheers,
Duck
Even worse. Think about the poor unsusptecting souls that attempt to use this in a car/train/bus/airplane/whatever. You will be accelerating quickly quite often while in a vehicle, and the laptop is not actually in any danger, but you are trying to get your work done. Just have to wait untill the next red-light/airport/train-stop I guess Fuzzy The Quantum Duck
Debian is as stable as you can get. If they want the support, they can hire someone to do it in house (and in doing so contribute back to the movmement), or pay another company for support. The cost either way will undoubtedly be less then shelling out more than $350K for Red Hat, licenses. I Vote DEBIAN, but I am sure would work as well ;0)
Fuzzy_The_Quantum_Duck
=0)
==================
Damn Slashdot cut the last 2 Chars from my name!!!
From what I have heard ( By a reputable co-worker/Linux Guru/IEEE Member ) you won't be seing OSS Drivers for 802.11g any time soon. Apparently Uncle Sam doesn't want all the specs made public for 802.11g, due to military interests. From what I undersood (correct me if I am wrong) 802.11g is capable of private chanells (Guessing this is done by slight frequency shifts or something), and U.S. Military is currently using such a private chanell. Henceforth they don't want an army of curious (or malicious) *NIX hackers sniffing around on thier network so they are not allowing the info to be freely available. This doesn't mean that a hardware vendor cannot take pitty on us and make binary drivers available. What I would really like to see are some drivers that split the packet stream and transmit on both 802.11g & 802.11a (Ala-ISDN). 108Mbit/sec Raw Data rate via photons would be very sexy indeed.
Cheers,
Fuzzy_The_Quantum_Duck