Slashdot Mirror

"Professor Floating Point" argues (trolls?) that Java sucks for floating point, but you need to wade through his entertaining read to see what he says about precision and processors and flags and traps. This dude (you have to scroll down to the section on IEEE 754) takes the opposite view: the two dudes are Dole and Clinton on that stupid "60 Minutes" thing, but between the two of them you kind of get the picture.

The picture is that a lot of why Intel is slow is they are doing an arguably higher-quality floating point, and dude number 2 reinforces the view that Alphas and SPARCs and other RISCs do what dude number 1 says is cheap floating point because they don't want to be slowed down.

Check the two references out and you decide whether everything Intel does is really needed, but it is important to know that an Alpha is not just a better, cheaper, faster chip -- it does its floating point differently, and some people (or perhaps just Kahan, dude number 1) care a great deal about this.

Think of the 8087 as a vehicle with "off-road" capability -- yes, it is slower and guzzles more gas, but if you gotta go off road, you gotta have it.

Har har. :-)

Trust me, you don't want to see the names we came up with before this one. "Cooperative Bug Isolation Project" may not be catchy or clever, but it could have been a lot worse.

On the other hand, do we have a really spiffy logo.

I guess it is on a higher level than a core dump. Perhaps showing the programmer what buttons had been clicked recently and things like that?

It's not higher level so much as continuous instead of only-after-you-crash. The specific behaviors we measure are things like which way branches went, or whether functions returned negative/zero/positive values, or the relative sizes of two variables we guess might be related.

It's very low-level, down at the scale of individual source program statements and variables. And it's sampled randomly throughout program execution, instead of only being observed as a single snapshot in a post-mortem core file.

See the techie details on instrumentation schemes page for more information on the kind of measurements we take.

The short version is that we are looking for differences in program behavior between runs that succeed and runs that crash. If there's something the program only seems to do when it crashes, then that may lead us to the bug.

The approach combines techniques from program analysis and statistical machine learning. The program analysis side addresses how to insert instrumenation that can be sampled in a sparse, random, but fair way with very little overhead. The statistical machine learning side addresses how to find the few instrumentation "needles" in the big "haystack" of noise that are strongly predictive of failure.

The goal is similar to that of Mozilla's Talkback system: find and fix the bugs that happen most often to the most people. In fact we have met with the Mozilla Talkback team on several occasions to brainstorm and exchange perspectives. A key difference is that Talkback can only observe program state at the moment of failure, whereas we collect measurements continuously as the program runs.

That potentially gives us the ability to discover deeper bugs, including things like memory corruption where the point of failure can be distant from the point where the bad behavior really happened. In one of our papers we showed how we can isolate a previously unreported buffer overrun in bc by detecting an unusual loop iteration count correlated with program failure.

More detail that that will not, I'm afraid, fit in a reasonable Slashdot comment. See the project pages, and especially the "learn more" area for more info, including links to papers of varying length and technical depth.

The short version is that we are looking for differences in program behavior between runs that succeed and runs that crash. If there's something the program only seems to do when it crashes, then that may lead us to the bug.

The approach combines techniques from program analysis and statistical machine learning. The program analysis side addresses how to insert instrumenation that can be sampled in a sparse, random, but fair way with very little overhead. The statistical machine learning side addresses how to find the few instrumentation "needles" in the big "haystack" of noise that are strongly predictive of failure.

The goal is similar to that of Mozilla's Talkback system: find and fix the bugs that happen most often to the most people. In fact we have met with the Mozilla Talkback team on several occasions to brainstorm and exchange perspectives. A key difference is that Talkback can only observe program state at the moment of failure, whereas we collect measurements continuously as the program runs.

That potentially gives us the ability to discover deeper bugs, including things like memory corruption where the point of failure can be distant from the point where the bad behavior really happened. In one of our papers we showed how we can isolate a previously unreported buffer overrun in bc by detecting an unusual loop iteration count correlated with program failure.

More detail that that will not, I'm afraid, fit in a reasonable Slashdot comment. See the project pages, and especially the "learn more" area for more info, including links to papers of varying length and technical depth.

If you want to take Gnumeric 1.2.0 for a spin, consider participating in The Cooperative Bug Isolation Project, a research project being conducted at UC Berkeley. We have prebuilt Red Hat 9 packages of Gnumeric and several other popular applications. These binaries are built with extra feedback instrumentation that lets us understand how the software is working (or failing to work) in the hands of real users.

Even if you have never written a line of code in your life you can help make the software better for everyone simply by using our special bug-hunting feedback packages.

Read more about it or download and install today!

If you want to take Gnumeric 1.2.0 for a spin, consider participating in The Cooperative Bug Isolation Project, a research project being conducted at UC Berkeley. We have prebuilt Red Hat 9 packages of Gnumeric and several other popular applications. These binaries are built with extra feedback instrumentation that lets us understand how the software is working (or failing to work) in the hands of real users.

Even if you have never written a line of code in your life you can help make the software better for everyone simply by using our special bug-hunting feedback packages.

Read more about it or download and install today!

If you want to take Gnumeric 1.2.0 for a spin, consider participating in The Cooperative Bug Isolation Project, a research project being conducted at UC Berkeley. We have prebuilt Red Hat 9 packages of Gnumeric and several other popular applications. These binaries are built with extra feedback instrumentation that lets us understand how the software is working (or failing to work) in the hands of real users.

Even if you have never written a line of code in your life you can help make the software better for everyone simply by using our special bug-hunting feedback packages.

Read more about it or download and install today!

Oh c'mon! Do you realize that if everybody on a plane breathed really hard, it just might cause a CO2 buildup that would asphixiate the pilot? Do you really want to take that risk?

I can see a cellphone causing interference, maybe. They have antennas and they're designed to transmit and receive. Same with other wireless things, but a pocket dictionary? A gameboy? A PDA?

Just because something is electronic doesn't mean it is dangerous. Just do the math. At peak usage a Palm Pilot uses less than 200mW of power. If the thing is in your lap, it is at least 20cm from any sensitive wiring (and that's assuming there's sensitive wiring in the panel right next to you). Let's say that the sensitive area occupies an area of 10cm * 10cm. That means its area is 1/50th the area of the sphere centered at the palm pilot. Even if the unit isn't radiating uniformly, I can't imagine that 1/10th of its radiated energy would hit the critical area. Most of the energy in a palm would disappear as heat, but let's pretend that even 1/4 of it is radiated as RF energy. That would mean that this exposed critical area would be hit with a whopping 200mW * 1/4 * 1/10 = 5mW of energy. That's about 1/20th the power require to light a typical LED. And remember, this is a worst case calculation.

So tell me, do you really believe the sensitive electronics on a plane are disturbed by incident radiation that's 1/20th the power required to light an LED?

Your bit about the 100s of people doing it all at the same time might have some validity if they were all sharing the same seat. Then you could add up the individual radiations their PDAs caused. As it is though, each person is trying in vain to make their 5mW of power break the plane. I think the "breathing hard" bit is more likely to work.

• MIT's RAW project
  
• Berkeley's Garp architecture
  
• CMU's PipeWrench

• MIT's RAW project
  
• Berkeley's Garp architecture
  
• CMU's PipeWrench

To me, the Connection Machine range of supercomputers were the ultimate in blinkenlighten computing.

The Connection Machine CM-2 cube. Another picture.

Presently, there's the Connection Machine CM-5. Another image.

Yeah, poor ones.

In the future, you will probably just have to download BOINC for any of these projects

Check out Mike LaVella's pinstriped computer done by Dirty Donny.

I'm amazed that nobody has mentioned MOSS yet. It is mainly used for checking CS students' assignments for plagiarism, and does exactly what we want.

It preprocesses code first (actually it works on different languages, and even things other than code, by using different preprocessor plug-ins) then takes hashes and compares. It manages to detect almost all the things student do to try to cover up their copying.

Speaking of BSD, a better way of doing this comes from Berkley too. It's a program called Moss that is used by many universities to detect plagarism in CS classes. I know from firsthand experience that this is a very powerful program. Unlike the shredding technique, things like changing variable names won't affect the comparsion value Moss returns. It even does a pretty good job of noticing changes like replacing for loops with while loops.

One disadvantage it does have though is that it won't work with the MD5 checksums, although I'm a bit skeptical of how well that would work anyway.

check out this research project coming out of berkeley CAP

Drop in the code you are interested in and it will tell you where its found in a bunch of open source stuff, including the linux kernel.

It's ironic that the usual opt-out clause for American universities who don't want to participate in morally bankrupt government research is that they wish to protect their academic staff's right to publish freely. (Which is intself an important concern, but still... they're shutting themselves out from multi-million dollar contracts on the basis of ethics, which should be applauded.)

Berkeley, for instance, maintains very strict standards about the kind of research it will and won't get involved in.

That's what all those k-5 kids are gonna be looking like after your third sentence. Your daughter will likely also learn a new level of humiliation when the other kids start saying that you have the "boringest" job in the world.

An earlier post mentioned using Logo for a hands on demonstration which I think is a fantastic idea but, probably won't be very effective using a single laptop.

I think you would be better understood if you abstracted the subject, tremendously. I think that you would be better appreciated if you showed clips from familiar movies that used CG heavily and then explained, at a very high level, how programmers made it all happen.

Perhaps you could demonstrate a very simple animation of your own and then explain what goes into making it work. Then all the kids will think you are God and ask when you will have the next Shrek finished. Also, your daughter won't think she has the lamest Dad in the world. At least until she is 13 or so.

As a final note, see if you can arrange for or borrow a projector. 20+ kids gathered around a laptop makes of a lame presentation.

At UCB the campus wide network (not just the resnet) is on alert for infected machines. If one is found, it is denied access until a sysadmin comes out and cleans it. They've sent several warning messages prior to doing this. The news release is here

Wrong! ... Since an office file opener could be used to open your own documents, or documents that others want you to open, there exists a substantial non-infringing use, so the software would not be a circumvention device.

Yes, he is partly wrong, but so are you. It may be true that the circumvention device clauses are satisfied. Unfortunately, we don't have to look far to see how companies and projects that fit that exception are still prosecuted/persecuted and even killed.

This would be a good target for a bunch of SLAPP suits against the developers -- if they chose to implement it. The potential gain for Microsoft and others ("We bankrupted 30 contributers to OpenOffice for DMCA violations. We're sending you a DMCA notice. You wanna be bankrupt next?") far outweighs their potential cost ("We paid $250,000,000 in the cases we lost, but it's just an investment for product lock-in and extra FUD against developers.") .

Just being on the right side of the law does not mean that you will survive a massive legal attack from a multi-billion dollar company. Anti-SLAPP laws are in effect in most states but the DMCA altered the USC, which is the federal law, so those state laws could be carefully avoided.

Examples:

• DeCSS (multiple cases, some still in appeal)
• kazaa (in court and dying)
• napster (dead)
• CopyWrite (alive, after expensive years in court and an expensive appeal)
• Lessig about Fox fair use problems, MyMP3, Napster (in court & private settlements, dead, dead)
• DRM Conference transcrpt (discusses dead & dying, but legal, projects)
• Embedded fonts (alive, but at a big cost and avoidance of court)
• A student's paper with summaries of other cases (United States v. Sklyarov, Lexmark v. Static Control Components , Felton v. Recording Industry Ass'n of America) and several interesting hypothetical physical-world comparisons to the law (locking keys out of your car == loss of ownership of car until you present the Automobile Protection Assocaition with a proper court orders allowing you to jimmy the lock).

The unfortunate fact is that just because it is legal, and even if it is right, both StarOffice (Sun) and the contributors to OpenOffice (including Sun) could both face deadly lawsuits from Microsoft if they attempt compatability.

Strategic lawsuits (gray-area, predatory lawsuits), "death by lawsuit", and even Google's lists of Allegedly Unethical Firms, Corporate Accountability, and corporate criminals show how corporations are attacking and killing projects, even when the projects or public participation are the right and legal thing.

So while you are right that such a project would be legal, you are wrong in your implied statement that it would be a safe thing to do.

frob

You claim the Prius rides more smoothly than a traditional car, but I suspect your experience with cars is merely limited to low-end econoboxes. Try hopping into a decent mid-range Benz one day for a smooth ride.

The hybrid concept was not previously embraced because (1) people didn't care about that kind of thing (it doesn't come cheaply or easily), (2) the cars look awful; it is only recently that the national sense of style has been so stunted that the design of the Prius is considerd somewhat acceptable, and (3) the technology wasn't really up to the challenge until recently (in any affordably mass-producible sense). I would also question whether it's actually being "embraced" yet -- I'd say it is still something of a curiosity at best, although it is definitely gaining ground.

We don't have cars that drive themselves because this is a very complicated problem to solve. It may not seem like a hard problem to you because you probably spend too much time watching TV (an admittedly gratuitous conclusion I'm drawing at least partially based on your command of the written word). There are plenty of people doing real work on the problem (here and here are some examples).

Furthermore, "they" would be facing a mighty huge bill to "implement" these sensors you're dreaming up, and your statement that government involvement would somehow magically simplify everything only further detracts from the value of your commentary. The project you can read about here estimates 7.5 miles of highway will cost $200 million to rebuild with a sensor-based system, with 80% of that cost being borne by "them"... who are, of course, actually us, better known by the name "taxpayers".

Has anyone noticed that there is a profound difference between a one-person piloted aircraft and the Mentor thing that resembles a broken umbrella/dragon fly dragging a chinese lantern. Or even these things

I thought the article referred to the "Mentor" alfoil thing, not the small flapping one-man aeroplane. But I guess that makes me a slashdot rebel because I read the article?

Here's the results of a salary survey for recent EECS graduates (from 2001) at Berkeley. The average annual salary was $65,806, median $67,000. Granted most of these jobs were in California, but still this kind of money was REALLY not uncommon at the time. Keep in mind also that this was taken sometime during the year after these people graduated, long after March 2001 when the recession official began.

It's funny you mention celery. Celery naturally has caffeic acid, which is carcinogenic in rodents. You can find many other examples of foods that naturally contain known carcinogens here. Look for the lines hilited in blue. If you've never heard of such a thing, try googling the phrase "natural carcinogen" some time.

I do agree with you that we probably don't have much of a basis for productive discussion here.

anything that collects light also reflects it when observed properly

Really?

Not to say that there are black holes on Europa, but that all light collectors are not necessarily great reflectors. I'm imagining a surface akin to black felt. If designed properly, a material made of lots of very small surfaces (like felt) will never specularly reflect light in any preferential direction. This would make it very difficult to observe directly.

Challenge-response using a machine-unreadable image.

Loading arbItrary code from somewhere is a great way to leave flexibility in the system and also demonstrate destructive capability without actually having to resort to it. What does that have to do with spam?

The worm does definItely not create open relays - it can be used to create them through the backdoor it presents. The same backdoor can be used to run seti (hmm, there's a thought), delete files or any other annoying activity.

Yes, the payload download feature could be used for anything, including spam, but I find that hardly likely that a spammer is behind this for the reasons listed in the grandparent.

Occam's Razor is telling me that this article and the ones referenced by it are most likely unintentional FUD written by people that benefit from it (symantec et al sell anti-virus protection, while journalists sell papers, magazines or page impressions). While I wouldn't put it past Symantec and peers to intentionally spread FUD, I don't see journalists doing anything other than repeating what Symantec is publicising. Don't ascribe to malice what you can explain with incompetence. :-)

Occam's Razor also indicates that you'll have better chances in life if you brush up on your spelling. :-)

"gimp-console" is console based app thats not gtk dependent useful for running script-fu and other scripts, this should make "gimp" start faster since it would not be needed to start all the plugins as they would handled by gimp-console. you can a see a mention about it here also see ftcameron's flamingtext and cooltext have been using "gimp --console" from a very long time.

At UC Berkeley (home of Unix!), around May 1999, I was a teaching assistant for CS 61B (Introduction to Data Structures). The course was taught in Java (and before that, C). The UC Berkeley CS labs for introductory undergrad courses are all Unix (Solaris x86, HP-UX, DEC OSF/1).

The lecturer received a letter from a Microsoft rep with a proposition to switch to Microsoft technologies, offering all of the software that we could possibly want. It was, of course, immediately tossed into the recycling bin with some sort of remark containing the word "slimey."

And yet they haven't made a robot that can walk up walls like a gecko.

No, MIT haven't made a wall-walking gecko-robot yet, but Berkeley have, and so have DARPA.

Two words: Civil Disobedience

• Stanford Movement Publications (2002 and before) - especially Kathy Pullen's paper
  
• Motion Synthesis from Annotation
  
• SIGGRAPH 2002 Publications
  

Its interessting to reflect a bit on current technology when discussing "science fiction" like this.

Reseachers at Berkely have developed a single chip sensor node called the spec . Although this node lacks sensors, it clearly demonstrates the potential of the approach, even using existing technology and implements the basic platform for a sensor node in 5 mm (thats 2.379E-5 cubic furlongs for the metricly challenged). This node have very low power requirements and are capable of communication of more than 10 meter at 19kbps.

This year the ACM holds its first international conference on sensor systems, SenSys 2003. A number of problems will most likely be adressed by this conference, moving the sensor network research forward.

Personally I think the visions are quite viable. It is correct that power sources (esp. batteries) are a major trouble, but there are many sources to be investigated, and solutions will be found. The worst problem with sensor networks are probably privacy (you thought RFID's were bad? How about sensors that you can not see, that communicates encrypted on unknown random spread spectrums freqs?) - Vernor Vinge have written a couple of (science fiction) books, where sensor networks are used in ways that will be a bit scary to the average privacy-aware slashdot reader....

Come on, if you're going to write a worm, do it right.

I think it's pretty obvious that this was a test of a few things:

• It was a test of the encryption of the virus executable to see how hard it would be for anti-virus vendors and law enforcement to decipher it (conclusion: they've nearly got it hard enough; law enforcement still don't know exactly what it does).
• It was test of how many next-stage sites would be needed in order to ensure that they didn't all get shut down before they were needed (conclusion: 20 is enough (they only shut down 19), 30 would be plenty it seems)
• It was a test of how quickly it could spread just relying on user gulliability to get it in the door (conclusion: real quick, I've been seeing 1000+ copies (well, attempts) per day from some IPs, and more than 3000 copies (well, attempts) per day in total)

So next time (and the speculation seems to be next time will be the day after SoBig.F expires on 10 September) will presumably have learnt from the results of these tests.

Oh, and it wouldn't surprise me if next time is a Warhol Worm. I'm guessing they've collected up millions of zombies this time around.

So, yes, this time around it's easy to filter, and it's really only the useless virus notification and other bounce backs which are annoying.

Please do not send virus notifications for any worm or virus which is known to forge email addresses.

But don't expect it to be so easy next time.

Ewen

I'll tell you why it's important to me (and why I contributed Pudge's story in the first place). I am working to set up a Slashdot-site for use by the San Francisco Bay Area watershed and open space community. This will be the discussion side of an on-line GIS system to track environmental restoration and creek protection projects.

In addition, I will be setting up an archive to capture printed/digital publications, volunteer monitoring data, and project photographs. (Kinda like a SunSite, but not quite.) Anyone know anything about HDF/XML?

After becoming a devoted Slashdot reader over the past 3 years since OS X 10.0, I wouldn't think of using anything else to run the site.

I'm looking for a host that would be willing to house the site and help me get it configured, but I need to mirror the functionality from home. I'm brand new to Apache, mySQL, and perl, but am trying to learn fast. Eventually, I would like to see this whole project housed on an XServe co-located someplace else, but to start I want to run this all from my iMac. (Why the hell not, I say? Steve Jobs is no saint, but Apple seems to be doing a damn fine job brdiging the gap between the casual computer user and everything that is the command line.)

Suggestions are welcome here, or via email. Thanks!

PS: I may be straight, but I ain't narrow. Thank you to everyone on these lists that provides valid feedback (instead of recycled off-topic crap.)

Tangent, Go!

Obviously, you couldn't patent the invention of banging two rocks together, since our ancestors did it.

Sponges are the most primitive Metazoans (multicelled organisms.) All animal life is descended from one sort or another of Sponge.

Our closest single-celled relatives are little buggers called Choanoflagellates, by the way.

Did the particular sponges from which we are descended make this stuff, I wonder? Probably not, since they presumably lived in relatively shallow salt water before evolving into worms.

My suspicion, which is pure speculation, is that these sponges make the glass fibers enzymatically, at some stage or another. Of course any enzymatic process would be difficult (to say the least,) to duplicate.

More tangential! If the glass itself is somehow secreted, made by enzymes, it ought to be POLARISING glass - because all the copies of a given enzyme must have the same handedness. That strikes me as totally awesome, for some reason.

D00D F U!
BS CHEATER
etc.

The people playing online, with lots of exceptions, don't generally act like a bunch of intellectual notables. So the bit about 'community' is stretching things a bit.

But let's not forget the deep bonds which are inevitable when
"Mr. Sticky" throws a grenade at "The Crimson Warlord"

If that's the case, then the code is GPL-compatible after all!

Like rsync or xdelta, you mean?

xdelta's even BSD-licensed, so there's nothing to stop them integrating it today. But again, Microsoft's arrogance and NIH-attitude stops them from recognising that outsiders might just have solved problems years before they even recognised the problem.

--

Despite tales of English PhDs driving taxis and science PhDs endlessly bouncing from one postdoctoral position to another, a new survey by researchers at the University of California, Berkeley, finds that most of those who earn a PhD are relatively satisfied with their career 10 to 13 years later.

http://www.berkeley.edu/news/media/releases/99lega cy/9-2-1999.html

MHTGR?

Since I'm sure most of /. is more interested in coding a 1 square inch sensor than protecting a 300 foot tree, here's some programming background on the little bastards (which I work with on a daily basis, as part of a sensor network research group in a VA university).

- the architecture

The motes run 4MHz or 8MHz processors, with built in memory. The amount of memory varies across mote models (currently Rene, Rene2, Mica, Mica2, Mica2Dot, and SmartDust) but we're talking 16KB to 128KB of program memory, 4KB to 16KB of data memory, and 4Kb to 8KB EEPROM for permanent storage. They have a short range radio capable of I believe 10kbps, and use an active message model to provide what we know as "ports", so that you can direct a message to a specific handler based on its message type. The packet sizes top out at 36 bytes. The motes are powered by two AA batteries, which can last a surprisingly long time if the radio is put to sleep. Your main means for debugging: 3 LEDs ... you can begin to imagine the headaches I face on a daily basis.

- the bridge

When deployed, most motes are programmed with routing protocols to autonomously establish networks, which are used for data aggregation and getting sensor readings around. The network is rooted at a basestation, a "powerful" PC without the restricted computation, communication and power limitations of a mote. This way any complex processing is offloaded to the PC, and the motes don't waste battery power doing stuff the PC can do instead. So what bridges this mote network to a PC? Well, it's a programming board. You plug a mote directly into the thing, and you hook up a db-25 to your parallel port, and a db-9 to your serial port. The parallel port is used to program the mote's instruction memory, and the serial port is used to receive messages sent by the mote to the PC. The mote that's hooked up to the programming board is loaded with code to translate RF packets to UART, and vice versa.

- sensing

Motes are equipped with 10-bit resolution ADC sensors which can read light and temperature. Other sensor boards can be hooked up to motes to read vibration, acceleration, and a bunch of other stuff. The motes commonly read their sensors, stuff the data in a packet, and send it along to the basestation for processing. That's the generic application model, at least.

- security

The main part of our research deals directly with implementing security in the sensor networks. This is far from easy, since you can't even store a public/private key in the mote's limited memory, let alone do anything with it. The protocols used are complex, involving securely distributing keys, efficient authentication protocols, and all this in 16KB of program memory (on Rene2s) INCLUDING the operating system! Just remember that the point isn't to stop a mote from being compromised, it's to realize it's compromised and drop it from the network. There are supposed to be thousands of motes in the network after all, so dropping a bunch won't hurt.

---

Here's hoping that background will help avoid the mass privacy paranoia that we /. readers love so much. At the time of this writing, motes aren't small enough or cheap ($250) enough to produce en masse, nor are they tiny enough to go unnoticed (remember the 2 AA batteries?). Yes, there are exceptions, but 1 square inch are the smallest production versions I know of (Mica2dots). And until they stop running on batteries, their biggest hindrance is their short lifetime, so they currently can't be constantly monitoring anything for months on end.

Aside: Take a look at the Spec. It could change that whole last paragraph. :)

As for the military surveillance stuff, that's what motes are ultimately designed for, to be dropped on

Since I'm sure most of /. is more interested in coding a 1 square inch sensor than protecting a 300 foot tree, here's some programming background on the little bastards (which I work with on a daily basis, as part of a sensor network research group in a VA university).

- the architecture

The motes run 4MHz or 8MHz processors, with built in memory. The amount of memory varies across mote models (currently Rene, Rene2, Mica, Mica2, Mica2Dot, and SmartDust) but we're talking 16KB to 128KB of program memory, 4KB to 16KB of data memory, and 4Kb to 8KB EEPROM for permanent storage. They have a short range radio capable of I believe 10kbps, and use an active message model to provide what we know as "ports", so that you can direct a message to a specific handler based on its message type. The packet sizes top out at 36 bytes. The motes are powered by two AA batteries, which can last a surprisingly long time if the radio is put to sleep. Your main means for debugging: 3 LEDs ... you can begin to imagine the headaches I face on a daily basis.

- the bridge

When deployed, most motes are programmed with routing protocols to autonomously establish networks, which are used for data aggregation and getting sensor readings around. The network is rooted at a basestation, a "powerful" PC without the restricted computation, communication and power limitations of a mote. This way any complex processing is offloaded to the PC, and the motes don't waste battery power doing stuff the PC can do instead. So what bridges this mote network to a PC? Well, it's a programming board. You plug a mote directly into the thing, and you hook up a db-25 to your parallel port, and a db-9 to your serial port. The parallel port is used to program the mote's instruction memory, and the serial port is used to receive messages sent by the mote to the PC. The mote that's hooked up to the programming board is loaded with code to translate RF packets to UART, and vice versa.

- sensing

Motes are equipped with 10-bit resolution ADC sensors which can read light and temperature. Other sensor boards can be hooked up to motes to read vibration, acceleration, and a bunch of other stuff. The motes commonly read their sensors, stuff the data in a packet, and send it along to the basestation for processing. That's the generic application model, at least.

- security

The main part of our research deals directly with implementing security in the sensor networks. This is far from easy, since you can't even store a public/private key in the mote's limited memory, let alone do anything with it. The protocols used are complex, involving securely distributing keys, efficient authentication protocols, and all this in 16KB of program memory (on Rene2s) INCLUDING the operating system! Just remember that the point isn't to stop a mote from being compromised, it's to realize it's compromised and drop it from the network. There are supposed to be thousands of motes in the network after all, so dropping a bunch won't hurt.

---

Here's hoping that background will help avoid the mass privacy paranoia that we /. readers love so much. At the time of this writing, motes aren't small enough or cheap ($250) enough to produce en masse, nor are they tiny enough to go unnoticed (remember the 2 AA batteries?). Yes, there are exceptions, but 1 square inch are the smallest production versions I know of (Mica2dots). And until they stop running on batteries, their biggest hindrance is their short lifetime, so they currently can't be constantly monitoring anything for months on end.

Aside: Take a look at the Spec. It could change that whole last paragraph. :)

As for the military surveillance stuff, that's what motes are ultimately designed for, to be dropped on

... the ratio of win to lose ... is constant over a particular time period.

The world is full of phenomena that are unpredictable on an individual basis but highly predictable when you consider multiple events over time. This includes not only things like roulette wheels and slot machines (which are only "random" in a practical sense -- in principle you could predict individual spins with enough advance information) but quantum pheonoma, which underly everything that happens -- and which cannot be predicted even in principle. So the universe itself is fundamentally random, yet still manages to be full of predicatable events.

this seems the complement of the smart dust .
The smart dust was supposed to be a 1 cube mm sensor with some computational power that was also supposed to transmit signals. I also recall that it was supposed to cost very few $ (one?). Clearly, you do not need parachutes for it and you can just deploy thousands on the battlefield or whatever you want to spy on. I don't know if these can send such a strong signal, but I believe that if you deploy enough of them you could. And being much smaller and many thousands, they would be much harder to get rid of. However, I haven't heard of smart dust in a while. Maybe they have perfected it and started using it. Or maybe the project just died.

Yes but Unix code in general has been used as examples in operating system programming. One of the big problems SCO has is Unix has been around so long that core features of it have been used in many other places than Unix.

So here are some links with some history and the battle SCO has is to prove that the code they see in Linux didn't come from these sources instead of IBM because if it came from these sources there is nothing SCO gets.

Public Money, Private Code

Quote from above: In 1992, Berkeley released its version of Unix and TCP/IP to the public as open-source code, and the combination quickly became the backbone of a network so vast that people started to call it, simply, "the Internet"

Why Caldera Decided to Release Unix

From that article note that Caldera did release Unix source code on some version and again SCO has to defend against the chance that code came from this source. And though it appears in protected System V it was also present in the release V7 and V32.

Introducing the Caldera OpenLinux Workstation

From thie quote on the above:OpenLinux is Caldera's self-hosted source code Linux distribution that conforms to commercial software release procedures. OpenLinux is based on the most current stable open source technologies, but subjected to rigorous testing procedures similar to those used for proprietary operating systems. How can SCO clain they did not see infected code go into Linux if they had standards that if up to proprietary operating systems would include a check as such.

Berkley Lab Notes
My question here is if you follow the links on this page and understand the history of Unix and how it became freely released can anyone tell me what if anything was left propietary in Unix?????
And maybe that is a question SCO should be answering.

And really this needs to be explored in detail because what does System V have that BSD does not and how does the BSDi vs USL case affect the Unix propietary code.

I know this is redundant it has all been said before but the Q&A is right. Without SCO showing the code in question and that code be compared to so much of the Unix system that legally leaked into the world they have no case.

All of you saying there are easier ways to generate random numbers are missing the point.
I'm sure if you ask on sci.crypt.random-numbers you'd get a lot of faster, and cheaper answers,
or check out this page but how many of them would be cool?

Lavarnd wins hands down in the "Oh my god, why?" department,
although the smoke-alarm HRNG is pretty cool too.

-- this is not a .sig

All of you saying there are easier ways to generate random numbers are missing the point.
I'm sure if you ask on sci.crypt.random-numbers you'd get a lot of faster, and cheaper answers,
or check out this page but how many of them would be cool?

Lavarnd wins hands down in the "Oh my god, why?" department,
although the smoke-alarm HRNG is pretty cool too.

-- this is not a .sig