On Wed, 3 Mar 2010 07:35:55 +0100
Pawel Jakub Dawidek wrote:
>> On Tue, Mar 02, 2010 at 08:32:20PM +0100, Dimitry Andric wrote:
>> > On 2010-03-02 09:47, Alexandr Rybalko wrote:
>> > >>>Definiatelly separately, not sure where. There is ongoing discussion
>> > >>>somwhere on importing this algorit
On Wed, 3 Mar 2010 16:01:59 +0800
Adrian Chadd wrote:
>> On 21 February 2010 02:20, Adrian Chadd wrote:
>> > Oh I know that! I'm just saying that I may try lzma'ing the kernel and
>> > rootfs's to see what kind of savings I get over gzip. :)
>>
>> The answer is "whoa". 24 megabyte compressed ke
On 4 March 2010 00:29, Tim Kientzle wrote:
> Interesting question: What is the impact on boot speed?
> It could be a lot faster to load 5MB from disk and
> decompress to a 24MB image than to wait for 24MB from
> disk.
Linear reads from disk are fast. :) Linear reads from the SPI flash
are slowe
On Thu, 4 Mar 2010 17:31:18 +0800
Adrian Chadd wrote:
>> On 4 March 2010 00:29, Tim Kientzle wrote:
>>
>> > Interesting question: What is the impact on boot speed?
>> > It could be a lot faster to load 5MB from disk and
>> > decompress to a 24MB image than to wait for 24MB from
>> > disk.
>>
On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
> Hi,
> I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma),
> in connection with this is an issue best left lzma
> code in the file "geom_ulzma.c" or store lzma library separately. If
> separately, then wher
On Thu, 4 Mar 2010 11:21:59 +0100
Ulf Lilleengen wrote:
>> On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
>> > Hi,
>> > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with
>> > lzma), in connection with this is an issue best left
>> > lzma code in the file "ge
Hello
I noticed the following on the FreeBSD website:
http://www.freebsd.org/projects/ideas/ideas.html#p-autoreport Has
there been any progress/work done on the automated kernel crash
reporting system? The current ways of enabling and gathering the
information required by developers for investigat
On Thu, 4 Mar 2010 07:09, dan.naumov@ wrote:
Hello
I noticed the following on the FreeBSD website:
http://www.freebsd.org/projects/ideas/ideas.html#p-autoreport Has
there been any progress/work done on the automated kernel crash
reporting system? The current ways of enabling and gathering the
i
On Thu, 4 Mar 2010 08:06:50 -0500
jhell wrote:
>
> On Thu, 4 Mar 2010 07:09, dan.naumov@ wrote:
> > Hello
> >
> > I noticed the following on the FreeBSD website:
> > http://www.freebsd.org/projects/ideas/ideas.html#p-autoreport Has
> > there been any progress/work done on the automated kernel cr
Hi Dan,
Automatic reporting would end up being a mess given that panics can be caused
by hardware problems. Having an autoreport check if memtest was run before it
reports, or having it only run with -CURRENTmight be useful.
Sean
From: jhell
To: Dan Naumov
On Thu, Mar 04, 2010 at 12:17:05PM +0200, Alexandr Rybalko wrote:
> LZMA compression optimized for fast decompression.
It is still measurable slower than gzip and it is certainly not free.
Most hard disks have linear read times >> 10 MB/s but the decompression
can easily need half a second even on
On Thu, 4 Mar 2010 15:28:19 +0100
Joerg Sonnenberger wrote:
>> On Thu, Mar 04, 2010 at 12:17:05PM +0200, Alexandr Rybalko wrote:
>> > LZMA compression optimized for fast decompression.
>>
>> It is still measurable slower than gzip and it is certainly not free.
>> Most hard disks have linear read
On 2010-03-04 15:28, Joerg Sonnenberger wrote:
It is still measurable slower than gzip and it is certainly not free.
Ehm, the LZMA SDK is in the public domain, how much more "free" would
you want it?
___
freebsd-hackers@freebsd.org mailing list
http:/
On Thu, Mar 04, 2010 at 03:54:05PM +0100, Dimitry Andric wrote:
> On 2010-03-04 15:28, Joerg Sonnenberger wrote:
> >It is still measurable slower than gzip and it is certainly not free.
>
> Ehm, the LZMA SDK is in the public domain, how much more "free" would
> you want it?
Free as in "time it ta
On Thu, Mar 04, 2010 at 04:38:31PM +0200, Alexandr Rybalko wrote:
> On Thu, 4 Mar 2010 15:28:19 +0100
> Joerg Sonnenberger wrote:
>
> >> On Thu, Mar 04, 2010 at 12:17:05PM +0200, Alexandr Rybalko wrote:
> >> > LZMA compression optimized for fast decompression.
> >>
> >> It is still measurable sl
In message: <20100304102158.ga8...@nobby.geeknest.org>
Ulf Lilleengen writes:
: On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
: > Hi,
: > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma),
in connection with this is an issue best left lzma
So, anyway...
Is there any resolution for this problem?
I have quite a few packages I'd like to get built (just "custom"
enough that pre-built packages from FreeBSD mirrors won't suffice).
I have to admit to not being convinced that nullfs is at the root
of the problem... I have vague, confused
For reasons that may well be idiosyncratic, I like to set up FreeBSD
machines to have at least 2 bootable slices -- e.g., one can act as a
fallback if an attempted software upgrade proves to have been ill-timed.
In the past, I've done this manually; while a bit tedious & fairly
"target-rich" with
hi there,
because i'm doing a lot of debugging lately i thought it might be a good idea
to build world (in addition to the kernel) with debugging symbols. what i've
done is add
CFLAGS+= -O2 -fno-strict-aliasing -pipe -g
to /etc/src.conf, because having -g in CFLAGS in /etc/make.conf would also
b
On 2010-02-28, Jaakko Heinonen wrote:
> > > http://people.freebsd.org/~jh/patches/lookup-root.diff
I have updated the patch taking some of bde's comments into account. The
new version also includes updates for namei(9) manual page.
The patch is attached to this mail and also found at:
20 matches
Mail list logo
