Austrian, I think.
...Well, this already shows the fundamental difference: SquashFS is a filesystem on its own, it reads a directory structure with a bunch of files from someplace and compresses them while putting them into a container.
Cloop, on the other hand, does not care about the underlying filesystem. It provides a sort of "compressing shell" around anything that is thrown at it. It could even be a cpio archive or a tar file.
With cloop you could do the following:
- Make a full bitwise backup copy of any partition, including boot sector and whatnot, using dd.
- After compressing it with cloop, you get a rather small image that provides read access while "staying compressed" and still contains everything the original partition did, true to the bit.
You cannot do that with sqashfs, you only get the part that is underlined above. The italic part will never be possible with sqashfs.
It could be arguable whether the possibility to have a bit-copy of the original filesystem at hand has any value in the use case of a live-CD/DVD. Maybe not. But I believe that cloop has some value above that: It is a general compressor/decompressor and, in the special case of a mountable filesystem, provides read access to the compressed thing (plus providing write protection by design).
Therefore, for me it would be a major pity to drop cloop altogether.
Have fun
Dirk
Last edited by DirkS; 04-15-2011 at 11:10 PM.
You are not even convinced yourself and yet you are trying to convince us. And finally you use the word 'believe' .....
You should give us an example of what you described is useful in the context of a live-CD/DVD which the purpose is to squeeze has many programs as possible into the distro.
And that better be something cannot be done by squashfs.
And finally I said before, if Klaus is serious about wanting to continue to use cloop, he should work on including his patch into the mainstream kernel.
Well, I am convinced that my use case can only be satisfied by cloop, never by squashfs. That's why I don't want to loose it altogether.
In terms of a live-CD/DVD: If space efficiency is the killer argument, squashfs is obviously the best. Maybe you can use it even without encountering problems that don't show up with cloop. Maybe there are good reasons to not use it for Knoppix, I don't know. Also I don't remember having ever remastered a Knoppix DVD, I used cloop for something else. So... *shrug*
Klaus Knopper is the one who decides whether to continue to use cloop or switch to squashfs, not you.
I'm on his side about this. The patch is easily added, the so it's not worth the fuss. It works like this since years, so why put a lot of extra effort on oneself, for very little benefit?
(Besides, things of much higher general interest than squashfs or cloop have been rejected by the kernel developers, like Con Kolivas' BFS - but meanwhile some distributions patch their default kernels with it, even though it's not in mainline and most likely never will be. (And since I use BFS myself for several years now, I can tell you it makes a noticeable difference.)
Being in mainline is not a sign of quality whatsoever, it just means that the developer managed to win a fight of some sort. )
I'd like to expand a little on this:
1. I don't think an ordinary comparison of cloop and squashfs is very fruitful - different tools, for different, but in the case of Knoppix overlapping, sets of jobs. I also think it is a bad idea to scrap cloop altogether, it seems to be completely(?) file system agnostic, that can be extremely useful.
2. For quite a few uses, among them the practically important remastering of USB or poor man's HD installs, squashfs may have an edge. While being in mainline is surely not a quality sign per se, in my view it offers some guarantee against being too bad for too long time. That may in fact be relevant in changing times. But the most important thing, is that using squashfs, we can use new or alternate kernel versions without having to update cloop. And while it is by no means a pure Knoppix project, cloop is a tool for special purposes, and will probably stay that way, as squashfs in many 'standard' cases will look like the natural default choice.
3. I think Knoppix has not got the use it deserves, and one of the reasons is clearly the development model, with Klaus Knopper "The Upstream Vendor" (TUV) and very little basic development being done downstream. What we are discussing, is different alternatives for system solutions, and the existence of different alternative solutions can only be a good thing. While I think it may be true that the Knoppix project would benefit from switching to squashfs, I don't think it is necessary now or in the near future.
4. I think Knoppix would benefit from a development process more analogous to kernel development, where Klaus Knopper is the Linus T equivalent of "benevolent dictator", free to include or reject different kinds of "patches" for inclusion in the basic Knoppix package.
5. Creating a squashfs-based derivative with a more specialized package selection (e.g. a hybrid of standard Knoppix and Quantian) could be a good way of experimenting. It could also have some standard non-free software pre-installed, like vmware Workstation and Oracle XE, subject to activation (e.g. by license number). Non-free software is one of the facts of life in many professional uses fo Linux.
I have a litle problem:
today I ditched up my usb with knoppix on just for fun and messed around with it.
Don't ask me how but I ruined my minirt.gz
I have no linux on my laptop installed so I can't patch it myself again and this is needed as my usb install uses squashfs
Can someone share his?
... please contact me; I can send you minirt.gz from 6.4.4
listings@wp-schulz.de
thanks a lot werner.
for the people who want squashfs without problems(or with the same issue as me ) go here : http://dl.dropbox.com/u/15024434/initrd.gz
It seems that Klaus K prefers cloop because of versatility and well proven good properties. But that's of course "past experience", not really present. He has his good reasons, but I think testing out squashfs should be encouraged, as eventual problems and improvements will have a much broader impact than for cloop, and fixes therefore are more likely to happen.
We should aim for a clean extension of the mounting function in minirt init, to cope with squashfs. Klaus K is of course free to reject such a patch, but if we prove it to be useful, I don't think it will be rejected for very long. (Reminiscent of Kanotix forked off because of reluctance to HD installs... not much later we had 0wn...)
When running cloop compression without optimization, it goes almost as fast as squashfs, so compression time isn't that much of an issue. But, the resulting difference in compressed size amounts to about the last GB of programs stuffed into memory from a DVD size image, and that is practically relevant. With an ever increasing footprint of the basic system functions and utilities, it tends to get more rather than less relevant with time, too. I see this very clearly with my pure 64-bits version of 6.4.4.
In the 64-bits context, it should be noted that there have been some adaptation problems with cloop, and I'm not quite sure they are alle honed out by now, Klaus' latest cloop patch being from July 6, and it seemed to make some difference for 64-bits remastering. Where I can still not make busybox (1.1.17, amd64, Debian package, 1.1.18 compiled from source doesn't run at all) get the mounting right, even if I can do it manually in debug mode. I should add that using a freshly compiled 2.6.39.2 64 bits kernel did not help for this bug, only a few others
I'm going to try the squashfs alternative here, and if that goes through, it will be a strong argument pro squashfs, I think. I would also like to add that the way cloop is used in current Knoopix, it's really not file system agnostic, rather we have a (harmless at best) step via isofs, which introduces another set of potential problems. Maybe small and/or irrelevant, but most likely, not empty.
We should, at least, know what may, eventually, be to learn from other successful live distros, in particular Debian-based. Like Ubuntu live and Kanotix. BTW, I looked at the init for the Debian 6.0.1 live CD showcasing LXDE - think Knoppix is far better, and it wasn't a very good user experience either - I just needed it as a starting point for "pure" 64-bits Knoppix.
2 Vintage MicroNetwork MN1182-10 Resistor Network Gold IC Chip Ceramic
$10.00
VINTAGE Compaq Presario 1255 Boots to Bios No battery
$40.00
Vintage Atari 600xl Computer With Cords and Power Source Clean In styrofoam.
$190.00
BlueSCSI V2 WiFi (Desktop) Modern Storage for Vintage Computers Latest Model
$53.50
BlueSCSI V2 WiFi (Narrow DB25) - Modern Storage for Vintage Computers
$51.50
Vintage Microsoft Serial Mouse.
$10.00
Vintage Dell USB Optical Mouse M-UAN DEL1 Black & Silver Clean Tested - VG COND
$13.20
Vintage Compaq iPaq with Targus Foldable Keyboard - WoW
$39.99
Vintage Atari 800XL Computer In Excellent Condition
$200.00
HP LaserJet 1100 Standard Laser Printer Model C4224A Retro Computer Vintage
$175.00