On Tue, 20 Oct 2009 03:46:49 +0100, The Natural Philosopher wrote:
Be careful not to photograph it.

Who knows whether next years Windows 7.3 will be able to read a JPEG?

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 ****.

cheers

Jules

Jules wrote:
On Tue, 20 Oct 2009 08:51:37 +0100, Dave Liquorice wrote:


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.


But ASCII is not a promarily human readable form!

That's the whole point.

Only if its printed on paper by a computer that understands it, is it
human readable.

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.


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.


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!

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.

There is essentially no difference.


cheers

Jules

On Tue, 20 Oct 2009 08:01:41 -0500, Jules wrote:

à êëó@ëó@

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)

It's been mangled, not surprised. There should have been 14, 8 bit
sequences representing the letters "This is EBCDIC" when coded as
EBCDIC not ASCII. The 0x40 for space has survived but I can't (be
bothered to) figure out what has happened to the others.

--
Cheers
Dave.

On Tue, 20 Oct 2009 14:31:16 +0100, The Natural Philosopher wrote:
Jules wrote:
On Tue, 20 Oct 2009 08:51:37 +0100, Dave Liquorice wrote:
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.

But ASCII is not a promarily human readable form!
That's the whole point.

I need to mull that over (more coffee first) - I think everyone's talking
apples and oranges here... :-)

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.

Yes, I think we're having two discussions here - one about published
standards v proprietary, and one about the ease of interpreting the data
when no kind of formal specification (open or otherwise) is available.

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.

Yes and no. A huge amount of PCs won't read FM-encoded data from a floppy
(which was the norm for a considerable period of time) and will only
handle MFM (far fewer still will *write* FM, but that's less of an issue
for most folk). The modern controllers just don't handle it. Similarly
there are issues around sector size (128-byte sectors seem to trip up a
lot of modern controllers), hard-sectored drives, drives which can vary
spindle speed etc.

I'd agree that if it were written on an old IBM-compatible PC though then
it'll generally be readable on a modern IBM-compatible PC via a
combination of software and the right flavour of drive.

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. There is essentially no difference.

Yes, AIUI DXF was designed with a certain amount of "human parsability" in
mind, so for the purposes of doing the job that DXF was designed for
there wouldn't really be any longevity benefit in using plain text
instead; if there was no software around that understood DXF natively,
you could still open the file in any old text editor, read the contents
via eyeballs, and work out what the contents 'mean'.

From a longevity point of view, the best formats are definitely the ones
where a human stands a chance of being able to make sense of the contents
by looking at the file 'raw' and make few* assumptions about how the
information is encoded.

* I was going to say 'no', but as has been discussed there is still the
need to know that the contents are ASCII, or EBCDIC, or some double-byte
unicode thing.

cheers

Jules

Jules wrote:
On Tue, 20 Oct 2009 14:31:16 +0100, The Natural Philosopher wrote:
Jules wrote:
On Tue, 20 Oct 2009 08:51:37 +0100, Dave Liquorice wrote:
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.
But ASCII is not a promarily human readable form!
That's the whole point.

I need to mull that over (more coffee first) - I think everyone's talking
apples and oranges here... :-)

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.

Yes, I think we're having two discussions here - one about published
standards v proprietary, and one about the ease of interpreting the data
when no kind of formal specification (open or otherwise) is available.

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.

Yes and no. A huge amount of PCs won't read FM-encoded data from a floppy
(which was the norm for a considerable period of time) and will only
handle MFM (far fewer still will *write* FM, but that's less of an issue
for most folk). The modern controllers just don't handle it. Similarly
there are issues around sector size (128-byte sectors seem to trip up a
lot of modern controllers), hard-sectored drives, drives which can vary
spindle speed etc.

I'd agree that if it were written on an old IBM-compatible PC though then
it'll generally be readable on a modern IBM-compatible PC via a
combination of software and the right flavour of drive.

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. There is essentially no difference.

Yes, AIUI DXF was designed with a certain amount of "human parsability" in
mind, so for the purposes of doing the job that DXF was designed for
there wouldn't really be any longevity benefit in using plain text
instead; if there was no software around that understood DXF natively,
you could still open the file in any old text editor, read the contents
via eyeballs, and work out what the contents 'mean'.


same goes for bloody postcript.

OR PLT format.


From a longevity point of view, the best formats are definitely the ones
where a human stands a chance of being able to make sense of the contents
by looking at the file 'raw' and make few* assumptions about how the
information is encoded.

* I was going to say 'no', but as has been discussed there is still the
need to know that the contents are ASCII, or EBCDIC, or some double-byte
unicode thing.

cheers

Jules

On Tue, 20 Oct 2009 16:11:13 +0100, Dave Liquorice wrote:
It's been mangled, not surprised. There should have been 14, 8 bit
sequences representing the letters "This is EBCDIC" when coded as
EBCDIC not ASCII. The 0x40 for space has survived but I can't (be
bothered to) figure out what has happened to the others.

Heh, OK. I was looking at it on the wrong side of 7am and not sure if I
were missing something obvious :-)

On Oct 19, 11:49*pm, Jules
wrote:
On Mon, 19 Oct 2009 15:21:13 -0700, NT wrote:
I'd be very surprised if garage wiring were too complex for ascii art.
But who knows, people have isntalled stranger things.

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.

lol. maybe draw them as @


NT

several contributors wrote:

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.

Good lord. You really dont know much about computers, do you?

What OS do you need to read your blessed ASCII then?

_Any_ OS, thats the point. ASCII is the one thing that pretty much
every computer today understands.



Why on earth do you need an OS or the orginal app to read the data?
- snip -

Take an example: .mmm format used in win3.1. Do you think that will be
supported in 50 years time? I expect writers will have long since quit
bothering to support it, just as today's OSes have quit bothering to
support formats from early computers. By then the only OSes/apps that
will be able to handle .mmm will only be compatible with what will
then be extremely historic hardware, such as 1990s PCs. Add the fact
that the skill set to set up win3.1/98 will have long gone, and it'll
be a mountain to climb just to view your data.

I've already been thru this cycle with a format I used in the 90s,
which nothing else supported in 2000, and the original hardware
finally died. Data recovery was successful but time consuming.


One of the many beauties of plain text is that's just never an issue.

snip

Any machine can display ascii, its a semi-worldwide massively cross
platform standard. ASCII is a good option for archival for this
reason.



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.

sometimes today its the only _practical_ way. Now fast forward 50
years


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.

That too. I can smugly count on my huge ASCII library being readable
for life. People that save in messier formats can't. Computers will
probably change out of recognition over the next 50 years.



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!


Indeed. I suspect that may have ceased to be a problem though, in that
I/we can now store all our data on a HDD or two (plus backups), and
move it from one machine to the next over a lifetime. Thus the
obsolete media issue should no longer arise. (that dreaded word
'should')


OTOH most linux computers today, given a floppy drive can read any
floppy disk that the drive will read.

Guess I'm stumped with those 8" 400k discs then.


Whether its ascii, DXF or JPEG
merely determinejs what softwaree you use to print it out or put in
onscreen.

in several cases none exists, and that just over a 20 year period.
Imagine another 50 years.



Its NT's strange notion that a text file is somehow different from a DXF
file that bothers me.

ASCII is the one standard that virtually every computer reads. Add to
that that plain text will continue to be needed indefinitely, and
there's no reason to move to a new standard, and you've got a very
long term format.


But ASCII is not a promarily human readable form!
That's the whole point.

Its not at all.


Yes, I think we're having two discussions here - one about published
standards v proprietary, and one about the ease of interpreting the data
when no kind of formal specification (open or otherwise) is available.

That might be true for professional archivists, but for most of us
we're never going to write software in 30 years time to enable display
of the then historic .jpg format. Either software is available to use
on existing machines of the time or it isn't. When software that will
run on computers of the time is not available, the data is usually as
good as lost.


NT