Slashdot Mirror

Is anyone else thinking about the movie Virus? Or is this the super army or robots anime has been warning us about for years. Maybe we should start considering the status of our own army of super robots. Some of the people I could find working on it are The Georgia Tech Mobile Robot Laboratory, The MIT Mobot Group, The University of Texas at Austin has a Robotics Research Group, and there is the Stanford Robotics Laboratory. All in all pretty dismal. you only have to go a few links down in a search result list to get to the Biped Robot Research in the World link. If you check it out you may notice, They are all in Japan. We are soooo gonna get our asses kicked. Even Robodex 2000, the world's first exhibition of "Robots as Partner" from November 24-26 is in Yokohama, Japan.

Companies have been building bipedal robots for years. The MIT Leg Lab has done a bunch.

What your comparison shows is merely that there are some pretty established ways of building humanoid robots: motors, communication, memory, and a pretty well publicized pathfinding algorithm.

Crying about stolen IP at this story is about the same as accusing Porsche of stealing Ford's IP about using four wheels to support an automobile.

These people need to realize that it is difficult/impossible to write salient things about the time period and culture that they live in. The best historical analysis comes from the generation produced after the period in question, because it is these people who understand what real effects the events of the past had on their present. There is an analogous argument for studies of culture and how it changes: people who exist outside the culture or after a major shift in their culture are the ones who will understand it best.

I predict that most, if not all, of these media writers will either be completely ignored by the next generation since the ideas of the writers turn out to be empty/obvious, or even worse, they will be parodied (like those "Popular Science" vinettes that amuse me so much, where 1950's announcers predicted the advent of the airborne car, and other ludicrous things).

It is exciting to have a medium which is a fusion of all existing media; a medium which allows communication to large groups of culture. It is exiting to have a medium which emphasizes non-linear thought. It would be foolish to assume that digital media will not have great impact on how we live life. However, I'm not optimistic that this is a time of media transition on par with the time after Gutenburg. There are some media prophets who do have a good handle on where their boundaries lie, and actually write some really good stuff (MIT department of Media Studies department chair Henry Jenkins, for example), but they are the exception to the norm. Internet writers need to rein themselves in and leave the real analysis to their children.

Wow, hadn't heard of the South Atlantic Anomaly before... Here's a great link about it: http://www.ll.mit.edu/ST/sbv/saa.html

Hope it survive's Slashdot's mungling.

I do research in this field; Honda's robot demo dates back to July, I believe. If you're interested, you can also check out MIT's project, or NASA's project.

In general, these humanoid robots are NOT meant for physical research: building legs, as cool as it is, is not a new thing. Instead, these are research PLATFORMS, designed to test new theories in artificial cognition. The thinking, quite simply, is thus: if we want a robot to act like a human, it has to perceive the world (and interact with it) as a human does. Therefore, you equip it with sensors akin to ours (eyes, ears, touch), program the drivers and such (so that the robot knows it CAN see, CAN hear, CAN touch), and then you teach the hell out of it. Fun stuff!

From their about page: "Let's face it: GNU/Linux is Unix." (4 paragraphs down after the bold) What a glaring error this is (anyone remember a little ditty that goes something like this: "GNU'S NOT UNIX"?!?) Linux is Linux, GNU is GNU (and most definitely not UNIX). Both are UNIX-like and arguably better, but definitely not the same.

Other than that (a rather large philosophical error in my opinion) the site looks very nice. A very valuable resource, I think. The best of luck to them.

A quick search on Altavista for xcmsdb.c gives the untarred X source code (delete spaces in the URL by hand otherwise it won't open. If only slashdot would fix that bug. If only more sites would keep the whole untarred X). Look in the datafiles sub-directory therein for examples (delete spaces in URL) of the data formats used to specify the forward and inverse color-correction matrices. You can load one of the example files onto the root window using xcmsdb sample2.doc. Check the data loaded ok using cmsdb -query

Calibrated color is now set up!

Specify all your colors for any X program in a device-independent color space like CIE XYZ, and you'll automatically get calibrated colors on the monitor (assuming your monitor matched the data in sample2.doc). The colors can be specified by command-line options or in X resource files. To use the example of the previous poster, try xterm -bg CIEXYZ:0.371298/0.201443/0.059418 &. Leave that xterm running in the background. Remove the calibration: xcmsdb -remove. Start another xterm as before, and notice the slightly different appearance of the background color: xterm -bg CIEXYZ:0.371298/0.201443/0.059418 &. Ignoring the hard part of creating the calibration data, that's a quick tour of color calibration in X!

A quick search on Altavista for xcmsdb.c gives the untarred X source code (delete spaces in the URL by hand otherwise it won't open. If only slashdot would fix that bug. If only more sites would keep the whole untarred X). Look in the datafiles sub-directory therein for examples (delete spaces in URL) of the data formats used to specify the forward and inverse color-correction matrices. You can load one of the example files onto the root window using xcmsdb sample2.doc. Check the data loaded ok using cmsdb -query

Calibrated color is now set up!

Specify all your colors for any X program in a device-independent color space like CIE XYZ, and you'll automatically get calibrated colors on the monitor (assuming your monitor matched the data in sample2.doc). The colors can be specified by command-line options or in X resource files. To use the example of the previous poster, try xterm -bg CIEXYZ:0.371298/0.201443/0.059418 &. Leave that xterm running in the background. Remove the calibration: xcmsdb -remove. Start another xterm as before, and notice the slightly different appearance of the background color: xterm -bg CIEXYZ:0.371298/0.201443/0.059418 &. Ignoring the hard part of creating the calibration data, that's a quick tour of color calibration in X!

... learn Common Lisp. Seriously. XML is really just S-expressions (in drag, with redundant, overblown syntax - see here; (sorry about the pdf)), so why not use a language designed for munging them?

Perl and XML don't really get along well, primarily because Perl and arbitrarily nested data structures don't really get along well (see here if you want a less biased, but still discouraging opinion).

Strangely enough, Java and XML aren't getting along as well as one would think, if this article on the JDOM project is any indication. Java also has the shifting sands problem - vendor-controlled standards are evil, no matter who the vendor is.

Common Lisp has an ANSI standard that hasn't changed since 1995, open-source multi-threaded web servers that you can add native code to on the fly (see AllegroServe or CL-HTTP) and a lot of other good stuff that I don't have time to list here.

MIT is currently working on project "Oxygen", which uses FPGA technology as its foundation. The FPGA project is called "RAW"

The idea as I understand it, is that as chip complexity increases, circuit pathways grow longer and longer, creating inefficiencies. So the folks at MIT have designed a repeatable CPU core (RAW project) that is highly parallel in nature and uses FPGA technology. As transistor density increases, more power can be added just as easy as new blocks can be added to Lego, because the design is modular.

Here's some URL's for y'all:

Scientific Article on Project Oxygen:
http://www.sciam.com/1999 /08 99issue/0899dertouzos.html

MIT's Oxygen website:
http://oxygen.lcs.mit.edu/

MIT's RAW website:
http://www.cag.lcs.mit.edu/raw/

One of the best documents on FPGA technology and it's existing state in the RAW/Oxygen projects is this PDF document:
ftp://ftp.cag.lcs.mit. edu /pub/raw/documents/RawSpec99.pdf

Enjoy!

MIT is currently working on project "Oxygen", which uses FPGA technology as its foundation. The FPGA project is called "RAW"

The idea as I understand it, is that as chip complexity increases, circuit pathways grow longer and longer, creating inefficiencies. So the folks at MIT have designed a repeatable CPU core (RAW project) that is highly parallel in nature and uses FPGA technology. As transistor density increases, more power can be added just as easy as new blocks can be added to Lego, because the design is modular.

Here's some URL's for y'all:

Scientific Article on Project Oxygen:
http://www.sciam.com/1999 /08 99issue/0899dertouzos.html

MIT's Oxygen website:
http://oxygen.lcs.mit.edu/

MIT's RAW website:
http://www.cag.lcs.mit.edu/raw/

One of the best documents on FPGA technology and it's existing state in the RAW/Oxygen projects is this PDF document:
ftp://ftp.cag.lcs.mit. edu /pub/raw/documents/RawSpec99.pdf

Enjoy!

MIT is currently working on project "Oxygen", which uses FPGA technology as its foundation. The FPGA project is called "RAW"

The idea as I understand it, is that as chip complexity increases, circuit pathways grow longer and longer, creating inefficiencies. So the folks at MIT have designed a repeatable CPU core (RAW project) that is highly parallel in nature and uses FPGA technology. As transistor density increases, more power can be added just as easy as new blocks can be added to Lego, because the design is modular.

Here's some URL's for y'all:

Scientific Article on Project Oxygen:
http://www.sciam.com/1999 /08 99issue/0899dertouzos.html

MIT's Oxygen website:
http://oxygen.lcs.mit.edu/

MIT's RAW website:
http://www.cag.lcs.mit.edu/raw/

One of the best documents on FPGA technology and it's existing state in the RAW/Oxygen projects is this PDF document:
ftp://ftp.cag.lcs.mit. edu /pub/raw/documents/RawSpec99.pdf

Enjoy!

I might even consider building a UFO from parts I can scrounge up from there.

One way to understand continuations is to look at how it's implemented. Check out the source code to one implementation of scheme, SCM. In effect it doesn't interpret continuations in scheme but implements continuations in C and then implements the scheme continuations using the C ones. The actual code works by deviously using setjmp, longjmp and messing with the stack but it's not that hard to understand (although it's a bit messy on architectures that have a non-contiguous stack). The last time I looked at this code was about 5 years ago so apologies if it's been reimplemented differently since then. Many years ago I used a similar implementation of continuations in C myself in order to implement a version of the very complex recursive pattern matching that Mathematica supports - in effect by using coroutines to generate streams of possible matches. At the time most people thought this was a gross solution to the problem but now I see that continuations are considered to be respectable I shall have to start using the method again.
--

Okay, for people who say that thinking is somewhat impossible for machines, I say this: Who's to say your not a machine? What, because you can think? What does it mean to think? You cannot describe in any detail how thinking works, because its unconcious! Therefore, if you were a machine, you wouldn't know it. This is a pretty gross summary of some of Marvin Minsky's theories on AI - You can read more by getting "Society of Mind" ISBN 0-671-65713-5 or by checking out his website at MIT where he teaches. Marvin Minsky's Home Page.

Sheesh, whatever happened to the hack for the sake of the hack? You need to read today's article in the New York Times on the MIT Media Lab.

-- Give him Head? Be a Beacon?

by Philip Greenspun (philg@mit.edu)

Submitted on: 2000-10-22

ArsDigita : ArsDigita Systems Journal : One article

Philip Greenspun founded ArsDigita Corporation and was its CEO from inception until it reached $20 million/year in revenue. Currently, he is Chairman of ArsDigita and teaches computer science at the Massachusetts Institute of Technology. Why an article on managing people? And one written by someone with training in computer science rather than business administration? There are thousands of books on the best ways to manage people. Many of these books are excellent, having been written by people who've devoted their lives to the discipline.

Software engineering is different.

Software engineering is different because only the best people significantly contribute to achievement. Traditional management texts assume a distribution of talent among the workers. Each worker is contributing something useful and the challenge is to get each one to perform at his or her maximum potential. In the same factory, the best worker may produce two or three times as much as the average, but all the workers are contributing. In software engineering a good programmer is at least 10 times more productive than an average programmer (Brooks 1995). If a product is being developed rapidly, the average programmers will consume nearly their entire work day just in reading and understanding the new code generated by the good programmers. Thus the challenges of a software engineering manager first and foremost are (1) creating a work environment where good programmers will be satisfied enough to stay, and (2) creating a system via which average programmers can become good. In an ideal software engineering organization, there are still some average-quality people but these should be viewed as being apprenticed to the best people and being taught as fast as possible.

Software engineering is different because people at all levels of the organization perceive themselves to be equally intelligent. Consensus-style management can perhaps work when there is a gradient of perceived ability. Given enough time, the less able workers will follow the lead of the more able workers. One of the paradoxes of software engineering is that people with bad ideas and low productivity often think of themselves as supremely capable. They are the last people whom one can expect to fall in line with a good strategy developed by someone else. As for the good programmers who are in fact supremely capable, there is no reason to expect consensus to form among them. Each programmer thinks his or her idea about what to build and how to build it is the best.

Software engineering is different because a leaf-node worker is more expert than any manager, even when the manager is a great engineer, in at least the small portion of the system that the leaf-node worker has personally built. This makes it difficult for a manager to engage in a technical argument with a worker. It becomes nearly impossible when the manager's technical skills are weak. The worker can spin castles of complexity in the air and come up with impressive-to-the-MBA excuses for why it has to be done a certain way or on a certain schedule.

Software engineering is different because the organization can't afford to lose the individual productivity of the best people by pushing them into management. A truly great programmer may generate 10 times as much business value as a merely good programmer. Can the organization afford to take someone who can do the work of 100 average programmers and push him or her into a pure management role? Probably not. Can the organization afford to put people with weak technical skills into management roles? Probably not. Once you give Joe MBA a title and ask him to coordinate eventually he will be making decisions that have engineering implications. Thus many of the best programmers are eventually forced at least to assume project leadership and mentoring responsibilites. Since they are still expected to produce designs, software, documentation, and journal articles, the danger is that the new manager will become glued to his or her screen and never look up to see how the project team is doing.

Software engineering is different because measurement is notoriously difficult. The world is full of products that failed due to overly complex and tasteless designs. Yet all of these designs were considered tasteful by their architects. Systems that experts evaluated and found wanting, such as the Unix operating system (1970), eventually proved to have great utility. It is a bit easier to count up the lines of code per day produced by a programmer but if the project was not very tightly specified originally, how do you know whether or not these lines of code are useful? At this point a skeptical reader might be thinking that, while software engineering is different from line production work or any other endeavor with a manufacturing division of labor, there are similarities with research and development, management consulting, and financial analysis. This is certainly true but there aren't too many interesting books on how to reliably produce results in these fields (one is referenced in the "More" section below). Ideas to Steal Software engineering is different but it is not that different. What ideas can we steal from the broader world?

• people don't do what they are told
• all performers get the right consequences every day
• small, immediate, certain consequences are better than large future uncertain ones
• positive reinforcement is more effective than negative reinforcement
• ownership leads to high productivity

people don't do what they are told In Bringing out the Best in People, Aubrey Daniels notes "If we always did what we were told, we would eat only nutritious foods, never drink too much alcohol, and exercise regularly." There is thus a natural limit on the effectiveness of written policies and management by telling then nagging.

A corollary to this principle is that people do what you reward them to do, not what you hope they will do. Often, when you look at what is truly rewarded in an organization, you find it is different than what you think is rewarded. Do the managers have an engineering background? If not, they'll probably be unable to perceive when a programmer is accomplishing nothing. So the programmer who does nothing gets a paycheck at the end of the month. Having thus been rewarded for doing nothing, the programmer tries it again the next month... all performers get the right consequences every day The natural way to manage is to spend time with people who aren't doing a good job. You help them out. You remind them of the good things that can happen to them if they finish a project or raise the spectre of their being laid off the next time the company needs to improve its profitability. These are probably the right consequences for someone who is underperforming. But what about the people who are performing? What if you ignore them day-to-day? Unless they are getting positive reinforcement from another source, they may stop coming in on the weekends to get a release out the door earlier, stop documenting their code, stop writing journal articles. A top performer won't sink to the level of a problem employee but that person may become average. And in the long run a company with average workers will at best earn an average return on equity. small, immediate, certain consequences are better than large, future, uncertain ones An annual review and bonus is not classically considered a very good way to motivate people. It is too far away, especially in a dotcom economy. Even if a worker is able to keep the bonus goal fixed in his or her head for the 365 days preceding the bonus allocation, there is uncertainty attached to it. What if the company is doing really badly at the end of the year? Will there still be a bonus? positive reinforcement is more effective than negative reinforcement Like most schools worldwide, MIT practices negative reinforcement at the undergraduate level. If student does not do a problem set by a certain deadline, we give him or her a bad grade. This has turned out to be extremely effective at ensuring that an MIT graduate has achieved some minimum standard. However, the students don't accomplish all that they could. The first term that we taught 6.916, we gave the students one week to do Problem Set 1. It was pretty tough and some of them worked all night the last two nights. Having watched them still at their terminals when we left the lab at 4:00 am, we wanted to be kinder and gentler the next semester. So we gave them two weeks to do the same homework assignment. The first week went by. The students were working on other classes, playing sports on the lawn, going out with friends. They didn't start working on the problem set until a few days before it was due and ended up in the lab all night just as before.

We thus proved the management adage that a deadline just gives someone an excuse to procrastinate and do nothing until the very end.

Graduate school at MIT is different. We want the students to do research, write up their results, publish them in journals, and graduate with a reasonably interesting PhD thesis. If a student finishes some research, the most effective faculty advisors immediately provide positive reinforcement by paying attention, helping design the next experiment, helping to draft a paper outline. If the student finishes a write-up, he or she is positively reinforced by being sent to a conference to present it. If the student finishes a PhD thesis, he or she is positively reinforced by being given a 3-7X pay raise.

The lesson from MIT? Negative reinforcement can work if the organization is extremely tightly managed, if the consequences are small and immediate (usually a problem set is due every week and only represents a part of the final grade), and if the goal is to make sure that everyone comes up to a reasonable level. However, the worldwide fame of MIT rests on research achievements by graduate students. This innovation is mostly supported by positive reinforcement. ownership leads to high productivity A related issue to positive/negative reinforcement is ownership. Non-ownership systems discipline those who are not working up to the minimum standard, but they do not offer enough of an upside to truly motivate people. Morever, non-ownership systems demand a very accurate setting of standards. Ownership-oriented systems include contingent rewards with an almost unlimited upside, and are thus effective at getting as much discretionary effort out of workers as possible.

As an example, in the early days of ArsDigita we had only a handful of customers: America Online, Environmental Defense Fund, Hewlett-Packard, Levi Strauss, Oracle Corporation, and Siemens. We had only a handful of programmers as well and hence the easiest way to divide the work was to give a programmer total responsibility for one project. The programmer owned that customer. If the project went well and the customer wrote us a big check, we gave nearly all of the money directly to the programmer. If any project had gone poorly and we'd been fired by a customer, we would not have had to think very hard to figure out who was responsible (fortunately this never happened while I was running the company!). People worked insanely hard to make their projects successful and their clients happy. More importantly, the programmer who did an entire project by him or herself learned enough to train new people, lead a larger project, etc.

After we grew beyond the 40-person mark, pressures to dilute the ownership aspects of our organization grew. We wanted to grow rapidly--nobody wants to buy enterprise software from a small company, even if the software happens to be open source. As our reputation grew, customers came to us with larger projects. We believed that many of our developers were too junior to handle complete responsibility for these large projects. Our costs went up because we had to coordinate the diffused responsibility. In the summer of 2000, when we had 200 or so employees, one of our clients was unhappy. It took a week just to arrange a meeting among the five managers who bore collective responsibility for the project! Meanwhile, individual productivity fell. It was taking more programmer-months and more calendar months to get things done. On weekend mornings you could walk naked through an entire floor of our headquarters building without fear of embarrassment.

(At the time of this writing, there is a proposal on the table to consolidate some of the separate management pyramids, thus taking us back closer to our original structure.) Building and keeping a good software engineering team What is the best way to attract some good software engineers to your organization? Hire a few to begin with. Good people like to work with other good people. This is true in every field but much more acute in software engineering. Why? Consider two management consultants working on different projects but within the same organization. If Consultant A does a bad job it harms Consultant B's reputation to some extent but does not require Consultant B to take any action. Whereas in most tech companies if Programmer A does a bad job it usually means that Programmer B will eventually be forced to use the bad code, read the bad code, and then fix the bad code.

What attracts good programmers? Traditionally the best programmers seek the most challenging problems. They want to work in an organization that is trying to build something important. Programmers have huge and fragile egos. If they are somehow assigned to a trivial problem and that is their only possible task, they may spend six months coming up with a bewildering architecture more complex than the Windows 2000 operating system, merely so that they can show their friends and colleagues what a tough nut they are trying to crack. Another source of ego-gratification for programmers is to have other programmers admiring their work. Open-source software projects thus have a big recruiting advantage over closed-source software companies.

What kind of working environment is necessary for programmer satisfaction? Good programmers want to achieve and therefore removing barriers to achievement is the most important step that one can take in creating an effective working environment. Programmers dread elaborate process, endless meetings, and layers of marketing approval before a product can be shipped. Ideally it would be possible to conceive a product on Friday evening, set up the development environment Friday night, write code on Saturday and Sunday, test on Sunday night, and ship on Monday morning. Maintaining this kind of freedom is a serious challenge as a company grows and its products become more complex. Successful companies such as Oracle Corporation burden their marketing departments with overlapping products rather than stifle programmer initiative. For example, during most of the late 1990s there were at least three different Web servers that you could buy from Oracle, each one backed up by a document explaining why it was the one true path toward database-backed Web site glory.

A good physical working environment is essential. Great programmers get a lot of positive reinforcement from their work itself. They write some code and immediately can see it dance. That keeps them at work for hours that, while they would not impress a taxi driver in Singapore or a factory worker in Guangzhou, will surprise many American business people. When we hired an architect to lay out the interior of ArsDigita's first building in Cambridge he surveyed the programmers and came back shaking his head: "I've never seen any group of people who spend so many hours continuously sitting at their desks."

From a business point of view, long hours by programmers are a key to profitability. A programmer probably needs to spend 25 hours per week getting coordinated with other programmers and comprehending the structures of the systems being extended. Thus a programmer who works 55 hours per week is twice as productive as one who works 40 hours per week. In The Mythical Man-Month, the only great book ever written on software engineering, Fred Brooks concludes that no software product should be designed by more than two people. He argues that a program designed by more than two people might be more complete but it will never be easy to understand because it will not be as consistent as something designed by fewer people. This means that if you want to follow the best practices of the industry in terms of design and architecture, the only way to improve speed to market is to have the same people working longer hours. Finally there is the common sense notion that the smaller the team the less management overhead. A product is going to get out the door much faster if it is built by 4 people working 70-hour weeks (180 productive programmer-hours per week, after subtracting for 25 hours of coordination and structure comprehension time) than if by 12 people working 40-hour weeks (the same net of 180 hours per week). The 12-person team will inevitably require additional managers and all-day meetings to stay coordinated.

Your business success will depend on the extent to which programmers essentially live at your office. For this to be a common choice, your office had better be nicer than the average programmer's home. There are two ways to achieve this result. One is to hire programmers who live in extremely shabby apartments. The other is to create a nice office. Microsoft understands this. In the early 1990s they did radio spots with John Cleese as a spokesman. One of the main points of the ad was to ridicule the cheap open-plan offices in which programmers were traditionally housed and promote the fact that at Microsoft each developer gets a plush personal office.

How can an office be nicer than one's home? Let's consider the following dimensions:

• social
• physical comfort
• aesthetic
• entertainment
• attractive

Social It is easy for an office to beat the home on the social dimension, especially if the programmer lives alone. If there are people at work at all times of day and night and you've succeeded in building an organization of good people, ipso facto there is always someone interesting to talk to at the office. To exploit fully the social possibilities of the programmers' office, it is important to have informal gathering spaces. At the MIT Artificial Intelligence Laboratory, which has nurtured groups of great programmers for nearly 40 years, the gathering spaces are referred to as "playrooms". These contain sofas and coffee tables, movable in the best tradition of Dewey, where programmers eat, talk, and occasionally listen to presentations. Usually a playroom will have some sort of shared writing surface such as a whiteboard. Note that these playrooms also are an important part of an organization's knowledge management system. You need to give programmers from different projects a place to meet where problems can be discussed and solutions from older/other projects can be suggested.

A social place will never be friendly if it is trapped behind a high wall of security. It ought to be very easy for a programmer to invite a friend over. If programmers are comfortable meeting their friends at the office it greatly increases the likelihood of friends recruiting friends.

An open office plan contributes to making the work environment stronger on the social dimension. Physical Comfort A programmer's work environment should be a supremely comfortable place to sit, look at information on a screen, and type. At ArsDigita we accomplish this via providing Aeron chairs, the keyboard of the programmer's choice, and at least two monitors. In the summer, the place should air-conditioned 24 hours per day, 7 days per week. In the winter, the office should be heated and humidified (often neglected). The air should be cleaned year-round with high-efficiency mechanical filters and electronic cleaners so that allergy sufferers are not discouraged from working.

One horrible mistake that we made was letting our architect design the workstations. Each programmer was given a 6'x2' desk, 12 square feet total. Two 21" monitors took up so much depth that there wasn't even room for a keyboard. Immediately we had to toss our monitors and get flat panels (cost about $400,000 extra). IBM had a better architect for its Santa Theresa facility: Gerald McCue. He found that each worker needed 100 square feet of dedicated space and 30 square feet of work surface. McCue also found that programmers needed noise isolation from enclosed offices or high partitions but personally we think this rule is worth breaking in a dotcom world where a team has to work fast and in sync. Better to manage noise by spreading desks apart a bit so that there are fewer programmers in a given area and therefore fewer conversations, fewer telephones, and more opportunities for sound to be absorbed before reaching someone's ear. Aesthetic Programmers don't have the same need for wood-paneled expensive plushness that, say, corporate lawyers or investment bankers might. However, the office has to be aesthetically satisfying or it will be tough for anyone to take seriously the idea that the company values aesthetic internal design of computer programs. Similarly, the office has to be finished and well-executed or nobody will believe that the organization is committed to finishing products. In the long run it is impossible for an organization to be excellent in one area and mediocre in all others. So the physical facilities have to look as though they were planned and decorated by someone with taste. Note that this need not be expensive. You could do it with $200 desks from Ikea and a consistent set of art posters on the walls. But an expensive facility with blank walls and boxes left over from the last move screams incompetence. Remember that the overall place has to look nicer than most of the programmers' houses. Entertainment It is easy to make an office more entertaining than the average person's home. Most people have a TV at home but they don't have friends with whom to watch it. Nor will they typically have the kind of big-screen equipment that is easy for a company to acquire. In the 1980s students at the MIT Media Lab would gather on quite a few nights to watch movies from analog laserdisks, presented with a very high quality projector. After the movie was over, they'd go back to their desks and work for a few hours, something that would not have happened if they'd gone out to the movies.

The average home cannot accomodate a pinball machine. An office can. The average home can have video games, which are very popular with young programmers, but not people with whom to play. The average home cannot have a grand piano but almost any office can. Attractive A worthwhile goal is to have at least one thing that is extremely attractive about the physical enivronment for any particular prospective software engineer. Here's a possible list:

• dog-friendly policy
• grand piano
• climbing wall
• indoor garden
• aquarium
• koi pond
• exercise room with fancy machines
• pinball machine

Not everyone has a dog. Not everyone can play the piano. Not everyone wants to practice rock climbing. But by having a long list in the same building, there is a good chance that at least one item will be very attractive to a particular person. If a person loves gardens, he or she can be seated at a desk within view of the garden. That person won't value the other items, perhaps, but another employee will. Change of Venue You can work on all of the preceding dimensions but there will come a day when a programmer gets restless. Sitting at exactly the same desk every day is tedious. We thought that we could solve this at ArsDigita by using the Internet and our branch offices. We'd encourage programmers from Cambridge to pick up and work at a spare desk in the Berkeley or Pasadena offices for a week or two. The idea did not catch on, however, because it turns out to be disruptive for one person on a team to disappear. One of the reasons we've found open-plan offices effective is that it helps to have one's team members close enough to look casually at what is on the screen.

What does it take to let the entire team pick up and work somewhere else for awhile? A beach house or a ski house within a two-hour drive of their main office. It is kind of expensive for an individual to rent a vacation house year-around, equip it with a DSL line or cable modem, and pack it with enough desks and computers for a team to work. But if you've got a group of 30 programmers and get a house large enough for 6 or so to sleep and work, the cost is manageable. In the winter, a programming team can disappear for a week, ski every morning and work all afternoon and evening. In the summer, a team can spend a week looking out at the ocean... while typing most of the time. It costs more than not having the beach house but a lot less than having employees go off on their own to have fun every weekend and not work. Turning average programmers into good programmers It is difficult to hire the most productive programmers in the world. Oftentimes these people are capable, by themselves, of turning out entire products, and thus they start their own companies. If a really productive programmer works for an established organization, that organization will usually take extreme steps to keep him or her. Thus beyond a certain point it is most effective for an organization to develop a strategy for creating good programmers internally.

How does one create a good programmer? Raw materials are important. You want someone with a strong computer science education, a high IQ, and an ability to communicate effectively in oral presentations and in writing. But without the right experience, such a person will never be more than an average quality programmer.

These principles are important in building up someone's programming skills:

1. A person won't become proficient at something until he or she has done it many times. In other words., if you want someone to be really good at building a software system, he or she will have to have built 10 or more systems of that type.
2. A person won't retain proficiency at a task unless he or she has at one time learned to perform that task very rapidly. Learning research demonstrates that the skills of people who become accurate but not fast deteriorate much sooner than the skills of people who become both accurate and fast.
3. Technology shifts force a programmer to go through bursts of learning every year or two.

Look around your organization. You can make a list of the people qualified to design and build a new system by counting up those who've built 10 or more similar systems in the past, at least two in the last year, and that could do the entire job in a month or two if they really had to. These are your "good programmers". Everyone else is a candidate to be turned into a good programmer as quickly as possible.

Learning to design and build software systems requires that the programmer design and build software systems. These can be smaller subprojects for internal or external customers, standalone software system for non-profit organizations, or demonstration systems to be written up and distributed to other programmers. A particularly effective option that is only available in the Web world is to build and launch a free public service. See http://remindme.arsdigita.com and http://towzone.arsdigita.com for examples of one-evening training projects.

Whatever the training task, the pace must be ruthlessly brisk. The learner should be expected to build at the same pace as an experienced developer. The difference between the learner and the wizard is that you expect the learner to make a lot of mistakes. The system as built may be awkward or not handle error cases properly. That's okay. Training research shows that if you get speed now you can get quality later. But if you don't get speed you will never get quality in the long run. We practice this technique in 6.916, Software Engineering for Web Applications, our course at MIT. Each student builds five database-backed Web applications during the 13-week semester. The first few that they build, during the course of the problem sets, are not necessarily elegant or optimal, but by the end of the semester they've become remarkably proficient, especially when you consider that each student is taking three or four other classes.

If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project. If you see one of your average programmers walking out the door at 6:00 pm, recognize that this person is not developing into a good programmer. An average programmer's productivity will never be significant in a group of good programmers. If you care about profits, you must either come up with a new training program for the person or figure out the best way to terminate his or her employment with your organization.

Still not convinced? Take a look at the Japanese "code factory" circa 1990. These precisely organized large organizations where each person had his role, however small, were supposed to overtake the American approach where small teams of craftsmen worked in a comparatively disorganized manner. The factory approach sometimes produces acceptable corporate IT solutions but for innovation and successful product development, the craft approach has been overwhelmingly vindicated. Turning good programmers into good managers As noted in the introduction, software engineering is different because the organization can't afford to lose the individual productivity of the best people as they are pushed into management. At ArsDigita, for example, a manager who is one or two levels up from the leaf nodes is still expected to write code, develop SQL data models, write system design documents, and write journal articles. Yet managers who are spending a portion of their time designing software or writing documentation are at risk of neglecting their duties to review subordinates' work.

The classic problem situation at ArsDigita is a manager getting lost in his or her own work and failing to review a subordinate's efforts for two or three months. When the review occurs, inevitably the subordinate has either been working on the wrong thing in the wrong way or hasn't been sufficiently productive. At this point the manager is really angry. Three months of calendar time and money have been wasted. But should the manager be angry with the employee? If the manager had reviewed the subordinate every week, the company would never have been at risk of losing more than one week of time and money.

Our solution is to decouple responsibility for review from responsibility for scheduling review. We use administrative assistants to ensure that each manager is scheduled to look at every subordinate's work at least once per week, more frequently in the case of junior employees. It has proven remarkably more effective when a neutral third-party is responsible for scheduling than when people with incentives to shirk are responsible for scheduling. Management by Consensus Considered Harmful Leaf-node engineers at every company on this planet think that they have better business ideas than the senior managers. Why not simply turn the company over to the engineers to run? Each engineer has a different set of better business ideas.

Software engineering companies will tend to have a fairly flat distribution of intelligence. The 22-year-old Stanford CS punk that was just hired will be just as smart as the 30-year-old lead engineer who will be just as smart as the 40-year-old CEO. Within a company's technical team, the raw IQ differences are even smaller. If each member of the team were playing the Bach Partitas and Sonatas for Solo Violin, the wrong notes, shaky intonation, and bad phrasing would make it pretty obvious to the novices that they needed to take advice from the experts. But because software quality is tough to measure and software quantity is seldom measured, the novices in a software engineering group are able to think of themselves as experts.

What would be wrong with a completely egalitarian software engineering group? Maybe the entire team really is at the same level of ability. And suppose that somehow the challenge of getting everyone to attack the same problem had been surmounted. Remember what Fred Brooks said in The Mythical Man-Month: high quality systems must be architected by no more than two people.

Getting design input from leaf-node engineers is important for having a good product design. But at the end of the day nobody should be confused as to who is providing leadership. There is an irreducible amount of Engineer A imposing his or her design on Engineer B. This can lead to some harsh-sounding words and bruised feelings. Microsoft is not the self-esteem company, at least if you believe Playboy magazine's interview with Bill Gates: "We hear you're brusque at times, that you won't hesitate to tell someone their idea is the stupidest thing you've ever heard. It's been called management by embarrassment challenging employees and even leaving some in tears." Truly elite organizations can be far worse than Microsoft. Ask a group of surgical interns and residents how much respect they get from the surgeons. Go into a world-class biology department and ask the grad students and post-docs about their treatment at the hands of the professors. Wherever You Go, There You Are Performance management textbooks will tell you that workers don't improve unless they get feedback. Joe Widgetmaker should get a nice chart, updated daily, of how many widgets he has produced personally each day, and how many have been built by his team.

Consider the average working programmer's life:

• surfing USENET
• surfing Slashdot
• reading docs
• questioning colleagues
• writing specs and designs
• writing docs
• writing code
• testing code
• fixing bugs
• filing bug reports on others' code
• attending meetings
• helping sales and marketing staff

(For comparison to the grad student life, see http://philip.greenspun.com/humor/graduate-student -emotion-check-list.)

Characterizing this person's productivity is going to require more than one number. But if we don't do it, days or weeks could slip by without the programmer realizing that his or her achievement levels are plummeting. In a company with disorganized or technically clueless managers, the programmer's supervisory chain won't notice the lack of achievement either.

Production of documentation and code is generally measurable by reference to the company's version control system. Bugs filed and fixed are easily tallied by looking at the company's ticket/bug tracking system (see http://www.arsdigita.com/doc/ticket for a description of our favorite open-source ticket/bug tracker). The softer stuff can still be quantified but it will have to be done by humans filling out forms.

Ideally the programmer will get daily feedback, which is kept private unless the individual elects to publicize it. Performance in each sanctioned area of activity will be marked up and scored with a weight. The programmer can then see if his or her crude achievement level is going up or down. Summary Building and managing a peak-performing software engineering organization is challenging but extremely profitable. The core Ariba product was written by two programmers, yielding a market capitalization of $30 billion. Microsoft Internet Explorer is a much better browser than Netscape Navigator and yet it was written by a much smaller team: only about 30 developers.

Start by attracting a good core team, perhaps by setting up an organization that enables each engineer to excel along the axes defined in http://www.arsdigita.com/asj/professionalism. Provide a productive working environment and a physical environment that is better than the average programmer's house. Provide daily positive reinforcement. Provide daily feedback showing the programmer more or less exactly what he or she has accomplished, plus a graph for the preceding few months showing the trend. Aim to install a feeling of ownership in each worker. More

• Bringing out the Best in People (Aubrey Daniels 1999; McGraw Hill). 200 pages containing 75 pages of good ideas plus the usual business book filler. But the ideas are genuinely good.
• The Mythical Man-Month (Fred Brooks 1995)
• Managing the Professional Service Firm (David Maister 1993). In terms of having an equal distribution of ability among all levels of the enterprise, the closest industry to software engineering is management consulting. Maister's work is a classic guide to success in this industry.
• Peopleware (Tom DeMarco and Timothy Lister 1999); page 98 is worth the price of admission, explaining that "the term unprofessional is often used to characterize surprising and threatening behavior. ... In a healthier organization culture, people are thought to be professional to the extent they are knowledgeable and competent." (See http://www.arsdigita.com/asj/professionalism for ArsDigita's independent conception of this idea.) Much of the rest of the book is a celebration of the 40-hour work week and the claim that "overtime" in the long run is never beneficial. If the authors were correct, Silicon Valley would be the poorest region of the nation, with Redmond, Washington the 2nd most impoverished. And Washington, DC would be our great source of innovation and productivity. Peopleware was probably written to help ensure success for internal corporate IT projects where there isn't any competition and delivering three months late won't change much.
• Making the Cisco Connection : The Story Behind the Real Internet Superpower (Bunnel et al 2000) -- shows how ignoring the "no overtime" admonitions in Peopleware can generate $400 billion in market cap.
• Parkinson's Law (C. Northcote Parkinson 1958) -- how management really works in the long run
• A Pattern Language (Christopher Alexander et al 1977) has very interesting things to say about physical space and social organization.

Reader's Comments

A corollary to this principle is that people do what you reward them to do, not what you hope they will do. Often, when you look at what is truly rewarded in an organization, you find it is different than what you think is rewarded.

This is illustrated by the classic business school article:

Kerr, S., 1975, "On the Folly of Rewarding A, While Hoping For B," Academy of Management Journal, Vol. 18, pp. 769-783.

It represents exactly what you are saying.

-- Tyler Pruett, October 30, 2000

Philip, your ideas on rewarding programmers are excellent. However, I don't believe number of hours worked defines a good developer. Programmers get older and have families. Saying that they have to log a certain number of hours in the office is stupid, almost like IBM counting programmer productivity in "K-Locks" (thousands of lines of code).
A good developer can often finish what an average one can do in half the time an average developer can - with less bugs and with better documentation.

A couple of good books on this topic include,
"Software Project Survival Guide by Steve McConnell"
(Somewhat dry - but good reference book)
First, Break All the Rules : What the World's Greatest Managers Do Differently
(Not one of the typical management books - this one has some actual research behind it.)
Microsoft Secrets : How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People
(A few good chapters worth reading)

-- Anthony Barker, November 1, 2000

Not to mention that programmers who are measured based on how late they stay at work will quickly figure out how to excel at staying late without being more productive (e.g. come in at 11:00 am).

This article reinforces many great ideas from Frederick Brooks but, unfortunately, regurgitates a few tired stereotypes. Most programmers that turn 30, get married, have a few kids (that go to bed at 7:00), may as well resign themselves to being put out to pasture.

Here's an idea. Instead of just assuming that it takes 25 hours a week for team coordination and build your management approach upon motivating programmers to work more hours, why not work to reduce the time it takes to coordinate through better management and more efficiency? Isn't that what management really is?

-- Tom Wilson, November 2, 2000

Dog-friendly offices may be great for dog owners / lovers, but aren't as wonderful for people with allergies or even those who just want to be able to concentrate on writing code without having a dog try to jump on their lap.

-- Kevin Scaldeferri, November 2, 2000

While you will find some of the bureucratization in these organizations that you find in government, you will also find people who would be sympathetic to open source. Being as these are well-establined outfits that regularly win contracts, these are good allies for the open source movement.

Now that I'm employed, I'm doing a pretty regular eecs job, but that's because I was kind of burned out on physics. In a year or two, I may see what is available.

But there really are a lot of overlaps, and not only in quantum computing/error correction/cryptography. Especially as frequencies get higher, linewidths get narrower, etc, understanding the physics gets more important just from a practical engineering point of view. There is a lot of research, eg, in the areas of nonlinear dynamics, where computer science and physics overlap heavily. Thinking about computation as a physical process can be useful, as can thinking about physical processes as computation.

Anyway, I would strongly recommend combining majors like this, or at least using elective classes to effectively learn what you need as the basis for graduate work or maybe even industry work in these areas. Undergrad programs tend to be heavy on the traditional fields, since a solid grounding is a good idea, but there is a lot of exciting interdisciplinary research going on. Check out the Physics and Media group at the MIT media lab for some examples and pointers to other research.

I think the last version of Extreme Linux was (searches for his Extreme Linux CD) is based on RedHat Linux 5.0 - it's a little out of date now - code has moved on considerably.

For you I would like to recommend some reading:

Building Linux Clusters by David HM Spector published by O'Reilly, (hmmm site seems to be down, come back later, or check Google cached version)

This book comes with a CD together with clustering software. It also comes with step-by-step instructions. I believe, however, that there are some errata, which means that some hacking will need to be done to get your cluster online.
It also goes through some aspects of choosing hardware etc...

A more in-depth resource, without step-by-step instructions, but with in-depth discussions on granularity of Beowulf systems and whether they are actually good for the tasks you have in hand is:
How to Build a Beowulf, A guide to the implementation and application of PC Clusters by the MIT Press

Also check the The Beowulf Project Site and the The Beowulf Underground Site

Have fun!
---

As for the parent post, ftp, if you use Kerberized ftp clients and servers, uses secure authentication, and can optionally encrypt the data. UNIX and Mac ftp clients are available, as well as UNIX ftp daemons. Recent RedHat distributions even come with MIT Kerberos V.

Check out http://web.mit.edu/kerberos/www

We use all these programs at my company (i'm the sysadmin), and they work very well.

-Ryan

Further information about the RFID tags and related technologies is available at the MIT Auto-ID Center homepage.

There's a program called fsv that looks similar and works just fine under Linux and Mesa.

-jfedor

Actually it is 1970. And it was invented by James T. Russell. But you are right, the CD wasn't even slightly popular until the late 80's.

A few handy quotes:

• "Like many audiophiles of the time, he was continually frustrated by the wear and tear suffered by his vinyl phonograph records."
• "He was also unsatisfied with their sound quality"
• "the final product imitated the phonographic disc which had been its inspiration"

Now that has to be the most interesting thing I've found today... I had always thought Philips/Magnavox and Sony invented the CD. But no, it wasn't even a company after all.

I am so sick of hearing about this majestic tetris hack, espescially since IT NEVER HAPPENED. The closest anyone can prove is a building VU meter, which was used for "one diminsional" tetris. Neat hack, but nowhere close to being really tetris played on a building.

This keeps showing up on slashdot, and it keeps getting shot down. See this story and search for tetris to read about the enormous difficulties of "building tetris" (I would provide a direct link to the appropriate comments, but they have been archived, and I don't want to just plagerize them).

Please, please, please, unless you can back something up with evidence (a link to pictures would be a start), quit spreading urban legends. We as geeks are supposed to be more skeptical than the general populous.

</rant>

Heck, even in "mainstream" American movies, there's sometimes a lot more violence/blood and nudity/sex than American media likes to claim there is in anime. For some generally interesting articles about anime, This Page is a good place to start. The author's views differ from mine in a few places, but its still mostly well-written.

Those who do not study Stallman are compelled to hear him repeat himself.
-- with apologies to Georges Santayana

If you don't want to listen to a recitation of dogma, you shouldn't ask the High Priest of Free Software how to make non-disclosure work with Open Source. You wouldn't ask the Pope how to reconcile Baal-worship with Catharism, would you? Tyberghein made the mistake of soliciting Stallman's opinion on the best way to comprimise with Evil without turning his back on Heresy. Of course Stallman responded by refusing to offer advice until Tyberghein renounced the Open Source heresy, and then replied with a sermon on Freedom.

Until people get it straight in their heads that Free Software is a religion, Stallman will always seem weird, dogmatic, and holier-than-thou. Once they do understand, "weird" will become "sacred", "dogmatic" a compliment, and "holier-than-thou" simply "holy". Likewise his antipathy for the schismatic Open Source Movement and it's Martin Luther, Eric Raymond. It will also then make perfect sense that Stallman is regarded by himself and his followers as the ultimate arbiter of Free-ness, and that he takes the clerical position of accepting donations while advocating poverty as a virtue. Like most religions, Free Software even has its lay evangelical arm, the League for Programming Freedom.

Tech Square is Stallman's cloister. Those who expect him to recognize terms like "console" and "PS2" ignore the Christian zealot's desire to be "in the world, but not of the world". Stallman knows about that which impinges upon his ascetic life as the chief prophet of software freedom. Like the most fervent and true practicers of monasticism, he is blissfully unaware of all else, and appears out of touch with reality to the world at large.

There's nothing wrong with religion. Like everything else, it has its place. And like most organized religions, Free Software is usually not well-understood outside of the priesthood. The lay preachers (those who write software but get paid to do so) tend to honor and in some cases revere the priests, but also tend to hold forth on scripture incorrectly. The Christian Bible is so full of contradictions and passages open to interpretation that the Roman Catholic church used to forbid its study outside the priesthood. At least Stallman asks his followers to read his works (see "What is Free Software?"), although he tends to reserve their interpretation to himself. Like most other religions in their infancy, Free Software lacks a category of simple adherents - the non-programmer software users in this case.

And perhaps that's the biggest reason for Stallman's hatred of Open Source. Those who are not practicing programmers are much more attracted to the heresy than to the mother church. Free Software is focused on software practitioners, and has no story to attract software users other than that they will benefit as a side-effect of having free practicioners loose in the world. Open Source focuses on the availability of quality software, and that interests users and programmers alike.

there has been some very interesting work in the past few years with regard to polymer gels which change physical properties drastically in response to small changes in environmental conditions such as temperature, ph, light, electrical/magnetic fields, solvents, and others.

in some cases, these changes may be a thousand fold increase in volume, or a change in viscosity from fluid to near solid.

In the words of one of theconference
The workshop [I organized] was designed to encourage programmers, systems architects, and usability experts to produce software which directly enhanced civil liberties. One proposal of mine, in particular, has garnered a lot of interest -- specifically, a project to replace the domain name system because of its current poor political properties, which encourage land-grabs, coercion, lawsuits, and other antisocial behavior. The replacement suggests, among other things, that a system in which all names are not guaranteed unique until further disambiguated might solve some of these problems, without (one hopes) insurmountable technical or sociologic problems taking their place.

In the words of one of the conference
The workshop [I organized] was designed to encourage programmers, systems architects, and usability experts to produce software which directly enhanced civil liberties. One proposal of mine, in particular, has garnered a lot of interest -- specifically, a project to replace the domain name system because of its current poor political properties, which encourage land-grabs, coercion, lawsuits, and other antisocial behavior. The replacement suggests, among other things, that a system in which all names are not guaranteed unique until further disambiguated might solve some of these problems, without (one hopes) insurmountable technical or sociologic problems taking their place.

Between C# and Java most of the developer mindshare for cross-platform server applications has been staked out. This language has to have a whole lot more going for it than simply being Open Source. It is battling incredible odds against entrenched languages/platforms, powerful companies with tons of research and development staff(Sun, MSFT, IBM, etc), several thousand developers, and the natural inertia that keeps people from trying anything new.

It seems to me from reading the page that their major claim to fame is that they are Open Source and as all those who have watched GNU Hurd development goes, being Open Source does not automatically imply mindshare.

PS: What the heck do they mean by the New Internet? Sounds like a rehash of every major Sun, MSFT, etc launch of the past few months/years.

Second Law of Blissful Ignorance

FN3. "Information superhighway" is a term initially popularized by then- Senator Al Gore. See Al Gore, Networking the Future: We Need a National "Superhighway" for Computer Information, WASH. POST, July 15, 1990, at B3.

I would post a link to the Washington Post Article, but their archives aren't free.

--

Artificial-reality pioneer Myron Krueger hinted to a "Kung-fu typewriter": You stand in an augmented environment. You type by throwing kicks and punchs to virtual or artificial keys.
It may not be very productive, but, if you currently spend 8 hours typing and 2 exercising to compensate the sedentary time, with this you could spend 10 hours kungfu-typing.

Great, this Krueger.
__

I bet these guys would be a shoo-in if they were eligible....

---------

Might not be what you're looking for, however...

Alan Cox posted this link to LKML a few months ago. It contains the early LKML posts, dating back to 1993. This prompted a post from tytso, who gave out this link to even earlier posts.

"quite apart from any threat of persecution, an advocate may believe her
ideas will be more persuasive if her readers are unaware of her
identity. Anonymity thereby provides a way for a writer who may be
personally unpopular to ensure that readers will not prejudge her
message simply because they do not like its proponent." Stevens
concluded "Under our Constitution, anonymous pamphleteering is not a
pernicious, fraudulent practice, but an honorable tradition of
advocacy and of dissent. Anonymity is a shield from the tyranny of
the majority. "

The obnoxious press licensing law of England, which was also
enforced on the Colonies was due in part to the knowledge that
exposure of the names of printers, writers and distributors would
lessen the circulation of literature critical of the government. The
old seditious libel cases in England show the lengths to which
government had to go to find out who was responsible for books that
were obnoxious to the rulers. John Lilburne was whipped, pilloried
and fined for refusing to answer questions designed to get evidence
to convict him or someone else for the secret distribution of books
in England. Two Puritan Ministers, John Penry and John Udal, were
sentenced to death on charges that they were responsible for writing,
printing or publishing books.

The main problem with this is not so much the health concerns (which there's no evidence for, as I understand it; I doubt it heats up your head more than a little exercise does). Rather, it's the 50% wasted power output by the cell phone.

In any case, before long this might be a moot point; there are various companies working on ways to tune the emission pattern so that most of the power is directed away from your head. (e.g. by using a phased antenna array, or by putting some sort of non-absorbing mirror like a photonic crystal on one side.)

;ht tp://hyperarchive.lcs.mit.edu/telecom-archives/TEL ECOM_Digest_Online/1238.html

true method by which the world will end...by all the evil in the world, black and evil....It is currently stored in a metal container, innocently labelled "Spam"

Slashdot story: World ends.
SPAM was cause of destruction.
Pork responsible.

Just my latest contribution to the world of spam haiku, and it's even on topic. Go me!

If you find this project interesting, you may want to also see THIS link which has details/schemas on many other Mech.Scanned clocks. None as neat and clean as Blick's - but nice nonetheless. Has a few projects with pretty large units - different formats/methods ect.. have a look.

Ive been putting off building a mechanically scanned clock like this for some time! I saw this page some time ago, Bob Blick's project is very neat and clean. I stumbled across it while researching about BEAM robotics. Meant to comment on the last story here on /. about the Home Robot. I dug up this link which is decidedly more hardcore an offering compared to the Pocket-Bot (scroll to very bottom of page) offered by Divent (though _Not_ the bot featured in the /. article - it is the other kit Divent apparently markets).



Hey Americans: Big Biz has bought your Democracy, are using your gov' and military to enslave you. Wake up. Free yourselves. Do the world a favour; Tell your friends/relatives/neighbours to:

This is probably scary enough to guard your house without being fully operational.

Look at the size of those things...(and you wonder where Lego gets its ideas)


- - - - - - - - -

I agree with you there, AC. One thing you brought up, using two displays for 3D, and as well as the price being cheap for small LCD displays:

Why aren't we seeing small, high-res, cheap LCD displays? Imagine a 1280 x 1024 display in a 1 inch display - what good would this do?

A lot, if you magnafied the image, to get a large FOV - use them in lightweight HMD's, for a 3D immersion that (should be) cheap.

It is said that the cost of high-res, large displays is due to the large "die" size of large LCDs, and getting high enough production yields with few flaws - hard to do with that size of a display. So, the solution would be to shrink the display, and wear it! Squeeze the rest of the laptop down to the size of a larger Walkman, add a twiddler (or a controller similar to this and a virtual keyboard), some kind of mouse - and you have an EXCELLENT product. And it should be cheap (one would think, since the LCD isn't the factor, now). Plus, it would consume less power, for longer battery life.

We could have this TODAY - but we are being denied it for some reason...

I support the EFF - do you?

(I took the liberty of cleaning up the spelling, and other nits ... :).

I guess that would be amusing, wearing computers with "touch" connectivity, then forming a human chain around an inner circle of cubicles around Christmas, singing, "O! Holy Quake, Nailgun Blight" while the wireless components shake Aibo robots about the office flashing their eyes red and green. (Can they do that? Would these folks have any input on this question?)

If anyone does this, please do make an MPEG2/4 of that and post an URL to it on Slashdot! I'd like to see that! 8^]

If you haven't been to one, you are missing out. You can get great deals on computer and electronics junk. Last time I was there I bought all the cables I needed at the time and a really nice case for my laptop and spent less than $30 total. Some people like to hang around towards the end of the day when vendors reduce their prices or give stuff away to get rid of it.

I wil be there manning the booth for my company. We have a ton of old equipment to get rid of. If you see a stack of 150 mac classics, stop by and say 'hi'!

They have wireless networking, speech recognition, and a thingie that brings up information based on context -- so when the guy is talking about a subject it will bring up information on what he is talking about.

Hi, I'm the grad student at Georgia Tech doing the "just-in-time information retrieval" based on speech.

I feel that I should give credit where it's due. While the work mentioned above is fun because I rigged it up to do speech recognition (yes, in an Emacs shell buffer), it's actually using Brad Rhodes's Remembrance Agent which has been around almost as long as wearable computers.

Take a look here to see some of the more current work going on in the Contextual Computing Group at Georgia Tech. (The page has only recently been put up so please forgive any dead links you find; they'll be fixed before the weekend).

--Ben

Sorry Roblimo, your 0-click patent is busted. I cite this Amazon spoof with its 'no-click[tm] ordering'.

http://www-tech.mit.edu/V119/N2/reg day .2n.html.

Apparently it used to draw crowds of a few hundred students.

Alas, the days when a nerd could be identified by his solder burns are long past. Aside from a few overclocking fanatics ($1000 worth of helium to squeeze out $100 worth of performance!), everybody seems to prefer to use off the shelf logic. Even MIT's famous robot-building competition seems to rely largely on pre-built components.

Nowadays "nerd" is more or less synonymous with "software nerd".

__________

You should check out FSV. It uses openGL to represent part of (or all) your filesystem. It uses volume to represent file/directory sizes. It's great for seeing where all that HD space goes.

--