-
Issues I see:
There is no specified method of saying 'minumum version for extraction'. Possibly it can be done by changing the group header tag. The version doesn't seem to be useful for this as it's a text string.
The compression block size is limited to single files; even with gzip (but more so with other algorithms) you get better ratios if you compress a group of files
.
There is...
2008-03-23 09:02:41 UTC in Adump Backup Suite
-
To follow up on this I think the other 'original' images should be deleted too. They're not insane with most comics but if you have an archive with real scans (300 DPI or 600DPI) each image may take 24 or 96 Megabytes. This can easily cause swapping, and once that happens the speed goes down the toilet.
I don't think an LRU cache would be useful for keeping the 'original' images around as...
2007-07-24 07:13:20 UTC in Comical
-
If given a large archive comical will use insane amounts of memory generating thumbnails; I have had it use over three Gigabytes of virtual memory! (ie it ran out!!) The problem is that it loads the uncompressed original image into memory but doesn't discard that image once it's created the thumbnail. It only discards the original image at the same time that it's discarding real resized images...
2007-07-15 18:20:24 UTC in Comical
-
Tried the 2007-01-17 build.
The transfer into CoLinux using slirp is now running at about 6MBytes per second.
The transfer from CoLinux to a remote are still running at approx 500kbyte/s. NASTY.
The Slirp measurements were made to a remote (100BaseT) server. Before as well as this time. The 6MBytes/s is maxing out the remote server (it's an old machine).
So I've relocated to a better...
2007-02-03 16:01:57 UTC in Cooperative Linux
-
Well, it seems I can no longer reproduce this, and nothing's changed; except everything. Upgrade debian sarge to etch, upgrade kernel to 2.6.18, different X driver.
About the only thing that's the same is the rdesktop binary file (dated 2006-11-30)
Sorry, I can't even say which upgrade "fixed" the problem.
2007-01-25 21:02:15 UTC in rdesktop
-
The performance of the slirp interface has improved however it's still very slow compared to the TAP interface.
On my machine:
TAP32: localhost colinux approx 6..10MBytes/s
This is reasonable but not really anywhere near the disk limit, processor usage is high but there appears to be some headroom.
SLIRP: To Colinux 3MByte/s, this is OK but isn't limited by anything obvious...
2007-01-15 18:09:53 UTC in Cooperative Linux
-
Remote server is Win2k3
Does NOT happen with vsn 1.4.1
Does happen with vsn 1.5.0
Rdesktop locks up completely; must be killed
Normally happens within a few moments of connection (seconds at most) if the connection survives that period it doesn't crash.
Connection is remote (internet) through an OpenVPN (or two).
Happens with different remote hosts.
Localhost is Debian 3.1.
2006-11-30 21:04:48 UTC in rdesktop
-
The attached patch allows rdesktop to change the name
of the pstcache file if the default one is currently in
use.
In addition I've added a '-i' option to alter the name
of the pstcache file so that each remote host has an
independent cache file.
The first change allows you to gain most of the
performance for a combined persistant cache without the
locking and coherancy issues. The...
2006-10-15 12:00:09 UTC in rdesktop
-
if you give it /? it says almost nothing.
It does not, however, accept the /passive /q /norestart
that it's given in winxpsp2-updates.bat.
I've just done a little test and it appears that it
doesn't like /passive ...
2006-10-07 18:35:08 UTC in Unattended, A Windows deployment system
