A Slackware based netbook question. Which provides more bang for the buck as far as system performance - SSD or tmpfs?

I am still trying to get a system working on my Acer Aspire One 725 that is to my liking. The constraints are as follows:

• Better video performance than is available with any installed, lightweight distro that I have tried, including Slacko.
  
• Vivaldi (preferred) or Google Chrome are needed as browser for their MIDI capabilities.
  
• Storage capacity for my music scores which get synced to the cloud (which if for no other reason, probably rules out the persistent USB pen drive alternative).

At this time, I have Salix64 XFCE 14.2 installed, but I don't have a problem trying this with a full Slackware64 14.2 install, but system resources as well as storage space are at a premium.

I don't know much of anything about tmpfs, but I understand that persistent USB pen drive systems use something similar to this?

An SSD up to around 250 GB would be OK as far as storage space is concerned, but the price is potentially a concern.

I am putting so much effort into this netbook, because it was relatively cheap, has a relatively small form factor and is lightweight, which is important to me when carrying my gear on the road, or using it in my rehearsal room.

No filesystem can outperform tmpfs. End of discussion.

Whether you understand the nuances of what you are asking is a different matter.

Thanks for your reply. Can / should the entire /root be configured to boot as tmpfs in the /etc/fstab? Are there specific Slackware related issues in trying this?

I think you should stop here and read a bit about what a tmpfs actually is.
When you run a Live OS, the files are loaded from the storage (mostly a USB stick) but any changes you make are kept in RAM, in a tmpfs (because that is what it is, a RAM based filesystem which does not touch your harddisk). Upon reboot, your changes to the Live OS are gone because they only lived in your RAM. A persistent Live OS still writes it changes back to the USB storage!

Now, you want to install Slackware on a SSD. That in itself will make your installation a lot faster and more responsive than with a regular harddisk with spinning platters. What some people do to speed up the daily operations is to put /tmp on a RAM disk (tmpfs). Compilations use /tmp for intermediate results and by writing all that to RAM your compilations will be a lot faster.
But there's really no sense in putting more than /tmp in RAM. What you are thinking of, to put all of the root filesystem onto tmpfs, how did you think you were going to achieve that? It would take an hour to just copy / to RAM and then re-mount the RAM-based copy. Let alone that you would have to re-write several Slackware boot scripts to do it.

1 members found this post helpful.

Not sure what you want to achieve with this, but I'll share some of my thoughts and opinions on tmpfs.

Root should ideally be stored somewhere, like a CD or HDD, there's no point having it in RAM because there is generally no dynamic data being written in /
In tmpfs you may want to store data which is being written and re-written all the time, so more or less just /tmp and ~/.cache (you can also symlink ~/.cache into /tmp)
It is useful when you have a lot of application profiles in /home and they all want to cache "permanent" data on your drive, so if you don't want permanent clutter, you just link it into tmpfs and it's all gone as soon as the power is out.
Web streaming cache is a good candidate for tmpfs, it's being loaded much faster from there, and it's just temporary data anyway.

1 members found this post helpful.

Yes, I actually had speculated about a persistent Live OS, but the main drawback for me is not enough storage space for syncing my sheet music, and various other files that I need access to from the cloud and to sync to the cloud.

As an alternative to tmpfs, yes.

As my main concern here is video and audio performance, minimizing lag but not necessarily low latency, and largely (but not only) in reference to the web browser, is /tmp where it is all happening?

The Vivaldi browser is normally installed in /opt, not sure about Google Chrome as that is installed from the extras section with slackpkg, would making /opt tmpfs feasible? The problem is sometimes things are HTML5 and other times Flash or Pepper player are used for Flash content, so again - only /tmp or does /opt also make sense for tmpfs?

If SSD and possibly /tmp as tmpfs is the way to go, then I could use some advice from the forum on reasonably priced SSDs.

Thanks. That is useful information.

Very interesting. Vivaldi browser, which I normally use, is configured as follows:
/home/username/.cache/vivaldi/Default/ and then it branches to either /Default/Cache/ or to /Default/Media Cache/. I assume that this is what you are referring to. So the idea would be to create a symbolic link for /Default/Media Cache/ to /tmp and then load /tmp as tmpfs?

Your beloved Acer Aspire One 725 sports an AMD C60 processor, which is one of the slowest and worst things made by AMD in the last years. Compared with it, even an Intel Atom is a powerful monster CPU.

My sincere suggestion is to buy another (and this time real) notebook instead of a 250GB SSD for this lame duck, err... netbook.

For gods sake, the words "AMD C60" and "performance" makes no sense in the the same phrase.

I've worked on a shared webcache project and we used to tar clean user profiles (~/.mozilla and ~/.cache/mozilla) and then untar (on boot) both the profiles and fresh cache into tmpfs through rc.local.
So it's technically possible, but you don't see that every day. I do have a couple of SSDs too, but I wouldn't let just anyone write there, especially when they're writing a db.

Yes, it is looking more and more like a ball and chain.

Interesting. Can you suggest some documentation as to a practical configuration?

Here is the default user setting in Slint for the cache:
This puts in RAM what would be in ~/.cache without user setting.

I just checked installing Vivaldi using the latest-vivaldi.sh script (thanks ruario!). I didn't do any further setting in Vivaldi and its cache is where I expected it to be:Of course the cache will be wiped out when I reboot.

This handle all software that honor the XDG Base Directory Specification. A lot of desktop software do, e.g.:
PS To be clear, this setting does not fiddle with the config files in ~/.mozilla and ~/.thunderbird (or any config file in ~/.config, like in the ~/.config/vivaldi directory), only the cached files are in concern.

3 members found this post helpful.

what kind of storage you worried about, as you made mention of sdd. 32GB sdd about 20 bucks US. 5GB for system, tmp in ram about 1GB, swap? that now days is an iffy, unless you hibernate the system.

I had an old netbook 1GB RAM ran Ubuntutu, Debain, and a few others on it. I went to Slackwhere later.

The only issue I had was movies that where so data saturated it was hard for the CPU to push it through to the player, choppy sometimes, but I did coding and what not on it. it was an Acer D250 w/ATOM N260 the first ones out. of and that liteel screen got to be too much, especially trying to code on it.

your specs CPU
the 1GHz is the only thing holding you back, that is just slow cycle times for what software is out there now days, MO.

250gb ssd price $60 ~ $80 US.

Pawnshop special, from the guy that just needed some fast cash so he let go of a decent Laptop, so buyer gets it cheaper.

that is where I use to go for mine. if you know what to look for then you'll cut down the worry. I'd crack them open and look at what kind of HDD it takes and ram and upgradeabiltiy stuff, boot it and hit the F' keys to get into the BIOS to see what it has etc.. 50 to 100 bucks and I got a few nice laptops doing it that way.

1 members found this post helpful.

I don't do documentation, sorry. I bashed the thing together in the most primitive way possible.
It's mostly just tar, coreutils, bash, rc, and squid for fast https filtering in tmpfs.

That wasn't a personal request I just thought that you had based it on some specific documentation.