DSL Tips and Tricks :: squashfs



JeffElkins,
I'm dying to try your build, please make link active again.
The folks at Debian Live have just release an unusable iso with rootfs  and squashfs. You might post your results on their mailing list, so at least we have an usable mimimal base to build a Debian system.
I am also interested. I was wondering if squashfs is slower or faster when booting from QEMU. I tried SLAX with QEMU and found it much slower during boot and it uses squashfs.

Thanks,

desNotes
Initially Qemu did not even support squashfs.
There are so many conflicting reports on which is faster or which compresses more. To me, it is like 6 or half-dozen. Is the effort worth the result.
Please, if you have two spare minutes read this:
My post on debian live mailing list
Markus Laire reply pointing to Puppy Linux
Puppy Linux article about squashfs and automatic backup

That might open new possibilities, also considering that DSL is considering some changes (DSL-N).

In particular the thing I found most interesting is that:
Quote
6. The entire filesystem is writable
Puppy1 has a rather complicated system whereby the home directory (/root) is writable, and /etc and /usr are made writable by actually saving the files inside /root.
The persistent storage file pup001 mounts on /root. The original files of /usr are in a compressed read only file called usr_cram.fs.


Puppy2 mounts the persistent storage file pup_save.sfs at the top level, that is, on "/". The read only compressed file with all the Puppy files, pup_xxx.sfs, mounts on "/" also.


Having only part of the directory hierarchy writable is a hassle when installing packages.


Now, the thing starts to go too far for my skills, I'd like your technical opinion.
NOTE:
I have been asked for my opinion.
Please take this as my personal opinion.
It very well may not be the opinon of John.
I came to this project three years ago with certain design goals in mind.
That was to create a more nomadic yet robust tiny distro based on the orginal work of John.
That being said and not being one to shy from expressing an opinion let me state first of all that this is not meant to be flamebait.

The two projects very different philosophies.

1. I would never advocate to run a system as user root.
2. I would never mount all hard drives on a host system, especially running as user root.
3. I do not like starting their distro and finding a large pup001 file placed on my hard drive.

DSL is made to place nice as a nomadic OS.
You can safely boot up on a host machine and not worry about distrubing the host machines hard drives.
DSL in my opinion is more nomadic and more Unix like.

With Puppy it appears that you are anchored to your machine with that huge pup001 file. Or even their rewrite to cdrom, is not portable to most other cdrom drives. Not to knock their efforts. It is  an alternative way to run an OS on older harware, not as nomadic as DSL. Also, everything is easier to do in Puppy, because you are root. As a unix guy, I cannot accept that. In fact DSL may be more difficult for new users but it is more Unix-like. Now that may be an agruable point. I hear other Linux distros run as root. It is just not for me.  Also they do not have much in CLI options. If I only had to worry about X apps it would be easier too. They also do not have much in hardware detection. If I could drop hardware detection and supporting modules, I could add in more robust apps too. To me puppy is like a single user early version of  Windows. We all know how popular all versions of windows have been. So don't take that as a put down.

If you want the full filesystem to be writeable then try DSL-N it can boot with unionfs. Some people love unionfs others not.
I made it an option with DSL-N. I could easily add unionfs to DSL proper but the self imposed size limit of 50MB currently prevents me from doing this. If it is that important to all then maybe a poll should be done.

Also there are other filesystems made specifically for flash devices.
If one were to dedicate to building an OS for flash then this would be a better way to go and one that I would probably presue.

As far as squash versus cloop, I am not convinced to change.
We had a squash extension for awhile and it never took off.

I have already stated my opionon on Debian.
For a hard drive installed system with tons of space it is super.
For tiny hardware it is not fine grained enough. That is the whole point about pre-packaging dsl extensions. Also packagement management itself takes up a very large space when compared to the tiny size and design of DSL. I readily admit I personally do not advocate the traditional Debian hard drive method for DSL.

Very different designs between the two systems.
I wish them only good fortune with their new system.
The more choices the better. I do applaude their orginial approach.

Use the one that works best for you. I know you will. I wouldn't expect it any other way.
Next Page...
original here.