Monday, January 21, 2013

Dell 2030M review.

Last time I reviewed Philips 192EL2 and gave moderate feedback; but after looking at this Dell monitor, I think I forgot to praise it's color and brightness.

This 'Windows 7 compatible' monitor comes in the same price range as any other budget monitor, so does the Philips 192EL2, but it's colors are completely washed off. They simply feel unatural and faded out regardless of the settings but appear to be too bright on some pictures. Point is, after looking at it's performance, you'll conclude something's wrong. It comes nowhere close to the CRT or the 192EL2 and looking at their price difference, this's not even good for general computing, it falls wayyy behind multimedia applications.

The brightness is reasonable, but the 192EL2 is about 5 times as bright.

So instead of recommending this 'Windows 7 compatible' monitor, I'd recommend a VGA and DVI compatible Philips 20 inch monitor.

Tuesday, January 15, 2013

AVFS howto/guide/tutorial.

This's a virtual FS to browse through archives. It can even browse through block devices (like cd/dvd drives, PD etc...) if you've written whole archives on them directly. It also supports network protocols like ftp, http etc..

Things work around avfsd with no root privileges required, just ensure you're in the fuse group (i.e. if that group exists in your OS).

Avfs is going to mount the root dir to a place where you point to –

avfsd archive

Will mount the root (or root like) FS to directory archive.

In archive/ browse to the archive location (or 'cd' to it), and then open it by placing a # after it's name, e.g. –

cd archive/home/user/backup_drive/backup.tar.xz#

This's going to cd into the archive.

If you use just #, avfs will rely on the extension of the archive to detect the type of archive, thus the # is actually a shorthand. The full path to open the archive also includes the type of archive, it's specified by placing certain text (depending on the archive type) after the # –

cd archive/home/user/backup_drive/backup.tar.xz#uz

Where uz means a xz archive and uses gzip for it's decompression. But cause it's tar.xz, you'll see a tar archive inside it, to also browse into the tar archive –

cd archive/home/user/backup_drive/backup.tar.xz#uz#utar

You have to use these with block devices if you burnt the archive to them directly –

cd archive/dev/sr0#utar

i.e. the tar archive has been burnt directly to the optical media.

This's going to make avfs assume the file is first compressed with uz, then utar. Similarly –

cd /home/user/backup_drive/backup#urar#utar

Supported archives and such keywords (as of the current time) –

#deb debian packages

#ftplist ?

#hp48 ?

#lslR directory tree listings

#mailfs ?

#patchfs browse patch files

#rpm rpm packages

#rpms List of installed rpms

#trpm Useful inside #rpms

#ucpio cpio archives

#ulha lha archives

#uzoo zoo archives

#a first floppy drive alias for #floppy:a

#avfsstat meta information builtin

#bz2 bzip2 uses bzip2

#dav webdav builtin

#dav_ctl control dav sessions

#floppy floppy uses mtools (mdir, mcopy, ...)

#ftp ftp builtin

#ftp_ctl control ftp sessions

#gz gzip uses gzip

#iso9660 CD/DVD filesystem no need to use mount -t iso9660!

#local local filesysem only for internal use

#rsh rsh/rcp only works if rsh needs no password

#ssh ssh/scp only works if ssh needs no password

#uar un-ar builtin

#ubz2 bunzip2 builtin

#ubzip2 bunzip2 uses bzip2

#ucftp ftp builtin (write support, no file cache)

#ucftp_ctl control ftp sessions

#ugz gunzip builtin (1)

#ugzip gunzip uses gzip

#urar unrar builtin list + uses rar to extract

#utar untar builtin

#uxz unxz/unlzma builtin

#uxze unxz/unlzma uses xz

#uz uncompress uses gzip

#uzip unzip builtin

#volatile 'memory fs' mainly for testing

#u7z p7zip 7z archives

These are built in type (or there by default).

Avfsd relies on programs (e.g. 7z, tar, xz, gzip, unrar etc...) and scripts to open up archives; the script tells avfsd how to operate the command (arguments etc...) to open up the archives.

This means you can extend the supported the archive type; the script in question is placed at /usr/lib64/avfs/extfs on Gentoo. May differ for other distros.

You can get a lot of such scripts on the net; but as know know, you're at risk 'downloading' them directly, it may be malware.

Depending on the archive type, programs's efficient etc... it may take a long time for a programs to read the file, or seek to the file (this's an issue in case of lzma1/2 compression); or it may take less time, it depends on the archive format.

To open ftp –

By cding to the mount mount of avfs FS.


Friday, January 11, 2013

Burning raw files/filesystems/archives/tar to disk/DVD/CD. Burning encrypted disks

What I mean here is that the disk will not contain any traditional disk FS like iso*, UDF etc.. but will contain a raw file at block level; the file that we'll be writing to the disk may be any file, like a tar archive with various compressions or squashfs image etc...

This can be done by cdrecord/wodim by simply placing the file instead of an iso image, or passing the file over stdout, e.g. -- 

cat test.squashfs | cdrecord speed=0  tsize=4617089843 driveropts=burnfree -

Here you've to set the tsize of the size of the squashfs image (in bytes), or alternatively you may simply specify the file as a command line argument -- 

cdrecord speed=0  tsize=4617089843 driveropts=burnfree test.squashfs

stdin is really useful for tar archives where you can directly stream the data while making the archive; here set the tsize to the size of the medium; in case the data is less than the specified tsize, it'll be padded with spaces; tar has no problems with this, but zip does, so don't burn zip archives.

To extract/mount -- 
unsquashfs /dev/sr0

mount /dev/sr0 ...

Speaking of mounting, udisk appears to recognize the squashfs volume on the DVD/CD and it works perfectly integrated with all DE... like with iso*/UDF filesystems.

For tar -- 

tar -xf /dev/sr0

It may give a warning that extra 0s toward the end has been ignored... which's perfectly fine.

The perfect FS or archive for the purpose -- 

squashfs – Its's detected perfectly by all DE; tsize can be easily figured out (writing the size of the FS image in bytes after figuring out it's size using ls, or using the input file at the squashfs image) but for the same reason you can't stream it to stdout, you've to make an intermediate large file. Also when burning, set the block size to largest possible, 1MB, cause without that seeking problems will occur, reducing read speeds and wearing out the drive. If you want compression with the FS you write to the disk, squashfs is the only option.

tar – Without various compressions (plane tar), can be streamed to stdout but you've to specify a large tsize (maximum of the disk maybe, a bit larger than the possible size of the archive); the extra 0s to the end don't matter, tar filters that out. On the downside, it can't be mounted natively as FS (not natively means you're using avfs, which I've discussed in the next post). If you use xz compression, the seek times to review a file will be too slow, cause lzma requires you to go through all the files which're placed previous to the file you wanna open, making it slow + it's single threaded. I've not tried gzip and bzip though.

Neither fuse-zip nor archivemount mounts the block device as archive. Only avfs works.

Using the same method, you can create a loop device (losetup) mapped to a encrypted block device via cryptsetup. Then you can write to this block device using mksquashfs (the file to be specified will be the block device -- mksquashfs works well this way). After you're done, remove the dm-crypt mapping, and optionally remove the loop device (or run sync); then burn the file (on which you created the loop device) to disk.

To read, cryptsetup on the DVD drive's block device and mount the resulting mapped block device.