Slashdot Mirror

There's a field called Grammar Induction, and the problem of learning regular languages, aka regular inference, can be considered a subfield. People have been working on this since the '50s. Applications include learning DTDs for XML/wrapper induction, and all kinds of problems in bioinformatics and natural language processing.

There's a strong link with the graph coloring problem, see
http://www.cs.ru.nl/~sicco/papers/alt12.pdf

In this field, the focus is generally on learning FSAs, but these can easily be transformed into regexps. There's work on learning regexps directly, see
http://www.informatik.uni-trier.de/~fernau/papers/Fer05c.pdf

Enjoy.

Now I know why slashdot asks you to use preview mode to double check those urls....how about: http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/j/Jaffe:Jeffrey_M=.html

It is fine to argue with Jeff's software philosophy, his use of buzz words in his blog, or his politics. But he is not an idiot MBA who doesn't know his way around a PC. He is a Fellow of the ACM and IEEE (for his technical contributions in algorithms and computer networks). He was a researcher before he became a corporate exec (see his publications at http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/j/Jaffe:Jeffrey_M=.html/ and http://portal.acm.org/results.cfm?coll=portal&dl=ACM&query=Jeffrey+M.+Jaffe&short=1/).

First, it's probably worth noting that there is a big gap between the majority of what academia considers "PLs research" and what you sound like you're interested in, which is more inventing languages on a semi-ad-hoc basis. Things like Python, Perl, Ruby, etc., didn't come out of academia, and are not greatly studied in the field of PLs. I'm not saying this is because they aren't worthy of study, it's just how it is--- if anything I think both those languages and academic PLs could actually benefit from more mixing, as those languages take a very programmer-centric view (language as a user interface), which I think is correct, but academic PLs knows a lot more about implementing them in ways other than "naive interpreter" and avoiding weird semantics edge cases that have to be patched over.

As for what academic PLs does do, probably a bit under half of it is currently working on functional languages and type systems; I'd say Haskell in particular is basis of the plurality of current PLs research. In that context, you wouldn't really be inventing a new language, but you would more likely be finding new language features and working out both the theory and practice of how to add them into Haskell. Besides Haskell, there are also pockets here and there working on the various ML languages, Clean, and a few others.

The other big concentration is a bit more real-world, engineering-oriented, mostly involving bolting features onto existing, widely-used programming languages to bring some of the advantages of "modern" languages without changing the original language too radically. These take the form of either extended static checkers, or conservative language additions, leading to things like Cyclone, ESC/Java, and so on. The classic lint goes in this category to some extent.

A third, sort of cross-cutting concern, is anything to do with language support for multithreading and concurrency. There is obviously a lot of interest in such things lately, almost regardless of where it gets bolted in.

If you want to do any of the above three concentrations, there are dozens of schools to choose from. Do make sure you look at the specific school to see if it does a specific one, though: many schools' PLs groups are small, and if you go somewhere with two people working on Haskell, and want to work on program verification in a subset of Java, you're in the wrong place.

If you want to do something else, then you need a much more narrow search to find a specific faculty member doing what you want. One suggestion for how to find them would be to scan through the proceedings of recent PLs conferences to find papers that sound like something in the area of what you'd like to do, then find where the people who wrote those papers work. Some of the major conferences are POPL, ICFP, and OOPSLA.

First, it's probably worth noting that there is a big gap between the majority of what academia considers "PLs research" and what you sound like you're interested in, which is more inventing languages on a semi-ad-hoc basis. Things like Python, Perl, Ruby, etc., didn't come out of academia, and are not greatly studied in the field of PLs. I'm not saying this is because they aren't worthy of study, it's just how it is--- if anything I think both those languages and academic PLs could actually benefit from more mixing, as those languages take a very programmer-centric view (language as a user interface), which I think is correct, but academic PLs knows a lot more about implementing them in ways other than "naive interpreter" and avoiding weird semantics edge cases that have to be patched over.

As for what academic PLs does do, probably a bit under half of it is currently working on functional languages and type systems; I'd say Haskell in particular is basis of the plurality of current PLs research. In that context, you wouldn't really be inventing a new language, but you would more likely be finding new language features and working out both the theory and practice of how to add them into Haskell. Besides Haskell, there are also pockets here and there working on the various ML languages, Clean, and a few others.

The other big concentration is a bit more real-world, engineering-oriented, mostly involving bolting features onto existing, widely-used programming languages to bring some of the advantages of "modern" languages without changing the original language too radically. These take the form of either extended static checkers, or conservative language additions, leading to things like Cyclone, ESC/Java, and so on. The classic lint goes in this category to some extent.

A third, sort of cross-cutting concern, is anything to do with language support for multithreading and concurrency. There is obviously a lot of interest in such things lately, almost regardless of where it gets bolted in.

If you want to do any of the above three concentrations, there are dozens of schools to choose from. Do make sure you look at the specific school to see if it does a specific one, though: many schools' PLs groups are small, and if you go somewhere with two people working on Haskell, and want to work on program verification in a subset of Java, you're in the wrong place.

If you want to do something else, then you need a much more narrow search to find a specific faculty member doing what you want. One suggestion for how to find them would be to scan through the proceedings of recent PLs conferences to find papers that sound like something in the area of what you'd like to do, then find where the people who wrote those papers work. Some of the major conferences are POPL, ICFP, and OOPSLA.

First, it's probably worth noting that there is a big gap between the majority of what academia considers "PLs research" and what you sound like you're interested in, which is more inventing languages on a semi-ad-hoc basis. Things like Python, Perl, Ruby, etc., didn't come out of academia, and are not greatly studied in the field of PLs. I'm not saying this is because they aren't worthy of study, it's just how it is--- if anything I think both those languages and academic PLs could actually benefit from more mixing, as those languages take a very programmer-centric view (language as a user interface), which I think is correct, but academic PLs knows a lot more about implementing them in ways other than "naive interpreter" and avoiding weird semantics edge cases that have to be patched over.

As for what academic PLs does do, probably a bit under half of it is currently working on functional languages and type systems; I'd say Haskell in particular is basis of the plurality of current PLs research. In that context, you wouldn't really be inventing a new language, but you would more likely be finding new language features and working out both the theory and practice of how to add them into Haskell. Besides Haskell, there are also pockets here and there working on the various ML languages, Clean, and a few others.

The other big concentration is a bit more real-world, engineering-oriented, mostly involving bolting features onto existing, widely-used programming languages to bring some of the advantages of "modern" languages without changing the original language too radically. These take the form of either extended static checkers, or conservative language additions, leading to things like Cyclone, ESC/Java, and so on. The classic lint goes in this category to some extent.

A third, sort of cross-cutting concern, is anything to do with language support for multithreading and concurrency. There is obviously a lot of interest in such things lately, almost regardless of where it gets bolted in.

If you want to do any of the above three concentrations, there are dozens of schools to choose from. Do make sure you look at the specific school to see if it does a specific one, though: many schools' PLs groups are small, and if you go somewhere with two people working on Haskell, and want to work on program verification in a subset of Java, you're in the wrong place.

If you want to do something else, then you need a much more narrow search to find a specific faculty member doing what you want. One suggestion for how to find them would be to scan through the proceedings of recent PLs conferences to find papers that sound like something in the area of what you'd like to do, then find where the people who wrote those papers work. Some of the major conferences are POPL, ICFP, and OOPSLA.

These folks seem like trollity-troll-trolls.

There is at least one outstanding challenge on the internet to recover a drive that has been overwritten just once with zeros. No one has accepted this challenge in over a year. Beyond that we now know that the assumptions that Peter Gutmann made when writing his seminal works in the mid-nineties about data recovery are complete hogwash. Once such assumption is that you know what data it is that you would like to recover. Why would you need to recover the data then if you have perfect knowledge of the data.

A new paper was published in December showing experimental data to back up how possible/impossible it is to recover data from a drive that has been overwritten once with any known pattern. They show that if you try to recover data from overwritten areas your likely hood of data recovery become astronomically low once you start trying to recover more than 32 bits of contiguous data. Add to that the time required to attempt the recovery. With Magnetic Force Microscopy (MFM) you can scan a disk platter at a speed of 1 byte every 4 minutes. This speed will change over time, but based on the research in this paper that still makes anything more than bit recovery unlikely and would be a huge time sink for anyone with appropriate technology and would most likely yield little useful information.

I recommend anyone in that deals with hard drive decommissioning read this paper.

Here's the link to the paper.

And here's a link to the BibTex entry.

Destructive analysis wont work if they are using a coating PUF. There are many crypto algorithms which work with low power requirements. Additionally, Veryao is a based on work done by Dr. Srini Devdas who is a pioneer in the area of PUFs

actually thats not completely true. in the security world he might be highly regarded but in the crypto world things are... different. look at a list of his publications. Most all are at security conferences. For that matter since 2005 he has published one paper. He has only ever published 2 papers at Crypto, 1 at Eurocrypt and none at TCC. (These being the most selective conferences in the crypto community.) Nor does he have any papers at PKC, CHES, RSA, SCC, Asiacrypt, CSN, and only one paper at Fincial Cryptography which are some second and third tier conferences.

The main exception are his FSE (fast software encryption) papers but here too it's since 2000 he's only produced 1 paper and that had 6 authors. However before that (in the 90s) he did have a string of relatively interesting papers related to cryptanalysis mainly together with John Kelsey who is a much more prolific cryptanalyst even in recent years. For example he has 5 papers in Eurocrypt and Crypto. As a measure of FSE vs. Crypto also for the field of cryptanalysis, the major MD4, MD5, SHA-0 and SHA-1 breaks were all published at Crypto.

Basically what i'm saying is that he is great in security and even respectable in the most practical corner of crypto. But there are many many people out there who have a much more impressive track record as far as pure crypto is concerned.

I guess the best testament to how seriously some people out there take him would be this collection of useful facts.

Line 1 of the abstract: "Two years ago, some of us wrote a paper ... 'One Size Fits All (OSFA)' [Sto05a]." Looking at the references indicates that the paper in question is:

Stonebraker and Cetintemel. "One Size Fits All: An Idea Whose Time has Come and Gone." In: ICDE, 2005.

Back around 1990-1991, there were also a bunch of HP and Apple people involved with OMG. Some of the HP people migrated over to Sun, and tricked Sun into starting Project DOE (Distributed Objects [Practically] Everywhere).

Michael Powell was "Mr. DOE" at Sun. Before going to Sun, he worked on a Modula-2 compiler . He thought C++ had a really beautiful object model ("once you get past all that other stuff"), and didn't think anybody could understand Lisp (and didn't want anything to do with it). Nobody in the company actually knew what DOE really was but Michael Powell, so if you wanted to know, you had to go ask him, and he'd tell you what he thought you wanted to hear at the time, because he hadn't ever bothered to write it down. That was how he consolidated his power and kept a grip on his position as the architect of DOE, because nobody could pin him down about anything. So after years of development, DOE was so late and bloated that Sun finally released it on *TWO* CDROMs (unheard of at the time).

Arthur van Hoff (who previously developed HyperLook for NeWS, and later wrote the Java compiler in Java, and founded Marimba) didn't think DOE was usable, so he sat down one day and rewrote a tiny version of DOE from scratch called "DOE-Lite", which everybody in their right mind used instead of the official bloated DOE release. Arthur then proceeded to use DOE-Lite to make a distributed object trading demo which Sun demonstrated on the show floor at Object World. Ironically, he implemented using the (then canceled) NeWS window system, instead the officially sanctioned DOE user interface toolkit (because the official DOE gui was vaporware).

Sun put a lot of different colors of lipstick on that fat old pig, DOE: they renamed it "NEO", and then they tried to pawn it off as a back-end to OpenStep (NeXTStep, which they later gave up on), and eventually they tried to imply that it had something to do with Java.

I'd love to know what happened to DOE architect Michale Powell since his reign at Sun back around 1991! (No he's not Colin Powell's son, head of the FCC.) Had anyone heard from Michael Powell ever since? Where is he now? Does he have anything interesting to say about what went wrong with DOE?

-Don

I've been working with SQL since 94 (12 years) - Microsoft SQL Server 4.2 on OS/2, no less. I know that SQL was around for quite a while before that because the standard used then was SQL-89.

CJ Date's book was published in 1975, so I'm sure it was around before then, too. http://dblp.uni-trier.de/rec/bibtex/books/aw/Date7 5/

Layne

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 =

There already exists such a tool, delevoped by a grad student at my school. It really sucks if the professor starts writing on the chalk board, but other than than that its actually pretty useful. The average lecture including video and audio usually takes up ~90 megs (lectures are 90 mins longe here), which is with the current broadband standards quite usable.

Much of this is not correct.

Firstly, the Anglosphere has a long tradition of research into the study of signs and symbols. See, for example, Peirce (pronounced "purse").

Secondly, the term "semiotics" is wide-spread in English-speaking communities, while the term "semiology" (or varaints) tends to crop up in European discussion.

Thirdly, the fields mentioned may make use of semiotics, but semiotics is a discipline in its own right, with its own journals and authors. Just because a particular Slashdotter has only encountered these concepts in a cognitive science course does not mean that they enjoy no independent existence. (Calculus exists independently of engineering!)

Fourthly, semiotics is often broken down - very loosely - into three areas: syntactics (the form of signs), semantics (meaning of signs) and pragmatics (use of signs). Hence, semantics is one area of semiotic study.

To find out more about how the study of signs and symbols intersects with computers and information systems, try this bibliography. In particular, the work of Ron Stamper is quite influential.

I strongly recommend this highly-readable introduction to semiotics.

Guess what? The real contribution is in the advancement of the field. That is, the generation of new ideas! Tanenbaum is just slightly ahead here. Compare http://www.informatik.uni-trier.de/~ley/db/indices /a-tree/t/Tanenbaum:Andrew_S=.html to http://www.informatik.uni-trier.de/~ley/db/indices /a-tree/t/Torvalds:Linus.html And yes, new ideas aren't always practical--very few are actually. But new ideas are the catalyst for better ideas.

Guess what? The real contribution is in the advancement of the field. That is, the generation of new ideas! Tanenbaum is just slightly ahead here. Compare http://www.informatik.uni-trier.de/~ley/db/indices /a-tree/t/Tanenbaum:Andrew_S=.html to http://www.informatik.uni-trier.de/~ley/db/indices /a-tree/t/Torvalds:Linus.html And yes, new ideas aren't always practical--very few are actually. But new ideas are the catalyst for better ideas.

Interacting with the environment in a manner like C-3PO is not neccessary in order to be intelligent. Otherwise, Steven Hawking and Christopher Reeves would not be considered intelligent.

That's why the Turing Test was specified to take place over a teletype. It didn't take long for a program to pass the Turing Test either. Anecdotally Eliza fooled a leading scientist in the field of AI. She is still fooling people today.

AI programs are being used to sentence criminals, split assets after a divorce, and approve legal aid applications according to a recent article in the Tech Review.

I remember reading about a program in the eighties that proscribed antibiotics. It was a difficult problem for physicians because infections often involve multiple types of bacteria, antibiotics vary in how effective they are and what they are effective against, many antibiotics are contra-indicated by others, and there are many reasons to want to use the minimum number and dosages. The program was able to create better prescriptions than the doctors, and it was able to explain why it choose what it did.

I couldn't find the paper that described the prescription program, but the Journal of Artificial Intelligence in Medicine probably has plenty of descriptions of AI making choices in a "real capacity".

You cannot define "truely human thought and thought processes", so you cannot judge when machines have reached that level. The history of AI is filled with people claiming some skill or ability required human-level intelligence, and then deciding that the software didn't have human level intelligence when it aquired that skill. There was the Turing Test in the beginning, chess now, poker and Go are next.

Google Scholar is not an attempt to replicate repositories like citeseer and the like. It is a specialized search service! If I search for a paper using Scholar, I get links from many different repositories, and from the web site of the authors. That's what this is all about. Furthermore, as a researcher, I always use plain Google or Google Scholar to locate papers, and I do have access to every other service. Google is just better at it than any other service. Do you know why? Because it gets the job done without any brain damage search language, without broken links and it searches the whole web, not just your random journal list. Can Google Scholar improve? Sure, but the article is pretty biased against a free (as in beer) service.

Also, there are other great free indexes out there that are not even mentioned in the article, like DBLP.

I saw nothing in that paper that makes me think he's "great" at anything. And he's definitely not a researcher, he's a VENDOR, no matter what his title

Yup. 122 papers and an ACM Turing award (the highest honor in computer science) doesn't make anybody great, much less a researcher.

I'd put my money on it being Clustra any day. Why would Sun want to fool around with MySQL, or Postgres, or Ingres when they have their own HA DBMS and a truck load of developers.

Clustra was developed by Svein-Olaf Hvasshovd, Oystein Torbjornsen, and Svein Erik Bratsberg http://www.informatik.uni-trier.de/~ley/db/indices /a-tree/h/Hvasshovd:Svein=Olaf.html. Looks like Svein-Olaf - Sophus - went back to Norwegian University of Science and Technology in Trondheim. But Oystein and Svein-Erik still work for Sun at the Trondheim office.

For extra credit read:

http://research.solidtech.com/publ/drake-isas04-ha db.pdf - note location of Sun credits to this paper.

Wirth published "The Programming Language Pascal" in 1971 in Acta Informatica, Volume 1. Pascal is 33 years old!

witness sentences like Er hat mich um gebracht which certainly has nothing to do with bringen.

Well, his resume is NOT extraordinary.

actually, his
CV does look quite amazing.

Is it normal for companies like SGI and Cray to have `oil and gas industry analysists' or a
'Director of Complex Scientific Computing Projects'? The only site referencing the latter term is his, not SGI's.

I'm not saying the CV is a fake, but some of it I just don't understand. For someone that has worked at Cray's Research departement and was the aforementioned director at SGI he hasn't published a lot. Citeseer doesn't know him, neither does DBLP. To be fair, publications in french wouldn't be indexed. Then again, he (allegedly) worked for american companies.

Google has a few pages with his emailadres @cray from '95, but that doesn't say the address is correct. AFAIK Cray has never had a french research departement.

So, is this harmless resume embellishment or more? Hopefully I'm just getting paranoid. Roland, if you're listening, perhaps you can explain (or update your CV).

Well, maybe is not a fully know process, but as you seems to know, there's a of lot work done in that area, and my expressed opinion is quite common in the field, so I don't understand why you try to emphasize firing rate as a limiting factor.

Of course higher frequencies are being detected and passed on to the brain; but absolute phase information, as far as anyone can tell, is not preserved beyond that few kHz limit."

I've never pretended that phase information is preserved, just that is not irrelevant, quite the contrary.

Again, your evidence to the contrary is welcome. Try to be specific and cite research wherever possible.

Easy, take a look at the work of Liaw and Berger on adaptative synapse simulation.
Now, could you please indicate some research work that provides some facts about the limits of neuron firing phase shifts effects?, Note that the work I've cited specifically adresses that point, and strongly (succesful and patented simulations) suggest the contrary,specifically read the work on computational capabities of pre and post adaptative synapse behaviour.

1. Cormack is very inexperienced in the area of statistical filtering.

Disagreed. Gordon Cormack has been doing information retrieval for 20 years. He is fairly well known in the area. See his publication history at DBLP.

A far more likely conclusion about what's going on here is that Zdiarski's ego has been hurt. Both he and Dr. Yerazunis engage in some very sketchy statistics in their papers and I think that it has caught up to them.

1. Yerazunis' study of "human classification performance" is fundamentally flawed. He did a "user study" where he sat down and re-classified a few thousand of his personal e-mails and wrote down how many mistakes he made. He repeats this experiment once and calls his results "conclusive." There are several reasons why this is not a sound methodology:

a) He has only one test subject (himself). You cannot infer much about the population from a sample size of 1.

b) He has already seen the messages before. We have very good associative memory. You will also notice that he makes fewer mistakes on the second run which indicates that a human's classification accuracy (on the same messages) increases with experience. For this very reason, it is of the utmost importance to test classification performance on unseen data. After all, the problem tends towards "duplicate detection" when you've seen the data before hand.

c) He evaluates his own performance. When someone's own ego is on the line, you would expect that it would be very difficult to remain objective.

2. Both Yerazunis and Zdziarski make use of "chained tokens" in their software. This is referred to in other circles as an "n-gram" model. As with many nonlinear models (the complexity of an n-gram model is exponential with n), it is very easy to over-fit the n-gram model to the training data. Natural language tends to follow the Pareto law (sometimes called the 80/20 rule) where the ranking of a term is inversely proportional to the frequency of occurence of that term. The exponential complexity of the n-gram model contributes to the sparse distribution of text leading to a database with noisy probability estimates.

3. Zdziarski uses a "noise reduction algorithm" called Dobly to smooth out probability estimates in the messages. Aside from his unsubstantiated claim of increased accuracy, I have never seen anything to suggest that it actually works as advertised.

Considering these points, I was not surprised at all by the results of Dr. Cormack's study. While one may argue that his experimental configuration can use some improvement, his evaluation methods are logically and statistically sound. What I personally saw in the results of this paper was that two classifiers that use unproven technology did not perform as advertised. After all, every other Bayes-based spam filter performed acceptably well.

Lastly, I won't really touch his flawed arguments about how using domain knowledge about spam (i.e. SpamAssassin's heuristic) somehow hinders the classifier over time when you are also using a personalised classifier. You'll notice that SpamAssassin still did acceptably well when all of the rules were disabled.

Go read some more of Zdziarski's work and draw your own conclusions about his work. Pay careful attention to his use of personal attacks when comparing his filter to that of others.

watching a presentation from someone

about some "wonderful" new product

Maybe so, but it's been done, at least on a smaller scale.

Simson Garfinkel eventually became a hermit and withdrew from public life after too many people mistook him for Art Garfunkel. He now lives in a cave in southern California.

Daniel Weise went on to work at Microsoft. He distinguished himself as the first non-Samoan to ever pick up Bob Barker after winning the Showcase Showdown on "The Price Is Right."

Steve Straussman (no website, sorry -- anyone?) left the Unix-Hater's list after it was revealed that he had fallen in love with a woman who loved Unix. He has come to terms with the past, and now teaches "How to Shell Script in Linux" classes at his local community college.

John Klossner went on to a successful career making cartoons for Lucas' Skywalker Sound company newsletter, until fired for printing one that suggested an unnatural intimacy between Luke Skywalker and Chewbacca.

Donald Norman won the coveted "Golden C< Prompt" award and retired from public life.

Dennis Ritchie became something of a celebrity on the web for his many and varied contributions of photos to Engrish.com.

Scott Burson became a monk and moved to Iceland.

Don Hopkins ran for office in Lousiana and lost. He is now a semi-successful insurance salesman, and plays harmonica regularly.

That was all I could find out about -- anyone got any more?

I bought it back in january, after first learning about AOP. At the time, it was the only book I could find directly on AOP, with a second coming in feb. Otherwise, the only other text source I could find was Generitive Programming.

So I bought it, and I was excited when I began reading. Then I found out it was just a bunch of JSP and other then the first 25 pages, very little content. Now I admit I put it down a good 25 or so pages later and skimmed through the rest, but I was extremely disapointed in it. Instead I've been grabbing all of the ECOOP workshop documentation.

In the end, it was worth the money. No, not for the book, god no! But by getting me excited and reading the ACM Communication articles and then talking to my adviser about it. It turns out the editor for the AOP material in the ACM communications is a professor at my school, and even better is happy to let me help her out next semester (I'm extremely swamped now). So now I'm considering doing the thesis option on my masters. I'll spend the summer reading REAL material.

My opinion: AOP is awesome but the book is a waste of money. Here are a few good readings:

Alternatives to AOP
Generitive Programming chapter
AOP publication
AOD 2002 workshop
ECOOP97

Athlons have circuitry to disconnect from the system bus when idle (on a signal from the Northbridge, which gives the signal when the OS enters the ACPI C2 idle state), reducing clock rate and essentially going into a standby mode (~5W power consumption). Unfortunately, it's not enabled by default, partly due to minor performance problems (~3% is the normal performance hit), and partly due to intermittent problems with some motherboards, especially when using PCI bus-mastering cards that require low latency (such as video capture cards). I'm not sure why it's not available as a BIOS option though.

In any case, you can enable it manually by setting the relevant bit in the Northbridge. For Linux, see the Athlon Powersaving HOWTO for a variety of methods to enable it.

For Windows, there's a utility called VCool, whose site was at vcool.occludo.net, but it appears to have disappeared in the past week or two.

When idled using the setpci trick mentioned in the HOWTO, my Athlon 1.33 GHz, which used to idle at 57 C, now idles at 33 C (case temp is 31 C, so it's generating very little heat and by extension using very little power, especially compared to what it used to do).

Isn't it a little harsh how they're going after this guy as incompetant? Read his answers- you'll see that he's doing his best to tell the truth and give factual information, as opposed to blurt out opinions.

Look the guy up. Read his Bio. Look at his list of papers. The dude was a bigshot on IBM's VM/370, has BS/MS in EE, Masters in Management, and a Ph.D. in CS (from MIT).

My point is that its easy to slam someone because "he so smart, but don't he ain't know nothin' about KDE". This article (ahd /.) makes him out to be an idiot, which I'll bet he's not..

One very nice thing about BibTeX is that you can get BibTeX citations for papers directly from the ACM Digital Library (sometimes), from DBLP, or from Citeseer -- so you download the paper, view it, and if you like it, cite it! There are also many large repositories of BibTeX entries for all manner of papers available, especially in the DB and OO communities -- just do a google search for "inproceedings" and a favorite author if you don't believe me. :-)

You might call Dr. Gray a researcher. He won the Turing Award in 1998 for his many contributions to the field of computer science.

http://www. inf ormatik.uni-trier.de/~ley/db/journals/cacm/turing. html

Sheesh.

To my surprise, he does seem to be a genuine person (not an april fool invention, etc) and a bona-fide mathematician. A quick search on google shows he's been around a ... so he really does think he has P=NP!? I have an nice'n'dodgy degree in mathematics, and I have to say I'll believe it when it's been seriously peer-reviewed. Of course, if P=NP, all our trapdoor-encryption starts to look a lot more susceptible...

Also, a silly plug, we (the monarch group) haven't updated our latest internet draft because we've been busy writing working code =) Another interesting protocol is DSR: http://www.monarch.cs.cmu.edu/ietf.html

Of course, people actually downloading the whole human genome probable wouldn't worry about this, but couldn't they use a better compression format than .zip? I bet using bzip2 or rar would shave a couple of hundred MBs off of that 753MB file. Also, the differences in compression techniques would be interesting to see on a large group of files mainly consisting of G, A, C, and T. -- demiurge You find a file that appears important and obliterate it from memory!!! Score one for the downtrodden hacker!

• G -- 00
• A -- 01
• T -- 10
• C -- 11

This would only work for the .fa files, but .fa files can contain "N"s also. If you just want to browse the Genome, look through the pieces directory. .

except for one-time pads, encryption methods today cannot be "proven" in a rigid scientific manner, which means that you can never trust them 100%. There have been a number of conspiracy theories over the years about NSA. For example DES, was initially developed by IBM. NSA suggested a change to S-box which supposedly made the algorithm more secure. I believe IBM never commented as to why they accepted this change, but many people feared it added a backdoor. Through the years many symmetrical algorithms have come and gone and DES was one of the few that held it's ground against newer crypto-analysis.

Check out

Generating Hard Instances of Lattice Problems M. Ajtai. ECCC on line Tech reports TR96-007 http://www.eccc.uni-trier.de/eccc/

of course I'm not say the system proposed is pratical at the moment.

except for one-time pads, encryption methods today cannot be "proven" in a rigid scientific manner, which means that you can never trust them 100%. There have been a number of conspiracy theories over the years about NSA. For example DES, was initially developed by IBM. NSA suggested a change to S-box which supposedly made the algorithm more secure. I believe IBM never commented as to why they accepted this change, but many people feared it added a backdoor. Through the years many symmetrical algorithms have come and gone and DES was one of the few that held it's ground against newer crypto-analysis.

Check out

Generating Hard Instances of Lattice Problems M. Ajtai. ECCC on line Tech reports TR96-007 http://www.eccc.uni-trier.de/eccc/

of course I'm not say the system proposed is pratical at the moment.