Oh darn. I can't have a single array that's larger than 18,446,744,073,709,551,616 bytes? Shucks.
Seriously, segmented programming sucked when segments were only 16 bits. We're doing segmented programming today on 32-bit machines that have more than 4GB of RAM. The trick there is that no individual task can see more than 4GB at a time. The OS has to handle the segment addressing to get to all the pages. It's not the most friendly model in the world, but it does work, and it's not nearly so painful as it was when you couldn't even hold an entire frame buffer in one segment, let alone a large document. It's still better than manual paging/bank switching like the 8-bitters went through.
(Although... it'd be pretty sweet if displays got to a high enough DPI that I needed more than 4GB to hold just the frame buffer. I better have the graphics acceleration to support it though.)
Obviously you have no concept of how much address space there is in 64-bits. There isn't enough raw material on Earth to create enough RAM and/or disk space to need 64-bit addressing.
Bollocks. If you want to do it with RAM alone, you need 4 billion machines with 4GB of RAM to reach 64 bits of RAM address space. Yeah, that sounds pretty high, but that's just RAM. If you want to consider disk space, you only need ~16 million terabyte drives to reach the limits of 64 bits of address space. I imagine there's at least that many out there right now. Are these all hooked to one machine? No. But they're probably all hooked to the Internet. If you wanted to globally address all the bytes out there today, you'd need a damn sight more than 64 bits.
And that's today. Storage trends are such that storage doubles fairly regularly, so that we end up burning address bits at a pretty steady rate. In fact, that rate appears to be just slightly faster than a bit per year.
Therefore, I think a 128 bit Windows 8 is ridiculous (and as others have pointed out, most likely a hoax). On that point we agree. At the point 128 bits becomes relevant, the notion of a monolithic OS on a distinct computer may well be obsolete. We'll see though.
I think that we'll see 64 bits as the limit on individual machines for quite awhile--another 20 years at least. In the x86 world, the jump from 16 to 32 took around 7 years whereas the jump from 32 bit to 64 bit took around 15. (8086 came out in 1978, i386 came out in 1985, and x86-64 came out in 2000.) If we burn address bits at a roughly constant rate as these last two jumps did, the jump from 64 to 128 bits will happen around 30 years after x86-64 came out, around 2030. If we hit fundamental technology limits, or simply reach a point of diminishing returns on greater storage (which may well happen unless we just start recording our entire lives in Quad-HD or something), we may get bored before we reach the limits of 64 bits.
Ugh... I see my error. I read that umpteen times as "catch a corrupted packet", not "match a corrupted packet." The unusual wording threw me off. I would have worded it as "let a corrupted packet slip by" or "miss a corrupted packet."
Then what exactly did you mean when you said this?
The checksum used by TCP is several orders of magnitude more likely to match a corrupted packet than the checksum used by bittorrent.
On one hand you're saying TCP's checksum is orders of magnitude more likely to catch the error, and on the other hand you're saying Bittorrent's is. Pick one.
You're confusing the different layers. The CRC-32 at the link layer is at a layer below the IP datagram. The TCP checksum catches errors between TCP and the link layer. Bittorrent's checksum checks at a layer above that, catching errors that may have occurred before the torrent's packets even entered the TCP/IP stack at the sending side. The authors of the paper you linked even recommend application-level error checking on the first page.
"Parity" RAM just means that it has an extra bit for each byte. With enough bytes, you have enough "parity" storage that you can store an ECC value instead. See this comment I made elsewhere on this thread.
Confusing things is that many people call Hamming codes "Hamming parity," which actually isn't as gross an error as it sounds, because Hamming codes are constructed from parity computations on different subsets of the data.
So, when you buy a x72 DIMM instead of a x64 DIMM, you have enough additional storage that you can store an ECC value with each 64-bit datum. That's true regardless of the fact the sticker and common parlance might refer to such a DIMM as "parity RAM".
Murrh? A soft-error means a bit flipped but the memory cell is still fine. It won't unflip until you rewrite it. A hard error means that a component repeatedly causes the same error, implying that the component itself is flaky.
So, a cosmic ray or alpha particle might flip a bit, but it's an error that's random and affects all bits across all DIMMs with roughly equal probability. A hard error is something you could isolate to a particular chip, bus or memory controller. EMI-induced errors due to bad board design or bad manufacturing fall in the hard error category, since it's a defect that will cause repeated errors at an elevated rate. The fact that 90% of the errors come from 20% of the machines in Google's study indicates that hard errors are the dominant error mode.
Kinda makes me wonder if running at say 10% underclock might make the errors mostly go away.
It depends on what the failure mode is. If the failure is due to a burst of cosmic rays or something flipping a set of bits, then it doesn't matter what clock rate you run at. If the failure is due to a bounce on the data bus that carries data to the DRAM while you're writing it (creating a hard error, the type Google observed at a much, much higher rate than expected), then a slower clock might work better there.
This also raises another question for me: What about signal line termination? The lines connecting the DRAMs to the memory controller are transmission lines, and so are subject to reflections and such. Buffered vs. unbuffered affects the electrical characteristics, as does the number of populated slots vs. unpopulated. Do the numbers shift dramatically if I don't fill all my DRAM slots?
First, the paper on hard drives did show that temperature was important. It did show though that too cold is worse than too hot. Also, the data wasn't perfect. Google doesn't have a whole lot of drives running at strange temperatures, since they're a datacenter. A consumer though, might well run a drive at 60C in a badly cooled desktop or laptop, and there's not a single datapoint on Google's graph for that.
Yipe! 60C is 140 degrees F... Really? How do you manage to get a hard drive that hot, when it's bolted to a case that can act as a heat sink? I can imagine CPU temps getting that high, but that's because you're dissipating 20W to 100W in an area the size of a fingernail. Even with a heatsink, it can be hard to move that much energy that quickly from that small a space. Hard drives, though? Are you wrapping the thing in bubble wrap?
The original PC added a 9th bit to each byte, creating parity RAM. It was unique among personal computers at the time. None (or nearly none) of the original PC's contemporaries did this. But, since IBM did, many clones followed suit in the PC space. Macs, notably, didn't support ECC for many, many years, but if you pop open a Columbia Data Products PC, you'll see parity RAM. (Note "128K RAM with parity" in that scan.) IBM went with byte parity in part because bytes were the smallest memory unit the CPU read or wrote to the memory. With byte parity, every memory access could be protected.
This ratio of 9/8 stuck with the PC's memory system over the years, following it to ever wider interfaces. That includes the 16 bit buses of the 286 and 386SX, the 32-bit buses of the 386DX and 486, and the 64 bit bus of the original Pentium. While many manufacturers made the byte parity optional as a cost saver, it was still rather common.
Once you get to 64 bits, you have 8 extra parity bits for a total memory width of 72 bits. This is enough bits to implement a single-error correct, double-error detect Hamming code on the 64-bit data. As long as you always read or write in multiples of 64 bits, you can also generate the Hamming code on writes and check it on reads.
Note that caveat: "As long as you always read or write in multiples of 64 bits." By the time you get to the 486 era, on-board L1 caches started to become standard equipment. Caches can turn a single byte read or write into a multiple byte line-fill (assuming they do read-allocate and write-allocate). They can also make writes wider. In write-back mode, they tend to write back the entire cache line if any portion was updated. In write-through mode, they could theoretically package additional bytes from the cache line to go with whatever bytes the CPU wrote to get to a minimum data size. (I don't know if the 486 or Pentium actually did this, FWIW. I'm speaking of general principles of operation.)
The combination of caches and wider buses made ECC practical for PC hardware starting with the Pentium. That's why you started to see it in that time frame and not before.
BTW, the error rate for individual DRAM bit flips should increase as the bits get smaller. It doesn't surprise me that your Pentium Pro's bits never flipped. It was probably built around 16 megabit DRAM chips, or maybe 64 megabit. If you compare a 16 megabit DRAM chip to a 1 gigabit DRAM chip of the same physical size, the bit cells on the gigabit chip are 1/64th the size. That means far fewer electrons holding the bit. As you can imagine, that might increase the likelihood of error per bit. Google's study didn't show an increase in error rate across memory technologies, but its window of memory technologies didn't stretch back 15 years to the Pentium Pro era.
There's also just the total quantity of memory. Your Pentium Pro system probably had at most 128MB. Compare that to a modern system with 4GB. A 4GB system has 32x the memory of a 128MB system. Even if the per-bit error rate remained constant, there are 32x as many bits, so 32x as many errors. Modern systems also implement scrubbing, meaning they actively read all of memory in the background looking for errors. Older systems just waited for the CPU to access a word with a bad bit to raise an error. This also makes the observed error rate drastically different, since many errors would go by unnoticed in a system without scrubbing, but would get proactively noticed (and fixed) in a system with scrubbing.
FWIW, I run my systems these days with ChipKill ECC enabled and scrubbing enabled. Not taking chances. I'll give up 3-5% on performance since most of the time I won't notice it.
ECC doesn't change the DRAM's bit error rate. It changes the number of bits.;-)
Decompressing that witticism a bit: DRAM cells have a particular error rate associated with them. That is, you can expect the total number of errors in your system to be proportional to both total memory size and total time. The DRAM used to store ECC bits needs to be included in that calculation. If you have 1 gigabyte of ECC DRAM, that's 8 * 2^30 bits of storage in a non-ECC system, and 9 * 2^30 bits of storage in an ECC system--12.5% larger. So the absolute number of single-bit errors should be 12.5% larger in the ECC system than the non-ECC system.
Now, since the amount of storage usable for data did not increase in the system with ECC RAM, it the error rate per data bit increased, even if the error rate per DRAM bit did not. ECC, though, will at a minimum correct single bit errors (including in itself), so it more than amply carries its weight. (Most commonly, it will also detect double-bit errors. On higher end systems, you get nifty features like AMD's Chip Kill, which can correct up to 4 bit errors.)
This being Slashdot, I will now dive into the car analogy.
Ok, here's something to try... ask random people on the street whether their car has overhead cams or pushrods. For the vast majority you'll get a blank stare. Folks know "V8", "V6", and "four banger", and a few know "VTEC." A few might remember their car has a SOHC or DOHC decal on it. But I wager the vast majority won't know. And we're talking cars here. That's something that's been part of the American experience for around a century. Lots more people "get" cars than computers.
The fact that the website you visit runs Linux isn't much different than the fact your car has dual overhead cams. Yeah, it may perform better, get better fuel economy, etc., but only gearheads really care. Everyone else just cares that aa given car holds up well and a given website loads quickly. It's much the same for this instant-on, low battery mode. Nobody cares that it's an ARM or that it runs Linux. Having a couple days' battery time and instant on? That's what matters.
Looking around, it appears it has an OMAP 3430, which is pretty darn cool from my perspective. I worked on the C64x+ DSP that's on that chip. It's the same chip that powers the Nokia N900.
MD5s won't help except to detect corruption, as you say in your first sentence. I imagine having duplicate copies of the DVD, recorded identically would be a cheap, low-tech alternative. Even if some blocks on one copy get destroyed, chances are those same blocks are good on another. With enough parallel copies, you can be sure to find a good version of each block on at least one.
While DVDs might only last a decade, it's not like they'll entirely go *poof* on day 3653. They'll begin degrading, but each one will degrade differently.
The only other issue, as another poster mentioned, is making sure that the data is in a format that current software knows how to read/decode, so you must also give them the right to transcode or otherwise export the work to other digital formats. (For example, transforming 3D model, texture, animation, and scene data from one format to another
This is where open formats and implementations, or at least openly documented formats and reference implementations, can come in handy. If you can back up reference material on how to decode the art along with the art, then if any copy survives, then someone motivated enough can reconstruct the output. For example, if you make a video in Ogg Theora format, why not include the source code for the Theora and Ogg libraries along with the related specs? Chances are that the size of the art itself is much larger than the codec and documentation. Think of it as something akin to the Rosetta Stone, applied digitally.
Even if there are no C compilers 1000 years from now (unlikely, as I suspect C is the cockroach of programming languages), there will be plenty of surviving references on how to interpret the code.. Heck, even today we can understand and "execute" Lady Ada Lovelace's Analytical Engine software. Even if there aren't, I'd posit that algorithms rendered in symbolic language are easier to decode sans reference than human text.
For relatively compact data, such as models, perhaps export them in a generic descriptive format such as XML. (I say relatively compact, since I imagine a detailed model may be large, but a movie rendered from that model at high resolution could be significantly larger.) Again, a transparent, clearly structured self documenting format can be much more easily reconstructed than a proprietary format. If you go XML, don't forget to include the schema!
--Joe
(PS. I call C the cockroach of programming languages out of love. Really, I do.)
I assume you refer to the United States. The US was actually late to the party. The Berne Convention got the ridiculous-copyright-term ball rolling... Disney just gave it an extra push. In particular:
The Berne Convention states that all works except photographic and cinematographic shall be copyrighted for at least 50 years after the author's death
The Berne Convention is also what gives us the rule that daid303 stated, that you don't need to add a copyright notice to get copyright:
Under the Convention, copyrights for creative works are automatically in force upon their creation without being asserted or declared. An author need not "register" or "apply for" a copyright in countries adhering to the Convention. As soon as a work is "fixed", that is, written or recorded on some physical medium, its author is automatically entitled to all copyrights in the work and to any derivative works, unless and until the author explicitly disclaims them or until the copyright expires. Foreign authors are given the same rights and privileges to copyrighted material as domestic authors in any country that signed the Convention.
The US didn't sign on to Berne until 1988. The EU's been on board for awhile, as have many, many other countries. So, yes, you're technically correct that there are some people that are unaffected by the US's copyright protections (or in the case of Nintendo's IP, Japan's). But, a great many places have similar restrictions.
January 1st is the 1st day of the year, but it's day index 0, since indices start at 0. So, the first day has day index 0. Therefore, the 256th day has day index 255. That still fits in a byte.
Slashdot Mirror
Most modern PSUs work that way. Older ones are 110v or 220v only, or had a switch.
Oh darn. I can't have a single array that's larger than 18,446,744,073,709,551,616 bytes? Shucks.
Seriously, segmented programming sucked when segments were only 16 bits. We're doing segmented programming today on 32-bit machines that have more than 4GB of RAM. The trick there is that no individual task can see more than 4GB at a time. The OS has to handle the segment addressing to get to all the pages. It's not the most friendly model in the world, but it does work, and it's not nearly so painful as it was when you couldn't even hold an entire frame buffer in one segment, let alone a large document. It's still better than manual paging/bank switching like the 8-bitters went through.
(Although... it'd be pretty sweet if displays got to a high enough DPI that I needed more than 4GB to hold just the frame buffer. I better have the graphics acceleration to support it though.)
Bollocks. If you want to do it with RAM alone, you need 4 billion machines with 4GB of RAM to reach 64 bits of RAM address space. Yeah, that sounds pretty high, but that's just RAM. If you want to consider disk space, you only need ~16 million terabyte drives to reach the limits of 64 bits of address space. I imagine there's at least that many out there right now. Are these all hooked to one machine? No. But they're probably all hooked to the Internet. If you wanted to globally address all the bytes out there today, you'd need a damn sight more than 64 bits.
And that's today. Storage trends are such that storage doubles fairly regularly, so that we end up burning address bits at a pretty steady rate. In fact, that rate appears to be just slightly faster than a bit per year.
Therefore, I think a 128 bit Windows 8 is ridiculous (and as others have pointed out, most likely a hoax). On that point we agree. At the point 128 bits becomes relevant, the notion of a monolithic OS on a distinct computer may well be obsolete. We'll see though.
I think that we'll see 64 bits as the limit on individual machines for quite awhile--another 20 years at least. In the x86 world, the jump from 16 to 32 took around 7 years whereas the jump from 32 bit to 64 bit took around 15. (8086 came out in 1978, i386 came out in 1985, and x86-64 came out in 2000.) If we burn address bits at a roughly constant rate as these last two jumps did, the jump from 64 to 128 bits will happen around 30 years after x86-64 came out, around 2030. If we hit fundamental technology limits, or simply reach a point of diminishing returns on greater storage (which may well happen unless we just start recording our entire lives in Quad-HD or something), we may get bored before we reach the limits of 64 bits.
*d'oh* our replies crossed. Again, my apologies.
Ugh... I see my error. I read that umpteen times as "catch a corrupted packet", not "match a corrupted packet." The unusual wording threw me off. I would have worded it as "let a corrupted packet slip by" or "miss a corrupted packet."
Sorry for the confusion.
Then what exactly did you mean when you said this?
On one hand you're saying TCP's checksum is orders of magnitude more likely to catch the error, and on the other hand you're saying Bittorrent's is. Pick one.
--Joe
You're confusing the different layers. The CRC-32 at the link layer is at a layer below the IP datagram. The TCP checksum catches errors between TCP and the link layer. Bittorrent's checksum checks at a layer above that, catching errors that may have occurred before the torrent's packets even entered the TCP/IP stack at the sending side. The authors of the paper you linked even recommend application-level error checking on the first page.
Hmmm... The lottery has astronomical odds, which means I have a microscopic chance of winning.
"Parity" RAM just means that it has an extra bit for each byte. With enough bytes, you have enough "parity" storage that you can store an ECC value instead. See this comment I made elsewhere on this thread.
Confusing things is that many people call Hamming codes "Hamming parity," which actually isn't as gross an error as it sounds, because Hamming codes are constructed from parity computations on different subsets of the data.
So, when you buy a x72 DIMM instead of a x64 DIMM, you have enough additional storage that you can store an ECC value with each 64-bit datum. That's true regardless of the fact the sticker and common parlance might refer to such a DIMM as "parity RAM".
Murrh? A soft-error means a bit flipped but the memory cell is still fine. It won't unflip until you rewrite it. A hard error means that a component repeatedly causes the same error, implying that the component itself is flaky.
So, a cosmic ray or alpha particle might flip a bit, but it's an error that's random and affects all bits across all DIMMs with roughly equal probability. A hard error is something you could isolate to a particular chip, bus or memory controller. EMI-induced errors due to bad board design or bad manufacturing fall in the hard error category, since it's a defect that will cause repeated errors at an elevated rate. The fact that 90% of the errors come from 20% of the machines in Google's study indicates that hard errors are the dominant error mode.
It could also be bad/dirty connectors on the motherboard, I suppose.
It depends on what the failure mode is. If the failure is due to a burst of cosmic rays or something flipping a set of bits, then it doesn't matter what clock rate you run at. If the failure is due to a bounce on the data bus that carries data to the DRAM while you're writing it (creating a hard error, the type Google observed at a much, much higher rate than expected), then a slower clock might work better there.
This also raises another question for me: What about signal line termination? The lines connecting the DRAMs to the memory controller are transmission lines, and so are subject to reflections and such. Buffered vs. unbuffered affects the electrical characteristics, as does the number of populated slots vs. unpopulated. Do the numbers shift dramatically if I don't fill all my DRAM slots?
Yipe! 60C is 140 degrees F... Really? How do you manage to get a hard drive that hot, when it's bolted to a case that can act as a heat sink? I can imagine CPU temps getting that high, but that's because you're dissipating 20W to 100W in an area the size of a fingernail. Even with a heatsink, it can be hard to move that much energy that quickly from that small a space. Hard drives, though? Are you wrapping the thing in bubble wrap?
"Regular RAM" has neither parity nor ECC.
The original PC added a 9th bit to each byte, creating parity RAM. It was unique among personal computers at the time. None (or nearly none) of the original PC's contemporaries did this. But, since IBM did, many clones followed suit in the PC space. Macs, notably, didn't support ECC for many, many years, but if you pop open a Columbia Data Products PC, you'll see parity RAM. (Note "128K RAM with parity" in that scan.) IBM went with byte parity in part because bytes were the smallest memory unit the CPU read or wrote to the memory. With byte parity, every memory access could be protected.
This ratio of 9/8 stuck with the PC's memory system over the years, following it to ever wider interfaces. That includes the 16 bit buses of the 286 and 386SX, the 32-bit buses of the 386DX and 486, and the 64 bit bus of the original Pentium. While many manufacturers made the byte parity optional as a cost saver, it was still rather common.
Once you get to 64 bits, you have 8 extra parity bits for a total memory width of 72 bits. This is enough bits to implement a single-error correct, double-error detect Hamming code on the 64-bit data. As long as you always read or write in multiples of 64 bits, you can also generate the Hamming code on writes and check it on reads.
Note that caveat: "As long as you always read or write in multiples of 64 bits." By the time you get to the 486 era, on-board L1 caches started to become standard equipment. Caches can turn a single byte read or write into a multiple byte line-fill (assuming they do read-allocate and write-allocate). They can also make writes wider. In write-back mode, they tend to write back the entire cache line if any portion was updated. In write-through mode, they could theoretically package additional bytes from the cache line to go with whatever bytes the CPU wrote to get to a minimum data size. (I don't know if the 486 or Pentium actually did this, FWIW. I'm speaking of general principles of operation.)
The combination of caches and wider buses made ECC practical for PC hardware starting with the Pentium. That's why you started to see it in that time frame and not before.
BTW, the error rate for individual DRAM bit flips should increase as the bits get smaller. It doesn't surprise me that your Pentium Pro's bits never flipped. It was probably built around 16 megabit DRAM chips, or maybe 64 megabit. If you compare a 16 megabit DRAM chip to a 1 gigabit DRAM chip of the same physical size, the bit cells on the gigabit chip are 1/64th the size. That means far fewer electrons holding the bit. As you can imagine, that might increase the likelihood of error per bit. Google's study didn't show an increase in error rate across memory technologies, but its window of memory technologies didn't stretch back 15 years to the Pentium Pro era.
There's also just the total quantity of memory. Your Pentium Pro system probably had at most 128MB. Compare that to a modern system with 4GB. A 4GB system has 32x the memory of a 128MB system. Even if the per-bit error rate remained constant, there are 32x as many bits, so 32x as many errors. Modern systems also implement scrubbing, meaning they actively read all of memory in the background looking for errors. Older systems just waited for the CPU to access a word with a bad bit to raise an error. This also makes the observed error rate drastically different, since many errors would go by unnoticed in a system without scrubbing, but would get proactively noticed (and fixed) in a system with scrubbing.
FWIW, I run my systems these days with ChipKill ECC enabled and scrubbing enabled. Not taking chances. I'll give up 3-5% on performance since most of the time I won't notice it.
ECC doesn't change the DRAM's bit error rate. It changes the number of bits. ;-)
Decompressing that witticism a bit: DRAM cells have a particular error rate associated with them. That is, you can expect the total number of errors in your system to be proportional to both total memory size and total time. The DRAM used to store ECC bits needs to be included in that calculation. If you have 1 gigabyte of ECC DRAM, that's 8 * 2^30 bits of storage in a non-ECC system, and 9 * 2^30 bits of storage in an ECC system--12.5% larger. So the absolute number of single-bit errors should be 12.5% larger in the ECC system than the non-ECC system.
Now, since the amount of storage usable for data did not increase in the system with ECC RAM, it the error rate per data bit increased, even if the error rate per DRAM bit did not. ECC, though, will at a minimum correct single bit errors (including in itself), so it more than amply carries its weight. (Most commonly, it will also detect double-bit errors. On higher end systems, you get nifty features like AMD's Chip Kill, which can correct up to 4 bit errors.)
That sounds like a telecom voltage. Hmmm.... ;-)
This being Slashdot, I will now dive into the car analogy.
Ok, here's something to try... ask random people on the street whether their car has overhead cams or pushrods. For the vast majority you'll get a blank stare. Folks know "V8", "V6", and "four banger", and a few know "VTEC." A few might remember their car has a SOHC or DOHC decal on it. But I wager the vast majority won't know. And we're talking cars here. That's something that's been part of the American experience for around a century. Lots more people "get" cars than computers.
The fact that the website you visit runs Linux isn't much different than the fact your car has dual overhead cams. Yeah, it may perform better, get better fuel economy, etc., but only gearheads really care. Everyone else just cares that aa given car holds up well and a given website loads quickly. It's much the same for this instant-on, low battery mode. Nobody cares that it's an ARM or that it runs Linux. Having a couple days' battery time and instant on? That's what matters.
Looking around, it appears it has an OMAP 3430, which is pretty darn cool from my perspective. I worked on the C64x+ DSP that's on that chip. It's the same chip that powers the Nokia N900.
MD5s won't help except to detect corruption, as you say in your first sentence. I imagine having duplicate copies of the DVD, recorded identically would be a cheap, low-tech alternative. Even if some blocks on one copy get destroyed, chances are those same blocks are good on another. With enough parallel copies, you can be sure to find a good version of each block on at least one.
While DVDs might only last a decade, it's not like they'll entirely go *poof* on day 3653. They'll begin degrading, but each one will degrade differently.
This is where open formats and implementations, or at least openly documented formats and reference implementations, can come in handy. If you can back up reference material on how to decode the art along with the art, then if any copy survives, then someone motivated enough can reconstruct the output. For example, if you make a video in Ogg Theora format, why not include the source code for the Theora and Ogg libraries along with the related specs? Chances are that the size of the art itself is much larger than the codec and documentation. Think of it as something akin to the Rosetta Stone, applied digitally.
Even if there are no C compilers 1000 years from now (unlikely, as I suspect C is the cockroach of programming languages), there will be plenty of surviving references on how to interpret the code.. Heck, even today we can understand and "execute" Lady Ada Lovelace's Analytical Engine software. Even if there aren't, I'd posit that algorithms rendered in symbolic language are easier to decode sans reference than human text.
For relatively compact data, such as models, perhaps export them in a generic descriptive format such as XML. (I say relatively compact, since I imagine a detailed model may be large, but a movie rendered from that model at high resolution could be significantly larger.) Again, a transparent, clearly structured self documenting format can be much more easily reconstructed than a proprietary format. If you go XML, don't forget to include the schema!
--Joe
(PS. I call C the cockroach of programming languages out of love. Really, I do.)
So instead of chasing taillights, we're chasing nausea and vomit inducing blinky lights? Nice.
I assume you refer to the United States. The US was actually late to the party. The Berne Convention got the ridiculous-copyright-term ball rolling... Disney just gave it an extra push. In particular:
The Berne Convention is also what gives us the rule that daid303 stated, that you don't need to add a copyright notice to get copyright:
The US didn't sign on to Berne until 1988. The EU's been on board for awhile, as have many, many other countries. So, yes, you're technically correct that there are some people that are unaffected by the US's copyright protections (or in the case of Nintendo's IP, Japan's). But, a great many places have similar restrictions.
You missed the Seinfeld and Gates commercials, didn't you? You know, including the one where Bill's milkshake brought nobody to the yard?
My dad joked that the work ethic there was "We pretend to work and they pretend to pay us." Sounds about right.
Nononono....
January 1st is the 1st day of the year, but it's day index 0, since indices start at 0. So, the first day has day index 0. Therefore, the 256th day has day index 255. That still fits in a byte.