Taking the fat dog for a walk

[MochiMoppel]

I used FD810 only for a couple of days now, Too early to say that I can see the beauty in this beast. For the time being I'll continue to explore it.

I noticed that the bugs/misconfigurations I mentioned in the Fosspup64 thread also apply to FD810

F5 in Geany not working
This is an old bug, already reported 7 years ago. Why does it still exist, and more surprising: Why does nobody complain? Am I the only one who runs scripts from Geany? Or does it miraculously work for everybody else except me? The command xterm -e "/bin/sh %c" contains a syntax error , doesn't it?

JWM Group setting
Forcing (g)xmessage to open with notitle and nolist makes no sense to me. There is no such restriction in Fatdog's Openbox implementation, so why for JWM?

Speaking of Openbox I have a question: If windows have a title bar, clicking on the upper left icon opens the Openbox window menu. This menu contains items like Move and Un/Decorate. Like in JWM the pager tabs in the tray also contain a window menu, however Move and Un/Decorate are not listed. This means that I can "undecorate" a window from the menu in the title bar, but I can't "decorate" again because the menu is gone. How is this supposed to work?
The same problem with my pxRuler application. pxRuler has no title bar in the first place, so how can a user move the window with the keyboard when there is no Move menu?

[fredx181]

If windows have a title bar, clicking on the upper left icon opens the Openbox window menu. This menu contains items like Move and Un/Decorate. Like in JWM the pager tabs in the tray also contain a window menu, however Move and Un/Decorate are not listed. This means that I can "undecorate" a window from the menu in the title bar, but I can't "decorate" again because the menu is gone. How is this supposed to work?

Not easy, but you can, for a resizable window right-click at the exact edge (where the resizable cursor appears, well at least for me, see pic).
For a non-resizable window, the same, at the exact edge, but then probably not showing the resizable cursor.
Not sure, perhaps the margin (px) can be adjusted in the openbox configuration ? (so it would be easier)

Fred

[user1111]

If windows have a title bar, clicking on the upper left icon opens the Openbox window menu. This menu contains items like Move and Un/Decorate. Like in JWM the pager tabs in the tray also contain a window menu, however Move and Un/Decorate are not listed. This means that I can "undecorate" a window from the menu in the title bar, but I can't "decorate" again because the menu is gone. How is this supposed to work?

Alt-Space M to move (using arrow keys)
Alt-Space D to toggle decorate/undecorate

[JakeSFR]

F5 in Geany not working
This is an old bug, already reported 7 years ago. Why does it still exist, and more surprising: Why does nobody complain? Am I the only one who runs scripts from Geany? Or does it miraculously work for everybody else except me? The command xterm -e "/bin/sh %c" contains a syntax error , doesn't it?

Actually, it works, but with real xterm (e.g. when you have devx.sfs loaded).
The corrected syntax works with both xterm and urxvt, though, so it will be fixed in next FD, thanks!

Greetings!

[jamesbond]

JWM Group setting
Forcing (g)xmessage to open with notitle and nolist makes no sense to me. There is no such restriction in Fatdog's Openbox implementation, so why for JWM?

JWM is second class citizen in Fatdog. It's there for people who can't live without it. Most of us use Openbox and we never look back.
We imported JWM configuration from Puppy ages ago; and we hope that people who do use it, to report back and send patches to improve things which they consider broken.

[MochiMoppel]

@fredx181 Thanks. Not easy indeed and not an option for non-resizable windows,
@rufwoof OK, that's acceptable for keyboard junkies like me. Mouse lovers may not agree.
@JakeSFR Fix appreciated. BTW: I miss your TAS in FD.
@jamesbond This makes me feel like a second class user. I prefer JWM when it's available since I'm familiar with it but I also agree that Openbox is the better wm. Instead of offering a choice that you don't really support you should consider to dump JWM altogether. People who can't live without it don't use FD

[MochiMoppel]

I downloaded and installed google-chrome. Runs fine in my laptop, does not run in my desktop ("Segmentation fault")

On my laptop I can start the browser from the menu but I can't figure out how to start it from the command line with a URL as parameter. May have to do with this spot stuff.
I also would like, with browser already running, execute a command in a different application that would send a URL to the running browser. With palemoon this would be the same command as starting the browser (palemoon URL) and it would not start another browser instance. I assume that this would be the same with google-chrome, but since I'm too stupind to start this thing in the first place I cannot test. Any advice appreciated..

[user1111]

I can start the browser from the menu but I can't figure out how to start it from the command line with a URL as parameter

defaultbrowser news.bbc.co.uk

[MochiMoppel]

I can start the browser from the menu but I can't figure out how to start it from the command line with a URL as parameter

defaultbrowser news.bbc.co.uk

Starts seamonkey. Google-chrome is an additional browser and is not the default.

[user1111]

@rufwoof OK, that's acceptable for keyboard junkies like me. Mouse lovers may not agree.

I install both tilda terminal and tmux from Fatdog's gslapt/repos and have tilda terminal set to drop down like quake ... when I press F1. I have it set so it doesn't full-screen, but leaves the Fatdog bottom panel still visible. When I run tmux in that I have it set to create new windows using Ctrl up-arrow, step between windows with ctrl left/right arrows. I've configured tmux to show my local tmux panel in the bottom screen centre, so directly above the Fatdog panel and where tmux windows are centered. In mc I have the user menu set to show/run frequently used commands/actions

ss1.png (308.61 KiB) Viewed 1216 times

So that doesn't conflict with when I ssh connect to hashbang and run tmux on that, in the hashbang tmux session I've set the backtick to be the tmux 'command' key and where the panel is set to show the windows on the left hand side. So another tmux panel above my local tmux panel which is above the Fatdog panel.

ss.png (496.24 KiB) Viewed 1216 times

I don't use panes to divide tmux windows and zoom in/out those panes as some do, I just flip between full sized windows and with the above arrangement the separation works well for me. I keep my calcurse calendar on hashbang, and I also use a text file for all my chrome bookmarks, displaying that with 'less' and where Tilda is set to highlight/follow links when you mouse over/click a link. Which all means that I don't use Fatdog's save option that often, boots the exact same time after time, all data etc. stored outside of Fatdog, no save when I shutdown. When I do save I use multi-session save style, a new sfs added to the set of save sfs's for each separate save.
Nice having all that toggle between show/hide via tilda's F1 key. Having tmux running on hashbang is also nice as you can just detach leaving things all running in the background and reattach later even from different devices to drop back into the exact same session(s) where you'd last left it.

CLI can be so much more than just a # prompt Blending graphical user interface (fatdog) with text user interface (tmux/tilda/hashbang ..etc.) and a simple F1 slide down/up toggle between the two Quake style is great IMO.

[user1111]

I can start the browser from the menu but I can't figure out how to start it from the command line with a URL as parameter

defaultbrowser news.bbc.co.uk

Starts seamonkey. Google-chrome is an additional browser and is not the default.

If you run as root ...
/opt/google/chrome/chrome --no-sandbox news.bbc.co.uk
it will start up at the url used. Chrome doesn't like running as root and will 'complain' however (prompts). If you run it as spot then there's no need for the --no-sandbox parameter

Code: Select all

# su spot
spot$ /opt/google/chrome/google-chrome --user-data-dir=/home/spot/.config/chrome news.bbc.co.uk

[MochiMoppel]

When running as root
google-chrome-spot www.whatever.com
seems to work.

[jamesbond]

When running as root
google-chrome-spot www.whatever.com
seems to work.

If you want to run as root, then just use "google-chrome-stable --no-sandbox whatever.com"

[MochiMoppel]

If you want to run as root, then just use "google-chrome-stable --no-sandbox whatever.com"

Thank you. I currently can't test since I have deleted FD. I will test the newer version some day but for now I had too many problems with the preinstalled Seamonkey and the added google-chrome on my 2GB desktop and 2GB Acer AspireOne. On both machines the browsers are practically unusable since they cause the system almost to freeze. On the desktop the suspend function works often but not always.

I find the google command not intuitive. Why not a wrapper script google-chrome or google-chrome-root as a logical alternative to the existing google-chrome-spot ? I only would see a justification for a a google-chrome-stable command if there also exists a google-chrome-instable command. Ahh..what do I know ... maybe there is?

[jamesbond]

I will test the newer version some day but for now I had too many problems with the preinstalled Seamonkey and the added google-chrome on my 2GB desktop and 2GB Acer AspireOne. On both machines the browsers are practically unusable since they cause the system almost to freeze.

If you only have 2GB, and you plan to run large programs, then you'll definitely want to do two things:
a) run with small initrd
b) run with a swap (file or partition)

On the desktop the suspend function works often but not always.

Suspend either works or it doesn't. It's different from hardware to hardware. One needs to spend effort to make it work, simply because we can't test on all possible machines out there.

Why not a wrapper script google-chrome or google-chrome-root as a logical alternative to the existing google-chrome-spot ?

All programs run according to the currently logged-in user, except the "-spot" program. Fatdog is multi-user, if you login as "fido" and launch a program, any program, including google-chrome, it will run as the user "fido". Hence calling it as "google-chrome-root" does not make sense. The "-spot" programs are the only exception, if being run as root, it will re-launch itself as "spot" instead.

I only would see a justification for a a google-chrome-stable command if there also exists a google-chrome-instable command. Ahh..what do I know ... maybe there is?

If memory serves correctly, at one point in time chrome had two sets of releases: stable and development (or beta). The one that the script fetch is from the "stable" channel, hence the name. Not sure if it's still like that now, but the name stuck. The correct name for google-chrome-spot should have been "google-chrome-stable-spot" - but that's way too long.

[MochiMoppel]

If you only have 2GB, and you plan to run large programs

I never considered Seamonkey to be a particularly large program.

, then you'll definitely want to do two things:
a) run with small initrd

Hmmm.. the initrd "is what it is" . For the desktop I already run with initrd-nano. Maybe it's fair to say that Fatdog is not suitable for machines with 2GB or less?

Suspend either works or it doesn't

I know that Suspend is delicate and needs the right mix of HW and SW. If Suspend doesn't work for a particular distro on a particular machine then this distro is out of the race for me since this feature is crucial. That's why I was delighted to see that with FD it worked on my desktop - until the day when it didn't. It would suspend and immediately wake up again. I tried different things and finally was able to make it work after setting the display back from its portrait mode to its usual landscape mode, using the xrandr -o normal command. Maybe a coincidence. Display orientation should have nothing to do with suspend and unfortunately this trick didn't work the next time I tried it. So I stand by my statement that here on my machine Suspend works "often but not always".

[wiak]

a) run with small initrd

I'm not at all sure why you say that. The initramfs RAM gets freed on switch-root:

https://landley.net/writing/rootfs-programming.html

A common use of initramfs is to find and mount another root filesystem. Since rootfs can't be unmounted, the way to switch to a different root filesystem is with switch_root command.
...
What switch_root does is delete all the files out of rootfs (to free up the memory) and then chroot into a new filesystem and exec a new init process out of the new filesystem.

Or are you talking about a 'huge-initrd' situation, where you never actually do a switch root?

[JakeSFR]

RE: initrd

Initrd-nano is not the same as "small" initrd.
Well, it is small, but it's sole purpose is to load the "humongous" one using kernel rather than BIOS, because the latter can be really slow in some cases.

Small initrd is humongous initrd with fd64.sfs and kernel-modules.sfs extracted and merged into fd64.sfs outside of it, so it's basically the classic Puppy setup with 3 files: vmlinuz, initrd and fd64.sfs.

I use small initrd on my Acer AO722 with 2G and IIRC it was a must on some Asus with 1G in order to boot at all.

Here's more info and ways to split it: http://distro.ibiblio.org/fatdog/web/fa ... nitrd.html

If you want to split initrd using fatdog-split-initrd.sh:

1. Create a TMP dir on some posix partition, because 2G is not enough to extract it to /tmp
2. Navigate to where your initrd is, e.g. /mnt/sdc1/Fatdog811/
3. Open terminal and:

Code: Select all

fatdog-split-initrd.sh initrd . /path/to/TMP /Fatdog811/fd64.sfs

The last arg is to hardcode in init where to find the extracted fd64.sfs, because it won't be a part of initrd anymore.

Greetings!

[jamesbond]

I never considered Seamonkey to be a particularly large program.

It's not the size of the program, it's the amount of memory that it uses. Modern websites loads tons of frameworks and eats lots of memory, and more still if you keep multiple tabs open since modern browser now runs a separate process for each tabs (so a crashing tab will not crash the entire browser).

Hmmm.. the initrd "is what it is" . For the desktop I already run with initrd-nano.

Jake already gave an excellent explanation. I will just add a little more example.

I use small initrd on my Acer AO722 with 2G and IIRC it was a must on some Asus with 1G in order to boot at all

It has been a while since I booted my Acer Netbook with ATOM N450 and 1GB RAM (can't remember the model, it was from 2012), and Fatdog has probably gained 50 MB since then (and I can't try it again since the machine is not with me at the moment), but I have always managed to boot pristine Fatdog with standard huge initrd.

To install, I used the same small initrd as Jake explained above, and then I created a 1GB swap file and activate it. With that settings I can launch seamonkey and watch youtube, with a few other tabs open (including visiting murga forum, at that time), very comfortably. I can launch libreoffice and work on documents while having duckduckgo open for research. No crash. Of course, sometimes there is a stutter when it performs swap, and an ATOM CPU isn't exactly a power house, so that's to be expected.

Maybe it's fair to say that Fatdog is not suitable for machines with 2GB or less?

I disagree. Every time I build a new ISO I boot it off on qemu with 1GB RAM just to make sure it still boots with 1GB RAM. It always works, with around ~350MB still available after the default desktop is running. If you take out the basesfs, you'll free another ~350MB, which gives you ~700MB free, on 1GB machine. That's plenty. If you take out the kernel modules you can free up even more.

So it works. Jake does it, and so do I. We never encounter problems. If you really want to know how low we can go, please read this article from 2016. The process explained in that article (step 2 / step 3) results in what today is called as "initrd-nano", which we now include by default in the ISO. Where else can you get a complete 64-bit OS, with full driver support, with all applications available at your finger tip, running with only 44MB occupied? Granted, this was from 4 years ago, from days of Fatdog 710, but the result won't be much different today.

I'm not at all sure why you say that. The initramfs RAM gets freed on switch-root

No. If you read Rob's article carefully, he said:

What switch_root does is delete all the files out of rootfs

So, in effect, switch_root does something like "rm -rf" of all the files in initramfs. But if those files are currently open and being used, even though they are deleted, the memory they occupy will not be freed until they're closed. If you have basesfs in initramfs and you loop-mount it, you can delete the basesfs file but the memory occupied remains in cache and won't be cleared.

[wiak]

I'm not at all sure why you say that. The initramfs RAM gets freed on switch-root

No. If you read Rob's article carefully, he said:

What switch_root does is delete all the files out of rootfs

So, in effect, switch_root does something like "rm -rf" of all the files in initramfs. But if those files are currently open and being used, even though they are deleted, the memory they occupy will not be freed until they're closed. If you have basesfs in initramfs and you loop-mount it, you can delete the basesfs file but the memory occupied remains in cache and won't be cleared.

Good point. Memory occupied in that loop-mounted case remains as such of course. I think I did enquire in post thereafter if original post was however for that special case where basesfs was in initramfs, which indeed has that issue you refer to. When I originally commented I didn't notice the post was a FatDog one (was just browsing the forum somewhat randomly) - once I noticed that I realised that original comment might relate to basesfs in initramfs possibility, which I knew was an available FatDog option.

[jamesbond]

Good point. Memory occupied in that loop-mounted case remains as such of course. I think I did enquire in post thereafter if original post was however for that special case where basesfs was in initramfs

Well this is what you said:

Or are you talking about a 'huge-initrd' situation, where you never actually do a switch root?

I didn't respond to that previously because it's irrelevant: if we don't switch_root then there is no point in talking about switch_root behaviour; and furthermore, "huge-initrd" (which means basesfs in initramfs) and "switch_root" are orthogonal to each other. Fatdog happens to do both.

which indeed has that issue you refer to.

It's not an issue, really. It's just knowing that if one wants to keep basesfs in RAM (no matter which method is being used - either directly having it in initramfs, or loaded to RAM through some other means), then some amount of RAM will be reserved for that basesfs and is unavailable for general use by applications.

When I originally commented I didn't notice the post was a FatDog one (was just browsing the forum somewhat randomly) - once I noticed that I realised that original comment might relate to basesfs in initramfs possibility, which I knew was an available FatDog option.

Ah, noted. A little clarification: Fatdog ships with basesfs in initramfs by default. It can, of course, be configured to run with basesfs located outside initramfs (this is what "small initrd" is all about); and when configured that way it's memory footprint will correspondingly go down.

[wiak]

Well this is what you said:

Or are you talking about a 'huge-initrd' situation, where you never actually do a switch root?

I didn't respond to that previously because it's irrelevant: if we don't switch_root then there is no point in talking about switch_root behaviour; and furthermore, "huge-initrd" (which means basesfs in initramfs) and "switch_root" are orthogonal to each other. Fatdog happens to do both

That's fine. My only knowledge of FatDog is from reading some posts by rufwoof about how FatDog has various initramfs configurations - I think I may have mixed my memory up of it with SliTaz in terms of initramfs used, which "I think", though haven't checked, has its basesfs in its initramfs and doesn't do a switch_root, but maybe it does and I'm wrong about that too and should google and not leave that as another unproven detail (so just now done quickest of checks and think SliTaz does switch_root too - I must have dreamed some frugal-install-type distro didn't... oh well).

EDIT: come to think of it my first weedoglinux initramfs didn't use any switch_root (used a chroot instead), but truth is I've lost the plot what my early very small post was about so not to worry...

Alas, and woe is me that in my erroneous and much regretted mistaken/inaccurate/wrong-end-of-the-stick posts above to this thread, I just glanced at one post and carelessly typed a quick comment, apparently irrelevant and miles off target, so by the time my fingers hit the keyboard I had forgotten whether original post mentioned switch_root or not (and I haven't rechecked but I presume it does). Basically, not noticing was about FatDog, I picked up wrong meaning anyway of whatever the original post was about so please just ignore whatever I then or since wrote! I think I'll limit my off-the-cuff post ''contributions' in future since result in this case was a waste of people's valuable time especially since I'm in too much of a rush at the moment to double check I've not accidentally picked up the wrong end of the stick, and only originally glanced at the original post so wasn't clear on what details it mentioned other than being some kind of advice to use small initrd to save RAM (I think). So I certainly did pick up the wrong end of the stick in this case and life is too short so please forgive me and I'll stay away in future. My mistake. I was horrendously wrong and guilty of not paying attention to detail and deserve a good thrashing! Relax. I'm moving on now and everything you originally posted is no doubt good and fine and no dispute my me needing answered. Soon be summer! No more computing for me for next six months anyway so peace and goodwill and enjoy yourselves as will I.

[user1111]

come to think of it my first weedoglinux initramfs didn't use any switch_root (used a chroot instead)

Fatdogs fd64.sfs when extracted is around 1.3GB size. So I made a file filesystem (using dd to create a 1.6GB file), formatted it to ext3 (mkfs.ext3) mounted that and unsquashed fd64.sfs into it. I also made a internal rsync of the content using hardlinks, so quick and takes up little space.

In initramfs/init I drop out to cli and and can either preserve the system content to replace those hardlinks, or restore the hardlinks using rsync. i.e. ... after mounting the fd64fs.ext3 to /m ...

rsync -a --link-dest=$PWD/m $PWD/m/ $PWD/m/hardlinks --exclude=hardlinks
or
rsync -a --delete $PWD/m/hardlinks/ $PWD/m --exclude=hardlinks

Either way that's very quick, and in using hard links based rsync, its just inode pointers (uses little space). That's pretty crude, more just a proof of concept, really should have more exclusions, --exclude=/{/run/*,/proc/*,mnt,sys ...etc}

After I exit that initramfs based /bin/sh cli it resumes normal bootup, I used chroot to do that.

Bit of a cross between frugal and full install. Using a file filesystem that's a single file for the main (otherwise) sfs content, that can be stored on ntfs or whatever. All changes are preserved within that as they occur, but with the hard link rsync changes can be rolled back quickly or the session preserved (save/no-save). When booted into the main system, sda1 where I store fd64fs.ext3 is unmounted (bottom left drive icons) and can be mounted/unmounted normally, and memory usages is very low; But sda1 is actually mounted within initrd, so whether its mounted or not in the main system it remains mounted in the parent (prior to chroot), so all changes are recorded into fd64fs.ext3 as/when they occur.

I did try using a fd64fs.btrfs (mkfs.btrfs), but ran into a bit of a can-of-worms in trying to get that to mount -o compress=lzo fd64fs.btrfs m ... within initramfs. If that had worked then not only could the filesystem be smaller (compressed), but could use snapshots instead or rsync.

[wiak]

I also made a internal rsync of the content using hardlinks, so quick and takes up little space.

In initramfs/init I drop out to cli and and can either preserve the system content to replace those hardlinks, or restore the hardlinks using rsync. i.e. ... after mounting the fd64fs.ext3 to /m ...

Clever and useful idea.

[user1111]

Thanks wiak. You could of course maintain multiple hard link rsyncs, like snapshots (or incremental backups). For me, around 1.6GB of main system data creates a hard links rsync in a few seconds, restores can take around 10 seconds; Space used was a little under 19MB (du -sh * indicated 18.8MB) for the 'snapshot' (hard links). I made a rsync store and then installed chrome using the standard right click, package-install, and then made a separate rsync store, so have the option to roll-back to pre chrome being installed, such as when another later release of chrome occurs.

This "initramfs for Btrfs" looks interesting https://ogris.de/initramfs.btrfs/ ... if btrfs was being used instead then its snapshots could be used instead of using rsync, and also the filesystem could be mounted with the -o compress=lzo ... or whatever preferred/supported compression method.

Fundamentally its just like using the Puppy 'save file' but where all of the main (normally read only) sfs content was also in the save file, and where that can be reinstated to having been like read only by rsync (or btrfs snapshot) restores.

[user1111]

Ah! ntfs supports compression, and hard links

dd'd a file : dd if=/dev/zero of=fd64fs.ntfs bs=4096 count=600000
formatted it to ntfs with compression support : mkfs.ntfs -C -F fd64fs.ntfs
Loaded the fd64.sfs into that, and make a hard links rsync
mkdir m
mount -t ntfs-3g fd64fs.ntfs m
unsquashfs -f -d ./m fd64.sfs
rsync -a --link-dest=$PWD/m $PWD/m/ $PWD/m/hardlinks --exclude=hardlinks

That indicates around a 50% compression rate i.e. 1.3GB of raw fd64.sfs data size reduced down to around 700MB within ntfs compressed filesystem

# du -sh *
694M m

Compiled ntfs FS support into the kernel (under Filesystems, Dos and NT in make menuconfig)
Inserted a static version of ntfs3g into initrd's /bin folder (borrowed from fatdog 810 as that is using kernel 4.19, the same kernel that I've been using for testing)

ntfs-3g is fuse based, so I expected it to be slower/sluggish

During bootup I dropped out to cli (/bin/sh) and found the next free loop device (losetup -f) which was /dev/loop2 so coded in

Code: Select all

/bin/mount -t proc proc /proc 
mount -t sysfs sysfs /sys
if ! mount -t devtmpfs devtmpfs /dev 2> /null; then	
	mount -t tmpfs tmpfs /dev -o mode=755 
	mdev -s
fi

[ -f /null ] && rm /null	
[ ! -e /dev/shm ] && mkdir -p /dev/shm
[ ! -e /dev/pts ] && mkdir -p /dev/pts
cd /
mkdir m
mkdir /mnt/sda1
mount /dev/sda1 /mnt/sda1
losetup /dev/loop2 /mnt/sda1/FATDOG810-FINAL/fd64fs.ntfs
ntfs-3g -o auto,users,permissions /dev/loop2 m
cd /
NEW_ROOT=/m
mount -o move /sys $NEW_ROOT/sys
mount -o move /dev $NEW_ROOT/dev
mount -o move /proc $NEW_ROOT/proc 
exec chroot $NEW_ROOT /sbin/init

and that boots to gui desktop OK, net connected, ran libreoffice writer ...etc. and other than the initial desktop being loaded, it wasn't slow at all.

Does seem to be somewhat traitorish to be running Linux using a NTFS filesystem But that supports compression and rsync hard links and seems to work OK At least from a casual inspection.

Booted to desktop and loop2 is indicated as having 743MB used

xscreenshot-20201006T121730.jpg (121.04 KiB) Viewed 1025 times

EDIT : Started running hot. Looking at Services ... and everything was running ... a file permissions issue. Modifying the ntfs-3g mount command to include -o auto,users,permissions ... resolved that (can now chmod -x <file> ... or whatever whereas previously files were all set with rwx permissions and couldn't be changed). I've edited the above code to reflect that change.

rsync hard links saving (or restoring) with ext3 was taking around 10 seconds. Under ntfs (fuse) that increases to around 25 to 35 seconds, so around 3 times slower. Similarly the desktop initial load takes around two to three times longer. Once up and running however (things already read into ram/cache), 'normal service' response times pretty much resume. Given that disk space nowadays is relatively inexpensive, the added benefit of having compression - the faster disk I/O speeds of which are impeded by ntfs/fuse based filesystem, over using a ext filesystem and non compressed is ???

[jamesbond]

Comments @rufwoof
1. You can do this in standard fatdog by using basesfs=none and savefile=fd64fs.img (created the way you explained it). Or if you wish, you can expand it into a proper partition and point savefile= to that partition (it becomes sort of "save directory" where the mountpoint is "/").
2. ntfs-3g does not need in-kernel NTFS support (but it's still good to have, because ntfs-3g is very picky when encountering damaged filesystems).
3. You run NTFS at your own risk. ntfsfix can only fix vanishingly small subset of corruptions; for the rest you need Windows. I don't think Windows can fix NTFS in a filesystem image, though.
4. What went wrong with your btrfs experiment?

[user1111]

4. What went wrong with your btrfs experiment?

Nothing James, just put btrfs on the back burner for the time being.