There was an HP Chimunk system at the MIT Lab for Computer Science which was running, along with its stacks of external SCSI hard drives, on a clearly over-loaded card table. The table collapsed while the disks were spinning (yes, while the disks were spinning) and the system came literaly crashing literaly to the ground.
Power off, clean up the mess, fix the table, reconnect all the wires, and power it on. Worked fine.
How about a manual method where one creates a ficticious bounce message from spam that has made it to the mailbox?
The idea is the following: spam gets through whatever filter you might have, but you still want to reject it, and given that some spammers MIGHT be trimming their lists based on bounces, you forge a bounce message from the spam.
Does anyone know if this is possible with, eg, RMail or VM (or something else) running under Emacs?
Having traversed from a predominantly engineering realm (computer science) to a predominantly scientific realm (neurobiology), my observations have been that the tools are selected mostly on habit or previous knowledge rather than fitness for use.
The most commonly-used analytical platform is probably Excel (or some similar tool like Statistica), but the more serious researchers, who are also the more mathematically-aware, nearly all use Matlab in my experience.
When efficiency is an issue, nearly everyone I've worked with turns either to IDL (a Matlab competitor that has more arcane syntax, but much higher processing speed) or writes a C/C++ program by taking algorithms from "Numerical Recipes in C".
Recently, I've also seen a rising use of Visual Basic, especially to do experimental control (although some Matlab hooks do exist for such), and, of course, LabView. Some diehards use LabView for data analysis as well, but their results are suspect just because the tool is so poorly fitted to the task. And, of course, many data collection hardware manufacturers (CED, National Instruments, TDT, etc.) supply scripting languages to control their hardware and perform rudimentary and sometimes not-so-rudimentary calculations.
The best researchers select the most appropriate tool for the job, but, again in my experience, it seems the selection is normally based on previous experience and inertia. Those who know a particular tool well (eg, Excel, Matlab, SPSS, Mathematica) tend to keep using that tool, even if it is not well-suited. This means you get abberations like Matlab programs that control real-time experiments and LabView programs that do higher-order mathematics.
Why?
Because the largest fraction of a scientists' time should be spent on data collection, not experimental implementation, and the amount of time (for nearly all fields except those with astronomical amounts of data) spent executing code is dwarfed by the time developing it. Clearly this breaks down for certain applications, but most of the science currently being done (read: molecular biology, and no, not bioinformatics) is not algorithm-bound.
Since data analysis is such a huge, broad field, I expect to see radically different answers from other posters!
I would say it is better than that. I use a VIA C3 900 Mhz processor in a Shuttle small form factor PC (SV24) at home. It uses so little power that it does not require a CPU fan.
I have played with a nearly identical setup. Like you, my experience was that it was fine for run-of-the-mill use, and not-so-good for computationally intensive tasts, just like a 500-or-so MHz PIII would be. My original comment was based on various benchmarks which have been floating around since the C3 was introduced, the brunt of which is that the C3's main selling point of low power consumption comes at the expense of a significant amount of computational horsepower.
To wit, and echoing what a lot of other posters have said, better to spend a little more money and get a real laptop.
A 933 MHz C3 is approximately equivalent, in real-world horsepower, to a 550 MHz Pentium (on integer tasks, much worse for floating-point). The C3 is not a high-performance architecture, although it has been tweaked for very low power consumption.
This article brings to mind a major, but unnoticed fatal flaw in Regan's Star Wars program which sought to put killer sattelites in space to protect the American People: all an enemy needed to do to take said network out was launch a handful of rockets to the same orbit to explosively release simple payloads of (many) ball bearings. No cost-effective defense against it.
Also someone leaked a project going on at National Instruments that really lit up my interest in this.
As a previous poster has replied, LabView is in wide distribution. It's aimed at the scientific and engineering markets, and, like AutoCAD and similar products, allows the user to enter program descriptions either in graphical or textual form.
But, here's the kicker: every single heavy LabView user I know of (even the ones without extensive previous programming training or experience) drops the graphical interface in favor of the textual one. Further, I am familiar with one large project developed under LabView, and the opinion of the programmers involved was that it pretty much sucks eggs.
What's the point or relevance here? National Instruments (not to be confused with National Semiconductor) has put a lot of time and effort into developing a graphical language that seems *perfect* for capturing data-flow like algorithms, just the kind of thing you'd want to run on an FPGA, and they've pretty much failed. (People continue to use LabView because, for that community, there currently is little better that has such wide support.) The problem of programming interface for things like this is hard, mostly because our algorithms are by-and-large not stateless.
My favorite version of such things, is "MIT, a wholly-owned subsidiary of Cornell Engineering." Had it on a T-shirt from my sister, who went to Cornell while I was at MIT.
That kind of tongue-in-cheek teasing is, like imitation, sincere flattery.
Caltech is a private university and not part of the UC system. To refer to it as "Cal Tech" or "CalTech" is not only wrong and misleading, but does a disservice to the people associated with that fine institution.
That said, I think the stuff happening there is very cool.
YES! This is a good observation, I too have seen ridiculously high line counts because of source code fragemented across many files. All because of the included headers 10,000 lines of code gets reported as 1,000,000!
MythTV is a nice project which is nearing some significant milestones in terms of usability. Isaac Richards, the fellow behind the effort, is good at both architecting and writing software, and is very quick at fixing problems that people (enthusiasts, mainly) find.
The biggest problem is that the architecture is based around software codecs which requires reasonably hefty CPUs. Hefty CPUs (eg, Athlon 1800) need hefty fans and big boxes. Hefty fans make a lot of noise, and big boxes are, to my eye, far too large for audio/video equipment, and often (but not always) plain ugly.
Isaac has made it clear that he intends at some point to support hardware codecs, but the timeline for that is unclear, as it requires support in a number of other areas (eg, xvideo).
My assessment of the current state of MythTV is that it looks great, has a nice interface, does most of the things you would want a PVR to do (and the list of unsupported options is getting shorter and shorter by the day), but as no hard-and-fast guidelines about supported hardware have been established, getting it to work on your particular box can be a hassle (but, might not be, if you get lucky with choosing the right hardware; unfortunately, there isn't a good published list of the right hardware). Unfortunately, MythTV requires a large handful of other packages, and getting exactly the right versions of each can be frustrating at times. While the project has considerable promise, and I have every expectation that it will eventually be excellent, it isn't quite ready for prime time.
YES! This became one of my all-time favorite, ah, car chase scenes. There was tremendous hype about the chase in Bourne Identity, but, frankly, Bond's tank chase was hands-down better.
This, to reflect another poster's assertion, was using available materials -- ie, his wits -- to best advantage. Mr. Broccoli, et al, more intrigue and plot please; less action-hero stuff.
JWZ's Law Of Software Envelopment states that all programs expand until they can read mail.
That would have been originally formulated as, "all programs expand until they become Emacs," observed by many people over the years at MIT's LCS/AI labs.
Interesting. I don't normally use AVX components, but this discussion has motivated me to re-examine our assumptions about tantalum reliabilities. We have, however, as previously stated, not seen one fail with the 50% voltage derating.
Solid alumninum sounds very interesting -- hadn't heard of those caps. I'd agree that from basic principles, alumninum oxide should be *much* more stable than tantalum oxide.
You can't be serious! Tantalums are notoriusly flaky. Not only that, the usual failure mode is that the cap vanishes in a spectacular flash of purple fire. Every capacitor failure I've ever seen in computing equipment has been a tantalum. An engineer who used to work at Motorola told me that tantalums were banned from pager designs. At the time, Motorola would rather pay the premium for ceramic caps than risk tantalums.
He was serious, and so am I when I say that I routinely design with tantalums when I want high reliability, electrolytics when it doesn't matter as much. The fellow you mention from Motorola (and his associates) don't understand the problems with tantalums: they are extremely reliable, and have far superior specifications than equivalent electrolytics, if you simply derate the maximum voltage by a factor of 2. Eg, if your design calls for the capacitor seeing a maximum differential of 15V, specify a 30V capacitor.
My father, also an electrical engineer, and I have separately been doing this for decades (him, something like 5, me, something like 2) and not seen a single tantalum failure. My father used to see a lot of tantalum failures until he took the time to understand the failure conditions and derated the specs. But, this applies when the options are electrolytic or tantalum.
When the options are ceramic or tantalum, as you suggest with the fellow from Motorola, there's a huge difference. Ceramics are not available in value ranges that electrolytics can be manufactured in (in part because it's difficult to make a realllllllly thin sheet of ceramic, plate it on one side, and roll it up). Ceramics, for the same value range as tantalums, have superior specifications but larger physical size, as long as you stay away from the lower end of the quality spectrum. Comparing, however, the selection of tantalums over electrolytics against ceramics over tantalums is, well, like two different kinds of fruit.
In sum, given my druthers, in larger values, it's tantalum, unless the value range necessary or cost contstraints precludes them, in which case the choice is electrolytics. In smaller values/higher frequencies, it's ceramic.
Indeed, there was a *slew* (pun intended) of timing problems with the initial software to run the shuttles (does anyone else remember the frequency of early launches scrubbed due to software?). From my understanding, the bugs were traced to race conditions amongst the (then large) array of onboard and ground computers.
No need to be rude. I saw the upper figures and didn't manage to load the lower figures until a second viewing of the article after the first fellow replied with a little more tact.
But, then I suppose you didn't bother reading my reply to his comment before writing yours, now did you?
This was in production Lisp Machine system code for a long time. I don't recall what triggered the error, but I did manage to get it once on a TI Explorer (Texas Instrument's Lisp Machine):
Something really bad happened. See if RMS is in the building.
Since RMS was responsible for much of the system code, this kind of made sense. But it was in a commercial machine! And, yes, it meant *that* RMS.
That's not frost you see, but chip outlines silkscreened onto the board. These are used by manufacturers to ease asssembly (eg, capacitor C32 goes here, resistor R98 goes here, chip IC42 goes here, etc.).
In many European cultures (eg, Greek, whence I draw my experience), the proposal has no suprise gift involved, and for the duration of the engagement, the wedding rings are worn on the opposite hand for both partners. The rings are then swapped over as part of the wedding ceremony.
A number of my friends after hearing this were inspired to follow suit. As you might imagine, these people were not traditionalists in any sense of the word, but for them, it made more sense than throwing thousands of dollars into an easily stolen or lost diamond.
Slashdot Mirror
There was an HP Chimunk system at the MIT Lab for Computer Science which was running, along with its stacks of external SCSI hard drives, on a clearly over-loaded card table. The table collapsed while the disks were spinning (yes, while the disks were spinning) and the system came literaly crashing literaly to the ground.
Power off, clean up the mess, fix the table, reconnect all the wires, and power it on. Worked fine.
How about a manual method where one creates a ficticious bounce message from spam that has made it to the mailbox?
The idea is the following: spam gets through whatever filter you might have, but you still want to reject it, and given that some spammers MIGHT be trimming their lists based on bounces, you forge a bounce message from the spam.
Does anyone know if this is possible with, eg, RMail or VM (or something else) running under Emacs?
Having traversed from a predominantly engineering realm (computer science) to a predominantly scientific realm (neurobiology), my observations have been that the tools are selected mostly on habit or previous knowledge rather than fitness for use.
The most commonly-used analytical platform is probably Excel (or some similar tool like Statistica), but the more serious researchers, who are also the more mathematically-aware, nearly all use Matlab in my experience.
When efficiency is an issue, nearly everyone I've worked with turns either to IDL (a Matlab competitor that has more arcane syntax, but much higher processing speed) or writes a C/C++ program by taking algorithms from "Numerical Recipes in C".
Recently, I've also seen a rising use of Visual Basic, especially to do experimental control (although some Matlab hooks do exist for such), and, of course, LabView. Some diehards use LabView for data analysis as well, but their results are suspect just because the tool is so poorly fitted to the task.
And, of course, many data collection hardware manufacturers (CED, National Instruments, TDT, etc.) supply scripting languages to control their hardware and perform rudimentary and sometimes not-so-rudimentary calculations.
The best researchers select the most appropriate tool for the job, but, again in my experience, it seems the selection is normally based on previous experience and inertia. Those who know a particular tool well (eg, Excel, Matlab, SPSS, Mathematica) tend to keep using that tool, even if it is not well-suited. This means you get abberations like Matlab programs that control real-time experiments and LabView programs that do higher-order mathematics.
Why?
Because the largest fraction of a scientists' time should be spent on data collection, not experimental implementation, and the amount of time (for nearly all fields except those with astronomical amounts of data) spent executing code is dwarfed by the time developing it. Clearly this breaks down for certain applications, but most of the science currently being done (read: molecular biology, and no, not bioinformatics) is not algorithm-bound.
Since data analysis is such a huge, broad field, I expect to see radically different answers from other posters!
I would say it is better than that. I use a VIA C3 900 Mhz processor in a Shuttle small form factor PC (SV24) at home. It uses so little power that it does not require a CPU fan.
I have played with a nearly identical setup. Like you, my experience was that it was fine for run-of-the-mill use, and not-so-good for computationally intensive tasts, just like a 500-or-so MHz PIII would be. My original comment was based on various benchmarks which have been floating around since the C3 was introduced, the brunt of which is that the C3's main selling point of low power consumption comes at the expense of a significant amount of computational horsepower.
To wit, and echoing what a lot of other posters have said, better to spend a little more money and get a real laptop.
A 933 MHz C3 is approximately equivalent, in real-world horsepower, to a 550 MHz Pentium (on integer tasks, much worse for floating-point). The C3 is not a high-performance architecture, although it has been tweaked for very low power consumption.
This article brings to mind a major, but unnoticed fatal flaw in Regan's Star Wars program which sought to put killer sattelites in space to protect the American People: all an enemy needed to do to take said network out was launch a handful of rockets to the same orbit to explosively release simple payloads of (many) ball bearings. No cost-effective defense against it.
Also someone leaked a project going on at National Instruments that really lit up my interest in this.
As a previous poster has replied, LabView is in wide distribution. It's aimed at the scientific and engineering markets, and, like AutoCAD and similar products, allows the user to enter program descriptions either in graphical or textual form.
But, here's the kicker: every single heavy LabView user I know of (even the ones without extensive previous programming training or experience) drops the graphical interface in favor of the textual one. Further, I am familiar with one large project developed under LabView, and the opinion of the programmers involved was that it pretty much sucks eggs.
What's the point or relevance here? National Instruments (not to be confused with National Semiconductor) has put a lot of time and effort into developing a graphical language that seems *perfect* for capturing data-flow like algorithms, just the kind of thing you'd want to run on an FPGA, and they've pretty much failed. (People continue to use LabView because, for that community, there currently is little better that has such wide support.) The problem of programming interface for things like this is hard, mostly because our algorithms are by-and-large not stateless.
My favorite version of such things, is "MIT, a wholly-owned subsidiary of Cornell Engineering."
Had it on a T-shirt from my sister, who went to Cornell while I was at MIT.
That kind of tongue-in-cheek teasing is, like imitation, sincere flattery.
Caltech is a private university and not part of the UC system. To refer to it as "Cal Tech" or "CalTech" is not only wrong and misleading, but does a disservice to the people associated with that fine institution.
That said, I think the stuff happening there is very cool.
YES! This is a good observation, I too have seen ridiculously high line counts because of source code fragemented across many files. All because of the included headers 10,000 lines of code gets reported as 1,000,000!
W95 doesn't have *preemptive* multitasking: all multitasking depends on the cooperation of each process to yield unused cycles to the system.
I'm pretty sure (please corret me) that proper preemptive multitasking didn't appear until W2K
(at least in OSes from Redmond).
Hear, hear!
MythTV is a nice project which is nearing some significant milestones in terms of usability. Isaac Richards, the fellow behind the effort, is good at both architecting and writing software, and is very quick at fixing problems that people (enthusiasts, mainly) find.
The biggest problem is that the architecture is based around software codecs which requires reasonably hefty CPUs. Hefty CPUs (eg, Athlon 1800) need hefty fans and big boxes. Hefty fans make a lot of noise, and big boxes are, to my eye, far too large for audio/video equipment, and often (but not always) plain ugly.
Isaac has made it clear that he intends at some point to support hardware codecs, but the timeline for that is unclear, as it requires support in a number of other areas (eg, xvideo).
My assessment of the current state of MythTV is that it looks great, has a nice interface, does most of the things you would want a PVR to do (and the list of unsupported options is getting shorter and shorter by the day), but as no hard-and-fast guidelines about supported hardware have been established, getting it to work on your particular box can be a hassle (but, might not be, if you get lucky with choosing the right hardware; unfortunately, there isn't a good published list of the right hardware). Unfortunately, MythTV requires a large handful of other packages, and getting exactly the right versions of each can be frustrating at times. While the project has considerable promise, and I have every expectation that it will eventually be excellent, it isn't quite ready for prime time.
YES! This became one of my all-time favorite, ah, car chase scenes. There was tremendous hype about the chase in Bourne Identity, but, frankly, Bond's tank chase was hands-down better.
This, to reflect another poster's assertion, was using available materials -- ie, his wits -- to best advantage. Mr. Broccoli, et al, more intrigue and plot please; less action-hero stuff.
JWZ's Law Of Software Envelopment states that all programs expand until they can read mail.
That would have been originally formulated as, "all programs expand until they become Emacs," observed by many people over the years at MIT's LCS/AI labs.
Interesting. I don't normally use AVX components, but this discussion has motivated me to re-examine our assumptions about tantalum reliabilities. We have, however, as previously stated, not seen one fail with the 50% voltage derating.
Solid alumninum sounds very interesting -- hadn't heard of those caps. I'd agree that from basic principles, alumninum oxide should be *much* more stable than tantalum oxide.
You can't be serious! Tantalums are notoriusly flaky. Not only that, the usual failure mode is that the cap vanishes in a spectacular flash of purple fire. Every capacitor failure I've ever seen in computing equipment has been a tantalum. An engineer who used to work at Motorola told me that tantalums were banned from pager designs. At the time, Motorola would rather pay the premium for ceramic caps than risk tantalums.
He was serious, and so am I when I say that I routinely design with tantalums when I want high reliability, electrolytics when it doesn't matter as much. The fellow you mention from Motorola (and his associates) don't understand the problems with tantalums: they are extremely reliable, and have far superior specifications than equivalent electrolytics, if you simply derate the maximum voltage by a factor of 2. Eg, if your design calls for the capacitor seeing a maximum differential of 15V, specify a 30V capacitor.
My father, also an electrical engineer, and I have separately been doing this for decades (him, something like 5, me, something like 2) and not seen a single tantalum failure. My father used to see a lot of tantalum failures until he took the time to understand the failure conditions and derated the specs. But, this applies when the options are electrolytic or tantalum.
When the options are ceramic or tantalum, as you suggest with the fellow from Motorola, there's a huge difference. Ceramics are not available in value ranges that electrolytics can be manufactured in (in part because it's difficult to make a realllllllly thin sheet of ceramic, plate it on one side, and roll it up). Ceramics, for the same value range as tantalums, have superior specifications but larger physical size, as long as you stay away from the lower end of the quality spectrum. Comparing, however, the selection of tantalums over electrolytics against ceramics over tantalums is, well, like two different kinds of fruit.
In sum, given my druthers, in larger values, it's tantalum, unless the value range necessary or cost contstraints precludes them, in which case the choice is electrolytics. In smaller values/higher frequencies, it's ceramic.
Indeed, there was a *slew* (pun intended) of timing problems with the initial software to run the shuttles (does anyone else remember the frequency of early launches scrubbed due to software?). From my understanding, the bugs were traced to race conditions amongst the (then large) array of onboard and ground computers.
This was not a programming error, but rather a data entry error. Had the correct constants been used, the code would likely have worked flawlessly.
It was also a human controller issue, as the slowly accumulating error was ignored for a long time.
No need to be rude. I saw the upper figures and didn't manage to load the lower figures until a second viewing of the article after the first fellow replied with a little more tact.
But, then I suppose you didn't bother reading my reply to his comment before writing yours, now did you?
You're right. I hadn't been able to load the later images due to /. effect.
This was in production Lisp Machine system code for a long time. I don't recall what triggered the error, but I did manage to get it once on a TI Explorer (Texas Instrument's Lisp Machine):
Something really bad happened. See if RMS is in the building.
Since RMS was responsible for much of the system code, this kind of made sense. But it was in a commercial machine! And, yes, it meant *that* RMS.
That's not frost you see, but chip outlines silkscreened onto the board. These are used by manufacturers to ease asssembly (eg, capacitor C32 goes here, resistor R98 goes here, chip IC42 goes here, etc.).
Early 60s. It was, at that point, called ITS. ITS begat Multics, which begat Unix.
In many European cultures (eg, Greek, whence I draw my experience), the proposal has no suprise gift involved, and for the duration of the engagement, the wedding rings are worn on the opposite hand for both partners. The rings are then swapped over as part of the wedding ceremony.
A number of my friends after hearing this were inspired to follow suit. As you might imagine, these people were not traditionalists in any sense of the word, but for them, it made more sense than throwing thousands of dollars into an easily stolen or lost diamond.