Slashdot Mirror

1. Stored Procedures
2. Parameterized Queries
3. Learn the SQL-92 Specification (so that you're familar with the language beyond just SELECT, INSERT, UPDATE, and DELETE. There are all kinds of things out there to help you get rid of that dynamic code, like COALESCE, and CASE WHEN, etc.)

From the parent poster: It will be interesting to see how this is applied and to whom.

the courts would have almost unlimited discretion to impose the order if they believe it probable that a suspect had 'acted in a way which facilitated or was likely to facilitate the commissioning of serious crime'.

Industry statistics suggest that hard-nosed engineering outperforms agile dramatically. Maybe Agile works better for you, but when fifteen thousand programmers have been measured and more than 95% end up doing better with real metrics, and when these engineers are some of the best on earth (the first military software house to hit CMM5, the Boeing 747 software team, etc,) it's a fair guess that you're the exception rather than the rule. Believe it or not, genuine formal engineering does exist for software, and the training isn't all that expensive.

Is it possible you would do better with up-front planning once you were familiar with a formal method like PSP / TSP? It turns out that saying you're planning hard then writing a bunch of stuff down isn't actually as good as learning statistical methods and keeping years of data from which to make schedules using mathematical models derived from tens of millions of man-hours of detailed real-world data. When the 747 software team sees a 60% time to market drop, a 95% testing time drop and two known bugs in a million and a half lines of code on an 18 month project (as compared to 228 on the previous iteration, by the same people,) it's time to consider whether to learn what it is that's helping them so much. After all, they're actually pretty good at their jobs.

Just a thought.

The saddest thing about this is how correct you are, and how it hinders you. If you and another team developed Product X, and both went 33% over schedule, the other team would hit early milestones, declare progressive success, change the schedule to fit the new needs, allow bloat, hammer in new features to justify the lag, and end up coming in 200% over budget. You would come in 33% over budget, but since you didn't dance around acting like the schedule was the only important thing, your lean and nearly on-time product would be seen as disasterously over-budget, and you wouldn't be allowed to manage again.

It's a pity that what you said is correct, because it encourages a kind of myopic and nearly religious devotion to what is really just a measuring tool, and the results are a massive drop in actual quality in exchange for the feeling of success. What you said is right, but remarkably counterintuitive, and it is my belief that what you're correct about is the primary basis for most of the problems in this industry today.

I wish more people were like you, and were willing to take the up-front hit instead of playing self-deception games to feel better about slippage. You plus a real estimating tool like the PSP/TSP (see propoganda video) are exactly what this industry needs, but facing the problem is so difficult and fixing it so superficially expensive-looking (despite the remarkable cost benefits in the long run) that I think your kind of actual observant development is a long time in coming.

Pat yourself on the back. You've made all the old people proud today.

Years ago at a sports psychologist's office I had these skin-response devices (among other things) attached to me while I was told to close my eyes and imagine being in a relaxing natural setting. It was neat to see my brain activity mapped out on a monitor and change drastically because of those thoughts.

Love them or hate them, the Scientologist's E-Meter is little more than a GSR meter. Of course, L.R. Hubbard takes credit for inventing it, despite clear evidence that it was, in fact, invented by Volney Mathison. Notice that it's the "Hubbard E-Meter"? How else can you take $40 of electronics and sell it for thousands of dollars?!?!? (scroll down about 2/3 down to see prices for various products)

Many would say that scientology is an organization dangerous to free-speech rights, as they seem willing to do almost ANYTHING to supress free speech if they think it's critical of them, even when such speech doesn't mention them. More information is available in this Neat-o video

And, it seems that, despite their best efforts, the church of Scientology is losing their war on the Internet - it was actually difficult for me to find information that was "positive" to Scientology when searching for information on the E-Meter!

I have a strange urge to possess a gadget that can measure the level of this "gadget disease" in people.

Why do I think such a gadget would be very similar to the E-Meter?

I get mails from Nigeria offering me lots of cash to pay my Valium and Viagra tablets with I get for cheap if I buy them by hunderds. Furtheron I use UW-IMAP and soon Cyrus IMAP for mail storage. The efficience is in the immediate box sorting and the use of the SIEVE filtering which will drop the load on the client side; the server side will filter the corresponding mails to their boxes. Some users can be in the same "group" to send mail directly to a map you have given access to; if not any.

I've got 2 folders; they are "active" and "storage". The storage space is all mail which is not (immediately) needed anymore but which needs to be easy accessible whenever I want to search in it. No need to subscribe to these maps from certain clients.

GMAIL is doing a very good job ; they do break the barrier between storable mail and giving you (and them) to using their search algorithms on your mailboxes.

I've always noticed a mailserver is best served cold with a good quota and good maintenance; together with a good mailserver policy - not just drop and keep it out there till it eventually dies out (which it will never if the servers are reliable). It's great to search through all your previous e-mails to know all your hunderds of conversations but if you use e-mail although on most mailservers it slacks right there... If you have your private server a 2gigabyte box would be sure no problem; if you are on a busy server a 250 to 500mb box is often a good solution; although this could also slack if everyone would be having their boxes fully loaded/open all the time...

Still a pity, years ago e-mail could be seen a little bit like a fax-machine; the fax-machine gets polluted but not -over-polluted. Mostly if you saw "new faxes received" there was something inbetween which was meant personal. E-mails are not so reliable and valuable anymore. Hotmail and lots of other providers are using blacklists which do even block gmail users (ORDB) which is often a very negative result of their users. The users do often not even know their mail is "dropped" into the void; there is no warning, the mail just never existed; unless the user gets in touch with the sender; if he even can. E-mail is also not reliable anymore because you need to filter -so much spam- and even if you use Bayesian filtering or any other techniques like greylisting; there are always catches (like false positives) which will block a remote user to mail to your address..

I did find out it's easy to filter out the known users to the corresponding boxes; which will also be replaced by sieve; which blocks 99% of the spam in those filtered boxes. Furtheron my inbox is really like my fridge; every time I open it I am afraid I get assaulted by one or another living organism wanting to survive and jump on me eating my guts out ;)

I get mails from Nigeria offering me lots of cash to pay my Valium and Viagra tablets with I get for cheap if I buy them by hunderds. Furtheron I use UW-IMAP and soon Cyrus IMAP for mail storage. The efficience is in the immediate box sorting and the use of the SIEVE filtering which will drop the load on the client side; the server side will filter the corresponding mails to their boxes. Some users can be in the same "group" to send mail directly to a map you have given access to; if not any.

I've got 2 folders; they are "active" and "storage". The storage space is all mail which is not (immediately) needed anymore but which needs to be easy accessible whenever I want to search in it. No need to subscribe to these maps from certain clients.

GMAIL is doing a very good job ; they do break the barrier between storable mail and giving you (and them) to using their search algorithms on your mailboxes.

I've always noticed a mailserver is best served cold with a good quota and good maintenance; together with a good mailserver policy - not just drop and keep it out there till it eventually dies out (which it will never if the servers are reliable). It's great to search through all your previous e-mails to know all your hunderds of conversations but if you use e-mail although on most mailservers it slacks right there... If you have your private server a 2gigabyte box would be sure no problem; if you are on a busy server a 250 to 500mb box is often a good solution; although this could also slack if everyone would be having their boxes fully loaded/open all the time...

Still a pity, years ago e-mail could be seen a little bit like a fax-machine; the fax-machine gets polluted but not -over-polluted. Mostly if you saw "new faxes received" there was something inbetween which was meant personal. E-mails are not so reliable and valuable anymore. Hotmail and lots of other providers are using blacklists which do even block gmail users (ORDB) which is often a very negative result of their users. The users do often not even know their mail is "dropped" into the void; there is no warning, the mail just never existed; unless the user gets in touch with the sender; if he even can. E-mail is also not reliable anymore because you need to filter -so much spam- and even if you use Bayesian filtering or any other techniques like greylisting; there are always catches (like false positives) which will block a remote user to mail to your address..

I did find out it's easy to filter out the known users to the corresponding boxes; which will also be replaced by sieve; which blocks 99% of the spam in those filtered boxes. Furtheron my inbox is really like my fridge; every time I open it I am afraid I get assaulted by one or another living organism wanting to survive and jump on me eating my guts out ;)

Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of surprising hard data. Since the training courses are several thousand dollars per person and require the whole team, you might want to start by reading the books (Intro to PSP and Intro to TSP) to make sure it's something you like and which is appropriate to your business model.

PSP and TSP are appropriate for up front engineered projects - application sequels, industrial software, military software (it's originally a DoD system,) et cetera. If you're writing business software or games, PSP and TSP aren't for you - they don't allow for the kind of rapid change that characterizes those designs. They can be bent into it, but there are better tools. Extreme Programming (start with Explained then read installed) are built for rapid-change environments, and were built on the Chrysler C4 project. They're industrial-ready, but they spend a lot of time on post-organization. You want that if your project is changing a lot, like an application you're building for a client who isn't sure what they want. You don't want that when you know exactly what you're building, like a realtime control system which has to respond to an exact list of inputs.

When you're somewhere inbetween those two poles - say, the new version of an office suite, or a game sequel, where you know most of the features and most of the format, but have to add some small and jazzy new stuff to get an upgrade, you might want to work with a thrash control process. The idea with thrash control processes is to start with a really wide (25-400%) range, and progressively whittle that down as the project takes shape. This is a very good process for when you have a fairly good idea what you're going to do, but when there's still a significant amount of mystery. For that you want the Microsoft axis, largely characterized by McConnell's Software Project Survival Guide and Sullivan's UPOT. Thrash control processes have a very nasty tendency to suffer detrimental early optimism, and they're already in a dangerous place for second system syndrome since they're mostly for reasonably well defined projects, so you'd do well to get some cold blanket advice from The Mythical Man-Month if you go this route.

And then, there's the hard-nosed engineer camp. They tend to use things like formal estimation based on code points and function points, systemal analysis and big models like COCOMO. This kind of thing is appropriate for large projects. You can get a clearer understanding of formal estimating practices, instead of just that one practice, from Software Estimation: Demystifying the Black Art.

That should get you started. There are a lot of real approaches to this sort of thing which aren't "zomg double your estimate" or "totally refuse." This is something business needs, and it needs to be done right. There are programmers and there are software engineers. Regardless of what your co

Go read The Personal Software Process. It's full of helpful, common sense suggestions that every programmer should know. Then go read The Team Software Process, which is a simple forward thinking way of getting programmers to work well together in teams. Then get really really depressed because no matter how hard you try at stuff like this, the software industry is so random and unpredictable that common sense is not all that common.

Before making yet another unusable PGP interface you should probably check out the two research papers below. They are two very famous user studies done that look at why the normal user can't use PGP correctly even as an Outlook extension.

http://www.gaudior.net/alma/johnny.pdfWhy Jonny Can't Encrypt
http://cups.cs.cmu.edu/soups/2006/posters/sheng-po ster_abstract.pdfWhy Jonny Still Can't Encrypt

Using the papers to address some of your suggestions:
* Automatically decrypt/sigcheck all incoming emails
How does the user know it has been decrypted and which key decrypted it? Currently PGP solves this problem by putting a line at the begining of the email saying that it was decrypted. But there is nothing to stop a phisher from putting a similar line at the begining of their emails before they are even sent.

* Automatically encrypt/sign all outgoing mails.
How does the user know they have successfully encrypted their email? Quick feedback is an essential part of learning. By making the encryption invisible the user gets no feedback and since the program auto decrypts they can't even send it to themselves to make sure it worked. Plus what happens if the user wants to send it to someone who can't decrypt it?

* Automatically (just ask for password confirmation or something) addition of incoming pubkeys to my keyring.
What is going to stop people from helpfully adding the phisher's keys to their keyrings? You had better make sure there is an easy way to remove them.

"I think MetaData is dead on the personal computer, because nobody wants to be a data entry clerk."

That's why you get clever with your solutions.

"People don't want to spend hours entering data."

Like spreadsheets, or documents...

Despite the generated jokes about dogs and the French, and the "oohing and aahing of the crowd at the AIBO robotics soccer games broadcast on U.S. national television, this is not merely "cute". This may be the most important research that you have ever read about.

Researchers Luc Steels and colleagues at Sony's Paris Computer Science Laboratory in France have performed a series of remarkable experiments demonstrating the development, from naught, of spoken language among robots. Words, grammar and semantics evolve spontaneously among cooperating robotic agents initially programmed with a small base set of ground perceptions and behaviors. And from the development of language arises cooperative group (intelligent) behavior.

Enhanced AIBOs are initially programmed to recognise simple stimuli from their surprisingly limited hardware sensors. Over the course of several hours or days, the AIBOs learn to distinguish objects and how to interact with them. A built-in curiosity system ('metabrain') continually directs the AIBOs to look for new and more challenging tasks and to cease activities that are not fruitful. In time they develop more complex tasks, just as do human children.

Like children, the enhanced Sony AIBOs initially babble ("argue?") until two or more settle on a sound to describe an object or aspect of their environment. Over time the group gradually builds a lexicon and grammatical rules through which to communicate. Agreement on word usage spreads through the population as terms for similar meanings compete for acceptance. For example, the robots develop the language structures to express that a red ball is rolling to the left. Just as human twins sometimes develop a unique language in which only they can communicate, the enhanced AIBOs (which are clone-like and similar to twins) develop their own language.

Language analysis and generation are part of Good Old Fashioned AI (GOFAI) and have been studied extensively for decades by AI researchers. In the past several decades GOFAI was challenged by Nouvelle AI (Situated AI) championed by Hans Moravec and Rodney Brooks. This alternative approach holds that true AI will not arise from formal mathematical systems but instead from robotic behaviors which have a subsumption architecture as an overall organising principle for the individual robot. This architecture consists of layers of behavioural modules, each capable of carrying out a complete but simple task. Steels' enhanced AIBOs are embodiments of just such a subsumption architecture and provide strong support for Moravec's and Brooks' hypotheses

Prior to Luc Steels' experiments, no one had experimentally demonstrated how language develops among intelligent agents. Steels' experiments are no less than stunning: in a controlled environment AIBO robots develop their own words and grammars for objects in their environment. All aspects of human language development are mirrored in these experiments: words compete for acceptance in the population, new words are created, and grammatical structures arise spontaneously. Steels' work also addresses the idea of a "robot culture", since it is in the context of a population of cooperating agents that language becomes most useful.

Contrast this with the W3C's Semantic Web effort, which has received much more interest and money in recent years due to the growth of the Internet yet has proven far less fertile. In the Semantic Web there are multiple competing "ontologies" (roughly, data dictionaries wherein all terms are strictly defined by specialists from their

http://www.cmu.edu/PR/releases06/060608_robocup.ht ml The competition is not just about robots preforming soccer. There are two other events that are completely unrelated to soccer. One event is search and rescue and the newest competition involves domestic applications. PS. This is probably the only time I will ever watch a soccer event.

"Women severely underestimate their abilities in many areas, but especially with respect to computers. One study about this topic is Undergraduate Women in Computer Science: Experience, Motivation, and Culture: http://www-2.cs.cmu.edu/~gendergap/papers/sigcse97 /sigcse97.html

For example, while 53% of the male computer science freshman rated themselves as highly prepared for their CS courses, 0% of the female CS freshman rated themselves similarly. But at the end of the year, 6 out the 7 female students interviewed had either an A or B average. Objective ratings (such as grade point averages or quality and speed of programming) don't agree with most women's self-estimation. I personally encountered this phenomenon: Despite plenty of objective evidence to the contrary, including grades, time spent on assignments, and high placement in a programming contest, I still didn't consider myself to be at the top of my class in college. Looking back objectively, it seems clear to me that I was performing as well or better than many of the far more confident men in my class." (HOWTO Encourage Women in Linux

In Perspectives on Open Source Software (2001) from Carnegie-Mellon's Software Engineering Institute the authors raise interesting points suggesting why the answer to "how open software needs to be" may come down to "it depends..." if we're thinking of "need" relative to optimizing for a set of requirements (as opposed to the relative simplicity of calling something "open" for marketing purposes or even establishing a trademarked definition.) They describe "open source software" as "at the most basic level [meaning] software for which the source code is open and available. Open and available is meant to convey two concepts: Open - The source code for the software can be read (seen) and written (modified). Further, this term is meant to promote the creation and distribution of derivative works of the software. Available - The source code can be acquired either free of charge or for a nominal fee (e.g., media and shipping charges or online connection charges)." And they contrast this with the Open Source Definition (OSD) from the Open Source Initiative (OSI) noting: "Under OSI (strictly speaking) a software product is in fact open source if and only if it conforms to the OSD...Upon reviewing the complete text of the OSD, it is interesting to point out that the definition does not pertain specifically to the source code itself, but rather to the license under which the source code is distributed. Therefore, in strict conformance to the OSD written by the OSI, a software product that conforms to only eight of the nine criteria is not OSS." They raise a few interesting points relevant to distinguishing meaningful requirements for the SW: An example of a license (Sun's JDK 1.3) that violates OSD criteria #6 ("No discrimination against fields of endeavor") by stating the SW "... is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility." (For most folks for whom lack of an OSI cert might otherwise be a showstopping characteristic, IMO I'd guess this violation is likely to be something of a trivial one in terms of relevance to actual usage scenarios...) And on the one hand the importance for customers who intend to treat OSS as a "black box"--meaning not themselves making any modification or even reviewing code--of the health of the OSS product's community, since the customer in this case plans to be dependent on the community: "If the community is small and stagnant, it is less likely that the software will evolve, that it will be well tested, or that there will be available support." Versus the case of customers who, on the other hand intend to treat OSS as a "white box"--meaning changing code--of characteristics of the SW itself rather than the community: "sometimes the source is the only documentation that is provided. Some consider this to be enough. Linus Torvalds, the creator of Linux, has said, "Show me the source." Yet if this were the case, there would be no need for Unified Modeling Language (UML), use cases, sequence diagrams, and other sorts of design documentation. Gaining competency in the OSS component without these additional aids can be difficult." The whole report is worth reading: http://www.sei.cmu.edu/publications/documents/01.r eports/01tr019/01tr019title.html

http://www.cs.cmu.edu/~dhoiem/projects/popup/index .html

Looks like some of the software they wrote to do this has been GPL'ed.

You're right about that. You're not going to argue ethics -- in the sense that you state what logically follows from certain ethical principles. No; you're just going to throw out ethical conclusions as though they're unquestionable when in fact they're hotly debated. You take the "public domain" to be an aberration -- or one of many options available. Wrong. The public domain is the natural habitat of ideas. Jefferson knew this. You have to back up the aberration of copyright with either a pragmatic or ethical argument.

"I also do not think that we should..."; "they should not be required..."; "all humans have a right to survive on their skills". these are ethical propositions that have to be supported with a theory of what is right and wrong. Sorry, but they are.

The last hilarious thing is: you insist you don't want to construct an ethical theory, but w/r/t the other line of reasoning -- the pragmatic one, viz: copyright stimulates science and art -- you agree with me almost perfectly. If "the effect of such change [a 5-10yr copyright] would be negligable on the music and game industries" then Why is the term 100+ years? Why is the State granting 20 times as much stimulus as is needed to achieve roughly the same result? Need a hint? okay:

M_____ Mouse

finally: A good read, explaining clearly the inferiority of the "property" metaphor to describe the nature of creative works.

Think of how difficult it would be to play test a game like Oblivion versus a typical FPS.

It can be avoided.

I'm serious.

The problem is that game companies are some of the most behind in state-of-the-art testing. I'm not talking about QA process, either. I'm talking about Model Checking. It's the kind of thing military contractors do with their code to make sure missiles never accidentally blow up in the wrong spot.

(It was the topic of an article on Slashdot a few weeks ago - which, I'm sorry to report, nobody here actually understood, thinking it was about automatic code generation. Talk about not RTFAing.)

Here's how it works: you model your quests and quest variables as finite state automata. (Remember discrete math?) You use a very expressive language for this, which makes it easy to read. A character, say, killing a certain fish would change a boolean quest variable. Then you define properties that your FSM should have, so that if a quest becomes unsolvable, one or more properties fails. Throw it at a model checking system and in a few minutes, it tells you whether a quest can be made unsolvable and how to get into that state.

It's extremely simple with quests, most of which are totally independent, leading to a relatively small global quest FSM.

Someone competent in Model Checking could add a new quest to the system and check it in less than two hours.

Since people seem to be interested in this, you might also take a peek at
the CMU computer networks course, which I put online almost entirely (lecture nodes, video, homeworks, and the programming projects). Click on "Syllabus" to get to the contentful-bits. Feedback is welcome: Srini and I hope that leaving it online will be useful for students and instructors everywhere.

Ugh... that is even more irritating than a regular text captcha.

Link to actual sample: http://gs264.sp.cs.cmu.edu/cgi-bin/esp-pix

I can set up Samba, etc. on just about any box. What defies me is setting up OpenAFS. How about a server that supports OpenAFS or Coda?

Well, this comment is kinda lateral (as in 'not related to opengl and games'), but I think you'd appreciate flipping through a few basic computer graphics books and related maths --- after all, opengl is just an implementation of the few of the most basic concepts and the red&blue books are mostly 'just' technical reference manuals. getting a handle of the basic concepts also probably clarifies what you actually want to do with the code.

Graphics:

watt&watt: Advanced Animation and Rendering Techniques - not a very recent book but the material is still relevant and the presentation of different concepts is relly good
Hearn & Baker: Computer graphics (c or opengl version depending on your preferences). Basic computer graphics. Pretty good. The opengl version eschews some of the more basic code samples from the c version, which is a bit shame really.
Moller & Haines: Real-Time Rendering - relevant for real time applications and contains great references to computer graphics resources in general

Geometry & linear algebra:
Philip Schneider & David Eberly: geometric tools for computer graphics (contains recipes for eg. checking collisions, raytracing, clipping...). Might be not best book of this type(?) but it's ok.

Freely available online material:
comp.graphics.algorithm faq:
http://www.faqs.org/faqs/graphics/algorithms-faq/

The physical modeling course of David Baraff available online is quite nice:
http://www.cs.cmu.edu/~baraff/sigcourse/index.html

Graphics gem's codes:

http://www.acm.org/pubs/tog/GraphicsGems/

The book's themselves are also excllent recipe repositories, but really useful only after you know the basic concepts from basic textbooks etc. ...and, if you have the access then the http://portal.acm.org/ stuff is really good. (search for 'siggraph "course notes" for starters') You can find details to most of the stuff Pixar, Alias etc. do from there...

If you have the time and resouces, then the Moller & Haines book is a decent roadmap to the field ("Oh, what's this...let's see the referred book/article has to say.. oh, that's interesting!") from the grass roots of z-buffers up to modern fps engine concepts.

Good suggestion! I would supplement it with the following as well:
1. Episodic Learner Model/An online Lisp tutorial
2. Common Lisp: A Gentle Introduction to Symbolic Computation
3. How to Design Programs
4. Practical Common Lisp
5a. The book - Structure and Interpretation of Computer Programs
5b. The movies - Structure and Interpretation of Computer Programs
6. Loving Lisp - the Savvy Programmer's Secret Weapon
7. Common Lisp the Language, 2nd Edition
8. On Lisp
9. common lisp: a web application tutorial for beginners
10. JavaScript: The World's Most Misunderstood Programming Language
11. Free JavaScript Learning Center
12. JavaScript for Scared People
13. JavaScript Closures
14. Why's (Poignant) Guide to Ruby

= 9J =

Good suggestion! I would supplement it with the following as well:
1. Episodic Learner Model/An online Lisp tutorial
2. Common Lisp: A Gentle Introduction to Symbolic Computation
3. How to Design Programs
4. Practical Common Lisp
5a. The book - Structure and Interpretation of Computer Programs
5b. The movies - Structure and Interpretation of Computer Programs
6. Loving Lisp - the Savvy Programmer's Secret Weapon
7. Common Lisp the Language, 2nd Edition
8. On Lisp
9. common lisp: a web application tutorial for beginners
10. JavaScript: The World's Most Misunderstood Programming Language
11. Free JavaScript Learning Center
12. JavaScript for Scared People
13. JavaScript Closures
14. Why's (Poignant) Guide to Ruby

= 9J =

You left out a language like Lisp.

I recommend the free book Common Lisp: A Gentle Guide to Symbolic Computation.

http://www-cgi.cs.cmu.edu/afs/cs.cmu.edu/user/dst/ www/LispBook/index.html

After that, Practical Common Lisp by Peter Seibel.

The reason I recommend lisp is this: I started on C/C++ and those languages were always a pain to program in, I was wrestling them to translate the ideas in my head to the screen. Lisp is pretty easy once learned (easier than most languages I find), especially when you have to learn about Algorithms and Data Structures, a language like lisp is a godsend compared to C or C++ (as lists are a built in type, you can concentrate on the algorith, not the code, mallocing or free correctly, etcetera).

The same goes for scheme (different dialent still lisp) or dylan (though I prefer prefix notation.)

Don't be so patronizing, firstly. Secondly, show me one bit of evidence to back up your claim that a scientist goes into his research project trying to explicitly and only to disprove his theory. It doesn't happen. Again, you must be open to the fact that:

I you are not open to those possibilities, then your work is going to be skewed. There have been may instances of this, polywater, is one that comes to mind.

The most accurate way to put it is, you make an observation, you formulate a hypothesis, you design a study and let the chips fall where they fall. The data, if the work is done correctly, will speak for itself. You need to be, as much as humanly possible, unbiased one way or the other, the rest of the bias you do your best to remove with controls.

It is clear to me now, reading your other posts in this thread that you likely have no formal scientific training, and know little of what you speak.

Philosophy and computer science are only wishfully held together by a select few in any official way. If you would like a more integrated curriculum I might suggest this.

Although from looking into it myself it looks like the program favors the analytic more. Also from talking with CMU's career office it sounded like most people ended up getting the same jobs that CS majors got. In other words it's not a gateway to something new and exciting except maybe impressing someone at a cocktail party.

Otherwise just do both separately and consider yourself better for doing it. The great philosophers were scientists and the great scientists were philosophers. So if you find yourself being philosophical, you are probably just a better scientist for it. Much of historical and contemporary philosophical literature is just the letters and notes of great scientists.

Proper cross education of philosophy and (hard) science would probably do both fields a lot of good toward bringing them both closer to reality.

Something like this has already been done at the CMU nanorobotics lab.

This is why I think people "invented" emoticons :)

Or, more specifically, why Scott Fahlman first made an ASCII smiley on 19 September 1982, when people didn't realise the joke he'd made about a lift being out of commission after someone contaminated it with mercury in a scientific experiment gone awry actually was a joke.

This is why I think people "invented" emoticons :)

"People" invented it? :-)

Smiley lore by Scott E. Fahlman.

Yep, there's a database of Enron emails:

Enron Email Dataset

As others have pointed out, IP Multicast is tough to deploy, fragile, and not particularly scalable. What you really want is so-called Application-Level Multicast: distributed construction of p2p multicast trees (or other similar structures) among end hosts, without help from routers. See: Scribe/SplitStream, End System Multicast (ESM), Overcast, etc.

Otherwise the main job of the microkernel is to enforce security policies, which means protect exactly against some driver "messing up things". So if there is a way for a driver to lock up the PCI bus by setting the wrong register then the microkernel should be the setting the registers. The way the drivers are written is totally diferent in the microkernel archicture. All the interrupts are processed by the microkernel, not immediatly by the drivers. Some slides about this: here

You get power dissipation in each gate or buffer that changes state because of some signal, irregardless of the direction in which the information is flowing. You can not recycle this power. This comes directly from the basic principle behind CMOS technology (used by almost all digital chips today) - you are charging and discharging a capacitor.

You're half right. You're right that what's going on is a charging and discharging of a cap, but you're wrong that the charge can't be recycled. A conventional clock works by connecting the gates of a bunch of devices (i.e. capacitance) to Vdd, then after a little time connecting it to ground instead. Wait a little bit, then repeat. What effectively happens is that you dump some amount of charge from Vdd to ground each switch, and it's gone (i.e. it's heat now). A water analogy would be a tub of water above you (Vdd), a bucket in your hand (the capacitance), and the ground (gnd). You pour some water from the tub into your bucket (charge the cap), then dump it on the ground.

It doesn't have to be this way. There are actually ways to charge a capacitor, and then pull the charge back out again (without dumping it to ground)! I'm going to assume you're familiar with LRC circuts, and how they can resonant when an impulse is applied. What's going on during the oscilattions? Charge is moving into the capacitor, and then being pulled back out to the inductor. The same charge goes back and forth, ideally forever (of course, in practice, the resistance isn't 0 so you put out some heat and the oscillations dies down). I'm not sure what exactly the water analogy would be - maybe a wave sloshing back and forth in a trough.

I recently attended a seminar where the presenter talked about clocking based on LRC oscillations and he had actually fabbed chips that worked. The basic idea was to put an inductor on the die, and set up oscillations between the inductor and the clock load capacitance, which results in a ticking clock. Of course, you get a sinusoidal clock instead of a nice almost-square-wave, so your circuits have to be designed a little bit differently, but the point is, it works and is doable.

Now, the technology described in this article, as best as I can tell, uses another idea - transmission lines. In a normal design, your clock grid basically looks like a bunch of capacitors with resistors in between (i.e. distributed RC). It takes time for a signal to propagate - signals propagate much slower than the speed of light, becuase you actually have to charge up the capacitance along the line through the resistance of the line itself. Imagine a long trough that's empty. You start pouring water in, and although water reaches the far side pretty quickly, you don't actually observe it until the water level at the far end is half way up. Signals propagate differently when wires are set up as transmission lines - they propagate at much closer to the speed of light, because you're actually sending a wave down the line (imagine creating a ripple on a trough of water, instead of actually filling and emptying the trough).

Now, I don't understand how they combined charge recycling and transmission lines, I don't understand transmission lines all that well, but your arguments aren't good reasons to disregard the claims made by the company.

If you're interested, here is a little bit of info about the talk I went to.

Typical example, that running signals in a circuit does not save power: take a ring oscillator (a number of negators wired in a loop). This circuit will oscillate (send changing signals through its loop) and consume an considerable amount of power.
If you created an oscillator between an inductor and a capacitor, on the other hand, once you started it going, it would continue for a long time with minimal energy injected in the future.

If you design user interfaces to secure applications, I highly recommend the O'Reilly book Security and Usability. It's a collection of classic and new papers on the topic. Simson Garfinkel's thesis is also a good reference on usability and security.

This has good advice in it, for engineers or anyone else: http://www.frc.ri.cmu.edu/~ssingh/RaibertGoodWriti ng.html

I recommend Carnegie Mellon for the same subject. Try the Center for Automated Learning and Discovery.

http://www.ml.cmu.edu/

So you want a completely detailed model of the world, down to bricks and individual grains of sand?
You want it all be simulated with physics so that you can interact with everything in a plausible way?

Well, I can tell you that any one of these things currently is a struggle to get to work at all,
even assuming you are willing to wait hours per frame. You want a pile of thousands of bricks
falling into a pile, with correct collision detection? This is an area of active research.

http://www.cs.cmu.edu/~djames/

You want the water on the beach to swirl and splash?
How about a piece of paper that you can burn?
Again, a challenging set of problems that we are just beginning to solve in a way that looks good.
http://graphics.stanford.edu/~fedkiw/

How about the snot you pull out of your nose?
You want to pick your nose and have the snot squish in a gooey fashion?
We can do it, but just barely, if you want to wait all week for a few seconds of animation.

http://www.cs.berkeley.edu/b-cam/Papers/Goktekin-2 004-AMF/index.html

Now, what you want is to combine all these simulations, plus many more.
Also you want it to run in real time on a desktop PC.

I predict we will have this in 50 years, and that is being extremely optimistic.
If Moore's law is really ending, then maybe much longer.

Hardware physics cards may be just the thing we need to make it possible one day.

It was probably 15 years ago that I first remember reading in Popular Mechanics about MIT (I think) instrumenting a big cargo van with the necessary sensors and computers to handle driving around a parking lot.

That was the CMU NAVLAB project, not MIT. And it was in 1994 that it successfully traveled across the US (only on freeways though). Actually, this grand challenge is easier than the previous ones. Road driving is easier on a computer vision system (better edges, more edges, and the edges mean more) than off-road driving. The tough part will be the interaction with other cars and the traffic signals.

Coda is the successor to AFS though I doubt it's much easier to administer.

Try the CODA file system: http://www.coda.cs.cmu.edu/

      1. disconnected operation for mobile computing
      2. is freely available under a liberal license
      3. high performance through client side persistent caching
      4. server replication
      5. security model for authentication, encryption and access control
      6. continued operation during partial network failures in server network
      7. network bandwith adaptation
      8. good scalability
      9. well defined semantics of sharing, even in the presence of network failures

The rest of this post I grabbed from my own comment on a Ask Slashdot story a few weeks ago about DNS management systems:
Carnegie Mellon's NetReg (*) is a DNS & DHCP management system (and much more) that we wrote in house to replace our previous database. We manage DNS & DHCP for 50K machines, and NetReg does it all. It is available under an OSS license and is in use at several other locations. NetReg provides a self service web interface with flexible permissions, privilege delegation, IP address space management, DNS record validation, and more.

As the current primary developer of the system I'm a bit biased, but I think its a great system. It has a steep learning curve, and the documentation leaves something to be desired (like a tech writer...), but once you hit a certain scale the benefits outway the cost. On the site linked above you'll find a working demo with some base data you can experiment with, but obviously the full power of the system isn't utilized until you have lots of data and can see the resulting zones & config files.

There is an active mailing list. Feel free to join it and ask questions.

*: Not to be confused with Southwestern University's NetReg, which is a completely different system developed in parallel around the same time. The two systems have some similar features, but SW NetReg doesn't do everything that CMU NetReg does.

The rest of this post I grabbed from my own comment on a Ask Slashdot story a few weeks ago about DNS management systems:
Carnegie Mellon's NetReg (*) is a DNS & DHCP management system (and much more) that we wrote in house to replace our previous database. We manage DNS & DHCP for 50K machines, and NetReg does it all. It is available under an OSS license and is in use at several other locations. NetReg provides a self service web interface with flexible permissions, privilege delegation, IP address space management, DNS record validation, and more.

As the current primary developer of the system I'm a bit biased, but I think its a great system. It has a steep learning curve, and the documentation leaves something to be desired (like a tech writer...), but once you hit a certain scale the benefits outway the cost. On the site linked above you'll find a working demo with some base data you can experiment with, but obviously the full power of the system isn't utilized until you have lots of data and can see the resulting zones & config files.

There is an active mailing list. Feel free to join it and ask questions.

*: Not to be confused with Southwestern University's NetReg, which is a completely different system developed in parallel around the same time. The two systems have some similar features, but SW NetReg doesn't do everything that CMU NetReg does.

The rest of this post I grabbed from my own comment on a Ask Slashdot story a few weeks ago about DNS management systems:
Carnegie Mellon's NetReg (*) is a DNS & DHCP management system (and much more) that we wrote in house to replace our previous database. We manage DNS & DHCP for 50K machines, and NetReg does it all. It is available under an OSS license and is in use at several other locations. NetReg provides a self service web interface with flexible permissions, privilege delegation, IP address space management, DNS record validation, and more.

As the current primary developer of the system I'm a bit biased, but I think its a great system. It has a steep learning curve, and the documentation leaves something to be desired (like a tech writer...), but once you hit a certain scale the benefits outway the cost. On the site linked above you'll find a working demo with some base data you can experiment with, but obviously the full power of the system isn't utilized until you have lots of data and can see the resulting zones & config files.

There is an active mailing list. Feel free to join it and ask questions.

*: Not to be confused with Southwestern University's NetReg, which is a completely different system developed in parallel around the same time. The two systems have some similar features, but SW NetReg doesn't do everything that CMU NetReg does.

I would like intelligent comment on this, maybe I set my goals too high.
I am manic depressive/bipolar as are most of my family.

ECT [shock therapt] has been successfully useful for one member of my family.

I dream about computer simulation being good enough to suggest some different approachs:

Connectionist Models of Bipolar Disorder
http://www.cnbc.cmu.edu/Resources/disordermodels/b ipolar.html

Connectionist Models of
Cognitive, Affective, Brain,
and Behavioral
Disorders
http://iora1.cnbc.cmu.edu/Resources/disordermodels /index.html

But then maybe that is a typical, to a programmer every information problem is a programming problem. I am beyond, if I was ever capable of, making innovative developments in this area but I just might try to put recent information in a more accessible format.

Anyone out there doing/reading interesting stuff along these lines?

Turloch

I would like intelligent comment on this, maybe I set my goals too high.
I am manic depressive/bipolar as are most of my family.

ECT [shock therapt] has been successfully useful for one member of my family.

I dream about computer simulation being good enough to suggest some different approachs:

Connectionist Models of Bipolar Disorder
http://www.cnbc.cmu.edu/Resources/disordermodels/b ipolar.html

Connectionist Models of
Cognitive, Affective, Brain,
and Behavioral
Disorders
http://iora1.cnbc.cmu.edu/Resources/disordermodels /index.html

But then maybe that is a typical, to a programmer every information problem is a programming problem. I am beyond, if I was ever capable of, making innovative developments in this area but I just might try to put recent information in a more accessible format.

Anyone out there doing/reading interesting stuff along these lines?

Turloch

I've reviewed the following:

Bluecat Networks Proteus/Adonis http://www.bluecatnetworks.com/
Incognito IP/Name/DNS Commander http://www.incognito.com/
INS IPControl http://www.ins.com/
Carnegie Mellon's NetReg http://www.net.cmu.edu/netreg
Lucent VitalQIP http://qip.lucent.com/
Solarwinds IPAM Pro http://www.solarwinds.net/
Men & Mice http://www.menandmice.com/
Infoblox http://www.infoblox.com/
IPPlan http://freshmeat.net/projects/ipplan
MetaInfo http://www.metainfo.com/

In hopes of replacing our current in-house developed solution.

I'll be honest, they are for the most part simply 'ok'. I wasn't super-impressed with any of them, and the bottom half of the list were definitely not ready for ISP/ASP/MSP-level use. I've listed them in descending order of my preference. All the useable ones are super-expensive, on the order of 'ok you can afford to pay a decent php/mysql coder to code you something from the ground up', or you can take this out-of-the-box thing, and shoe-horn it into your existing network. Which will in most cases take some weeks of programming anyway...

I had some of what I thought were pretty simple requirements...

- unix/linux based
- no single point of failure (clustering)
- handle forward and reverse dns
- api's (mostly to allow us to present a customer access to their zones)
- web-based gui with tiered user-levels
- pref software-based install rather than appliance, due to the shoe-horn prediction i mentioned above

Those are the highlights off the top of my head. I was surprised how few actually had all those features.

After months of doing webcasts, reading white-papers etc we've come to the conclusion that it's going to be developed in-house from the ground up, using bsd/apache/postgres/php/bind and some soap.

After reviewing these, I'm actually dying to know what large enterprises are using. I'm hoping there's some magic bullet IPAM solution that I missed on google. Please someone tell me about it!

Anyway, hope this helps you in your quest.

I just hope they don't patent it!

what CS problem that I might encounter in an upper-division CS course requires the use of Diff. Eq., Linear Algebra or Physics?

To pick just one example, the Kalman Filter, which is used for everything from radar tracking to helicopter stabilization, relies on linear algebra. And physics gives an excellent background in learning to apply mathematical modeling techniques to real-world phenomena. One of the best (or at least most interesting) distributed version control systems out there, Darcs, was written by a physicist, in the Haskell programming language (the latter of course being based on the lambda calculus, another seemingly esoteric subject which is so fundamental that it really ought to be taught in high school). Darcs is based on a physically-inspired theory of patches.

There's a problem here which was described by Paul Graham as "The Blub Paradox" (in Beating the Averages). Graham writes "But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up." It's not easy to correctly assess that which you do not (yet) understand.

The other side of the story is that you're totally right about coding being different from CS. The problem is that most HR/Business types don't know the difference.

I agree, this is a big part of the problem. This comes from the fact that everything about computers, and particularly software, is so relatively new. As alluded to elsewhere in the thread, you don't get HR people trying to hire mathematicians or even economists for accounting positions - they know better than that. They just don't know better than that, yet, when it comes to programming, particularly in "IT". And this confusion affects academic curricula, too - universities want to satisfy the commercial demand with subjects they already teach, and academic computer scientists don't want to turn themselves into a Java instructors any more than they absolutely have to.

It seems the best course of action is to expand software engineering programs to fill the void and make sure those are focused on turning out pratical, level-headed engineers who can solve a variety of problems but do not care to learn any more about math or physics than it takes to get an equation from a mathematician or physicist and implement it.

I think that'd be a start. However, I also think we'll eventually find that the tentacles of software are so diverse that "software engineering" is too broad a subject, and we'll end up with a "software school" analog to "medical school" or "law school", where a wide variety of subjects are taught, including theory, engineering, and other topics. I notice CMU has a "School of Computer Science already, and Northeastern has a College of Computer and Information Science, but most other institutions still treat CS and related disciplines as a "department".