I think the Elliott 803 was 39 bits... but I also suspect it was pre-dating any concept of attaching a filename to a piece of data or program by at least a decade (not to say that there wasn't some form of meaningful label in there, though).
Can I pass? ;) No, on a serious note it's certainly not perfect - but it's better than nothing in some circumstances (the main issue of course being the amount of space 'wasted' by the semantic information - which is half the reason I loathe things like HTML-based emails!) For the purpose of my comment I was making the assumption that it was at least in ASCII or some flavour of double-byte charset - albeit not necessarily English for the human-readable part.
of course, we're all running binary after all, which is pretty alien under the hood.
:) A 50,000 squid computer could cost as much as a sizeable village.
The trouble with 2&3 is that over time it often ceases to be worth picking it apart, or finding compatible hardware to install the OS to install the app to read the data. One of the many beauties of plain text is that's just never an issue.
Piece of cake - it's part of the design of XML to make such things easy.
My day job consists largely of sight-reading pages of garbage and telling that the consuitants have encoded their Bulgarian as ISO-8859-3 when they meant to use ISO-8859-5, then not being allowed to brand them with a red-hot clueiron that says UTF-8.
I keep a clueiron under my desk, just in case. Along with my rubber stamps for "UTF-8" and "It's on the wiki"
Ours featured a big ol' knife switch and a pair of 30A time-delay fuses in a cabinet full* of dead ladybirds - I'd have a heck of a job doing that in ASCII ;)
until I opened it and the whole bloody lot cascaded into my face, anyway.
Certainly easy enough to code (assuming that something doesn't mangle it...)
Why on earth do you need an OS or the orginal app to read the data? All you need is suitable hardware to extract the bit stream from the storeage media. In the case of magnetic media that could be a bottle of "edivu" and a microscope, with a CD/DVD/Blu_Ray just a microscope.
Once you have the bit pattern you need number 3 to decode it, the simpler the format specification the easier that is.
er you are forgetting that machines don't know anything about "plain text" they just handle 0's and 1's in blocks called bytes which can also be joined into words. The number of bits in a byte and/or the number of bytes in a word can vary and ASCII is just *a* way of encoding a given character to a bit pattern, using 7 bits per character.
What would have happened if we got a time machine going, and teleported an angle grinder and everlasting atomic power pack back to the stone age. What fantastic wall engravings we'd be looking at!
"I've been over to Stonehenge and =C6lfric the mason says he's got a nice chunk of Ordovician dolerite you can turn into fireplaces, going cheap but you've to cut it up yourself. The whole site's going to be cleared for some executive mud-huts apparently so see if there's anything else you can scrounge while you're up there"
That's yet to come. There's a chap down the road uses an angle grinder and diamond discs to carve Easter Island-style heads and faces from granite beach boulders. Wherever they end up after the next Ice Age, they'll probably start a new religion.
You have me curious there. I think only a couple of those have direct translations to ASCII, do they not? (unless usenet or my newsreader's munging something in the transfer/display - I get the sequence: D2 EA EB F3 40 EB F3 40 0A)
... and if it's a machine-interpreted sequence rather than something meaningful to a human, what's it from/do?
I think NT's point (and mine in part) is access to "suitable hardware". Getting the data onto a modern system is often easy in comparison to interpreting it - and sometimes the least painful* way is to find an example of the original hardware/software combination and use it to extract the data onto a modern platform in such a way that it is easy to interpret.
expense and/or time.
Agreed. I think NT was trying to say that it's a lot easier for people (after the fact) to understand data that's been stored in a primarily human-readable format than it is for data stored in a primarily machine-readable one.
e.g. (to take email as an example) I'd feel a lot happier if the world used mbox format for message storage rather than some undocumented and encoded Microsoft (or Sun, or whoever) format that made sense to a specific email app but nothing else. A few decades down the line, I bet it's going to be a lot easier to access the data in the former than the latter, because it's essentially "plain text" and a human could look at the file contents, figure out how it's put together, and extract individual messages relatively easily.
Of course to get at the data at that level, you may need to access individual files. To access individual files, you may need to understand the filesystem. To understand the filesystem, you may need to understand how the filesystem is stored on the media as a raw sequence of bits. (And even then you may need to know how the raw sequence of bits translates to variations on the media - e.g. flux transitions for floppies and hard discs). Picking all that apart when presented with some kind of 'alien' media can be challenging (albeit fun) - which is why it's sometimes far easier just to access things using the original equipment!
That's OK, I think I have enough spares and service information to keep a BBC micro + drive going for the rest of my lifetime, although I should really get the JPEG specs off the fileserver and onto a couple of floppies[1] just to be on the safe side.
[1] actually, I should burn one copy into ROM just so I'm not relying on a single type of media.
;-)
Serious note: JPEG might be a crappy format for long-term data storage; I'm not sure[2] how well it recovers from partial errors. Something more 'raw' is probably better for longevity as at least it's possible to skip over partial errors and get something meaningful back out. (This is something I've not mentioned yet about reading old data - most of the time it's horribly incomplete, and some formats are better at letting you get at least *something* back than others)
[2] I wrote a decoder once, so probably knew, but that was over a decade ago now and that part of my head's been re-used for something else by now :)
'course I could post all my JPEGs as ASCII dumps to uk.d-i-y and just let Google's archive store them for all eternity, but that relies on Google's archive not being shit. ;)
Only if its printed on paper by a computer that understands it, is it human readable.
Thats not about ascii versus DXF, that's about proprietary versus open standard.
DXF, ASCII, JPEG - these are essentially open standards, de facto if not de jure.
OTOH most linux computers today, given a floppy drive can read any floppy disk that the drive will read. Whether its ascii, DXF or JPEG merely determinejs what softwaree you use to print it out or put in onscreen.
Its NT's strange notion that a text file is somehow different from a DXF file that bothers me.
Both need programs to read them and hardware to retrieve them.
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.