You'd like Baseball Boss as well then. It combines card trading (real players, MLB licensed) and then playing those cards on teams. Great stats and tons of fun.
For disks which only have minor scratches, rub a plain wax candle all over the surface, radially. Once covered, buff it with a smooth cloth (I usually use my cotton T-shirt).
The wax fills the scratches well enough to read them, usually. If this doesn't work, try the toothpaste trick but the wax trick is non-destructive.
Furthermore, one can access other libraries than those written in Scheme, using bindings to C/C++ libraries,
or in the case of SISC, access to any and all Java libraries. This,
combined with Scheme's flexible language constructs, has led to amazingly powerful programming frameworks
such as SISCweb (think Web 3.0 if you want a buzzword).
That may be true, but Microsoft is currently hurting on Wall Street trying to show continued growth. 2.5 million/day may really hurt profit margins, which could cost their stock to tank, employees to lose confidence, etc. That has some force.
For something different, you'll find SISC
brings actual new expressability to the Java platform, rather than just scripting
the same old stuff. This lets you do radically different things, as demonstrated
by SISCweb, which allows you to write web applications
without dealing with the stateless, page-centric nature of HTTP.
Plus, you'll learn Scheme, which will make you a better programmer.
Whatever you do, you're probably not thinking enough. Archival is hard.
Here is what I'm doing, and the rationale for why
First, I bought an Epson Perfection 4990. It does 48-bit negative
scans with Digital ICE for dust removal. The scans of a 24 exposure roll
take 180 minutes, but trust me, its worth the time to not have to spend
the time in Photoshop removing the dust by hand.
You are scanning negatives right? Photos are great, but they are
a small dynamic range snapshot of what the camera actually recorded. Scan negatives, and scan them in high bit depth, otherwise you're not really archiving digitally, you're making a lossy copy. You want to be
able to make large prints, not just 4x6's forever.
I use the bundled scanning software, but other packages are probably as good or
better. Each picture is numbered sequentially, and the negatives are moved
after scanning into an archival binder with non-PVC negative protector sheets,
and each sheet is labeled with the range of image numbers. This is important, as
you *will* need to go back and rescan a few images for some reason at some time,
and the negatives themselves will last longer than the digital media if neglected.
Now, as for the format, I'm encoding to JPEG 2000, which preserves the lossless,
48-bit image, at 1/3 the size of a tiff. However, no software really uses it,
so each DVD includes a Windows and Linux statically linked build of the converter.
Each image group is burnt onto two DVDs, one DVD-R, and one DVD+R, from two different
reputable manufacturers. DVD reliability is all over the map, and you don't want
bitrot taking out one brand. Burning in different formats mitigates the risk
that one format stops being as readable in the future. Each DVD also includes
parity (PAR2) files, about 5-10% of the disk depending on how full they get.
This allows you to verify the disk is intact, a step you should do to all the DVDs
once every couple of years. If the disk is starting to fail, you can copy both DVDs
to harddrive, recover from parity, and burn anew.
Each DVD set is a mix of half DVD-R, half DVD+R (eg Disk 1=-R, Disk 2=+R, etc),
and a set is sent to my parents for safe keeping, and one set stays here. I've
sent the negatives home too, since they live in a safer climate.
Finally, the useless master DVDs with JPEG2000's are nice, but people really want to
*see* these images. Here, metadata is key. Make sure each image is at least tagged
with basic metadata in the Dublin Core set, like date, subject, location. I'm doing
that as a baseline, and adding Flikr style tags to all the images, and Getty TGF
tags for locations. The images are then converted to JPG at HDTV resolution for
viewing, and I'm writing a viewer application for searching, and all of this
will go online.
Its not an easy project, but its really rewarding to come across old photos and
know that they won't sit in a photo album or shoebox unseen, and future generations
will have something to look back at. Have fun!
See also SISCweb, a framework which uses Scheme on the J2EE platform, getting you all the fun of continuation based web-programming, with the library -goodness of Java.
No, it just means that those myths don't apply on the Cell-phone platform. Thats not surprising, I doubt Cell Phones do JIT compiling, and their hardware is so different from PCs and each other, that you're stupid to think you aren't going to get away without testing.
And to reiterate, Java is nearly as fast as native code. Some of it's libraries aren't as fast as C equivalents though. I should know
Still, Java is appropriate for those devices, since it allows the manufacturers to change their phones frequently without rewriting much software, and allows consumers to use the same software on multiple makes/models of phone.
The definition of a supercomputer is a moving line. At any given time, a supercomputer is usually just a machine with an order of magnitude more CPU throughput than a PC. This neglects things supercomputers have that desktops don't like massive I/O capabilities, but in terms of CPU performance, today's desktops are usually as fast as the past's supercomputers.
Sarahbot, a Scheme bot written in SISC, interfaces with an ALICE bot (Anna actually) for AI. She hangs out in #scheme, #ant-wars, and #sisc on irc.freenode.net, and acts as a general infobot as well as a clever diversion.
My point was rather that some Ant Wars ants, which have been created in the last week, not three months, defeat the winner which they had never seen.
I'm not trying to take away from the winning teams accomplishment, which is stupendous, but rather to point out that its interesting that there were no ants in competition which aggressively defended their bases.
For those of you who want to see the winners in action, the Formicidae simulator from Ant Wars can be used. It comes with a converter from the ICFP language to Ant Wars bytecode. To do so:
1. Grab a copy of Formicidae from the download page
2. Use the included convert.py on an ICFP.ant file: convert.py <filename.ant>
3. Run formicidae.[sh|bat], and provide a world (ICFP maps included in the worlds/ subdirectory) and two.antc files
4. Check ICFP Mode
5. Enjoy the match
Interestingly, this year's winning ant is already beaten by some of the competitors on Ant Wars, due to the fact that some Ant Wars ants have more aggressive defensive tactics that wind up decimating Dunkosmiloolump's ants that too brazenly approach their ant hill.
As has been mentioned, the high level language is written to be easily parsed and compiled (its recursive and LISPy). The target is actually bytecode, so there is nothing stopping people from writing any sort of syntax, or higher level frontends capable of things that aren't possible in the provided language.
We don't use Java, one, because we don't want people to have to use Java, and more importantly we have to avoid turing completeness both to keep the game simple and elegant, and to ensure a reasonable amount of time to simulate games.
Besides, the Java Security Manager isn't so fine grained that you can turn off arbitrary parts of the Java library. It just prevents certain known dangerous things like I/O, etc.
First, a little about SHA and SHA-1. SHA (0) was developed as a national standard hash function. Curiously, a last minute change was proposed by the NSA which resulted in SHA-1. The change was puzzling the cryptographers in academia. After some time, an attack was discovered on some classes of cryptographic hashes which SHA-1 turned out to be curiously immune to.
All that aside, one should view cryptographers a bit like plumbers. Cryptographers have a bag full of equipment (algorithms), which they combine in many ways to accomplish what they want. After much research and testing, certain ways of combining those pipes, valves, and spigots are 'proven' to work well, within given assumptions, such as expecting an L-joint not to leak. SHA-1 likewise is an integral component in many cryptographic systems.
SHA, MD5, RIPEM, and others are cryptographic hash functions.
Cryptographers expect certain things out of a hash function. Its job is to take a variable amount of input bytes, and give you back a small, fixed number of bytes. Most importantly:
The function is 'one-way'. You can't determine from the output what any of the input was.
The probability that two inputs hash to the same output should be exceedingly low. In particular, an ideal hash function has a randomly distributed output for a large set of inputs.
Given a hash output, it should be extremely difficult to construct another document which also hashes to that output.
In this case, it seems that it may be much more easy than the designers had hoped to break the second condition. This tends to mean that 3 is easier as well, which has ramifications for security protocols.
So, in summary, this discovery is a bit like finding out that an L-joint which has been used reliably by plumbers the world over is much more likely to leak than previously thought.
Materialized views are provided in the PostgreSQL contributed package. Its implemented using database triggers, and works (I use it in production) but its not as mature as the official features.
If Microsoft successfully grabs and holds a monopoly on browsers, it can continue to create software and encourage other developers to create software (web applications) which use IE enhancements like DHTML.
Then people begin to rely on those web applications, like online Banking sites, webmail, etc. This holds people on the MS platform, increasing OS sales, but probably more importantly, those enhancements often require a Microsoft server platform, which equals big bucks for MS.
All you need to do to make sure the idea isn't ever patented and used against your wishes is to make your idea strong prior art.
To do this, describe your idea in detail (as if you were going to patent it), but instead of spending the large sum of money to patent it, spend a smaller amount getting it officially notarized by a notary public.
In addition, you may want to timestamp a digital copy (Verisign will do this for a small fee), and make it available online.
Fetching memory from the other processor does add latency, and consumes some bandwidth. But the added latency is on the order of 15ms, which combined with the architectures already low latency (due to the onboard memory controller), still puts it 20ms or so faster than the P4 memory interface. So don't sweat the latency.
The bandwidth is of somewhat greater concern. This is essentially the same setup as the traditional x86 architecture, where all access to memory occurs over a shared bus (in this case, the hypertransport link between CPU0 and CPU1). So again, no worse than the SMP systems of yore (better actually because of reduced latency and the faster hypertransport link).
Slashdot Mirror
You'd like Baseball Boss as well then. It combines card trading (real players, MLB licensed) and then playing those cards on teams. Great stats and tons of fun.
For disks which only have minor scratches, rub a plain wax candle all over the surface, radially. Once covered, buff it with a smooth cloth (I usually use my cotton T-shirt). The wax fills the scratches well enough to read them, usually. If this doesn't work, try the toothpaste trick but the wax trick is non-destructive.
See for example SISCweb.
Furthermore, one can access other libraries than those written in Scheme, using bindings to C/C++ libraries, or in the case of SISC, access to any and all Java libraries. This, combined with Scheme's flexible language constructs, has led to amazingly powerful programming frameworks such as SISCweb (think Web 3.0 if you want a buzzword).
That may be true, but Microsoft is currently hurting on Wall Street trying to show continued growth. 2.5 million/day may really hurt profit margins, which could cost their stock to tank, employees to lose confidence, etc. That has some force.
Not true:
(let ([x 3])
(set! x 4)
x)
=> 4
For something different, you'll find SISC brings actual new expressability to the Java platform, rather than just scripting the same old stuff. This lets you do radically different things, as demonstrated by SISCweb, which allows you to write web applications without dealing with the stateless, page-centric nature of HTTP.
Plus, you'll learn Scheme, which will make you a better programmer.
Whatever you do, you're probably not thinking enough. Archival is hard.
Here is what I'm doing, and the rationale for why
First, I bought an Epson Perfection 4990. It does 48-bit negative scans with Digital ICE for dust removal. The scans of a 24 exposure roll take 180 minutes, but trust me, its worth the time to not have to spend the time in Photoshop removing the dust by hand.
You are scanning negatives right? Photos are great, but they are a small dynamic range snapshot of what the camera actually recorded. Scan negatives, and scan them in high bit depth, otherwise you're not really archiving digitally, you're making a lossy copy. You want to be able to make large prints, not just 4x6's forever.
I use the bundled scanning software, but other packages are probably as good or better. Each picture is numbered sequentially, and the negatives are moved after scanning into an archival binder with non-PVC negative protector sheets, and each sheet is labeled with the range of image numbers. This is important, as you *will* need to go back and rescan a few images for some reason at some time, and the negatives themselves will last longer than the digital media if neglected.
Now, as for the format, I'm encoding to JPEG 2000, which preserves the lossless, 48-bit image, at 1/3 the size of a tiff. However, no software really uses it, so each DVD includes a Windows and Linux statically linked build of the converter.
Each image group is burnt onto two DVDs, one DVD-R, and one DVD+R, from two different reputable manufacturers. DVD reliability is all over the map, and you don't want bitrot taking out one brand. Burning in different formats mitigates the risk that one format stops being as readable in the future. Each DVD also includes parity (PAR2) files, about 5-10% of the disk depending on how full they get. This allows you to verify the disk is intact, a step you should do to all the DVDs once every couple of years. If the disk is starting to fail, you can copy both DVDs to harddrive, recover from parity, and burn anew.
Each DVD set is a mix of half DVD-R, half DVD+R (eg Disk 1=-R, Disk 2=+R, etc), and a set is sent to my parents for safe keeping, and one set stays here. I've sent the negatives home too, since they live in a safer climate.
Finally, the useless master DVDs with JPEG2000's are nice, but people really want to *see* these images. Here, metadata is key. Make sure each image is at least tagged with basic metadata in the Dublin Core set, like date, subject, location. I'm doing that as a baseline, and adding Flikr style tags to all the images, and Getty TGF tags for locations. The images are then converted to JPG at HDTV resolution for viewing, and I'm writing a viewer application for searching, and all of this will go online.
Its not an easy project, but its really rewarding to come across old photos and know that they won't sit in a photo album or shoebox unseen, and future generations will have something to look back at. Have fun!
See also SISCweb, a framework which uses Scheme on the J2EE platform, getting you all the fun of continuation based web-programming, with the library -goodness of Java.
No, just the N.
No, it just means that those myths don't apply on the Cell-phone platform. Thats not surprising, I doubt Cell Phones do JIT compiling, and their hardware is so different from PCs and each other, that you're stupid to think you aren't going to get away without testing.
And to reiterate, Java is nearly as fast as native code. Some of it's libraries aren't as fast as C equivalents though. I should know
Still, Java is appropriate for those devices, since it allows the manufacturers to change their phones frequently without rewriting much software, and allows consumers to use the same software on multiple makes/models of phone.
The definition of a supercomputer is a moving line. At any given time, a supercomputer is usually just a machine with an order of magnitude more CPU throughput than a PC. This neglects things supercomputers have that desktops don't like massive I/O capabilities, but in terms of CPU performance, today's desktops are usually as fast as the past's supercomputers.
Sarahbot, a Scheme bot written in SISC, interfaces with an ALICE bot (Anna actually) for AI. She hangs out in #scheme, #ant-wars, and #sisc on irc.freenode.net, and acts as a general infobot as well as a clever diversion.
My point was rather that some Ant Wars ants, which have been created in the last week, not three months, defeat the winner which they had never seen.
I'm not trying to take away from the winning teams accomplishment, which is stupendous, but rather to point out that its interesting that there were no ants in competition which aggressively defended their bases.
For those of you who want to see the winners in action, the Formicidae simulator from Ant Wars can be used. It comes with a converter from the ICFP language to Ant Wars bytecode. To do so:
1. Grab a copy of Formicidae from the download page .ant file: .antc files
2. Use the included convert.py on an ICFP
convert.py <filename.ant>
3. Run formicidae.[sh|bat], and provide a world (ICFP maps included in the worlds/ subdirectory) and two
4. Check ICFP Mode
5. Enjoy the match
Interestingly, this year's winning ant is already beaten by some of the competitors on Ant Wars, due to the fact that some Ant Wars ants have more aggressive defensive tactics that wind up decimating Dunkosmiloolump's ants that too brazenly approach their ant hill.
Something's definitely wrong with your browser or DNS then. The front page has no authentication whatsoever.
No, the only restricted parts of the site are starting ranked matches or submitting ants.
As has been mentioned, the high level language is written to be easily parsed and compiled (its recursive and LISPy). The target is actually bytecode, so there is nothing stopping people from writing any sort of syntax, or higher level frontends capable of things that aren't possible in the provided language.
We don't use Java, one, because we don't want people to have to use Java, and more importantly we have to avoid turing completeness both to keep the game simple and elegant, and to ensure a reasonable amount of time to simulate games.
Besides, the Java Security Manager isn't so fine grained that you can turn off arbitrary parts of the Java library. It just prevents certain known dangerous things like I/O, etc.
The ants in Ant Wars are defined using a bytecode, so you can create/use any language which generates said bytecode.
.f6..2..81....5...2....l...6.2..b..d0.....6.1..g.. 0
....l6.1..B..D0v...l1....l..t
An example ant species genome:
i0v....1.......8.f3..o..t1....r...3.....6.2..w..y
First, a little about SHA and SHA-1. SHA (0) was developed as a national standard hash function. Curiously, a last minute change was proposed by the NSA which resulted in SHA-1. The change was puzzling the cryptographers in academia. After some time, an attack was discovered on some classes of cryptographic hashes which SHA-1 turned out to be curiously immune to.
All that aside, one should view cryptographers a bit like plumbers. Cryptographers have a bag full of equipment (algorithms), which they combine in many ways to accomplish what they want. After much research and testing, certain ways of combining those pipes, valves, and spigots are 'proven' to work well, within given assumptions, such as expecting an L-joint not to leak. SHA-1 likewise is an integral component in many cryptographic systems.
SHA, MD5, RIPEM, and others are cryptographic hash functions. Cryptographers expect certain things out of a hash function. Its job is to take a variable amount of input bytes, and give you back a small, fixed number of bytes. Most importantly:
- The function is 'one-way'. You can't determine from the output what any of the input was.
- The probability that two inputs hash to the same output should be exceedingly low. In particular, an ideal hash function has a randomly distributed output for a large set of inputs.
- Given a hash output, it should be extremely difficult to construct another document which also hashes to that output.
In this case, it seems that it may be much more easy than the designers had hoped to break the second condition. This tends to mean that 3 is easier as well, which has ramifications for security protocols.So, in summary, this discovery is a bit like finding out that an L-joint which has been used reliably by plumbers the world over is much more likely to leak than previously thought.
But we haven't seen the results yet...
Materialized views are provided in the PostgreSQL contributed package. Its implemented using database triggers, and works (I use it in production) but its not as mature as the official features.
Okay: You're clueless.
If Microsoft successfully grabs and holds a monopoly on browsers, it can continue to create software and encourage other developers to create software (web applications) which use IE enhancements like DHTML.
Then people begin to rely on those web applications, like online Banking sites, webmail, etc. This holds people on the MS platform, increasing OS sales, but probably more importantly, those enhancements often require a Microsoft server platform, which equals big bucks for MS.
All you need to do to make sure the idea isn't ever patented and used against your wishes is to make your idea strong prior art.
To do this, describe your idea in detail (as if you were going to patent it), but instead of spending the large sum of money to patent it, spend a smaller amount getting it officially notarized by a notary public.
In addition, you may want to timestamp a digital copy (Verisign will do this for a small fee), and make it available online.
Fetching memory from the other processor does add latency, and consumes some bandwidth. But the added latency is on the order of 15ms, which combined with the architectures already low latency (due to the onboard memory controller), still puts it 20ms or so faster than the P4 memory interface. So don't sweat the latency.
The bandwidth is of somewhat greater concern. This is essentially the same setup as the traditional x86 architecture, where all access to memory occurs over a shared bus (in this case, the hypertransport link between CPU0 and CPU1). So again, no worse than the SMP systems of yore (better actually because of reduced latency and the faster hypertransport link).