Slashdot Mirror

There are several several groups who have published rulebooks. The end of game scoring is very strange, and each rulebook has a different system, so players of this game are advised to carefully determine which, if any, are correct.

... this page might help to explain...

It was Leonard Adleman (of RSA fame) who first proposed the idea of using DNA to perform simple computations in a 1994 paper entitled "Molecular computation of solutions to combinatorial problems" (you can find it here.

Adleman's DNA computer computed the answer to the Hamiltonian Path problem for a small graph. The Hamiltonian Path problem is solvable on a conventional computer, however it is an "NP-Complete" problem, which means that all known deterministic algorithims have a running time which is exponential with respect to the problem size.

Adleman's solution was to encode random paths through the graph in billions of DNA strands, then use custom engineered enzymes to eliminate those strands that were not a Hamiltonian path. Essenially, he simulated a non-deterministic machine through massive parallelism.

While this is increadibly clever, and very interesting, it isn't necissarily practical; at least, not for NP-complete problems. Adleman acheived linear execution time for an NP-complete problem, but he did so at the expense of requiring an exponential number of DNA strands with respect to his problem size. A small graph with only a few hundred nodes would require more strands of DNA than there are atoms in the universe.

This is not to say that DNA computers are of purely academic interest; Adleman's computer was merely a "proof of concept". I'm sure there exist problems in P which would benefit immensely from massively parallel computing. It's just a question of finding problems which are cost effective to implement.

Perhaps many of these "distributed" computing efforts that are underway now would better be served by a DNA computer.

There were no riots facing George Bush senior.

On the contrary, there were devastating riots in Los Angeles in late April, 1992.

Go to http://www.ict.usc.edu/disp.php?bd=proj_games_fsw for some screenshots and video.

It's shocking how much better the San Francisco Chronicle article is to the BBC article.

Clearly both writers had the same source to work with, but the sfgate article was much more researched, thought-out, and nicely tied together. Even when I had only read the BBC article, I was shocked at how poorly structured the article was.

If you're only going to read one of the two, read the sfgate piece.

Here is the abstract from the The American Society of Human Genetics article, and here is Stanford's press release on the story.

And are the web pages of Marcus W. Feldman and Noah Rosenberg From Rosenberg's research page, here is access to a PDF of the journal article.

Here is the abstract from the The American Society of Human Genetics article, and here is Stanford's press release on the story.

And are the web pages of Marcus W. Feldman and Noah Rosenberg From Rosenberg's research page, here is access to a PDF of the journal article.

Here is the abstract from the The American Society of Human Genetics article, and here is Stanford's press release on the story.

And are the web pages of Marcus W. Feldman and Noah Rosenberg From Rosenberg's research page, here is access to a PDF of the journal article.

The scariest thing here about this story is that both of these dim bulbs have law degrees. Are they giving degrees away when you get enough box tops!?

No, they're selling them for tons of cash, like they have for a long time. And please, don't tell me about people failing out. That only happens to the 'not fabulously wealthy.'

note: law school links just chosen at pseudorandom. Just making a point, not accusing any one school of being any worse than any other.

And a group of architecture students (including myself) did it to a computer lab around 2 years ago using Mister House. (Lot of other research into 3D viz technology and expiremental construction materials and techniques)

http://www-scf.usc.edu/~arch507

It wouldn't be too tough to implement :-)

A combination of NN based recognition coupled with Eigen vectors for a standardised dimension (for the pic) might just be able to do it ;-)

Its not rocketscience you know, just pr0n :-p

@( * O * )@

Biological anthropology is certainly an interesting topic. Craig Stanford wrote a book entitled The Hunting Apes that examines meat eating (primarily about its role social development), but which does map out what's known about diets of various primates, aboriginal societies, and historical extrapolations. Well worth checking out.

FWIW, it appears that for most of human history, meat consumption was much less common than caveman cartoons would have us believe.

Statistical analysis only works on linear systems.

For this and much more, you could also read the article by Chian et al., cited above by Watchful.Babbler, which is based on the well-known Volterra approach.

You'd be far, far better equipped than I to review their work (having just read the Neurocomputing paper, I could use an artificial hippocampus right about now!), but it seems that their "black box" modeling is limited to specific subprocesses, and rather than a static lookup table (as per the NS article), they've used nonparametric analysis to derive a set of functions to simulate the various processes in question.

That, at least, makes sense to me; I'm used to modeling things we don't really understand. Unfortunately, if their artificial brain works twice as well as my econometric models, their research project is doomed to a very short life.

The University of Southern California is starting a new video game design minor program. An article in the Daily Trojan (USC Student Newspaper) tells about one class. A syllabus can be found here.

~apok

The University of Southern California is starting a new video game design minor program. An article in the Daily Trojan (USC Student Newspaper) tells about one class. A syllabus can be found here.

~apok

I was first introduced to DNA computing by Leonard M. Adleman's article Molecular Computation of Solutions to Combinatorial Problems which describes using DNA computers to solve problems such as the notorious Traveling Salesman problem.

The basic idea is to coerce a ton of DNA into producing random potential solutions to the problem, and to then use chemical processes to select "good" solutions in mass. Since the space of possible solutions to Traveling Salesman problems of any reasonable size is tremendous (larger than the national debt expressed in pesos) DNA computing has an edge over traditional methods, because solutions are easy to generate and then weed out.

Unfortunately, this is really just a gigantic parallel processor - with each strand of DNA the memory of a processor induced by the chemical manipulations, and a small subset of useful algorithms are parallelizable (can be broken up into small "chunks" that can be computed independently and tied back for a larger result.

The immense benefit that this technology will have will be in fields like evolutionary computation. Evolutionary computation relies upon generating large populations of solutions, and then applying simple rules (which could be chemically encoded) to "improve" the generation, towards the pursuit of some ultimate goal. This could be training a neural network to predict coronary artery disease, or optimizing the design of a jet engine without tackling fluid dynamics - truly wondrous!

To understand all the hype, here is an article about how DNA computing works. DNA Computing, interestingly, was first proposed by Prof. Len Adleman (of RSA fame), who used it to solve the famous travelling salesman problem for seven cities. He encoded the cities in DNA such that only valid tours could react and form longer strands. The reaction was instant and presto - he had a solution (pun unintended ;)) in a gazillionth of a second.

Here is the bad news. The solution to the problems might be instant, but programmability and reading the output are still headaches. It is interesting to note that it took Adleman several days to read the answer even though the DNA computer "figured out" the answer in no time. But its a promising technology that would be refined in future no doubt.

-Dracken

• biography
  
  
• a study guide for Zarathustra
  
  
• an ecncylopedic reference in German and English
  
  
• secondary sources, all online
  
  
• original writings (English translations) and links to criticism
  
  
• Hypernietzsche (very advanced)
  
  
• Nietzsche listservs

And of course NASA uses old, proven technology like the Pentium.

Not so. RTV is a robot researcher who urges you not to build evil robots.

Not so. RTV is a robot researcher who urges you not to build evil robots.

P/S is used by research labs all over the world, as well as by several DARPA funded projects in the US. The program manager (an official agent of the Man) has always been extremely cool about the OS nature of the project. He immediately understood that by staying OS we could pool the resources of hundreds of researchers, most of whom were not being paid by DARPA, to solve a pressing need for network-friendly robot interfaces and re-usable code. A good deal for everyone.

Yet another poster who says that "they dont care". Obviously you DO care; do you think that by saying this you


I'm not saying at all that I don't care about this thread. Obviously, as you point out, I do, or I wouldn't have done that simulation. What I meant (at the bottom of the website I posted and which you quote) is that I don't care to spend more time on the simulation, because I didn't believe it necessary.


Proving that something can be faked doesnt make the original a lie; what it proves is that you are skilled at forgery,


I was not attempting to prove that it was a forgery, and I do not in fact believe it was a forgery. I suspect it is, most likely, an actual telescopic photograph taken by the satellite in question.

What I was attempting to demonstrate was that there wasn't enough information in their original image to form a conclusion about the nature of the object.

That the original was a very low-resolution image. In specific, that the bright white object seen is only 3 pixels wide and in reality is just a 4-pixel upside down "T" shape. In only looks like the classic UFO shape because of the "enhancement" they applied. The shape it was before ehnancement could have been a picture of anything: a star, a planet, a comet, a spacecraft, or a speck of dust on the lens.

My argument is that, based on only a few pixels of color and no other information, one cannot generally make a conclusion as to the nature of the object.


havent got either the brains or skills to do the REAL WORK that is needed to comb through this evidence to find out whats really going on.


While normally I wouldn't even respond to such an obvious troll, in this case I'll make an exception. I would be the first one to cheer in the case of confirmed evidence of extraterrestrials. My real work is, in fact, in astrobiology - the search for life on other worlds. It involves a great deal of "combing through the evidence" -- many years worth, and a whole lot of hard work. I work now at the California Institute of Techonology in collaboration with researchers at JPL and USC.

I just can't abide people who don't understand the scientific method and critical thought, and who believe a tiny amount of nonspecific, unconfirmed data like a three-pixel-wide image can prove anything.

Give me *real* evidence, say a few 300-pixel-wide image showing spacecraft structures, or parallax and spectrographic shift data demonstrating that this object is in our solar system but moving contrary to gravity (i.e. under thrust or other sort of propulsion), and get that data confirmed by a couple of independent laboratories, and you'll make a believer out of me. I want it to be true as much as you do.

In the meantime, I'll remain wary of charlatans who would capitalize on your naievete and fanatical desire for UFOs to be real in order to sell you CDs of "enhanced" pictures of what are probably random space rocks.

Bingo!

I did read the article. And it is true that people succeed without Going to fancy schools. In fact, success often comes (at least in America) from hard work. That's the american dream. And I agree with the intent of the article. Just because Harvard or (in slashdot land ) Cal tech rejected you and you had to go to Cal State Northridge, does not mean you will be a failure (far from it).

Now, the article did not argue that university is useless, or that the best schools are bad. But there are those in this thread who seem to think because famous person x did not graduate from college, therefore a college degree is useless. This is just absurd.

I have a degree in film production from the school that rejected spielberg. I am also a worthless film director. My student films are incoherent crap. I heard, over and over again from the people that didn't get in the story of Spielberg's rejection. It is always cited as proof that school is a waste of time, the USC production program is stupid, etc. I asked my advisor about the Spielberg effect. He told me that that's what USC film uses to describe people who insist on measuring their success against the wunderkind like Spielberg. The fact was that Spielberg was rejected because USC cinema had nothing to offer him. He was already a talented film maker. He didn't want to learn the craft, he wanted to direct films. Film school would have done nothing for him.

I am obviously biased. But I am very glad I went to school and got an expensive degree. It was worth every penny, not because it put me in a position to be a super successful and famous film director. You can't teach that. But you can teach the sort of universal skills that I use every day in my work. School was useful for me. I specialized in cinematography and also did a lot of computer graphics learning on the side. I had a chance to learn from some amazing teachers(and some bad ones too of course). I got my hands on equipment you can't just play with on your own. And I got to learn the way things are done and why, instead of having to go out and screw up on my own. I was very prepared for my career. (I work as a 3d artist) A one semester cinematography course from Woody Omens was worth the price of admission.

Universities are not designed to create the super succesful. Those people are not created, they are born. Universities are intended to teach people a broad range of information, to create well rounded individuals capable of success in any aspect of their future careers. In school I learned to speak french, the history of japan and how to draw. I also learned the basics of editing, cinematography, animation, sound, direction and acting. I am terrible film director. I don't feel bad about that. I am not going to be Steven Spielberg. Nor am I going to be Hemingway or Nabokov. University is not for the geniuses. Its for the rest of us. So put it to rest. Just because people who don't go to university are succesful does not mean that universities are useless. If people that didn't go to high school learned algebra on their own, would you claim that Universities offer nothing? No, a degree is not necessarily an indicator of future performance. But it will often be useful to YOU in your career.

H0re of them all?

Actually, I've never done this. But on the (off) chance you guys /. his server, here's a mirror.

http://www-scf.usc.edu/~skoonce/ogg_mirror/

The device they are using seems to be the Phantom by SensAble Tecnologies (product page). I used one of these a few weeks ago at USC's Integrated Media Systems Cetner, they're pretty cool. If you are interested in this kind of thing, the field is called "haptics," from the greek "to touch."

Actually we do have a lot of 2D tools available, if not exactly pre-press tools. Many of them were originally developed under Unix and Xlib rather than using the Gtk or Qt toolkits, so aren't part of either of the "standard" Linux desktops (although are certainly usable with same). Some of them are under oddball licenses (eg 'tgif' has free-as-in-beer and QPL type licenses).

Examples: tgif, xfig, pstoedit, gnuplot, xgraph, fig2java, xv, and so on. I find tgif useful for laying out EPS and PS files (you can draw and edit too), xfig is a nice general vector draw tool.

Actually, what the article is referring to is the Nation of Islam group - not Islam in general. If you're not familiar with the Nation of Islam you can find more information here.

That's right children, remember the REAL USC is in California!

There is some other fake institution that uses those letters, but they are a sad, pathetic school that is barely a shadow of the REAL USC!*

*This post written by a thru-and-thru Clemson student, and all those that know that USC is a school in California!

(Before you mod me into troll/flamebait heaven, consider that I am taking on issues of race and cultural history and talking about such things is hard to do without offending...)

Harlem in the 1930s was a flourshing center of art, culture, literature, and music. The boom period known as the Harlem Renaissance is unparalleled in American history with perhaps the exception of the late 1960s, also known as the Countercultural Revolution. The Harlem Renaissance inspired poets such as Gwendolyn Brooks and Langston Hughes, musicians the likes of Charlie Parker and Dizzy Gillespie, novelists such as Zora Neale Hurston and Ralph Ellison, and painters like Jacob Lawrence.

Art Deco, the style of art and architecture that exalts urbanism and the modernist avant-garde, flourished during this time, undoubtedly due to the broad sex appeal of jazz, an African-American musical form.

The amazing part about the Harlem Renaissance is that this is period of cultural growth during one of the most abysmal periods in economic history, a period so awful it is named "The Great Depression." You may not know a damn thing about niggers, but you should know that like the Founding Fathers of the United States, they know how to survive when things are tough. But more importantly, they know how to survive with style.

Niggers also have quite a bit in common with geeks. They are despised for their gifts and feared for their power. "Beautiful people" commit violence upon blacks and geeks and laugh about it. Now, imagine being a black geek (reading at -1) and coming to this thread.

It's now 2002, and the systematic (if unorganized) oppression and rejection of African Americans as "niggers" and "shit" is as strong as ever. In the early part of the twentieth century, groups of European-Americans killed blacks with impunity. Blacks were lynched and the KKK was scapegoated for America's racial hatred. I'm not saying the KKK were not guilty, but they were singled out, while everyday forms of racism survive unscathed.

Slashdot is one of my favorite webites. But I've never for a second doubted that some of my fellow /.'ers are racists. Now I have the proof. But I also know many /.'ers really don't have a lot to say about race, and the silence is deafening. So I thought in addition to those moderators who are on the job that I'd send out a few tendrils and try to turn up the signal to noise ratio, FWIW.

Luke: You were in the Crypto Wars?

Schneier: I was once an RSA Knight like your father. He was the best Composite Factorer in the whole galaxy... I see you have written programs that factor large numbers yourself. He was a good friend. Before the Dark Times, before The Empire.

Luke:What happened to my father?

Schneier:A young RSA Knight by the name of Len Adleman betrayed and murdered your father. Adleman was seduced by the Dark Side of the Force

Luke: You were in the Crypto Wars?

Schneier: I was once an RSA Knight like your father. He was the best Composite Factorer in the whole galaxy... I see you have written programs that factor large numbers yourself. He was a good friend. Before the Dark Times, before The Empire.

Luke:What happened to my father?

Schneier:A young RSA Knight by the name of Len Adleman betrayed and murdered your father. Adleman was seduced by the Dark Side of the Force

For instance, if somebody drew a mustache on Mona Lisa prints, and sold those, you could raise an entire generation of folks who threw out what was good about the Mona Lisa because Leonardo's mustache drawing abilities were clearly sub-par.)

What if you editted the moustache off of Marcel Duchamp's DaDa masterpiece L.H.O.O.Q? And can Duchamp's estate sue warhol's over his L.H.O.O.Q?

• We are investigating the use of aggressive behaviour to improve the efficiency of robot teams; this paper presents our initial simulation experiments. Our eventual goal is to demonstrate these methods running on real robots, so we have tried to keep the simulations and controllers realistic and as easy to transfer to the real world as possible. We demonstrate that a simple stylised fighting behaviour improves the overall performance of our system by reducing interference. We then discuss the (non)usefulness of social dominance hierarchies and suggest ways to improve overall efficiency.

Experience with the HelpMate hospital delivery robot indicated that a bit of pushyness was needed, or the robot would be stalled by people standing and talking in corridors.

This is, as far as I know, a result not anticipated in science fiction.

James Madison did: info here

This is something that bothers me more and more about film. Our eyes and ears have been wired into our brains since we had them. We are programmed to interpret and respond to this kind of stimulus at a very basic level, the ancient core of our brains. Visual and aural stimulation and response in a human kernal module.

Sitting in the middle row in a theater watching fiction is not like reading a book. For most low-level purposes it is real. The information in the film hasn't been processed by the concious mind at all. It is entertainment beemed broadband into the brainstem. Its a lot more like dreaming than reading, you very rarely need to think at all, even when watching fairly "heady" cinema. I don't know if there is research on this, but I think watching a film is very like dreaming. Notice also that the experience is designed to exclude any non-film stimuli, other sounds, images, etc. While in a cinema your entire world becomes that film. (I first noticed this was after seeing Event Horizonthe second time at home. On a small screen, where the film doesn't take over your mind its really just stupid crap. In the cinema it was a terrifying experience that left me emotionaly scarred for weeks)

What sort of long term effect on us and on society does film have? How often should we allow Hollywood to have root access to our brains?

Disclosure: I have a BA in cinema production from an accredited university. This means I have an seen way to many movies, know too much about them, and have a keenly developed ability to spout pages and pages of complete, total BS film theory nonsense....so what I say here should definetly be taken with a grain of salt

SHIT COCK! You're a FUCKING DUMBASS. I mean, FUCKING ASS DICK, that's the lamest anti-MS thing I've ever heard. FUCK SHIT.

Shit, this deserves the Serrano award for sheer ASS FUCKING RETARDATION.

The Cambridge is what drew me online.

We got these cool computers at school which had this cool thing called html... then I found things like telnet and wow! (before then I had only used lame AOL at my friends house-it was fun, but not functional)

Then I could finger coke machines and it was great... I knew we had to get on the internet at home! Of course then it didn't take long to browse all Yahoo! had to offer and I was on-line at a blazing 9600 baud.

Connected devices have always been my favorite things, and it's what I've used to this day to get people excited about the internet.

But, I think this is the coolest thing I've seen (text version) besides this.

I was addicted to my garden!

And on an ironic side note, USC's mascot is "Tommy Trojan"

Another possible reason why it is the only non-top level domain included.

The ``physical source lines of code'' (physical SLOC) measure was used as the primary measure of SLOC in this paper. Less formally, a physical SLOC in this paper is a line with something other than comments and whitespace (tabs and spaces). More specifically, physical SLOC is defined as follows: ``a physical source line of code is a line ending in a newline or end-of-file marker, and which contains at least one non-whitespace non-comment character.'' Comment delimiters (characters other than newlines starting and ending a comment) were considered comment characters. Data lines only including whitespace (e.g., lines with only tabs and spaces in multiline strings) were not included.

Note that the ``logical'' SLOC is not the primary measure used here; one example of a logical SLOC measure would be the ``count of all terminating semicolons in a C file.'' The ``physical'' SLOC was chosen instead of the ``logical'' SLOC because there were so many different languages that needed to be measured. I had trouble getting freely-available tools to work on this scale, and the non-free tools were too expensive for my budget (nor is it certain that they would have fared any better). Since I had to develop my own tools, I chose a measure that is much easier to implement. Park [1992] actually recommends the use of the physical SLOC measure (as a minimum), for this and other reasons. There are disadvantages to the ``physical'' SLOC measure. In particular, physical SLOC measures are sensitive to how the code is formatted. However, logical SLOC measures have problems too. First, as noted, implementing tools to measure logical SLOC is more difficult, requiring more sophisticated analysis of the code. Also, there are many different possible logical SLOC measures, requiring even more careful definition. Finally, a logical SLOC measure must be redefined for every language being measured, making inter-language comparisons more difficult. For more information on measuring software size, including the issues and decisions that must be made, see Kalb [1990], Kalb [1996], and Park [1992].

Note that this required that every file be categorized by language type (so that the correct syntax for comments, strings, and so on could be applied). Also, automatically generated files had to be detected and ignored. Thankfully, my tool ``sloccount'' does this automatically. 2.3 Estimation Models

This decision to use physical SLOC also implied that for an effort estimator I needed to use the original COCOMO cost and effort estimation model (see Boehm [1981]), rather than the newer ``COCOMO II'' model. This is simply because COCOMO II requires logical SLOC as an input instead of physical SLOC.

Basic COCOMO is designed to estimate the time from product design (after plans and requirements have been developed) through detailed design, code, unit test, and integration testing. Note that plans and requirement development are not included. COCOMO is designed to include management overhead and the creation of documentation (e.g., user manuals) as well as the code itself. Again, see Boehm [1981] for a more detailed description of the model's assumptions. Of particular note, basic COCOMO does not include the time to develop translations to other human languages (of documentation, data, and program messages) nor fonts.

There is reason to believe that these models, while imperfect, are still valid for estimating effort in open source / free software projects. Although many open source programs don't need management of human resources, they still require technical management, infrastructure maintenance, and so on. Design documentation is captured less formally in open source projects, but it's often captured by necessity because open source projects tend to have many developers separated geographically. Clearly, the systems must still be programmed. Testing is still done, although as with many of today's proprietary programs, a good deal of testing is done through alpha and beta releases. In addition, quality is enhanced in many open source projects through peer review of submitted code. The estimates may be lower than the actual values because they don't include estimates of human language translations and fonts.

Each software source code package, once uncompressed, produced zero or more ``build directories'' of source code. Some packages do not actually contain source code (e.g., they only contain configuration information), and some packages are collections of multiple separate pieces (each in different build directories), but in most cases each package uncompresses into a single build directory containing the source code for that package. Each build directory had its effort estimation computed separately; the efforts of each were then totalled. This approach assumes that each build directory was developed essentially separately from the others, which in nearly all cases is quite accurate. This approach slightly underestimates the actual effort in the rare cases where the development of the code in separate build directories are actually highly interrelated; this effect is not expected to invalidate the overall results.

For programmer salary averages, I used a salary survey from the September 4, 2000 issue of ComputerWorld; their survey claimed that this annual programmer salary averaged $56,286 in the United States. I was unable to find a publicly-backed average value for overhead, also called the ``wrap rate.'' This value is necessary to estimate the costs of office space, equipment, overhead staff, and so on. I talked to two cost analysts, who suggested that 2.4 would be a reasonable overhead (wrap) rate. Some Defense Systems Management College (DSMC) training material gives examples of 2.3 (125.95%+100%) not including general and administrative (G&A) overhead, and 2.81 when including G&A (125% engineering overhead, plus 25% on top of that amount for G&A) [DSMC]. This at least suggests that 2.4 is a plausible estimate. Clearly, these values vary widely by company and region; the information provided in this paper is enough to use different numbers if desired. These are the same values as used in my last report. 2.4 Determining Software Licenses A software license determines how that software can be used and reused, and open source software licensing has been a subject of great debate. The Software Release Practice HOWTO [Raymond 2001] discusses briefly why license choices are so important to open source / free software projects:

The license you choose defines the social contract you wish to set up among your co-developers and users ...

Who counts as an author can be very complicated, especially for software that has been worked on by many hands. This is why licenses are important. By setting out the terms under which material can be used, they grant rights to the users that protect them from arbitrary actions by the copyright holders.

In proprietary software, the license terms are designed to protect the copyright. They're a way of granting a few rights to users while reserving as much legal territory is possible for the owner (the copyright holder). The copyright holder is very important, and the license logic so restrictive that the exact technicalities of the license terms are usually unimportant.

In open-source software, the situation is usually the exact opposite; the copyright exists to protect the license. The only rights the copyright holder always keeps are to enforce the license. Otherwise, only a few rights are reserved and most choices pass to the user. In particular, the copyright holder cannot change the terms on a copy you already have. Therefore, in open-source software the copyright holder is almost irrelevant -- but the license terms are very important.

Well-known open source licenses include the GNU General Public License (GPL), the GNU Library/Lesser General Public License (LGPL), the MIT (X) license, the BSD license, and the Artistic license. The GPL and LGPL are termed ``copylefting'' licenses, that is, the license is designed to prevent the code from becoming proprietary. See Perens [1999] for more information comparing these licenses. Obvious questions include ``what license(s) are developers choosing when they release their software'' and ``how much code has been released under the various licenses?''

An approximation of the amount of software using various licenses can be found for this particular distribution. Red Hat Linux uses the Red Hat Package Manager (RPM), and RPM supports capturing license data for each package (these are the ``Copyright'' and ``License'' fields in the specification file). I used this information to determine how much code was covered by each license. Since this field is simply a string of text, there were some variances in the data that I had to clean up, for example, some entries said ``GNU'' while most said ``GPL''. In some cases Red Hat did not include licensing information with a package. In that case, I wrote a program to attempt to determine the license by looking for certain conventional filenames and contents.

This is an imperfect approach. Some packages contain different pieces of code with difference licenses applying to different pieces. Some packages are ``dual licensed'', that is, they are released under more than one license. Sometimes these other licenses are noted, while at other times they aren't. There are actually two BSD licenses (the ``old'' and ``new'' licenses), but the specification files don't distinguish between them. Also, if the license wasn't one of a small set of common licenses, Red Hat tended to assigned nondescriptive phrases such as ``distributable''. My automated techniques were limited too, in particular, while some licenses (e.g., the GPL and LGPL) are easy to recognize automatically, BSD-like and MIT-like licenses vary the license text and so are more difficult to recognize automatically (and some changes to the license would render them non-open source, non-free software). Thus, when Red Hat did not identify a package's license, a program dual licensed under both the BSD and GPL license might only be labelled as having the GPL using these techniques. Nevertheless, this approach is sufficient to give some insight into the amount of software using various licenses. Future research could examine each license in turn and categorize them; such research might require several lawyers to determine when two licenses in certain circumstances are ``equal.''

One program worth mentioning in this context is Python, which has had several different licenses. Version 1.6 and later (through 2.1) had more complex licenses that the Free Software Foundation (FSF) believes were incompatible with the GPL. Recently this was resolved by another change to the Python license to make Python fully compatible with the GPL. Red Hat Linux 7.1 includes an older version of Python (1.5.2), presumably because of these licensing issues. It can't be because Red Hat is unaware of later versions of Python; Red Hat uses Python in its installation program (which it developed and maintains). Hopefully, the recent resolution of license incompatibilities with the GPL license will enable Red Hat to include the latest versions of Python in the future. In any case, there are several different Python-specific licenses, all of which can legitimately be called the ``Python'' license. Red Hat has labelled Python itself as having a ``Distributable'' license, and package Distutils-1.0.1 is labelled with the ``Python'' license; these labels are kept in this paper.

The ``physical source lines of code'' (physical SLOC) measure was used as the primary measure of SLOC in this paper. Less formally, a physical SLOC in this paper is a line with something other than comments and whitespace (tabs and spaces). More specifically, physical SLOC is defined as follows: ``a physical source line of code is a line ending in a newline or end-of-file marker, and which contains at least one non-whitespace non-comment character.'' Comment delimiters (characters other than newlines starting and ending a comment) were considered comment characters. Data lines only including whitespace (e.g., lines with only tabs and spaces in multiline strings) were not included.

Note that the ``logical'' SLOC is not the primary measure used here; one example of a logical SLOC measure would be the ``count of all terminating semicolons in a C file.'' The ``physical'' SLOC was chosen instead of the ``logical'' SLOC because there were so many different languages that needed to be measured. I had trouble getting freely-available tools to work on this scale, and the non-free tools were too expensive for my budget (nor is it certain that they would have fared any better). Since I had to develop my own tools, I chose a measure that is much easier to implement. Park [1992] actually recommends the use of the physical SLOC measure (as a minimum), for this and other reasons. There are disadvantages to the ``physical'' SLOC measure. In particular, physical SLOC measures are sensitive to how the code is formatted. However, logical SLOC measures have problems too. First, as noted, implementing tools to measure logical SLOC is more difficult, requiring more sophisticated analysis of the code. Also, there are many different possible logical SLOC measures, requiring even more careful definition. Finally, a logical SLOC measure must be redefined for every language being measured, making inter-language comparisons more difficult. For more information on measuring software size, including the issues and decisions that must be made, see Kalb [1990], Kalb [1996], and Park [1992].

Note that this required that every file be categorized by language type (so that the correct syntax for comments, strings, and so on could be applied). Also, automatically generated files had to be detected and ignored. Thankfully, my tool ``sloccount'' does this automatically. 2.3 Estimation Models

This decision to use physical SLOC also implied that for an effort estimator I needed to use the original COCOMO cost and effort estimation model (see Boehm [1981]), rather than the newer ``COCOMO II'' model. This is simply because COCOMO II requires logical SLOC as an input instead of physical SLOC.

Basic COCOMO is designed to estimate the time from product design (after plans and requirements have been developed) through detailed design, code, unit test, and integration testing. Note that plans and requirement development are not included. COCOMO is designed to include management overhead and the creation of documentation (e.g., user manuals) as well as the code itself. Again, see Boehm [1981] for a more detailed description of the model's assumptions. Of particular note, basic COCOMO does not include the time to develop translations to other human languages (of documentation, data, and program messages) nor fonts.

There is reason to believe that these models, while imperfect, are still valid for estimating effort in open source / free software projects. Although many open source programs don't need management of human resources, they still require technical management, infrastructure maintenance, and so on. Design documentation is captured less formally in open source projects, but it's often captured by necessity because open source projects tend to have many developers separated geographically. Clearly, the systems must still be programmed. Testing is still done, although as with many of today's proprietary programs, a good deal of testing is done through alpha and beta releases. In addition, quality is enhanced in many open source projects through peer review of submitted code. The estimates may be lower than the actual values because they don't include estimates of human language translations and fonts.

Each software source code package, once uncompressed, produced zero or more ``build directories'' of source code. Some packages do not actually contain source code (e.g., they only contain configuration information), and some packages are collections of multiple separate pieces (each in different build directories), but in most cases each package uncompresses into a single build directory containing the source code for that package. Each build directory had its effort estimation computed separately; the efforts of each were then totalled. This approach assumes that each build directory was developed essentially separately from the others, which in nearly all cases is quite accurate. This approach slightly underestimates the actual effort in the rare cases where the development of the code in separate build directories are actually highly interrelated; this effect is not expected to invalidate the overall results.

For programmer salary averages, I used a salary survey from the September 4, 2000 issue of ComputerWorld; their survey claimed that this annual programmer salary averaged $56,286 in the United States. I was unable to find a publicly-backed average value for overhead, also called the ``wrap rate.'' This value is necessary to estimate the costs of office space, equipment, overhead staff, and so on. I talked to two cost analysts, who suggested that 2.4 would be a reasonable overhead (wrap) rate. Some Defense Systems Management College (DSMC) training material gives examples of 2.3 (125.95%+100%) not including general and administrative (G&A) overhead, and 2.81 when including G&A (125% engineering overhead, plus 25% on top of that amount for G&A) [DSMC]. This at least suggests that 2.4 is a plausible estimate. Clearly, these values vary widely by company and region; the information provided in this paper is enough to use different numbers if desired. These are the same values as used in my last report. 2.4 Determining Software Licenses A software license determines how that software can be used and reused, and open source software licensing has been a subject of great debate. The Software Release Practice HOWTO [Raymond 2001] discusses briefly why license choices are so important to open source / free software projects:

The license you choose defines the social contract you wish to set up among your co-developers and users ...

Who counts as an author can be very complicated, especially for software that has been worked on by many hands. This is why licenses are important. By setting out the terms under which material can be used, they grant rights to the users that protect them from arbitrary actions by the copyright holders.

In proprietary software, the license terms are designed to protect the copyright. They're a way of granting a few rights to users while reserving as much legal territory is possible for the owner (the copyright holder). The copyright holder is very important, and the license logic so restrictive that the exact technicalities of the license terms are usually unimportant.

In open-source software, the situation is usually the exact opposite; the copyright exists to protect the license. The only rights the copyright holder always keeps are to enforce the license. Otherwise, only a few rights are reserved and most choices pass to the user. In particular, the copyright holder cannot change the terms on a copy you already have. Therefore, in open-source software the copyright holder is almost irrelevant -- but the license terms are very important.

Well-known open source licenses include the GNU General Public License (GPL), the GNU Library/Lesser General Public License (LGPL), the MIT (X) license, the BSD license, and the Artistic license. The GPL and LGPL are termed ``copylefting'' licenses, that is, the license is designed to prevent the code from becoming proprietary. See Perens [1999] for more information comparing these licenses. Obvious questions include ``what license(s) are developers choosing when they release their software'' and ``how much code has been released under the various licenses?''

An approximation of the amount of software using various licenses can be found for this particular distribution. Red Hat Linux uses the Red Hat Package Manager (RPM), and RPM supports capturing license data for each package (these are the ``Copyright'' and ``License'' fields in the specification file). I used this information to determine how much code was covered by each license. Since this field is simply a string of text, there were some variances in the data that I had to clean up, for example, some entries said ``GNU'' while most said ``GPL''. In some cases Red Hat did not include licensing information with a package. In that case, I wrote a program to attempt to determine the license by looking for certain conventional filenames and contents.

This is an imperfect approach. Some packages contain different pieces of code with difference licenses applying to different pieces. Some packages are ``dual licensed'', that is, they are released under more than one license. Sometimes these other licenses are noted, while at other times they aren't. There are actually two BSD licenses (the ``old'' and ``new'' licenses), but the specification files don't distinguish between them. Also, if the license wasn't one of a small set of common licenses, Red Hat tended to assigned nondescriptive phrases such as ``distributable''. My automated techniques were limited too, in particular, while some licenses (e.g., the GPL and LGPL) are easy to recognize automatically, BSD-like and MIT-like licenses vary the license text and so are more difficult to recognize automatically (and some changes to the license would render them non-open source, non-free software). Thus, when Red Hat did not identify a package's license, a program dual licensed under both the BSD and GPL license might only be labelled as having the GPL using these techniques. Nevertheless, this approach is sufficient to give some insight into the amount of software using various licenses. Future research could examine each license in turn and categorize them; such research might require several lawyers to determine when two licenses in certain circumstances are ``equal.''

One program worth mentioning in this context is Python, which has had several different licenses. Version 1.6 and later (through 2.1) had more complex licenses that the Free Software Foundation (FSF) believes were incompatible with the GPL. Recently this was resolved by another change to the Python license to make Python fully compatible with the GPL. Red Hat Linux 7.1 includes an older version of Python (1.5.2), presumably because of these licensing issues. It can't be because Red Hat is unaware of later versions of Python; Red Hat uses Python in its installation program (which it developed and maintains). Hopefully, the recent resolution of license incompatibilities with the GPL license will enable Red Hat to include the latest versions of Python in the future. In any case, there are several different Python-specific licenses, all of which can legitimately be called the ``Python'' license. Red Hat has labelled Python itself as having a ``Distributable'' license, and package Distutils-1.0.1 is labelled with the ``Python'' license; these labels are kept in this paper.

One of the main potential military applications of robots is working in built-up areas, because these are so hazardous for soldiers. DARPA sponsors a LOT of work in this area, for example the MARS program.

The current most successful approaches are all broadly statistical, providing a means to "see through" the noise, drift and variations in robot sensor readings. Sebatian Thrun's group at CMU has some of the best work in this area (for an overview, see this review paper. Andrew Howard at USC has some cool movies here showing his technique based on a physical spring/damper metaphor. Great stuff.

This problem is here to stay. If you have ideas, join a grad school program and help out!

One of the main potential military applications of robots is working in built-up areas, because these are so hazardous for soldiers. DARPA sponsors a LOT of work in this area, for example the MARS program.

The current most successful approaches are all broadly statistical, providing a means to "see through" the noise, drift and variations in robot sensor readings. Sebatian Thrun's group at CMU has some of the best work in this area (for an overview, see this review paper. Andrew Howard at USC has some cool movies here showing his technique based on a physical spring/damper metaphor. Great stuff.

This problem is here to stay. If you have ideas, join a grad school program and help out!

One of the main potential military applications of robots is working in built-up areas, because these are so hazardous for soldiers. DARPA sponsors a LOT of work in this area, for example the MARS program.

The current most successful approaches are all broadly statistical, providing a means to "see through" the noise, drift and variations in robot sensor readings. Sebatian Thrun's group at CMU has some of the best work in this area (for an overview, see this review paper. Andrew Howard at USC has some cool movies here showing his technique based on a physical spring/damper metaphor. Great stuff.

This problem is here to stay. If you have ideas, join a grad school program and help out!

Actually, since '96 when the first PCI macs were released, namely the PPC 7500/100mhz and every significant desktop mac since then, has come with a removable CPU chip, lots of empty RAM slots and 3 to 6 PCI expansion bays, and extra room for mobo L2 cache RAM, additional video ram, empty drive bays and all that good stuff. Plus the 7500 pioneered the whole concept of upgrading your mac without touching a single screw.

I've owned my 7500 since early '96.

I have used it as my computer back in the dorms. It came with a built-in video capture card.

I've used it to watch TV: back in the dorm, i had a vcr but no tv. i'd plug the antenna cable to vcr tuner input and plug video and audio output of the vcr to ppc 7500's video input and stereo audio inputs (y-cable). I'd watch basketball games and take screen grabs. fun shit.

i've used it to actually capture video: I'm the one who digitized every single student movie clip from that site using this puppy.. It was running MacOS 7.5

Then i turned it into a full-time co-located server at an ISP in beverlyhills, where it would host a slew of web sites. it was running MacOS 7.6.1. It stayed there and worked very nicely for about 3 years after which i finally took it back home.

Meanwhile I had upgraded its processor chip from an old PPC 603, to the very first 250Mhz G3 chip. I boosted its RAM up to ~200MB, while it could in theory hold up to a GIG of ram with its 8 slots. I added an Ultra2 LVD SCSI card on one of my free PCI slots and an extra internal 10gig 8.5ms access-time Ultra2 SCSI cheetah IBM drive. i picked both of those by comparing prices on pricewatch.com.

I also added another Ultra SCSI-2 controller on another pci slot cuz i had planned to chain external scsi drives at some point but never followed-thru.

And of course i did all those upgrades without touching a screw. things worked as advertised.

Today, i could still stick a G4 processor in this thing. It's now running LinuxPPC Q4 2000. It sits at home where it's serving some hobby websites of mine off of my DSL connection behind my linksys router.

One thing i'd like to mention is that ever since i've bought this computer, 6 full years ago, it has been on 24/7/365. I've crashed it many times while dicking around with the OS and some server software but never managed to corrupt any of my hard drives.

As of today it is still happily cracking RC5 keys for distributed.net.

I might whipe out the drives and install Mandrake Linux PPC once it has matured a bit.

Can't upgrade a mac eh? right. and that's a '96 model. Today Apple has VGA displays, USB peripherals, ATA controllers. PCI expansion slots, and support for industry-standard video and graphics acceleration cards. Aside from things directly-tied to your motherboard, i'd say you've got a pretty wide choice of upgrade options.

So now you complain you couldn't build it from scratch in the first place? Well lemme put it this way:

At least, when you buy your mac, you KNOW, *everything*, and i do mean *everything* just WORKS out of the box. That gives you a baseline of a stable reference system. A powerful one. With all the features a geek could ever dream of. (and i'm pretty picky ) (and not a gamer, okay).

Countless friends of mine have mail-ordered all of their PC parts from all over the states, spent NIGHTS putting it all together only to find out some driver is not compatible with their specific configuration.

heh.

Aside from hardware considerations, in my mind, OS X *alone*, is a good-enough reason to buy a mac.

Call me a cynic, but it sounds like this guy is just out to plug his class to help with future enrollment and/or generating press for the CS community at Brown. I mean I go to USC and our intro to robotics class, CSCI 445, had to create Mindstorms that played soccer, yet I didn't go plugging it. Oops guess I did.

____________________________

However, in many modern countries (perhaps yours excluded) power is generated using modern techniques that are impervious to all but the most severe weather, and the transmission lines are underground