Slashdot Mirror
Jean-loup Gailly On gzip, go, And Mandrake
1) bzip2 Support
by Aaron M. Renn
When is gzip going to provide (transparent) support for bzip2 files and the Burrows-Wheeler algorithm?
Will BW be an algorithm option within the gzip file format itself ever?
Gailly:
I have worked very closely with Julian Seward, the author of bzip and bzip2. The goal was to integrate a Burrows-Wheeler algorithm inside zlib 2.0 (upon which gzip 2.0 is based). One of the requirements was to avoid the kind of arithmetic coding used in bzip because of both patent and decoding speed concerns, so Julian wrote the Huffman coding code now used in bzip2. Another requirement was to put the code in library form and Julian did that too.
Unfortunately, Julian decided to release bzip2 independently instead of staying within the gzip 2.0 project. It was mainly my fault, since I couldn't spend enough time on the other parts of the project, and the project was not advancing fast enough. Since Julian left, the project progressed even more slowly, and new blood is obviously necessary, because other responsibilities no longer leave me enough time for gzip. If you're an expert in data compression, e-mail me to convince me that you are the most qualified person to turn the zlib/gzip 2.0 project into an overwhelming success :-)
2) The Data Compression Book
by drudd
I am a happy owner of The Data Compression Book (2nd Ed). With the increasing availability of compression routines within libraries (Java's GZIP streams spring to mind), does this make your book a little unnecessary?
Should software authors continue to write their own compression routines, or simply trust the versions available to them in library form?
I can see some definite advantages to library code, i.e. the ability to upgrade routines, and having standardized algorithms which can be read by any program which utilizes the library.
Gailly:
The compression routines in The Data Compression Book were written mainly for clarity, not for efficiency. The source code is present to help understand how the compression algorithms work. It is not designed to be used as is in other software packages, although it does work if efficiency is not a concern. Consider the book as teaching material, not as a data compression library distributed in printed form.
This doesn't mean that the book is unnecessary. Good data compression libraries don't appear magically; their authors had to learn compression techniques one day. If the book helps one person to get started in the data compression area and this person later writes a great compression library, the book will have been useful.
Judging by the success of my zlib data compression library, I think that a vast majority of software authors prefer using an existing library rather than reinventing the wheel. This is how the open-source model works: building upon the work of others is far more efficient than rewriting everything.
3) Compression patents
by Stephen
The compression world has many patents, notably for Lempel-Ziv compression as used in GIF. What is your view on companies patenting non-obvious algorithms for such processes as data compression?
Gailly:
The worst problem is companies patenting obvious algorithms. There are far more patents on obvious ideas than patents on really innovative ideas. In the data compression area, even something as basic as run-length encoding (replace "aaaaa" with a special code indicating repeat "a" 5 times) has been patented at a time where this technique had been well known and widely used for many years.
It is distressing to see the U.S. patent office granting such patents, in contradiction with the law requiring an idea to be both novel and non-obvious to be patentable. Philip Karn has made a good analysis of the problem.
Patents on non-obvious algorithms are a different matter. One view is that algorithms should not be patentable at all, whether obvious or not. This used to be the case, until the US patent office started to grant patents on methods which were nothing else than pure algorithms. I'm afraid that a switch back to the original situation is extremely unlikely.
Several reforms are necessary:
- The patent term should be significantly shortened, at least for algorithms. The patent system was designed to benefit society as a whole, ensuring that new ideas would eventually be made public after a limited period of time instead of being kept as trade secrets. But 20 years is incredibly long in the software area. Granting a monopoly for such a long time no longer benefits society.
- The non-obviousness requirement should be applied much more strictly. A little bit of common sense would avoid a lot of patents on trivial ideas.
- Prior art should be checked more thoroughly. Even non-obvious ideas should not be patented if they have been in use for several years already.
4) A question about Mandrake...
by Mr. Penguin
As we all know, at first Mandrake was little more than a repackaged version of Red Hat. That's changed a bit with the newer versions. My question is this: to what degree will Mandrake continue to differ from RedHat and will there ever be a "developer" version (i.e. one that is centered towards those who are a bit more technically competant)?
Gailly:
That's changed more than a bit. Our distribution is now completely made by us. Believe me, doing everything ourselves represents a significant amount of work. Few people understand how much work is involved in making an independent distribution. We have our own development teams producing things like our graphical install DrakX, our disk partionner DiskDrake, management of security levels in msec, hardware detection with Lothar, etc... Our packages are more recent than those of Red Hat and have more functionality (such as supermount support in the kernel). Red Hat is now even copying packages made by MandrakeSoft (e.g. rpmlint). I hate having to speak like a salesman here, but it is really unfair to say that Mandrake just repackages RedHat; this is simply not true anymore.
Have you looked at Linux-Mandrake 7.0? It does include a developer version. At install time, select the option "Custom" then "Development". You will get all necessary development tools. We, as developers, use our own distribution :-)
5)Why is Mandrake better than Red Hat?
I guess that you have at least a little something to say about this.
Is the 586 optimization enough to justify Mandrake's position? Are you especially proud of any of the architectural differences between the distributions (from what I have been told, the Apache-PHP layout is quite a bit different).
How do feel about the steps that Red Hat has taken to change their distribution in reaction to yours?
Gailly:
Mandrake is far more than Red Hat plus 586 optimization. It is an independent distribution. (See the answer to A question about Mandrake above.) We have enhanced some packages (such as the kernel or Apache) to provide additional functionality for users.
It's clear that Mandrake pushes Red Hat to improve its own version and nowdays Red Hat includes some development from Mandrakesoft. There is a coopetition: Red Hat and MandrakeSoft both benefit from the same open-source community, but they compete for the customer. This coopetition is fully beneficial for the Linux users since we both need to constantly improve our version. We just make sure that Mandrake stays ahead :-)
6)Winzip
by Uruk
I noticed that you allowed the people who make the Winzip product to incorporate code written for Gzip. I think it's cool that you did that, because it would be horrible if winzip couldn't handle the gzip format, but at the same time, what are your thoughts about allowing free software code to be included in closed-source products?
Just out of curiosity, (tell me it's none of my business if you want to and I'll be OK with that) did you receive a licensure fee from the company that makes Winzip for the code?
Gailly:
I started writing compression code simply because my 20 MB hard disk, the biggest size one could get at the time, was always full. I didn't write it for money. Even after I got a bigger hard disk, I continued writing compression code for fun. In particular I was not interested in writing a Windows interface. This is why I allowed my code to be used in Winzip. I received exactly 0$ for this.
The zlib license also allows it to be used in closed-source products. This was an absolute requirement for the success of the PNG image format, which relies on zlib for data compression. If we had used a GPL license, Netscape and Microsoft Explorer wouldn't support PNG, and the PNG format would be dead by now. I also received 0$ for zlib, if you're curious...
Even though I allowed my code to be used in closed-source products, I am a strong supporter of the open-source model. That's also why I work for MandrakeSoft. The open-source model is getting so much momentum that it will in the end dominate the software industry.
7) What about wavelets? by Tom Womack
The Data Compression Book was an excellent reference when it came out, but there are some hot topics in compression that it doesn't cover - frequency-domain lossy audio techniques (MP3), video techniques (MPEG2 and especially MPEG4), wavelets (Sorenson video uses these, I believe, and JPEG2000 will), and the Burrows-Wheeler transform from bzip.
Do you have any plans for a new edition of the book, or good Web references for these techniques? BZip is covered well by a Digital research note, but documentation for MPEG2 seems only to exist as source code and I can't find anything concrete about using wavelets for compression. The data is all there on the comp.compression FAQ, but the excellent exposition of the book is sorely lacking.
Gailly:
These are all very worthy topics, and Mark Nelson and I would like to incorporate them into a new version of the book someday. However, the decision to produce a new version is taken by the publisher, not us.
Note also that these are all very big topics, and it would be quite easy to write an entire book on each one. I don't think they will fit well in a chapter or two. Covering JPEG in one chapter was difficult, and Mark Nelson has been criticized for not describing the specifics of the standard algorithm.
You can find some Web references here and there, in addition to the comp.compression FAQ.
8) Compression software
by jd
It is a "truism" in the Free Software community that code should be released early and released often.
However, much of the software you've written has started gathering a few grey hairs. Gzip, for example, has been at 1.2.4 for many, many moons, and looks about ready to collect it's gold watch.
Is compression software in a category that inherently plateus quickly, so that significant further work simply isn't possible? Or is there some other reason, such as Real Life(tm) intruding and preventing any substantial development?
(I noticed, for example, a patch for >4Gb files for gzip, which could have been rolled into the master sources to make a 1.2.5. This hasn't happened.)
Gailly:
I knew this question would come when I accepted a Slashdot interview. But I had to face it :-(
In short, you are completely right. While working on gzip 2.0, I continued to maintain gzip 1.x, accumulating small patches, and answering a lot of e-mail. But I was hoping to be able to release gzip 2.0 directly, without having to make an intermediate 1.x release. See my answer to the question bzip2 support concerning the state of gzip 2.0 and the Real Life interference. I'd be glad to hand over all my patches for 1.2.4 to the person who can help me getting the gzip 2.0 project to full speed.
9) Proprietary algorithms
by Tom Womack
The field of compression has been thronged with patents for a long time - but patents at least reveal the algorithm.
What do you think of the expansion of trade-secret algorithms (MP3 quantisation tables, Sorensen, RealAudio and RealVideo, Microsoft Streaming Media) where the format of the data stream is not documented anywhere?
Gailly:
The hardware specifications for some video cards were kept as trade secrets. As a result, the XFree86 project couldn't support these cards. Increasing pressure from users who didn't buy those cards because they couldn't be supported has led the manufacturers to release the hardware specifications, and those cards are now well supported.
Similarly, I think that pressure from the open-source community can become strong enough to force companies to open their formats. We're not completely there yet, but I believe that the open-source model will win in the end. Even a giant like Microsoft starts considering Linux as a real threat.
10) Go and Compression
by Inquisiter
When I think of a game like go or chess, I think that each player develops there own algorithm to beat their opponent. If you agree, what relationships or similarities do you see between your intrest in Go and your intrest in compression?
Gailly:
What a nice question!
Even though the rules of go are very simple, the complexity of go is astonishing. The best go programs can be beaten by a human beginner. The search space in go is so large that is impossible to apply the techniques that are so successful in chess. Professional go players never evaluate all possible moves. They are able to compress an enormous amount of information into a relatively small number of concepts.
Where a human beginner would have to painfully examine many possibilities to realize that a certain group is doomed, and would most likely fail in the process, a go expert can immediately recognize certain shapes and can very quickly determine the status of a group. One gets stronger at the game by reaching higher levels of abstraction, which are in effect better compression ratios. A professional go player can elaborate concepts that an average player would have great difficulties to understand.
Current go programs are overwhelmed by the amount of information present in a game of go. They are unable to understand what is really going on. Since brute force techniques can't work in go, programs will only improve by compressing the available information down to a manageable level.
Maybe the slashdot effect will help these folks get some well-deserved attention.
bun-fhuinneog agam!
When I asked if there would ever be a "developer" version of Mandrake, I didn't mean a distribution that automatically included all of the developer tools. I do use Mandrake 7.0, and I do have all of the developer tools installed. What I was referring to would be something a bit more like Debian, where things are quite so user-friendly and "windowsish". In other words, a distribution that would be more fun for developers to play around with.
I realize that Debian exists for this purpose, but I would like to see a variety of developer platforms of Linux. I think that the community as a whole seems to be forgetting that Linux started as Linus's hobby, and grew to be the hobby of dedicated hackers everywhere. Now, Linux has moved to the corporate world (even though I do love the new "business Tux" /. icon) and the roots and history are really gone.
Brad Johnson
--We are the Music Makers, and we
are the Dreamers of Dreams
Brad Johnson
I like this sort of thing, because a lot of people involved in the more "sexy" parts of development (videogames, GUI's, Compilers...) get heared from a lot. It's nice to hear from somebody who is in the trenches working on the mundane but absolutely invaluable day to day tools that we all use.
One of my russian friends when talking about the programmers that write all the little bits of useful code translated (akwardly) a proverb that i cannot remember. It said basically that there is just as much dignity in being a farmer as [some high profile occupation] because without them we would all starve.
If anybody knows the correct wording and or translation for this...
---
Play Six Pack Man. I
Have you tried Powdermilk Biscuits?
My, they're tasty, and expeditious...
thank you.
I love this word "coopetition". (Well, I don't know it's new, but I've never seen it before). In one word, it describes exactly why and how the open source model can work.
11.0010010000111111011010101000100010000101101000
Now we know what the next Slash poll should be...
...blah...blah...blah...
What distro are you using?
)Red Hat
)Mandrake
Personally, I'm using Mandrake 7.
First off, thanks to J-L and /. for another informative interview.
Compression algorithms should be patentable, but for a 2-year period. This way, the company that develops a new one will have a temporary monopoly to make their money, but it can be included in other programs and libs after it is opened to public use. Developing new algorithms is great, but useless if they're not used because of a 20-year lock on them.
I think that Mandrake is pushing RH to innovate. Remember, RH is used more by the newbies because it is more 'commercial' and it does some of their work for them. No, I'm not slamming RH, I'm just saying it's probably the most used by newcomers who, after they get used to Linux, can then either stay with RH or try the other flavors.
I'm also quite pleased that J-L released the gz lib to Winzip. Even though he's allowing them to make money from his work, he is actually pushing the acceptability and openness of Linux. The man is to be commended for looking at the whole picture and truly accepting open-source GPL.
"First things first, but not necessarily in that order."
- Doctor Who
I for one had never heard of the author of Gzip nor Zlib and was just aware they worked. I was also not aware he allowed code to be used in winzip and other projects such as IE so that PNG could survive. Little pieces all fit toghether and he deserves props. Good Job. I am glad not everyone in the world is after money! And he could have easily asked for some money and im glad to see someones proud for NOT taking money! Good job again!
Baaaaaa -Sheep
That "go" question was really cool. I wish I played it well enough to attempt to write a great computer player, as this is a classic hard problem in AI, with a $2,000,000 reward, IIRC...
Of course, his "compression" is generally expressed in terms of "rules", and even some tips from image compression might help here. (recognize similar configurations, whether they be rotated, translated, etc., and adjust your strategy accordingly)
bzip2 is a really great program, generally offering better compression than gzip at least for large bodies of text. What I'd really like to see is a meta-compression format that has some heuristic to identify the type of file, and use the appropriate (optimal) algorithm. I know most modern compression programs do something like this already, (like RAR and its multimedia compression) but it's still neat. The few bits to identify the compression methods can be well worth it...
Also, hopefully those compression patches will eventually make it into Linux; it'd be great to see something like that working at the VFS level.
If it used something like LZO, there'd be up to gzip levels of compression with practically no performance hit on even a modest system. Maybe even speed improvements would be possible, due to having to read less data from the disk...
Under those situations, I'd advocate comressing swap (and even memory!) where it would help (not recently used data), and maybe merging more of that into the filesystem too...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
I was a bit disappointed that Jean-Loup didn't mention the inclusion of quite a number of localization packages into their release, and actively soliciting additional translations into any language they can find translators for. In the spirit of full disclosure, my name does appear there, and I did receive a copy in exchange for some late-night translation efforts.
Speaking of unsung heroes. I'd be interested in seeing an interview with one of the people who have kept the internationalization and localization of open source moving forward such as François Pinard of the Free Translation Project or Pablo Saratxaga of MandrakeSoft who is also running the Linux i18n Project.
The net will not be what we demand, but what we make it. Build it well.
Several reforms are necessary:
The patent term should be significantly shortened, at least for algorithms. The patent system was designed to benefit society as a whole, ensuring that new ideas would eventually be made public after a limited period of time instead of being kept as trade secrets. But 20 years is incredibly long in the software area. Granting a monopoly for such a long time no longer benefits society.
Unfortunately, I don't think a lot of people on Capitol Hill read slashdot frequently. Someone will eventually need to trudge to D.C. and make the case. The viability of the software industry is at stake.
Hates people who have stupid little sigs
I'm so glad the last question was choosen and answered! It goes right to the heart of AI.
:-)
- Go is severly complex to a computer. To play requires a combination of looking "n" moves ahead(which a computer does well) but regonizing patterns(which a computer doesn't do so well). The combination is way out of the reach of current computer AI.
- Computers can't regonize what is in a digital image without massive hardware and even then the results aren't inspiring(think abstract art or oil painting). Yet humans can easily grasp the concept around images.
- Computers can't regonize the content in text either. There are spell checking programs out there that can check grammer but none can actually know what they are doing...and "spell checking" is pattern matching! Humans can easily judge whether a sentance is "clever" or "stupid" but computer can not nor can the computer tell the difference between a sonnet or a memo.
- We all know how poorly game AI tends to be. A computer can easily outplayed because it can not regonize between the good time to attack/defend and the bad time to attack/defend. The best it can do is guess(I've got "n" number, they've got "m"...my number is bigger so I should attack). Position and disposition are completely lost to a computer.
I believe the Holy Grail in AI has to be real human like "recognition"**. Pattern recognition is something a computer does well but that really isn't the whole problem. Humans recognize "things" and instantly has memories associated with that "thing". Both steps seem to be compressed together. To a computer, recognition is an exhuastive, brute force search of its set of knowledge(ie a database) and the assocition is another exhuastive, brute force search through a different kind of set of knowledge(ie another database). Both steps are impossible to implement or maintain with our current methods and algorithms for pattern matching and searching. Something new has to be invented and I believe that "compression" and "hashing" will be a key to creating a true AI like sytem.
** note: for a computer to have "real human like recognition" it must also have the ability to be "mistaken".
Fabrice Bellard wrote LZEXE, which transparently compressed executables under DOS, as well as the 486 mpg123 patch -- yes, MP3 playback on a 486, which I used on a 33Mhz box. Thanks to both of them, we all squeeze more efficiency out of hardware.
Fuck Slashdot
One view is that algorithms should not be patentable at all, whether obvious or not.
Algorithms are patentable. In a sense, Algorithms have always been patentable. You just had to have a good patent attorney. Here's how it works:
1. Submit application for algorithm patent
2. Get laughed at by patent office clerk
3. Hire good attorney to write application
4. Submit application for a DEVICE which implements the algorithm
5. Rake in the big bucks
Anyone can implement your algorithm, as long as they don't manufacture a device that implements the algorithm. So if I had a compression algorithm, I would patent a device, consisting of CPU, memory, and disk drive that compresses data by (insert algorithm here). You would be free to implement the algorithm by hand, or maybe in a device made up of steam-powered wheels, cams, and rods. For all practical purposes, my algorithm would be patented.
BTW, this same technique could be used to get around five year limits on software patents. Bezos is almost certainly aware of this, so I found his open letter to be quite disingenuous.
Maybe I'm misremembering, but I think Bezos mentioned that he was going to actively seek out and try to meet with some of the Capitol Hill guys about the patent duration issue.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The RLE compression patent to which Gailly refers is "4056828: Run length encoding and decoding methods and means", filed by - you guessed it - Xerox. The full patent can be found here at IBM's Patent Server, or here at the US Patent and Trademark Office. The good news is that, as far as I know, this patent has expired because it's over 23 years old.
#Linux-Mandrake on irc.openprojects.net is a dedicated Linux-Mandrake Channel. It's quite nice, we help out newbies and the developers discuss the latest stuff in Mandrake. #Linux-Mandrake ON: irc.linux.com
on whether this post deserves a -1 or not?
"Increasing pressure from users who didn't buy those cards because they couldn't be supported has led the manufacturers to release the hardware specifications, and those cards are now well supported.
Similarly, I think that pressure from the open-source community can become strong enough to force companies to open their formats."
I think this is probably a bit too optimistic. No matter how formidable the Open Source movement becomes, companies are probably not going to be releasing the full specifications for everything they develop. Competition won't allow for it.
It's much more likely that, as Linux becomes more popular, hardware companies will begin to write drivers for Linux, instead of releasing the specs... on the software side, if we can't get vendors to start using open source formats, the time honored tradition of reverse engineering proprietary formats will continue...
I've also considered the stuff you're talking about. Data compression could also be called decomplexification- removing the irrelevant. (It could also be called maximal complexification too I suppose- separating the 'data' from 'that which is referenced to determine what the data means' to get a hunk of data with no pattern. That is, no redundancy.) Labeling is a kind of compression. Storing the name of a thing rather than the thing itself. Information itself could be called compression. Reducing infinite territory to finite map. Reducing an experience/phenomenon describable in an infinite number of ways from an infinite number of perspectives to a representation of that experience with only a finite number of perspectives from which that representation "makes sense". O mind is a tiny tiny comicbook =) J
Seems to me... Mandrakesoft is now just as beligerant about endusers as Microsoft is. I have posted in mandrake cooker mail list. I have posted in various Linux newsgroups/websites. So far I have 2 responses. NO responses from anybody at MandrakeSoft. So this means I can translate this to. MandrakeSoft is in it for the Money ONLY. Let people buy the OS. Let them find out that it will NOT run stable on their AMD K6/K62 Computer. Let them reinstall Windows 98. Let them put Mandrake 7.0 on the shelf to gather dust. If they question a simple issue... ignore it. DO NOT respond. THEY will GO AWAY. Well... I am not going to go away. there is not much I can do. Except REFUSE to install mandrake 7.0 on any and all machines I build and sell. I hope you enjoy the money you get from the retail sales to users who have no idea you only want their money. I really liked mandrake . Then I get this kind of response from a simple issue. I guess I will go back to where the first STABLE retail Linux began... RED HAT. That is where mandrake started from. I guess I have to join the Mandrake sucks newsgroups? No I refuse to drop that low. I would prefer a simple response, from the mandrakesoft people. It won't happen... but it would be nice. take care Christopher De Long
Personaly, i think this blows, Jean deserves all the media attention he can get, people need to know what he has done for all of us...I think it's very important for all of us to know who he is, and what he has accomplished for the open source community... So i say Kudois for Jean...
Mog The Moogle
Have you experimented to narrow down the problem a bit?
;^)
Here are a few ideas.
Remove some of the RAM from one of the machines (I'm using a K6 with 48 megs and have never seen any problems like this under linux - I did see similar problems on this box before I installed linux - more on that below). I honestly don't think it's likely that the amount of memory has anything to do with the problem, but you obviously do - this would be the only way to be sure.
Have you got another distribution to work on this machine? I would try another distro, any distro, if you haven't - if the same thing happens then you know it's not specifically a mandrake problem.
You haven't provided enough information to allow anything approximating certainty here, but just going on what you said, I do have an educated guess as to what might be happening - from the symptoms, and the time element, I would personally suspect a cooling problem. I have seen similiar problems hit my box after 24 hours or so of uptime - this was before I switched over to linux but it sounds very similar - installing a new heavy duty heat sink and ball bearing fan to replace the el cheapo that my box came with solved the problem for me.
Oh, one more questions - after the kernel panic have you tried turning the box off for awhile (bringing the temperature back down) then bringing it back up again?
(Moderators please be kind - if any of you are actually reading pages that are over an hour old
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Just had a thought, and it relates to a topic in the topic. I contend that /. is becoming 'mainstream', not in the philsohical sense but socilogically. I read somewhere that most of the people who read this site are windows users. Can anyone post the actual weekly stats, cause its gotta be big.
/. as M$ is about Linux ...
Anyway, some of the bigger media sites are probably starting to notice, but probably getting as worried about
-
Me thinks you would enjoy:
Metamagical Themas by Douglas R. Hofstadter
isbn: 0-465-04540-5
Frontiers of Complexity by Peter Coveney & Roger Highfield
isbn: 0-449-91081-4
Chaos Under Control by David Peak & Michael Frame
isbn: 0-7167-2429-4
and Order Out of Chaos by Ilya Prigogine
isbn: 0-553-34082-4
Should help you quantify those thoughts a bit more =)
The Night Angel - So fuzzy even I don't understand myself =)
3dfx used to sue people for glide wrappers, now everything under Glide 3 is "openish". Companies will do what makes sense, and if today releasing a binary driver makes sense, it will be done. Tomorrow when that code is only suitable for some 15-year old to cut their teeth on, then it will make sense to release it so you can hire that kid without paying to train him (sorry, or her - me biased with all that testosterone). Linux is poised to go mainstream, binaries are going to be a part of life in the future because no matter how cool and froody Open Source is, no company with a legitimate reason to NOT release their source will. The core of Linux will continue to be open, but man, people gotta make a buck to pay the rent. Bread don't come cheap and all the other things the hippies learned before they went off and became rich yuppies. It's going to be a good future for Linux, yeah it may make you feel a bit dirty using that binary whats-it to make the thingie work right but at least the darn thing won't crash because that's where the bar is set in the Linux community - if it crashes and it's closed source it will die an amazing fast death in a community that talks to each other and know's better than to accept such crap.
The Night Angel.
Au contraire Mon capitan! (pardon me =)
Pattern recognition has already reached a significant level of compexity but, what is not public at this moment is an integrated personality. A Machine Intelligence might even exist today, if it does you definately don't know about it and neither do I. To know of such a thing would very logically be a death warrent or at least permanent house arrest.
I think therefore I am. The prefrontal cortex is one of Gödel's islands of consistancy, reverse-engineering of that structure is well under way on many fronts: here, here, here and too many other places to mention. Gaming AI doesn't have a trillionish dollar distributed budget behind it simply because games don't generate that kind of revenue. Besides this hardware is woefully inadequate, a few very fast processor versus my billions of slow ones. I simply have more chances to stumble across something.
Hmm. So a compressed dictionary is the key to creating a true intelligence? Well! Step right over to those fine folks at Cyc who have been doing just that! To bad the darn thing is a lot more brittle than you or I. Although I really like the semantics they're developing - someday it could make good baby food for the real thing. I've spent many sleepless nights researching this field and the only thing I've learned is that there are a whole lot of distractions. The proof of that lies in the fact that HAL didn't come online on schedule.
The Night Angel
Only the fool would take trouble to verify that his sentence was composed of ten a's, three b's, four c's, four d's, forty-six e's, sixteen f's, four g's, thirteen h's, fifteen i's, two k's, nine l's, four m's, twenty-five n's, twenty-four o's, five p's, sixteen r's, forty-one s's, thirty-seven t's, ten u's, eight v's, eight w's, four x's, eleven y's, twenty-seven commas, twenty-three apostrophes, seven hyphens, and, last but not least, a single !
Oops, sorry Mr. Hofstadter. The last sentence was published by Douglas R. Hofstadter in his book Metamagical Themas (isbn 0-465-04540-5). This book explores the forest without touching a single tree =). e.g. I am going two-level with you.
Form emerging from structure, pretty heady stuff. Not much concrete in there from a money grubbing capitalist point of view but excellent background philisophical reading.
The Night Angel
Got carried away making assumptions about what the people reading my message would know about the money funding AI research: military. For example: "Pulse-coupled neural networks for cruise missile guidance" can be found here.