3 ms·

Files are data. Data should be eternal. You should be able to convert a presentation you make today 30 years from now to a newer format. Making software not-bac

by Touche 13y ago

Files are data. Data should be eternal. You should be able to convert a presentation you make today 30 years from now to a newer format. Making software not-backwards compatible is fine and normal but if files expire in a few years Apple is saying that the things you do on their computers are disposable.

345723 13y ago
It is eternal, as long as you have the system and the software that it was created with. This can be said for all sorts of things, from the Commodore 64 to Keynote. If you want to be able to access the data on an NES cartridge you are going to need special hardware and software. Yes the ROMS are available now online, but that's only because someone with the hardware and software made it available to others. This is the nature of proprietary formats.
- pif 13y ago
  > This is the nature of proprietary formats. Indeed. When you choose to save your work in a not-public format, you are decidîng not to care about its lifespan: complaining later is just useless, unfortunately.
teej 13y ago
The world isn't so black and white. Document serialization is a rocky landscape that is rife with compromise. You have to balance document open time, document save time, file size, backwards compatibility, forwards compatibility, recovery modes, interoperability, size in memory, parsing time, time to save to disk, proprietary embedded file formats, metadata support, and more. And those are just the development considerations. You also have to think about upgrade cycle, time-to-market, third party integrations, and what will help you win marketshare and sell copies. Software is hard. I think it's pragmatic for software vendors to have a strong, transparent philosophy about the trade-offs so that consumers can make the right choice. As the grandparent points out, Microsoft values backwards compatibility. If you value that too, buy Microsoft.
- Touche 13y ago
  > Software is hard. I think it's pragmatic for software vendors to have a strong, transparent philosophy about the trade-offs so that consumers can make the right choice. I'm not talking about software, I'm talking about information. Information shouldn't have an expiration date. Here's a webpage from 1994: http://www.lysator.liu.se/pinball/expo/ http://www.lysator.liu.se/pinball/expo/ Surely you wouldn't prefer a world where the blog you wrote 4 years ago can't be viewed on a new computer?
  - pgeorgi 13y ago
    That was one of the main reasons IE6 survived for so long. So yes, under some circumstances, old formats are deprecated - even on the web. The world is better for it, but it still sucks for those who need that old stuff and are unable to move it forward.
  - banachtarski 13y ago
    That's just not true. Data is software in it's own sense. For example, if you were to compare different binary serialization formats, you would find that you can do better than Google's protocol buffers but only because protobuffs value backwards compatibility. Sure you could write software to migrate formats each step of the way but this is expensive and perhaps the company wanted to focus on the next thing.
  - Timmmmbob 13y ago
    Yeah but "information" generally requires software to view it. The only reason that web page still works in modern browsers is because they've gone to all the effort to account for quirks in ancient HTML. Apple clearly didn't think it was worth the effort in this case. Also worth pointing out it's much easier to display old formats than it is to make them editable.
    - upofadown 13y ago
      I don't think ancient HTML was complicated enough to have quirks.
mturmon 13y ago
"Data should be eternal." This is not a useful statement. If you convert the "should" to a "shall", and try to design a system around that requirement alone, it would prove very hard. Even designing a clock around that requirement is very hard (http://longnow.org/clock/ http://longnow.org/clock/). If you back off from the "shall", then you are in the standard world of engineering tradeoffs, which is where you started. What features do you want to give up for "eternal"?
- niels_olson 13y ago
  Perhaps the ideas should be eternal, but the byzantine markup system? This is a major reason why the older I get, the more I prefer plain text wherever I can get it and open standards when I can't. Fancy rendering is just a variation on the drug dealer's bargain "the first hit is always free".
- wpietri 13y ago
  Designing a clock around that is very hard because the clock is a physical machine that needs to physically last. Software is easier, because it's, well, soft. I'm the developer who build their related Long Bets project (http://longbets.org/ http://longbets.org/) and I think "data should be eternal" is a perfectly reasonable standard. That was certainly my goal in designing Long Bets. If you start with that as a principle, I don't think it imposes particularly large engineering burdens, especially if you accept some potential degradation as a consequence. For example here, instead of a "fuck you" dialog box, they could have imported the core of a presentation: text and images positioned on a sequence of frames. An analogy is HTML. It's basically zero engineering effort to just suck the text out of a page. It is only modestly more effort to pull out some of the semantic markup, like headings, lists, and emphasis. And that's the part that really hurts to lose, not which precise shade of blue you used in your footer text.
keithpeter 13y ago
My approach: Export every presentation as PDF. I'm guessing LibreOffice will be around for a bit (files from 2003 and later working ok) and the PDFs provide a second line of access, but, I accept, they are not convenient for editing.
- chris_wot 13y ago
  Use ODF.
  - keithpeter 13y ago
    I do. LibreOffice saves in that format by default.
reeses 13y ago
Assuming arguendo that data = information, a printout will suffice. Your conversion will be manual, but you should not expect a complicated, performant, object serialization format to last through several generations of computer architecture.
jmcqk6 13y ago
All of this reminds me of _why http://www.scribd.com/doc/136918361/Collected-PDFs-of-why http://www.scribd.com/doc/136918361/Collected-PDFs-of-why

by Touche 13y ago

345723 13y ago

It is eternal, as long as you have the system and the software that it was created with. This can be said for all sorts of things, from the Commodore 64 to Keynote. If you want to be able to access the data on an NES cartridge you are going to need special hardware and software. Yes the ROMS are available now online, but that's only because someone with the hardware and software made it available to others. This is the nature of proprietary formats.

pif 13y ago
> This is the nature of proprietary formats. Indeed. When you choose to save your work in a not-public format, you are decidîng not to care about its lifespan: complaining later is just useless, unfortunately.

teej 13y ago

The world isn't so black and white. Document serialization is a rocky landscape that is rife with compromise. You have to balance document open time, document save time, file size, backwards compatibility, forwards compatibility, recovery modes, interoperability, size in memory, parsing time, time to save to disk, proprietary embedded file formats, metadata support, and more. And those are just the development considerations. You also have to think about upgrade cycle, time-to-market, third party integrations, and what will help you win marketshare and sell copies. Software is hard. I think it's pragmatic for software vendors to have a strong, transparent philosophy about the trade-offs so that consumers can make the right choice. As the grandparent points out, Microsoft values backwards compatibility. If you value that too, buy Microsoft.

Touche 13y ago
> Software is hard. I think it's pragmatic for software vendors to have a strong, transparent philosophy about the trade-offs so that consumers can make the right choice. I'm not talking about software, I'm talking about information. Information shouldn't have an expiration date. Here's a webpage from 1994: http://www.lysator.liu.se/pinball/expo/ http://www.lysator.liu.se/pinball/expo/ Surely you wouldn't prefer a world where the blog you wrote 4 years ago can't be viewed on a new computer?
- pgeorgi 13y ago
  That was one of the main reasons IE6 survived for so long. So yes, under some circumstances, old formats are deprecated - even on the web. The world is better for it, but it still sucks for those who need that old stuff and are unable to move it forward.
- banachtarski 13y ago
  That's just not true. Data is software in it's own sense. For example, if you were to compare different binary serialization formats, you would find that you can do better than Google's protocol buffers but only because protobuffs value backwards compatibility. Sure you could write software to migrate formats each step of the way but this is expensive and perhaps the company wanted to focus on the next thing.
- Timmmmbob 13y ago
  Yeah but "information" generally requires software to view it. The only reason that web page still works in modern browsers is because they've gone to all the effort to account for quirks in ancient HTML. Apple clearly didn't think it was worth the effort in this case. Also worth pointing out it's much easier to display old formats than it is to make them editable.
  - upofadown 13y ago
    I don't think ancient HTML was complicated enough to have quirks.

mturmon 13y ago

"Data should be eternal." This is not a useful statement. If you convert the "should" to a "shall", and try to design a system around that requirement alone, it would prove very hard. Even designing a clock around that requirement is very hard (http://longnow.org/clock/ http://longnow.org/clock/). If you back off from the "shall", then you are in the standard world of engineering tradeoffs, which is where you started. What features do you want to give up for "eternal"?

niels_olson 13y ago
Perhaps the ideas should be eternal, but the byzantine markup system? This is a major reason why the older I get, the more I prefer plain text wherever I can get it and open standards when I can't. Fancy rendering is just a variation on the drug dealer's bargain "the first hit is always free".
wpietri 13y ago
Designing a clock around that is very hard because the clock is a physical machine that needs to physically last. Software is easier, because it's, well, soft. I'm the developer who build their related Long Bets project (http://longbets.org/ http://longbets.org/) and I think "data should be eternal" is a perfectly reasonable standard. That was certainly my goal in designing Long Bets. If you start with that as a principle, I don't think it imposes particularly large engineering burdens, especially if you accept some potential degradation as a consequence. For example here, instead of a "fuck you" dialog box, they could have imported the core of a presentation: text and images positioned on a sequence of frames. An analogy is HTML. It's basically zero engineering effort to just suck the text out of a page. It is only modestly more effort to pull out some of the semantic markup, like headings, lists, and emphasis. And that's the part that really hurts to lose, not which precise shade of blue you used in your footer text.

keithpeter 13y ago

My approach: Export every presentation as PDF. I'm guessing LibreOffice will be around for a bit (files from 2003 and later working ok) and the PDFs provide a second line of access, but, I accept, they are not convenient for editing.

chris_wot 13y ago
Use ODF.
- keithpeter 13y ago
  I do. LibreOffice saves in that format by default.

reeses 13y ago

Assuming arguendo that data = information, a printout will suffice. Your conversion will be manual, but you should not expect a complicated, performant, object serialization format to last through several generations of computer architecture.

jmcqk6 13y ago

All of this reminds me of _why http://www.scribd.com/doc/136918361/Collected-PDFs-of-why http://www.scribd.com/doc/136918361/Collected-PDFs-of-why