On Thu, 06 Dec 2012 20:59:23 +0100, Lanarcam <lanarcam1@yahoo.fr> wrote:>Le 06/12/2012 00:25, Jon Kirwan a �crit : >> On Wed, 05 Dec 2012 23:10:14 +0200, upsidedown@downunder.com >> wrote: >> >>> On Wed, 05 Dec 2012 12:17:50 -0800, Jon Kirwan >>> <jonk@infinitefactors.org> wrote: >>> >>>> But I lose the ability to have good storage for millennia. >>>> Holes in papertape will easily last a millenia, and more. >>>> Maybe I want to communicate with neo-humans 10,000 years from >>>> now and say "hi," eh? >>> >>> I guess a punched card (with a serial number in columns 73-80) made >>>from some more durable material would be a good way to send such >>> messages. >> >> Ah. The difference between ancient paged codices and scrolls. >> >> Hmm. Do I want future historians to handle codices or scrolls >> of mine? Must think on that problem. ;) >> >Nothing lasts longer than carved stone, prepare your chisel!Hmm. New 3D printer --- melts rock fed into a hopper and extrudes it.... might work. A few things may. Some very old fossils have been found. I don't know of any carved stone that has survived anywhere near that long. Of course, I don't think there have been the technical concepts for making carved stone for long enough to know, either. hehe. Still, it's an open question. Some fossils, I gather, (not many) have actually survived an overturning into heated situations near and perhaps through liquified magma. Rare, if I remember reading. But some minerals that substitute for bone may withstand higher heat than the surrounding rock. Hmm. Sapphire melts at over 2000C. Iridium at over 2400C. Both not entirely cheap, a sapphire boule cost me about $5000 last time I bought one. Iridium is very expensive (never bought any, though it is used to make the crucibles that are sometimes used to make sapphire.) But it might be usable in smaller quantities for communication over eons and tectonic effects. ;) Or, getting back to the 3D printer head, I just need to make the extruder out of sapphire or iridium -- most magma is lower temperature when liquid, I think. So technically doable that way, perhaps. Now there is a business opportunity if I ever saw one. :) Jon
Getting started with AVR and C
Started by ●November 24, 2012
Reply by ●December 6, 20122012-12-06
Reply by ●December 6, 20122012-12-06
In article <0c07ab50-9ad1-4e3b-915f- 0b5a245de80d@p15g2000yqd.googlegroups.com>, dp@tgi-sci.com says...> > On Dec 6, 4:05�pm, Ian Malcolm <See.My.Sig.for.em...@totally.invalid> > wrote: > > dp <d...@tgi-sci.com> wrote innews: > > .... > > > Is aluminum foil (I think plain kitchen foil) not longer lived than > > > paper? > > > Punching it at a 10 holes per mm (fairly dense but surely doable using > > > things we have at hand like lasers, PLL-ed rotating mirrors etc.) will > > > store >100 megabytes on an A4 sheet... > > > Hopefully the morlocks will be smart enough to read that though. > > > > > Dimiter > > > > Unfortunately the only durable metal foils are of precious metals and > > your epic is likely to be recycled for jewlery or coinage long before the > > next civilisation develops an interest in archeology. > > Hmmm, true of course. Gold foil will last but we will have to do > better with the pyramids to store it in than the Egyptians did, > otherwise the morlocks will always get only fragments and thus CRC > errors - at best. > > > I'd look at PTFE impregnated glassfibre cloth tape. > > <http://www.psadhesives.com/pdfs/ptfe-glass-cloth-tapes.pdf> > > have some non-adhesive ones on up to 30 meter rolls. > > Well Teflon should be long lived indeed but we can only > extrapolate on its longevity, too new. > I wonder if there are people who really want to do something in the > data longevity field who have already made CDs with some highly > durable plastic (or plain glass?), gold plated (there we go, > pyramids again). > Likely so, come to think of it.Already been done. Check out the Voyager Golden Record: http://en.wikipedia.org/wiki/Voyager_Golden_Record> > > To print on it you would need a custom ink with platinum black pigment in > > a PTFE binder, which would be thermally fused into the surface. > > <http://www.standardtechnical.com/page39a.html> > > Yes, that would make the pyramids unnecessary. But then who knows, > those future beasts may use the things as jewelry or toilet paper, > we should never underestimate their inventiveness. > > Walters idea to beam the data into space and let those who capture > it worry about it is probably best, long-term speaking. > > I wonder whether ants are interested in parsecs the way we seem > to be interested in millenia, universe age etc. :D . > > Dimiter >Mark Borgerson
Reply by ●December 6, 20122012-12-06
On Thu, 06 Dec 2012 20:59:23 +0100, Lanarcam <lanarcam1@yahoo.fr> wrote:>Nothing lasts longer than carved stone, prepare your chisel!How about etched diamond?
Reply by ●December 6, 20122012-12-06
George Neuner wrote:> On Thu, 06 Dec 2012 20:59:23 +0100, Lanarcam <lanarcam1@yahoo.fr> > wrote: > > >Nothing lasts longer than carved stone, prepare your chisel! > > How about etched diamond?Diamond burns but is hard enough :) w..
Reply by ●December 7, 20122012-12-07
On Thursday, December 6, 2012 3:04:07 AM UTC+2, dp wrote:> On Dec 6, 1:25�am, Jon Kirwan <j...@infinitefactors.org> wrote: > > > On Wed, 05 Dec 2012 16:32:15 -0500, Mel Wilson > > > > > > <mwil...@the-wire.com> wrote: > > > >Jon Kirwan wrote: > > > > > > >> But I lose the ability to have good storage for millennia. > > > >> Holes in papertape will easily last a millenia, and more. > > > >> Maybe I want to communicate with neo-humans 10,000 years from > > > >> now and say "hi," eh? > > > > > > >The holes will probably outlast the tape. �"Time Team" is one of my favorite > > > >shows, and they're continually trying to deduce, since dirt right here is a > > > >slightly different color from the dirt over there, that Saxons must have > > > >built something out of wood. > > > > > > > � �Mel. > > > > > > Cool, yet another reason for holes rather than ink spots on > > > paper. > > > > > > Jon > > > > Hmmm, joining the party a bit late but... > > > > Is aluminum foil (I think plain kitchen foil) not longer lived than > > paper? > > Punching it at a 10 holes per mm (fairly dense but surely doable using > > things we have at hand like lasers, PLL-ed rotating mirrors etc.) will > > store >100 megabytes on an A4 sheet... >Mmmm. 2100 * 2970 is 6237000 bits. Not sure where the 100Mbytes comes from.
Reply by ●December 7, 20122012-12-07
On Dec 7, 7:38�am, Rocky <RobertG...@gmail.com> wrote:> On Thursday, December 6, 2012 3:04:07 AM UTC+2, dp wrote: > > On Dec 6, 1:25�am, Jon Kirwan <j...@infinitefactors.org> wrote: > > > > On Wed, 05 Dec 2012 16:32:15 -0500, Mel Wilson > > > > <mwil...@the-wire.com> wrote: > > > > >Jon Kirwan wrote: > > > > >> But I lose the ability to have good storage for millennia. > > > > >> Holes in papertape will easily last a millenia, and more. > > > > >> Maybe I want to communicate with neo-humans 10,000 years from > > > > >> now and say "hi," eh? > > > > >The holes will probably outlast the tape. �"Time Team" is one of my favorite > > > > >shows, and they're continually trying to deduce, since dirt right here is a > > > > >slightly different color from the dirt over there, that Saxons must have > > > > >built something out of wood. > > > > > � �Mel. > > > > Cool, yet another reason for holes rather than ink spots on > > > > paper. > > > > Jon > > > Hmmm, joining the party a bit late but... > > > Is aluminum foil (I think plain kitchen foil) not longer lived than > > > paper? > > > Punching it at a 10 holes per mm (fairly dense but surely doable using > > > things we have at hand like lasers, PLL-ed rotating mirrors etc.) will > > > store >100 megabytes on an A4 sheet... > > Mmmm. 2100 * 2970 is 6237000 bits. Not sure where the 100Mbytes comes from.ROFL, I wish I could answer that. Pressed the * key twice on my calculator? Been asleep? Both? .... :D Dimiter
Reply by ●December 10, 20122012-12-10
Hi again Robert, Yesterday I thought of something I thought I might add to my reply, in case you are still reading this thread. In C there are certain types, e.g. "int", but there is no law that says how an int is stored in memory. It may be 16 bits or 32 or whatever (the compiler chooses this). There are however also types that specify exactly how wide they are, these are in the header file inttypes.h. Then you can choose things like uint16_t or int32_t. Especially in embedded systems these are very handy but to be honest, I use them in every C program I write nowadays. You may not find this "type of types" mentioned in for example the book I recommended, in practice they are more of an embedded / low level stuff thing but like I said, I always use them and I thought it wouldn't be a bad thing to explicitely mention them to you. Good luck again! Sincerely, Rene
Reply by ●December 10, 20122012-12-10
On Mon, 10 Dec 2012 13:21:35 +0100 Rene <a@b.c> wrote:> In C there are certain types, e.g. "int", but there is no law that > says how an int is stored in memory. It may be 16 bits or 32 or > whatever (the compiler chooses this). There are however also types > that specify exactly how wide they are, these are in the header file > inttypes.h. Then you can choose things like uint16_t or int32_t. > Especially in embedded systems these are very handy but to be honest, > I use them in every C program I write nowadays.Agreed those are wonderful types for situations where they make sense, but they are actually in stdint.h, not inttypes.h. inttypes.h contains various related goop like the PRI/SCN macros and other bits and pieces. Chris
Reply by ●December 11, 20122012-12-11
Op Thu, 29 Nov 2012 21:36:53 +0100 schreef Keith Thompson <kst-u@mib.org>:> upsidedown@downunder.com writes: >> On Thu, 29 Nov 2012 11:01:34 -0500, James Kuyper >> <jameskuyper@verizon.net> wrote: >> >>> On 11/29/2012 10:23 AM, Grant Edwards wrote: >>>> On 2012-11-29, Tim Wescott <tim@seemywebsite.com> wrote: >> >>>> ... Trying to impliment >>>> any sort of communications protocol with that was fun. >> >> Using left/right shifts and AND and OR operations work just fine. >> Works OK with different CHAR_BIT and different endianness platforms. >> Do not try to use structs etc. >> >>> Thanks for that information. Claims have frequently been made on >>> comp.lang.c that, while the C standard allows CHAR_BIT != 8, the >>> existence of such implementations is a myth. I'm glad to have a >>> specific counter example to cite. >> >> IMHO CHAR_BIT = 21 is the correct way to handle the Unicode range. >> >> On the Unicode list, I even suggested packing three 21 characters into >> a single 64 bit data word as UTF-64 :-) > > I like it -- but it breaks as soon as they add U+200000 or higherNot really. You can use the spare bit to indicate a different packing.> , and I'm not aware of any guarantee that they won't. > > I've thought of UTF-24, encoding each character in 3 octets; that's > good for up to 16,777,216 distinct code points.I hope that, when the galactic discovery is underway that would make this amount of code points necessary, software engineering will have evolved beyond the point of humans worrying about bit widths and encodings. -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
Reply by ●December 11, 20122012-12-11
On 12/11/2012 03:33 AM, Christopher Head wrote:> On Mon, 10 Dec 2012 13:21:35 +0100 > Rene <a@b.c> wrote: > >> In C there are certain types, e.g. "int", but there is no law that >> says how an int is stored in memory. It may be 16 bits or 32 or >> whatever (the compiler chooses this). There are however also types >> that specify exactly how wide they are, these are in the header file >> inttypes.h. Then you can choose things like uint16_t or int32_t. >> Especially in embedded systems these are very handy but to be honest, >> I use them in every C program I write nowadays. > > Agreed those are wonderful types for situations where they make sense, > but they are actually in stdint.h, not inttypes.h. inttypes.h contains > various related goop like the PRI/SCN macros and other bits and pieces. > > ChrisHm, I had noticed myself that in a certain source file in which these types were used I had not included inttypes.h and it still worked. But I thought that probably it was included through some other included file. Obviously my assumption was wrong, my apologies for spreading this incorrect information and thanks to Chris for correcting it. Yours sincerely, Rene
