So I figured out how to make a ram disk on haiku lately, i’ve been just using speed up the saving process. If i’m working on a the document or creating a photo and then when i’m done, I’d move it over to my hard drive what are other interesting things I could possibly use? A ram disk for besides storing temporary files
It is the quickest way to copy a file from storage medium A to storage medium B, if you only have one physical attachment point for that storage type. That’s how programs like XCopy on the Amiga allowed people to clone floppies with only one drive.
Honestly, ram disks are most useful on old systems. For example I have the browser cache location set to RAM: on my Amiga 1200 and it does give a nice boost while browsing.
1 Like
thats pretty cool I wish i had one I’m still playing around with my commodore 64 well right now its sitting in my closet because i dont have space to set it up anywhere right now
Fwiw files taking longer to copy to a storage medium on Haiku is kind of deliberate, we don’t want to fill the buffer like linux completely and then return on the write operation, while in reality the OS is still hard at work copying your file for severeall minutes.
On linux for example the operation seems to finish “directly”, but it has not really finished, because the write never arrived at the filesystem.
I assume you mean this is the case of “Make WonderBrush save faster”; Do you have some examples of this?
I think showing the User when the save is actually completely is a good design decision, so that users can trust “The Save is complete, it is actually on the disk”
I guess your problem here is a bit using alt-s to save and then having to wait for it to complete before beeing able to use the application again? Perhaps if that is the case it may be possible to have an Indicator that a save is in progress, but also allow you to continue using your application at the same time.
This is debatable.
BeOS used to do this for floppy disks: copy the entire disk to RAM, so you could work on the files in there very quickly. It would then write everything back to the floppy when you unmount it.
On small and very slow storage media, this approach makes a lot of sense, and makes the experience way better.
You just don’t want such things to fill up your entire RAM and bring your system to a halt as it struggles to find space for other things. And you don’t want to keep things in memory for too long, in case there’s a power cut you don’t want too much data to be lost when it appears to be “saved” from the application point of view.
The problem is more one of user experience here: having predictable behavior, so that when you click “save” on an app, the file is really saved when the operation completes. But there are other cases where the asynchronous write also makes sense, because, for example, the file is transient and will be immediately read back and reprocessed. In which case, if you can avoid it hitting the disk at all, that’s actually a great performance improvement.
So it’s all about letting apps access either of these behaviors through the API, and app developper be conscious of the difference and how to use the APIs correctly.
I mean, I would like to show this to you, but I do not have a capture card or a working laptop in my possession Currently though to be honest with you, it’s not that much of a speed boost i do weird things that are kind of deprecated, because I be like that i also like to automate things using crontab and shell scripts that don’t really need to be because i’m kind of a weird quirky guy like that
Well, if this was significant for some app, that you need to wait a long time before you can continue working on what you saved, I would have investigatged an asynchronous save mode where the app will tell you when it is finished but let you continue your work.