6 ms·

I don't want to bash amiga, actually I really envy the history and capabilities of that system. Nevertheless, posts like this are almost always seen through a b

I don't want to bash amiga, actually I really envy the history and capabilities of that system. Nevertheless, posts like this are almost always seen through a bit of rose tinted glasses. The part about DataTypes: "Datatypes describe a file format and tell the OS how to handle it. Any datatype-aware program can use any file format as long as a relevant datatype is present." Doesn't looks that different from how codecs are used in modern OS's. AFAIK, as soon as ffmpeg or gstreamer learns new formats or how to use hardware codecs, so does every program using them without the need of even recompiling. Of course, doing that 30 years ago is another thing. And: "RAD: is a fixed-size bootable RAM disk that survives soft reboots. Equivalents exist for most modern Operating Systems. They’re worth trying out. You don’t really know how useful they are till you lose them." Maybe I can change my mind if I use them, but I really don't feel the need. On my notebook, I simply close the lid and when I open it, it is mostly in the same state I left; some system I used are stable enough to have months of uptime; using /tmp/ seems enough for me. I once had I power failure and recovering whatever was on /tmp/required booting from a keychain but it was easy to do and a very rare occurrence. The "RAD:" may be interesting on not specially stable, non high uptime, /tmp/-lacking systems but I can't see how they can be relevant on modern OS's.

vidarh 5y ago
There is a fundamental difference in that you can drop in a new datatype without any program like ffmpeg or gstreamer having to learn new formats. More importantly, how many applications actually use these as their primary means of accessing file types? Chrome doesn't learn a new image type if I drop in a file. LibreOffice doesn't. Certainly not from the same one. Gimp doesn't. There's no reason why all of those should not be able to load a new image type without updating the applications themselves, just by dropping in a datatype/codec. The concept isn't anything magical - or new -, but it's still largely forgotten and ignored outside of small islands of use. We have all kinds of little API's to do this for specific types of files, like e.g. ImageMagick's "convert" for images, ffmpeg for video etc. as you mention, but what we lack is a unified API, the ability to drop plugins in for new file types, and for applications to actually unify around using a specific standard. Heck, we even have a workaround to avoid needing application support: A FUSE filesystem to trigger conversion to suitable target filetypes. This is the same issue with a lot of the things we're missing from AmigaOS. They're not hard to do. E.g. "assigns" are conceptually largely a OS-provided way of creating PATH's for everything you'd like, for example - it can also easily be provided via a FUSE filesystem. Dbus "almost" gets us to what AREXX provided, but is just not supported as widely or as simple for regular users to get started with. What was special with the Amiga in that respect was that these things were embraced fully across the board, and integrated into the culture surrounding the Amiga.
- nitrogen 5y ago
  unified API, the ability to drop plugins in for new file types, and for applications to actually unify around using a specific standard. There have been attempts, such as OLE and ActiveX on Windows, or KParts in KDE 2 (and dcop from Qt 2) (or was it 3?), or Intents on Android, or WebIntents, but yeah, none of them became universal, and many of them had security problems.
  - vidarh 5y ago
    I think all of these illustrate part of the challenge: They're all tremendously complex compared to the basic functionality of datatypes. That is part of the problem with many of the attempts to do the same again. A lot of the constraints AmigaOS had to deal with became strengths in that these APIs had to be simple because they had to work on machines with memory measured in kilobytes or megabytes. Of course it's also more complex to do on a system where you expect security (no memory protection on Amiga's made that rather moot), but I think a targeted attempt to do just the minimum datatypes does - or even less, would still be valuable. E.g. many of the security issues are related to embedding a widget, but just providing a unified mechanism for loading and saving which could easily be sandboxed and interfaced to via a dumb pipe (still security issues in validating what's passed over that of course).
- AnIdiotOnTheNet 5y ago
  Indeed. Systems like the Amiga show us what we have lost from the world of personal computing. Things we could do in the 80s and 90s have disappeared and been replaced by hodgepodges of barely interacting components. It is, frankly, disgraceful and we should be ashamed as an industry that we've regressed so far.
  - pjmlp 5y ago
    The idea lives on as COM, XPC and DBUS. The problem is that many kind of ignore using them.
- tialaramex 5y ago
  > There is a fundamental difference in that you can drop in a new datatype without any program like ffmpeg or gstreamer having to learn new formats. It's not an interesting or useful difference. The thing Datatypes lets you do is pointlessly spell things differently. Once you spot that you ask yourself, "Why am I doing this?" and the answer is only that you need to interoperate with other people who hadn't settled on one way to spell things so the best route forward is consolidation. Most applications gain nothing from having, say, yet another mediocre bitmap graphics format. You just made your system more complicated without any improvements whatsoever. Clearly we should agree to just stop doing this. And we did. > Gimp doesn't Actually Gimp does. Gimp's file format handling is all via plug-ins. As with ImageMagick in this context maybe you actually needed to rescue crappy 1980s files you found on a floppy disk or whatever. But this helps us see what's going on - because Gimp's image file format handling is only for import and export of necessity Gimp itself is richer than any of these formats. Its native XCF format reflects a superset of the features you can care about. But anything Gimp's native images can't do, you can't "add" using these plug-ins. The SVG plug-in for example can't magically make Gimp understand vector images, it just has to render the vector image as pixels because that's all Gimp understands. So in the end any innovation is rendered pointless by this abstraction, the only way for an innovative idea to flourish is to sidestep a "datatypes"-like abstraction altogether. > actually unify around using a specific standard. You've almost understood. Instead of adding a layer of abstraction, and then unifying around this unnecessary layer, we instead chose to just use a specific standard format. The problem you're intent on solving vanished. Didn't you ever wonder why Datatypes seemed so brilliant for image files, and kinda sorta OK for music, and then basically of no value at all for most other file formats? It's because there really were sixty different crappy pixmap formats that were completely interchangeable and half a dozen PCM audio formats likewise. But that's not what happened in other domains, because it's pointless.
icedchai 5y ago
It was a different world then. RAD: was pretty amazing in 1989, when I added another couple megs of RAM to my Amiga 500. It took 30+ seconds to boot off of floppy, and a few seconds to boot off RAM disk.
AlanYx 5y ago
The appeal of RAD: makes more intuitive sense if you think of it as a kind of clipboard that you access via filesystem operations, rather than clipboard operations (though the Amiga had a clipboard too). It did make more sense in an era when disks were slow and a huge proportion of Amigas had no hard disks. Thinking about it now, it might be interesting if someone developed a FUSE interface to the system clipboard on modern OSes.
- vidarh 5y ago
  The actual Amiga clipboard is actually quite interesting. When an application posts a clip to the clipboard device, it resides in that applications memory until the clipboard device requests it "post" that data somewhere. This makes sense on a low memory system - if an application can ensure the "clipped" data isn't modified, it can just keep it as is without making a copy until it's asked for it. When "posted" to the clipboard (either in response to pasting, or because the application itself wants to, e.g. because it's being closed), the clip is written as an IFF file to the assign "CLIPS:". Like any other assign, CLIPS: can be reassigned anywhere, including RAD: or RAM: or disk. Unless I misremember badly, CLIPS: defaults to a directory in RAM: possibly indirectly via T: Since AmigaOS will request volumes that aren't currently in a drive, you could even reassign the clipboard to a floppy with a given label, and the OS would pop up a requester asking for it to be inserted as needed.
  - zozbot234 5y ago
    > Since AmigaOS will request volumes that aren't currently in a drive That's a great feature and it should be forward-ported to modern OS's.
    - vidarh 5y ago
      It was, but it's a feature that's much less important today with less tight integration of removable media. Though it meant e.g. software on multiple volumes could just try to access a file on one of the other volumes and let the OS deal with prompting for it, even that is a quite rare operation today. You could do it with FUSE relatively easily: Make a FUSE filesystem that acts as an overlay, so, say when you access /<path to the fuse system>/foo it looks for /<path to mount>/foo and if it doesn't find it, pop up a window with "Please insert volume 'foo'" Frankly there are a lot of these things that would be quite straightforward to support on Linux that'd be "nice to have" but are not quite essential enough to motivate someone to do it.
fogihujy 5y ago
RAD isn't really relevant anymore, but it was very handy on a floppy-based system without a hard drive. Data types, on the other hand, were absolutely amazing. Sure, ffmpeg covers some of it, but datatype support was, and remain, a killer feature of AmigaOS. Want almost universal support for a new format, including support by legacy applications? Datatypes. Want to replace a common format's encoder with somerhing else? Datatypes. The other killer feature of AmigaOS applications was the AREXX support, which allowed advanced scripting far before it was available on other consumer platforms.
ithkuil 5y ago
Another thing RAD was useful for, namely there is a reason you rebooted more often an Amiga that you'd reboot your modern laptop: due to lack of memory protection / virtual memory (due to the lack of a HW MMU) when an application crashed it brought down the whole OS (the (in)famous guru meditation failures). After rebooting the content of the RAD was still there (unless overwritten by a buggy program)

vidarh 5y ago

There is a fundamental difference in that you can drop in a new datatype without any program like ffmpeg or gstreamer having to learn new formats. More importantly, how many applications actually use these as their primary means of accessing file types? Chrome doesn't learn a new image type if I drop in a file. LibreOffice doesn't. Certainly not from the same one. Gimp doesn't. There's no reason why all of those should not be able to load a new image type without updating the applications themselves, just by dropping in a datatype/codec. The concept isn't anything magical - or new -, but it's still largely forgotten and ignored outside of small islands of use. We have all kinds of little API's to do this for specific types of files, like e.g. ImageMagick's "convert" for images, ffmpeg for video etc. as you mention, but what we lack is a unified API, the ability to drop plugins in for new file types, and for applications to actually unify around using a specific standard. Heck, we even have a workaround to avoid needing application support: A FUSE filesystem to trigger conversion to suitable target filetypes. This is the same issue with a lot of the things we're missing from AmigaOS. They're not hard to do. E.g. "assigns" are conceptually largely a OS-provided way of creating PATH's for everything you'd like, for example - it can also easily be provided via a FUSE filesystem. Dbus "almost" gets us to what AREXX provided, but is just not supported as widely or as simple for regular users to get started with. What was special with the Amiga in that respect was that these things were embraced fully across the board, and integrated into the culture surrounding the Amiga.

nitrogen 5y ago
unified API, the ability to drop plugins in for new file types, and for applications to actually unify around using a specific standard. There have been attempts, such as OLE and ActiveX on Windows, or KParts in KDE 2 (and dcop from Qt 2) (or was it 3?), or Intents on Android, or WebIntents, but yeah, none of them became universal, and many of them had security problems.
- vidarh 5y ago
  I think all of these illustrate part of the challenge: They're all tremendously complex compared to the basic functionality of datatypes. That is part of the problem with many of the attempts to do the same again. A lot of the constraints AmigaOS had to deal with became strengths in that these APIs had to be simple because they had to work on machines with memory measured in kilobytes or megabytes. Of course it's also more complex to do on a system where you expect security (no memory protection on Amiga's made that rather moot), but I think a targeted attempt to do just the minimum datatypes does - or even less, would still be valuable. E.g. many of the security issues are related to embedding a widget, but just providing a unified mechanism for loading and saving which could easily be sandboxed and interfaced to via a dumb pipe (still security issues in validating what's passed over that of course).
AnIdiotOnTheNet 5y ago
Indeed. Systems like the Amiga show us what we have lost from the world of personal computing. Things we could do in the 80s and 90s have disappeared and been replaced by hodgepodges of barely interacting components. It is, frankly, disgraceful and we should be ashamed as an industry that we've regressed so far.
- pjmlp 5y ago
  The idea lives on as COM, XPC and DBUS. The problem is that many kind of ignore using them.
tialaramex 5y ago
> There is a fundamental difference in that you can drop in a new datatype without any program like ffmpeg or gstreamer having to learn new formats. It's not an interesting or useful difference. The thing Datatypes lets you do is pointlessly spell things differently. Once you spot that you ask yourself, "Why am I doing this?" and the answer is only that you need to interoperate with other people who hadn't settled on one way to spell things so the best route forward is consolidation. Most applications gain nothing from having, say, yet another mediocre bitmap graphics format. You just made your system more complicated without any improvements whatsoever. Clearly we should agree to just stop doing this. And we did. > Gimp doesn't Actually Gimp does. Gimp's file format handling is all via plug-ins. As with ImageMagick in this context maybe you actually needed to rescue crappy 1980s files you found on a floppy disk or whatever. But this helps us see what's going on - because Gimp's image file format handling is only for import and export of necessity Gimp itself is richer than any of these formats. Its native XCF format reflects a superset of the features you can care about. But anything Gimp's native images can't do, you can't "add" using these plug-ins. The SVG plug-in for example can't magically make Gimp understand vector images, it just has to render the vector image as pixels because that's all Gimp understands. So in the end any innovation is rendered pointless by this abstraction, the only way for an innovative idea to flourish is to sidestep a "datatypes"-like abstraction altogether. > actually unify around using a specific standard. You've almost understood. Instead of adding a layer of abstraction, and then unifying around this unnecessary layer, we instead chose to just use a specific standard format. The problem you're intent on solving vanished. Didn't you ever wonder why Datatypes seemed so brilliant for image files, and kinda sorta OK for music, and then basically of no value at all for most other file formats? It's because there really were sixty different crappy pixmap formats that were completely interchangeable and half a dozen PCM audio formats likewise. But that's not what happened in other domains, because it's pointless.

icedchai 5y ago

It was a different world then. RAD: was pretty amazing in 1989, when I added another couple megs of RAM to my Amiga 500. It took 30+ seconds to boot off of floppy, and a few seconds to boot off RAM disk.

AlanYx 5y ago

The appeal of RAD: makes more intuitive sense if you think of it as a kind of clipboard that you access via filesystem operations, rather than clipboard operations (though the Amiga had a clipboard too). It did make more sense in an era when disks were slow and a huge proportion of Amigas had no hard disks. Thinking about it now, it might be interesting if someone developed a FUSE interface to the system clipboard on modern OSes.

vidarh 5y ago
The actual Amiga clipboard is actually quite interesting. When an application posts a clip to the clipboard device, it resides in that applications memory until the clipboard device requests it "post" that data somewhere. This makes sense on a low memory system - if an application can ensure the "clipped" data isn't modified, it can just keep it as is without making a copy until it's asked for it. When "posted" to the clipboard (either in response to pasting, or because the application itself wants to, e.g. because it's being closed), the clip is written as an IFF file to the assign "CLIPS:". Like any other assign, CLIPS: can be reassigned anywhere, including RAD: or RAM: or disk. Unless I misremember badly, CLIPS: defaults to a directory in RAM: possibly indirectly via T: Since AmigaOS will request volumes that aren't currently in a drive, you could even reassign the clipboard to a floppy with a given label, and the OS would pop up a requester asking for it to be inserted as needed.
- zozbot234 5y ago
  > Since AmigaOS will request volumes that aren't currently in a drive That's a great feature and it should be forward-ported to modern OS's.
  - vidarh 5y ago
    It was, but it's a feature that's much less important today with less tight integration of removable media. Though it meant e.g. software on multiple volumes could just try to access a file on one of the other volumes and let the OS deal with prompting for it, even that is a quite rare operation today. You could do it with FUSE relatively easily: Make a FUSE filesystem that acts as an overlay, so, say when you access /<path to the fuse system>/foo it looks for /<path to mount>/foo and if it doesn't find it, pop up a window with "Please insert volume 'foo'" Frankly there are a lot of these things that would be quite straightforward to support on Linux that'd be "nice to have" but are not quite essential enough to motivate someone to do it.

fogihujy 5y ago

RAD isn't really relevant anymore, but it was very handy on a floppy-based system without a hard drive. Data types, on the other hand, were absolutely amazing. Sure, ffmpeg covers some of it, but datatype support was, and remain, a killer feature of AmigaOS. Want almost universal support for a new format, including support by legacy applications? Datatypes. Want to replace a common format's encoder with somerhing else? Datatypes. The other killer feature of AmigaOS applications was the AREXX support, which allowed advanced scripting far before it was available on other consumer platforms.

ithkuil 5y ago

Another thing RAD was useful for, namely there is a reason you rebooted more often an Amiga that you'd reboot your modern laptop: due to lack of memory protection / virtual memory (due to the lack of a HW MMU) when an application crashed it brought down the whole OS (the (in)famous guru meditation failures). After rebooting the content of the RAD was still there (unless overwritten by a buggy program)