4 ms·

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 operati

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

by AlanYx 5y ago

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.