If you'll re-read you'll see that I didn't
say it was a criterion for getting a patent.
As for which way to go:
I think this is a question of strategy, rather
than one of us being wrong or right.
Certainly many filers obfuscate on purpose
as a strategy. That strategy might be helpful
in certain ways, but it will not help them
in explaining the patent to the jury.
Therefore my friend prefers the alternate
strategy of being very clear.
Which strategy to use might be a matter of taste
or business model etc,
but you know, I really do think that my
friend's approach is a more honest use
of the patent system!
A friend has filed his own patents starting with
one granted in 1980. That is definitely the
cheapest approach.
On the other hand, not everyone has the right
skills and mindset to search for prior art well,
which is important.
Similarly he says (and I sure believe) that it
is very important to write your patent very
very clearly, and to have very clear diagrams,
because if the patent is ever contested,
you want to be able to convince a non-technical
jury as easily as possible.
That kind of clarity of writing and creating
diagrams is not all that common, so using
professional help might be in order.
Then again, not all professionals are all
that great at clarity, either! Many patents'
writing suck, IMHO.
Don't assume people are stupid just because
they didn't explain themselves ultra-thoroughly
in a public forum where there is a premium on
posting fast (otherwise responses end up
buried under hundreds of others and are never
seen). Slashdot is not Usenet, much less a
research journal.
When I gave the talk to the AI forum, my
use of provocative terms like "cheating" and
"dishonesty" is precisely what gave rise to
a very interesting discussion in the audience.
Yet not a single person there was tempted to
actually believe the anthropomorphism as an
underlying reality.
You would do well to read the seminal works
by Konrad Lorenz on animal behavior. He
nicely points out the difference between
the fallacy of teleology (ascribing purpose
to nature) versus teleonomy (apparent
purpose in nature as a useful model to
describe functionality regardless
of exact cause).
Fact is, teleonomic terminology is very
appropriate for describing experiences with
genetic programming and artificial life,
as you will discover if you ever try it.
It is vastly more difficult in those realms,
compared with most kinds of programming,
than you seem
to think to do the "due diligence" to
avoid unexpected results as you snidely
suggest.
For the sake of any historians reading this
archive thousands of years from now: correction --
I checked my archives, and my tic tac toe breeding
software is dated 1985 on the paper printout, not
1987 as I originally said.
Probably makes a difference; I was doing this
very early on in the history of genetic evolution.
I waited a while to post this so as to avoid
flack from people complaining about me replying
to my own post.:-)
This is typical of evolution (both natural and artificial), rather than surprising.
I bred tic-tac-toe programs around 1987, and they were always surprising me. The first round of winners evolved to win by cheating -- they found
a bug in my software that allowed them to make
three moves all at once and win on the first move!
When I fixed that, they cheated again, by collusion: when they played the O's they dithered and did nothing, so that when they played the X's they could get an easy win with no resistance. I had to breed the O and X populations separately to fix that.
As for finding genetically evolved solutions
puzzling, again that's par for the course.
It is extremely difficult, in fact, to
breed populations whose solutions *do*
make sense. They find "organic", bizarre,
complicated, twisted, fragile solutions much
more often than something simple and straight-forward.
I gave a talk entitled "On the Evolution of
Dishonesty" on the phenomenon to the local
AI society (the title being of course a
take-off on Axlerod's "Evolution of Cooperation"
Katz hasn't actually cancelled!
on
Disconnecting
·
· Score: 2
Many have said he should have just told his credit
card company to cancel, but no one has pointed
out that he still must do that.
In other words, Earthlink and AOL both claimed
his service was cancelled -- but will they
keep billing his credit card anyway? Of course!
That's part of the whole cancellation hell;
even when you think you've won, the battle has
only just begun.
It said the circuit was a ring counter, which is basically the fastest circuit you can build that actually does something. It's almost always the first circuit built with new process technology for exactly that reason.
On the other hand, more complex circuits nearly always run significantly slower than ring counters. So if their ring counters are running at 110Ghz, then some simple communication circuit might run at 30Ghz. Depending on details.
Moral: as usual, never just blithely believe these press releases are implying what they seem to imply.
That's what Thinking Machines did in the 1980s, roughly. They eventually moved away from bit-serial processors to more conventional bit-parallel processors.
The main reason why highly parallel machines have never gotten really popular is that, even aside from cost, they need special programming by humans. Parallel programming is a black art compared with serial programming. Compilers can't parallelize C worth a damn.
I found OO and C++ to be very helpful in a signal processing package I did some years ago. It performed FFTs, fast cosine transforms, correlation, cepstral analysis, graphing, etc to support experimentation with audio and voice analysis/recognition.
I started out in C, but converted to C++ when it became clear there would be a serious advantage
for that particular code.
Looking at the header file, I see that I ended
up with a class SampleInfo that contained basic info like the sampling rate and a dozen other items of interest. This basic type was useful as a parameter to constructors and converters throughout the package.
Then there was a class HeaderInfo, which inherited from SampleInfo. It added information such as whether the data was a stream of bytes, complex numbers, or in phase-magnitude form.
Using that starting point, several other classes inherited from HeaderInfo to add still more specialization: VectorHeaderInfo (information
about an array of arrays of samples) plus associated implementation classes: ByteVector (just an array of samples of type byte), ComplexVector, ComplexVectorOfVectors, etc.
The class hierarchy and associated inheritance doesn't sound especially impressive, but it immediately cleaned up the code and made it easier to experiment and easier to find certain kinds of conceptual bugs.
Actual transformations were made easy by always
returning a pointer to 'this', so a typical usage
would look like:
This style of pipelining data through transformation stages makes experimentation a breeze...just insert/delete pipeline stages.
Even design of core algorithms like fft() itself benefited somewhat from reimplementation in C++, although the benefit there was a little smaller.
Basically the added value of OO is small (but non-zero) if you
look at converting just one function implementing a single numeric technique, but becomes larger and larger as you implement a family of related techniques, such as matrix arithmetic, multiple transforms, diff eq techniques, etc.
P.S. the biggest optimization advantage for using Fortran is on things like vector processors. And in any case, the right way to optimize is to re-code only inner loops. Thus one could have a package written mostly in C++, but with inner loops recoded in Fortran, if necessary.
Sadly, people are forgetting the great science fiction authors of the past, so these days it's not well known that Monty Python based that skit on the amusing short story "Nothing but Gingerbread Left", by Henry Kuttner, written in 1943!!!
The Python sketch is reasonably close to the
original story, as I recall, except for trivial details. E.g. I remember that part of it had to
do with a German marching song, which was harmless in English but drove soldiers mad in German, which went in part "Left! Right! Left his wife and seventeen children with nothing but gingerbread left! Right! Left....etc". Thus
the story title.
Kuttner is always worth reading, and often very funny. I think some of his stuff is still in
print. (Hmm, was Kuttner a pseudonym? I can't
recall.)
I agree that Goldberg's "What Every Computer
Scientist Needs to Know about Floating
Point Arithmetic" is a good and important
read. Google found it several places,
including at
citeseer
But you know, just yesterday I re-read 80% of Kahan's site, and he does in fact recommend that
non-expert numerical analysists (i.e. just about
everyone) should use the maximum precision
possible, as a sort of band-aid. Not that
a guru like him thinks it's a cure-all,
just that it'll help people a bit.
He's incorrect in saying that include files are a major cause of slow compiles. Actually, well-implemented preprocessors (like the ancient Reiser one out of Bell Labs) are blindingly fast.
The idea of precompiled headers became popular in environments with (a) slow media like floppies and (b) with poorly written preprocessors.
In addition to studying the Reiser source code,
which was very clever in a bunch of different ways,
I also once timed it as actually being *faster*
than "cat file1 file2 file3 > junk". Admittedly
this was under Xenix on a 286 with a badly
implemented stdio package, but still...
As for operator overloading, it's pretty monstrous,
however it's indispensible for new numeric
types. A lot of programmers don't ever seem
to need new numeric types, but it depends on
your work. I've created easily a dozen unusual
numeric types over the years (e.g. floating
point with a floating point exponent). Don't
assume that you can ever provide 100% of all
numeric types that anyone will ever need; can't
be done. Therefore, support overloading for
numeric types only, somehow; *that* would
fix the C++ problem without crippling the language.
Other data types are not object oriented? It's
already a major pain in C++ that e.g. int and
char* etc aren't classes. Make everything a class.
Delete bit fields? Give me a break. Promote them
to first class, and then they'd really be useful. A large part of the reason they're not used heavily is that they not fleshed out in the language.
(I realize I'm simply replying to someone who quoted the D author, but it was a handy springboard.)
The Singularity Institute is just one guy,
Yudkowsky, who is a high school dropout but
apparently pretty bright, and his stuff makes
for interesting reading.
However, he's not a programmer, and so there
is no code, and probably never will be. He's
a futurist, not an implementor.
This is the main flaw in his ideas; they're
reasonably well researched, but they're not
grounded in software realitites, so he has
no guide for when he's being reasonable
(which he often is),
versus stating the obvious (fairly often),
versus
when he has wandered off into the weeds with
ideas that are unimplementable, or perhaps
worse, not even wrong ("This isn't right. This isn't even wrong." -- Wolfgang Pauli).
Even so, his stuff is a reasonably interesting
read.
Check
it out. The link on that page to
"Creating Friendly AI" is sort of
his manifesto.
Grid computing was hyped back in the 1960s
(Multics was targeted towards that, IIRC).
It never happened because of Moore's Law.
Cheap processors means it's been more
cost effective in most cases to buy your
own cpu than to lease it from a grid.
A science fiction novel I read recently (Permutation City by Greg Egan),
however, reminded me that this may eventually
change, if and when Moore's Law stops working.
If compute power hits a stable plateau
in 10, 20, 100 years, whatever, then the
cost of compute power will also roughly
become a constant number of dollars per
clock cycle (or peta-clock cycle).
In that case, as Egan presents it, compute
power from a global grid may indeed be
the only way to get larger amounts of
compute power than your local processor
can give you, and therefore, as a commodity,
it may go to the highest bidder at any
given moment.
(Hopefully not so badly as with California's
power grid bidding, but we'll see.)
P.S. the advent of nanotechnology computers,
or quantum computers, or purely optical
computing, etc, wouldn't dispel the above
scenario, it would just delay it. It's
not clear that even Vinge's Singularity
would literally prevent Moore's law from
going away. (I don't believe that the
Singularity will do away with the laws
of physics.)
Bitter because he's Bill Gates
on
Just For Fun
·
· Score: 2
I think only Bill Gates could get that
bitter on that topic over so little provocation;
he's worried about his own future legacy. In
a thousand years, Bill Gates will be forgotten.
The reason is right there in what he said:
"if it weren't for Microsoft and IBM"
Sorry, but the world was already changing in
nice ways thanks to Intel and Zilog and Motorola
and Commodore and Apple, etc.
We never did need Microsoft and IBM to come in
and monopolize the blossoming microcomputer
market place.
And as the above AC notes, PDPs were very
nice minicomputers; we didn't need to be saved
from them.
('Course, he's right that Torvalds isn't the
be-all and end-all of OSes and free/open source;
I personally am keenly aware of earlier traditions
from e.g. Stanford and MIT and Berkeley that
we are still building on.)
Considering that Linux only runs on 32-bit and some 64-bit platforms, your chances for finding a configuration
involving a 16-bit microprocessor are slim.
Consider that the original Unix ran very nicely
on 16 bit processors!
Full-featured (although pre-networking and
pre-graphics)
Unix Version 6 and 7 ran
on the PDP 11/70, which was 16 bits, although
with the helpful extension of giving one
64K byte address space for data and a separate
64K byte address space for instructions,
for a total of 128K bytes. It also helped
that the 11/70 supported something like 512K
of RAM, so that the operating system could
use its full 128K at the same time that several
other processes were also resident in other
RAM.
Call it a minimum of 256K of RAM, although
512K would be better.
There were versions of Unix that ran
in less, even in a total of only 64KB, but
this was very difficult, and features needed
to be stripped out of the kernel to get that
to work.
Anyway this suggests that it would be close to
hopeless to look for any Unix/Linux variant
that could run in only 64KB RAM total.
(Unless
it used an MMU to swap RAM and Flash chunks
extremely frequently, which is (a) probably
undesirable and (b) probably is not an existing
hardware configuration, unless you did a homebrew
MMU.)
If you stripped out enough features for
a Linux/Unix kernel to run in 64K, it would
be so crippled that it would be pointless;
it would be better to use an OS that was
designed to be ultra-small in the first place.
Note that you'd also have the problem that
extremely few apps would run in only 64K of
RAM. Almost none, if there is no MMU to swap
to Flash.
P.S. Version 6 Unix actually didn't use ANY
RAM! Yep, it's true. Instead it used magnetic
core memory.:-) RAM wasn't available for the
11/70 until approximately the time of Unix
Version 7.
Since the ftp site is slashdotted, here's
the fine print in question:
Applicability: Linux-Mandrake 8.0 BETA 1 WARNING This BETA has the potential to mis-
recognize the drive geometry on systems with VIAApollo Pro or KT133 Chipsets and WD drives greaterthan 8.4Gb in size. This leads to massive andunrecoverable data corruption. Do NOT install or attempt to test with these systems. It relates to recently discovered kernel bug which may be fixed in kernel 2.4.2. We expect to have the fix in place for BETA 2 (Traktopel). Thank you for your patience.
Re:Dolphin Uplift -- Math Mistake (combinatorics)?
on
Uplifting Dolphins
·
· Score: 1
You're right, my math example was horribly
flawed; I was getting sleepy when I wrote that.
I shouldn't even have said "four word sentences",
for that matter, since that implies there might
be meaning attached to each position in the
sentence, implying some kind of grammar, which
is actually part of what Brin is contradicting.
One or two word order-insensitive sentences would be more to the
point.
Brin's essay didn't give specific numerical
data, as I recall, so I'll just leave it there.
David Brin, who coined the "uplift" term in the
title of this article, also had some very
interesting comments to make about dolphin
communication (and therefore implicitly about
upper bounds on dolphin intelligence).
Brin has written fascinating science fiction about
genetically-alterered dolphins actually crewing
and captaining starships, but it's interesting to
note that he has also strongly critiqued
non-fictional hopes
of communication with unaltered dolphins.
In his essay Dogma of Otherness (originally
published in Analog, Apr 1986, collected in
his book Otherness, 1994), he points out that,
long ago, dolphin researchers analyzed dolphin
"speech" (sonic and ultrasonic sound emission),
and simply applied information theory to the
sounds, and discovered that, no matter whether
we understand what dolphins are saying or
not, nonetheless, they don't seem to be saying
very much: they use only a few sound patterns,
which are only used in short sequences.
(Information theory, to oversimplify, allows
us to say "if there are only N bits of variation
in a message, then that message cannot possibly
convey more than 2^N bits of information,
regardless of what those bits mean."
It separates the question of the often-unknown
meaning of messages, from
the question of how many messages might in
principle be communicated with any given
communication system.
It has been invaluable in e.g. cryptography
and computer science since the WWII era.)
In other words, there just isn't very much
information that can be extracted (in an
information-theory sense) from dolphin sonic
signals, regardless of what those signals mean.
It's as if we can see that they have (e.g.) a
6 word vocabulary, and never use more than 4
words in a sentence, and never speak in paragraphs. No matter what they're saying, that
would limit them to communicating no more than 24
thoughts total -- period.
(I'm making up the above numbers in order to get
across the gist of Brin's essay.)
What this means is that, it doesn't *matter*
whether we understand dolphin "speech" or not,
because their speech just doesn't contain enough
information to convey very much. In particular,
Brin's argument says that there is no way in
hell that dolphins could be using sonic holograms,
or any other large-information-conveying signals.
Brin might, of course, be wrong in his
interpretation of dolphin research, but I personally have seen nothing to refute him in
the 15 years since I first read his essay.
That still leaves us the option of Uplifting
dolphins, of course, just as Brin does in his
fiction. That is, making dolphins
intelligent, rather than hoping they
already are intelligent.
As to other primate communication, another
poster in this thread claimed a chimp made
signs quoted as "Tickle me, then bring me
one of those bananas. Oh, and I would like to watch some TV
That's laughable. The original signs were literally
"Tickle. Banana. TV.". Paraphrasing those
(admittedly interesting) signs into full sentences is
a kind of blatant lie, in my book.
Chimps and apes are pretty smart. But they don't use complex grammar, and pretending otherwise
doesn't help them (nor us).
We use XML extensively to get data from remote
sites, like movies.com and abcnews.com, and then
display that data on wireless devices like web
enabled cell phones.
It was a huge advantage, but not because XML is
some amazing breakthrough, no, just because it's
a standard meta-syntax. So we can re-use the
XML parser on each data source rather than having to
write a whole new parser for each data source,
which is the way that sort of thing used to go.
So if MapQuest started offering a new data service
that we subscribed to, like driving directions
for flying cars,
it would be very helpful if they offered the
data served from their servers in XML -- just
because we are already set up to use XML.
So the whole magic of XML is just that it's
standard and flexible. That makes it highly
worthwhile.
I have my doubts about other XML related subjects
like XSL and XHTML, which may not ever get hugely
popular. But XML itself is already hugely popular -- behind the scenes where you may never notice it, busily exchanging data with remote servers.
You misunderstand wnissen. He didn't say it
was bad for MS to try to make money. He was
actually pretty neutral, and just pointed out
something factual, which is that it is not
charity on MS part, because it is simply
a business strategy that they are using and
expect to gain from. He didn't say it was
bad for them to do that.
It's not "charity" when a return on the
investment is expected. In that case it's
simply an investment.
There is no moral judgement involved in
point out such simple facts.
(Unlike my previous replies to you, which
were not particularly neutral.:-)
Slashdot Mirror
As for which way to go: I think this is a question of strategy, rather than one of us being wrong or right.
Certainly many filers obfuscate on purpose as a strategy. That strategy might be helpful in certain ways, but it will not help them in explaining the patent to the jury.
Therefore my friend prefers the alternate strategy of being very clear.
Which strategy to use might be a matter of taste or business model etc, but you know, I really do think that my friend's approach is a more honest use of the patent system!
That is a decades-old urban legend (check with absolutely any lawyer, intellectual property book/website etc).
E.g. a quick search finds this on the subject: cbsnews.com
Moderators please mod that down (it's currently at 3, informative) for disseminating harmful misinformation.
On the other hand, not everyone has the right skills and mindset to search for prior art well, which is important.
Similarly he says (and I sure believe) that it is very important to write your patent very very clearly, and to have very clear diagrams, because if the patent is ever contested, you want to be able to convince a non-technical jury as easily as possible.
That kind of clarity of writing and creating diagrams is not all that common, so using professional help might be in order.
Then again, not all professionals are all that great at clarity, either! Many patents' writing suck, IMHO.
Don't assume people are stupid just because they didn't explain themselves ultra-thoroughly in a public forum where there is a premium on posting fast (otherwise responses end up buried under hundreds of others and are never seen). Slashdot is not Usenet, much less a research journal.
When I gave the talk to the AI forum, my use of provocative terms like "cheating" and "dishonesty" is precisely what gave rise to a very interesting discussion in the audience. Yet not a single person there was tempted to actually believe the anthropomorphism as an underlying reality.
You would do well to read the seminal works by Konrad Lorenz on animal behavior. He nicely points out the difference between the fallacy of teleology (ascribing purpose to nature) versus teleonomy (apparent purpose in nature as a useful model to describe functionality regardless of exact cause).
Fact is, teleonomic terminology is very appropriate for describing experiences with genetic programming and artificial life, as you will discover if you ever try it. It is vastly more difficult in those realms, compared with most kinds of programming, than you seem to think to do the "due diligence" to avoid unexpected results as you snidely suggest.
Probably makes a difference; I was doing this very early on in the history of genetic evolution.
I waited a while to post this so as to avoid flack from people complaining about me replying to my own post. :-)
I bred tic-tac-toe programs around 1987, and they were always surprising me. The first round of winners evolved to win by cheating -- they found a bug in my software that allowed them to make three moves all at once and win on the first move!
When I fixed that, they cheated again, by collusion: when they played the O's they dithered and did nothing, so that when they played the X's they could get an easy win with no resistance. I had to breed the O and X populations separately to fix that.
As for finding genetically evolved solutions puzzling, again that's par for the course. It is extremely difficult, in fact, to breed populations whose solutions *do* make sense. They find "organic", bizarre, complicated, twisted, fragile solutions much more often than something simple and straight-forward.
I gave a talk entitled "On the Evolution of Dishonesty" on the phenomenon to the local AI society (the title being of course a take-off on Axlerod's "Evolution of Cooperation"
In other words, Earthlink and AOL both claimed his service was cancelled -- but will they keep billing his credit card anyway? Of course! That's part of the whole cancellation hell; even when you think you've won, the battle has only just begun.
On the other hand, more complex circuits nearly always run significantly slower than ring counters. So if their ring counters are running at 110Ghz, then some simple communication circuit might run at 30Ghz. Depending on details.
Moral: as usual, never just blithely believe these press releases are implying what they seem to imply.
1024x1024 array of 1 bit processors
That's what Thinking Machines did in the 1980s, roughly. They eventually moved away from bit-serial processors to more conventional bit-parallel processors.
The main reason why highly parallel machines have never gotten really popular is that, even aside from cost, they need special programming by humans. Parallel programming is a black art compared with serial programming. Compilers can't parallelize C worth a damn.
How can you simultaneously ignore and ridicule it? If you're pointedly ridiculing it, you're not ignoring it, now are you?
Note that this is talking about the ratio of known & reported issues.
Take a wild guess: which kind of system will have a higher percentage of its bugs that are unknown and/or unreported ; open source or closed source?
I started out in C, but converted to C++ when it became clear there would be a serious advantage for that particular code.
Looking at the header file, I see that I ended up with a class SampleInfo that contained basic info like the sampling rate and a dozen other items of interest. This basic type was useful as a parameter to constructors and converters throughout the package.
Then there was a class HeaderInfo, which inherited from SampleInfo. It added information such as whether the data was a stream of bytes, complex numbers, or in phase-magnitude form.
Using that starting point, several other classes inherited from HeaderInfo to add still more specialization: VectorHeaderInfo (information about an array of arrays of samples) plus associated implementation classes: ByteVector (just an array of samples of type byte), ComplexVector, ComplexVectorOfVectors, etc.
The class hierarchy and associated inheritance doesn't sound especially impressive, but it immediately cleaned up the code and made it easier to experiment and easier to find certain kinds of conceptual bugs.
Actual transformations were made easy by always returning a pointer to 'this', so a typical usage would look like:
This style of pipelining data through transformation stages makes experimentation a breeze...just insert/delete pipeline stages.
Even design of core algorithms like fft() itself benefited somewhat from reimplementation in C++, although the benefit there was a little smaller.
Basically the added value of OO is small (but non-zero) if you look at converting just one function implementing a single numeric technique, but becomes larger and larger as you implement a family of related techniques, such as matrix arithmetic, multiple transforms, diff eq techniques, etc.
P.S. the biggest optimization advantage for using Fortran is on things like vector processors. And in any case, the right way to optimize is to re-code only inner loops. Thus one could have a package written mostly in C++, but with inner loops recoded in Fortran, if necessary.
Coding whole apps in Fortran is neolithic.
The Python sketch is reasonably close to the original story, as I recall, except for trivial details. E.g. I remember that part of it had to do with a German marching song, which was harmless in English but drove soldiers mad in German, which went in part "Left! Right! Left his wife and seventeen children with nothing but gingerbread left! Right! Left....etc". Thus the story title.
Kuttner is always worth reading, and often very funny. I think some of his stuff is still in print. (Hmm, was Kuttner a pseudonym? I can't recall.)
Professional Wild-Eyed Visionary
But you know, just yesterday I re-read 80% of Kahan's site, and he does in fact recommend that non-expert numerical analysists (i.e. just about everyone) should use the maximum precision possible, as a sort of band-aid. Not that a guru like him thinks it's a cure-all, just that it'll help people a bit.
So Walter isn't that far wrong there, after all.
In addition to studying the Reiser source code, which was very clever in a bunch of different ways, I also once timed it as actually being *faster* than "cat file1 file2 file3 > junk". Admittedly this was under Xenix on a 286 with a badly implemented stdio package, but still...
As for operator overloading, it's pretty monstrous, however it's indispensible for new numeric types. A lot of programmers don't ever seem to need new numeric types, but it depends on your work. I've created easily a dozen unusual numeric types over the years (e.g. floating point with a floating point exponent). Don't assume that you can ever provide 100% of all numeric types that anyone will ever need; can't be done. Therefore, support overloading for numeric types only, somehow; *that* would fix the C++ problem without crippling the language.
Other data types are not object oriented? It's already a major pain in C++ that e.g. int and char* etc aren't classes. Make everything a class.
Delete bit fields? Give me a break. Promote them to first class, and then they'd really be useful. A large part of the reason they're not used heavily is that they not fleshed out in the language.
(I realize I'm simply replying to someone who quoted the D author, but it was a handy springboard.)
However, he's not a programmer, and so there is no code, and probably never will be. He's a futurist, not an implementor.
This is the main flaw in his ideas; they're reasonably well researched, but they're not grounded in software realitites, so he has no guide for when he's being reasonable (which he often is), versus stating the obvious (fairly often), versus when he has wandered off into the weeds with ideas that are unimplementable, or perhaps worse, not even wrong ("This isn't right. This isn't even wrong." -- Wolfgang Pauli).
Even so, his stuff is a reasonably interesting read. Check it out. The link on that page to "Creating Friendly AI" is sort of his manifesto.
A science fiction novel I read recently (Permutation City by Greg Egan), however, reminded me that this may eventually change, if and when Moore's Law stops working.
If compute power hits a stable plateau in 10, 20, 100 years, whatever, then the cost of compute power will also roughly become a constant number of dollars per clock cycle (or peta-clock cycle).
In that case, as Egan presents it, compute power from a global grid may indeed be the only way to get larger amounts of compute power than your local processor can give you, and therefore, as a commodity, it may go to the highest bidder at any given moment.
(Hopefully not so badly as with California's power grid bidding, but we'll see.)
P.S. the advent of nanotechnology computers, or quantum computers, or purely optical computing, etc, wouldn't dispel the above scenario, it would just delay it. It's not clear that even Vinge's Singularity would literally prevent Moore's law from going away. (I don't believe that the Singularity will do away with the laws of physics.)
The reason is right there in what he said: "if it weren't for Microsoft and IBM" Sorry, but the world was already changing in nice ways thanks to Intel and Zilog and Motorola and Commodore and Apple, etc.
We never did need Microsoft and IBM to come in and monopolize the blossoming microcomputer market place.
And as the above AC notes, PDPs were very nice minicomputers; we didn't need to be saved from them.
('Course, he's right that Torvalds isn't the be-all and end-all of OSes and free/open source; I personally am keenly aware of earlier traditions from e.g. Stanford and MIT and Berkeley that we are still building on.)
Consider that the original Unix ran very nicely on 16 bit processors!
Full-featured (although pre-networking and pre-graphics) Unix Version 6 and 7 ran on the PDP 11/70, which was 16 bits, although with the helpful extension of giving one 64K byte address space for data and a separate 64K byte address space for instructions, for a total of 128K bytes. It also helped that the 11/70 supported something like 512K of RAM, so that the operating system could use its full 128K at the same time that several other processes were also resident in other RAM.
Call it a minimum of 256K of RAM, although 512K would be better.
There were versions of Unix that ran in less, even in a total of only 64KB, but this was very difficult, and features needed to be stripped out of the kernel to get that to work.
Anyway this suggests that it would be close to hopeless to look for any Unix/Linux variant that could run in only 64KB RAM total.
(Unless it used an MMU to swap RAM and Flash chunks extremely frequently, which is (a) probably undesirable and (b) probably is not an existing hardware configuration, unless you did a homebrew MMU.)
If you stripped out enough features for a Linux/Unix kernel to run in 64K, it would be so crippled that it would be pointless; it would be better to use an OS that was designed to be ultra-small in the first place.
Note that you'd also have the problem that extremely few apps would run in only 64K of RAM. Almost none, if there is no MMU to swap to Flash.
P.S. Version 6 Unix actually didn't use ANY RAM! Yep, it's true. Instead it used magnetic core memory. :-) RAM wasn't available for the
11/70 until approximately the time of Unix
Version 7.
I hadn't heard this news before, so I'm not complaining that it's stale. I am, however, wondering what's happened since.
The article says NEC expected to ship product by the end of 2000. Did that happen???
Applicability: Linux-Mandrake 8.0 BETA 1 WARNING This BETA has the potential to mis- recognize the drive geometry on systems with VIAApollo Pro or KT133 Chipsets and WD drives greaterthan 8.4Gb in size. This leads to massive andunrecoverable data corruption. Do NOT install or attempt to test with these systems. It relates to recently discovered kernel bug which may be fixed in kernel 2.4.2. We expect to have the fix in place for BETA 2 (Traktopel). Thank you for your patience.
I shouldn't even have said "four word sentences", for that matter, since that implies there might be meaning attached to each position in the sentence, implying some kind of grammar, which is actually part of what Brin is contradicting. One or two word order-insensitive sentences would be more to the point.
Brin's essay didn't give specific numerical data, as I recall, so I'll just leave it there.
Brin has written fascinating science fiction about genetically-alterered dolphins actually crewing and captaining starships, but it's interesting to note that he has also strongly critiqued non-fictional hopes of communication with unaltered dolphins.
In his essay Dogma of Otherness (originally published in Analog, Apr 1986, collected in his book Otherness, 1994), he points out that, long ago, dolphin researchers analyzed dolphin "speech" (sonic and ultrasonic sound emission), and simply applied information theory to the sounds, and discovered that, no matter whether we understand what dolphins are saying or not, nonetheless, they don't seem to be saying very much: they use only a few sound patterns, which are only used in short sequences.
(Information theory, to oversimplify, allows us to say "if there are only N bits of variation in a message, then that message cannot possibly convey more than 2^N bits of information, regardless of what those bits mean." It separates the question of the often-unknown meaning of messages, from the question of how many messages might in principle be communicated with any given communication system. It has been invaluable in e.g. cryptography and computer science since the WWII era.)
In other words, there just isn't very much information that can be extracted (in an information-theory sense) from dolphin sonic signals, regardless of what those signals mean. It's as if we can see that they have (e.g.) a 6 word vocabulary, and never use more than 4 words in a sentence, and never speak in paragraphs. No matter what they're saying, that would limit them to communicating no more than 24 thoughts total -- period.
(I'm making up the above numbers in order to get across the gist of Brin's essay.)
What this means is that, it doesn't *matter* whether we understand dolphin "speech" or not, because their speech just doesn't contain enough information to convey very much. In particular, Brin's argument says that there is no way in hell that dolphins could be using sonic holograms, or any other large-information-conveying signals.
Brin might, of course, be wrong in his interpretation of dolphin research, but I personally have seen nothing to refute him in the 15 years since I first read his essay.
That still leaves us the option of Uplifting dolphins, of course, just as Brin does in his fiction. That is, making dolphins intelligent, rather than hoping they already are intelligent.
As to other primate communication, another poster in this thread claimed a chimp made signs quoted as "Tickle me, then bring me one of those bananas. Oh, and I would like to watch some TV
That's laughable. The original signs were literally "Tickle. Banana. TV.". Paraphrasing those (admittedly interesting) signs into full sentences is a kind of blatant lie, in my book.
Chimps and apes are pretty smart. But they don't use complex grammar, and pretending otherwise doesn't help them (nor us).
It was a huge advantage, but not because XML is some amazing breakthrough, no, just because it's a standard meta-syntax. So we can re-use the XML parser on each data source rather than having to write a whole new parser for each data source, which is the way that sort of thing used to go.
So if MapQuest started offering a new data service that we subscribed to, like driving directions for flying cars, it would be very helpful if they offered the data served from their servers in XML -- just because we are already set up to use XML.
So the whole magic of XML is just that it's standard and flexible. That makes it highly worthwhile.
I have my doubts about other XML related subjects like XSL and XHTML, which may not ever get hugely popular. But XML itself is already hugely popular -- behind the scenes where you may never notice it, busily exchanging data with remote servers.
AC's links above go to the following (good) books:
Algorithms in C++ (Robert Sedgewick -- excellent choice)
The Art of Computer Programming Vol 1-3 boxed set (Donald Knuth -- irreproachable choice, although much of it requires higher math)
The C Programming Language (Brian Kernighan -- a famous classic, updated to the ANSI C standard)
Introduction to Algorithms (Cormen, Leiserson, Rivest -- I don't know this one, but Rivest has a sterling reputation)
Programming Pearls 2nd Edition (Jon Bentley -- great fun and very educational in a unique way)
It's not "charity" when a return on the investment is expected. In that case it's simply an investment.
There is no moral judgement involved in point out such simple facts. (Unlike my previous replies to you, which were not particularly neutral. :-)