Last one I looked at they were using IceWM - after the 215CE I think. Wonder why they switched. Icewm is nice.
Re backup: the Puppy backup methology is quite different to dsl. DSL simply makes an archive, which is fine for our purposes - Puppy is writing changes to a filesystem on a file-backed loop - that filesystem is part of the aufs unified view that the user sees. This makes the "backup" very fast (barring a sync) and you can have a lot of stuff in it if you want to.
User writes to the filesystem are held on a tmpfs filesystem on ramdisk and are copied over to the file-backed loop at intervals if this resides on a flash drive. This is quite clever for reducing write cycles to flash, though you could conceivably lose data if the system freezes or power is lost in between. In practice doesn't seem to be a problem.
To encrypt the file-backed loop, last time I cheked they're using cryptoloop I think, which has known vulnerabilities and is a bad choice.
[ Mind you, dsl is writing its backup in *plaintext* to the backup medium (like it once used to) before overwriting and encrypting since switching from 3des to bcrypt, so in terms of data security that could be considered a retrograde move. ((bcrypt can't work in a pipe the way 3des or gpg can so Robert would have had little choice other than to not use bcrypt). ]
Puppy could get stung one day if they get the wrong kernel/loop driver combination, it will start freezing the system up randomly. They seem to have avoided that so far.
I'm out of touch, they may have swiched to dm-crypt/cryptsetup-LUKS by now, but that still would not avoid potential loop driver freezes on a file-backed loop.I didn't look at puppy's encrypting possibilities at all, I didn't have a need for that..
Anyway, there are ways around bcrypt's limitations, three come to my mind: - either building on the official blowfish implementation, or editing bcrypt - keeping the plain backup in RAM, not the backup medium (probably not feasible for DSL) - and the the ideal solution: named pipes. If we make one, it will be accepted into bcrypt as a file, and nothing will be written in plaintext. Even the tar compression speed of the system isn't a problem, bcrypt just sees a slow-to-read device.
You seem to be a better security expert than me - do you see any obvious flaws in named pipes? If not, maybe this could be implemented in DSL.Just a comment. I designed DSL features long before there was unionsfs/aufs. I designed DSL to be nomadic. Therefore no hardware specifics in the backup. I designed and created dot dsl, uci, and tar.gz extensions before dot pup, et. al. I did this several reasons, factor out large static files from the backup, reduce write cycles, read many, write once, provide easy self contained "packages" with easy reboot and they are removed.
I am still supporting what I wrote, now years ago. I too, could have dropped, syslinux, legacy (non-unionfs) and chose to not be nomadic.
Most, if not all kernel 2.6 based distros now offer a unionfs/aufs with liveCD. Instead, I have tried to offer more within my original design goals. Both Austrumi and Puppy have gone on to larger systems and use higher compression to achieve small physical (download) size, but system requirements and runtime size is much higher than DSL. I cannot run those systems on much of my hardware.
Even the new eeePC uses "a frugal" installation. Where the system is frozen and all user changes are done in union space. I applaud this approach. That concept was what I was doing with DSL frugal install and ramdisk. One can always boot to a known pristine state. One does not suffer from "system rot" or other "oops" corruption.
While the 2.4 kernel is still being maintained, I don't have the luxury of newer unionfs/aufs and other subsystems being supported in 2.4 kernel. There is much debate on 2.6 kernel being more for servers than desktop. But the pressure of lack of support by major subsystems, aufs, ndiswrapper, etc limits the capability moving forward.@Curaga:
Quote
named pipes. If we make one, it will be accepted into bcrypt as a file
No it won't unfortunately. As I said, bcrypt can't work in a pipe. (You're probably not aware that I was the one who suggested using named pipes with 3des on dsl back in the olden days to avoid this issue then). A look at the bcrypt code shows why. It gets the input file size at the beginning and passes this down as an argument through a bunch of functions. This makes it quite sure how much memory it's using, and is slightly easier, but is not necessary. A name piped is a 0-byte file, which bcrypt interprets as no file at all. Reading from stdin or a pipe is not difficult to code, so I wish they'd done this and it seems like bad design to me when most other encryption progs can read from stdin. Writing to stdout can be more problematic because garbage out cannot be deleted or rewound on a pipe.
@Roberts: interesting background there on 2.6.xx. I recall Puppy *had* to move to aufs, because the way they stack their filesystem layers was causing lots of problems under unionfs (can't recall the details) - certain files went invisible in certain packages or something - aufs solved this for them dsl's system doesn't have these issues with unionfs.Could you possibly add stdin reading to it? It's open source, under the first BSD license.Next Page...
original here.