How sure are you that the lamps failed due to the cold, and not due to condensation? Especially in a deep freezer, and then suddenly exposed to ambient conditions, you'd end up with quite a bit of condensation on the interior circuit boards.
People deal with this shit in their everyday life and dont want to watch it when they pay to enter a theater for some relaxation.
Odd, by your logic, a gay man would not want to watch a movie like Milk, or an African American wouldn't want to watch Malcom X, but that doesn't seem to be the case.
The idea with Itanium was to make a CPU that could perform on the level of RISC and CISC CPUs with a relatively simple front end. In essence the Itanium executes a fixed number of instructions each cycle, then leaves it to the compiler to select which instructions are to be executed in parallel and make sure they don't read and write to the same registers and such (instead of having logic in the CPU figuring this stuff out).
One would think they learnt this particular lesson from the i860, but apparently not. Perhaps they believed too much in the ability of compilers to predict what the code would do at run-time. This was bad enough at the time the i860 was built, but far worse in the age of the Itanium, given the insane ratio of CPU throughput to memory bandwidth.
I wonder if there would be some utility in porting Android to work under frameworks such as OpenEmbedded, or just as a developer's kit that can be deployed to some of the various ARM SBCs. Hook your SBC to a small LCD panel/touchscreen and you've got a nice platform for Industrial control and all manner of "ambient devices". I'm guessing the framebuffer system of Android would be lighter weight than X.
True, but use of pre-built libraries for time consuming tasks on the CellBE should make it easier to extract maximum performance. I'll quote the only example I know of: the FFTW port to CellBE
IAARE (I am a radar engineer) The DOWs use NCAR's older PIRAQ-III PCI digitizers to digitize the radar's final IF. The software to support the PIRAQ runs on DOS, AFAIK. The Windows box inside the DOW runs the antenna controller, which is a visual basic program with some, uh, "interesting" choices for user interface (think shocking pink buttons).
"Real" weather radars, such as the NWS NexRad now run Sigmet/Vaisala RVP-8 processors, which use Linux.
Funny how TFA talks about wire wrap boards giving projects a "vintage" look. I saw, as recently as 2004, an Augat wire-wrap board being used as a part of a PhD student's research work. This isn't so bad in itself, except it had about 20 ECL logic chips, carrying 80 MHz signals. There were runt pulses and false triggering all over the place. I replaced it with a single Xilinx Coolrunner II.
I'd say go with Agilent. Many have commented that they are more expensive, but that's not true for Universities, they have very good educational discounts (often 20%), talk to an Agilent rep.
I've used a 6000 series, they're very nice, and have plenty of knobs for each function. Try to avoid scopes that use one big encoder knob (or a small number of knobs) for everything. My Tek 3034 has this problem.
The thing I don't like about the DPO4000 (well we have an MSO4000) is its bootup time. It takes a half-minute or so to boot, and that's too long for field work. We have a TDS3034 instead for that.
Also, the MSO4000 waveform update rate takes a hit when you enable digital channels.
Trouble with PARs is calibration. Military folks don't have to worry about that, but when one or more T/R elements fail on a PAR, how do you measure and compensate for that loss? With the SPY-1, it's relatively simple since it's a space-fed array, but for true active arrays, nobody's come up with a good solution to tackle the calibration issue. Worse, the sidelobe characteristics change when elements fail, and this would affect the antenna gain. How would you compensate for that?
There are some who pooh-pooh accurate calibration, but when you're looking at variations of 0.1 dB (for differential reflectivity), it becomes quite a challenge.
Slashdot Mirror
They even sell a fembot.
But will it survive in a manbot's manputer's world?
Neon tubes? Surely you mean mercury-vapor fluorescent tubes. Neons would glow red.
How sure are you that the lamps failed due to the cold, and not due to condensation? Especially in a deep freezer, and then suddenly exposed to ambient conditions, you'd end up with quite a bit of condensation on the interior circuit boards.
Try saying that in Hermes' voice :)
It's funny, but is it going to get them off their tractors?
I can see it now, Youtube commenters talking about how "ITER pwns LHC's ass!"
People deal with this shit in their everyday life and dont want to watch it when they pay to enter a theater for some relaxation.
Odd, by your logic, a gay man would not want to watch a movie like Milk, or an African American wouldn't want to watch Malcom X, but that doesn't seem to be the case.
The idea with Itanium was to make a CPU that could perform on the level of RISC and CISC CPUs with a relatively simple front end. In essence the Itanium executes a fixed number of instructions each cycle, then leaves it to the compiler to select which instructions are to be executed in parallel and make sure they don't read and write to the same registers and such (instead of having logic in the CPU figuring this stuff out).
One would think they learnt this particular lesson from the i860, but apparently not. Perhaps they believed too much in the ability of compilers to predict what the code would do at run-time. This was bad enough at the time the i860 was built, but far worse in the age of the Itanium, given the insane ratio of CPU throughput to memory bandwidth.
my Wii is named Lrrr
From the planet Nintendu 64?
No, but according to TFA, it would be the year of real-time raytracing across 20 desktops.
Windows 7 Beta: Now with more hookers.
In fact, forget the Windows 7 Beta!
I wonder if there would be some utility in porting Android to work under frameworks such as OpenEmbedded, or just as a developer's kit that can be deployed to some of the various ARM SBCs. Hook your SBC to a small LCD panel/touchscreen and you've got a nice platform for Industrial control and all manner of "ambient devices". I'm guessing the framebuffer system of Android would be lighter weight than X.
True, but use of pre-built libraries for time consuming tasks on the CellBE should make it easier to extract maximum performance. I'll quote the only example I know of: the FFTW port to CellBE
Seems like I have a lot to worry about, I have a couple of disk arrays inside a 40-ft trailer that tends to rock in the wind...
The racks are shock-mounted, though.
I would buy this, then keep clicking "refresh" on Amazon to check if the third edition is released yet. This is a superb book, if a little dated.
Agreed. The chapter on noise finally got me to understand what three crappy textbooks and an undergrad microwave course did not teach me.
IAARE (I am a radar engineer) The DOWs use NCAR's older PIRAQ-III PCI digitizers to digitize the radar's final IF. The software to support the PIRAQ runs on DOS, AFAIK. The Windows box inside the DOW runs the antenna controller, which is a visual basic program with some, uh, "interesting" choices for user interface (think shocking pink buttons).
"Real" weather radars, such as the NWS NexRad now run Sigmet/Vaisala RVP-8 processors, which use Linux.
Funny how TFA talks about wire wrap boards giving projects a "vintage" look. I saw, as recently as 2004, an Augat wire-wrap board being used as a part of a PhD student's research work. This isn't so bad in itself, except it had about 20 ECL logic chips, carrying 80 MHz signals. There were runt pulses and false triggering all over the place. I replaced it with a single Xilinx Coolrunner II.
I'd say go with Agilent. Many have commented that they are more expensive, but that's not true for Universities, they have very good educational discounts (often 20%), talk to an Agilent rep.
I've used a 6000 series, they're very nice, and have plenty of knobs for each function. Try to avoid scopes that use one big encoder knob (or a small number of knobs) for everything. My Tek 3034 has this problem.
The thing I don't like about the DPO4000 (well we have an MSO4000) is its bootup time. It takes a half-minute or so to boot, and that's too long for field work. We have a TDS3034 instead for that.
Also, the MSO4000 waveform update rate takes a hit when you enable digital channels.
Doesn't that sound a lot like what India is trying to do?
Also, it gives the ISRO sufficient prominence that a greater fraction of fresh graduates would consider a career there.
I suppose one argument in favour of Chinese home-grown software is the language barrier.
Maybe the extraterrestrial Richter is lying to Cohagen again...
This also sounds like the "Scrye" spell from Clive Barker's Undying.
Trouble with PARs is calibration. Military folks don't have to worry about that, but when one or more T/R elements fail on a PAR, how do you measure and compensate for that loss? With the SPY-1, it's relatively simple since it's a space-fed array, but for true active arrays, nobody's come up with a good solution to tackle the calibration issue. Worse, the sidelobe characteristics change when elements fail, and this would affect the antenna gain. How would you compensate for that?
There are some who pooh-pooh accurate calibration, but when you're looking at variations of 0.1 dB (for differential reflectivity), it becomes quite a challenge.