> Just my 2 cents: If you're on linux look at the file rw permissions,
> especially for I/O-interfaces like ttyS0, ttyS1, etc. In Fedora they
> have only root write permissions.
> Joep
Well as far as I know I'm not writing to anything except the log file, and the
daemon is running as root anyway
A.J. Venter wrote:
Any idea where I should start looking ?
Just a shot into the dark: maybe you start yout deamon, before your
local timezone is set up?
Does it change anything, when you move your bootscript to a higher
position in rc.x, e.g. make it S99whatever?
Good theory, but m
> > Any idea where I should start looking ?
>
> Just a shot into the dark: maybe you start yout deamon, before your
> local timezone is set up?
>
> Does it change anything, when you move your bootscript to a higher
> position in rc.x, e.g. make it S99whatever?
Good theory, but my daemon is very nea
Am Donnerstag, 1. Juni 2006 22:40 schrieb A.J. Venter:
> Hi all,
> I have written a daemon as part of a project (I used the daemon.pp
> example as a skeleton), it's working quite perfectly if you start it
> from the commandline, including from the bootscript I wrote.
>
> But when started at boottim
Hi all,
I have written a daemon as part of a project (I used the daemon.pp example as
a skeleton), it's working quite perfectly if you start it from the
commandline, including from the bootscript I wrote.
But when started at boottime it doesn't operate correctly anymore.
The timer still counts
Michael Van Canneyt wrote:
Inno setup (for the windows installer) uses bz2, so that is
already a start :-)
I think the lazarus inno setup installer uses a variant of 7z. But its
compressing time is about 1 MB (compressed) per minute: so 40 minutes
for a 40 MB installer.
Vincent
_
On Thu, 1 Jun 2006, ??? wrote:
To save your time, you should limit your tests to:
It doesn't take much human time.
1. Command-line tools.
Creation of installs is automated.
GUI tools cannot be used in automated builds.
2. Completely cross-platform.
For obvious reas
> To save your time, you should limit your tests to:
It doesn't take much human time.
> 1. Command-line tools.
> Creation of installs is automated.
> GUI tools cannot be used in automated builds.
> 2. Completely cross-platform.
> For obvious reasons.
> 3. Completely Open source.
>
On Thu, 1 Jun 2006, ??? wrote:
Correction: Rar produced 212 Mb on OO 2.0.2 sources, but using "force text
compression" makes it produce 206 Mb with not really big time overhead.
Then try one of the last compressors as PAQ8, your OO 2.0.2
sources will take days in compress, but
Correction: Rar produced 212 Mb on OO 2.0.2 sources, but using "force text
compression" makes it produce 206 Mb with not really big time overhead.
> Then try one of the last compressors as PAQ8, your OO 2.0.2
> sources will take days in compress, but i think you can get 140-150
> MB or even le
I tried to benchmark a little. Archivers were limited to 512 Mb.
Timings only in the second test. Precision is kept 1 Mb/10 seconds
intentionally.
There are many comprehensive benchmarks, but I tested nearly the
last versions.
OpenOffice 2.0.2 sources, 1209 Mb (there are several .gz and
11 matches
Mail list logo
