I noticed that we have a handful of patterns currently ignored in
svn:ignore (at least at the top-level… the lower levels don't appear to be set
in any particular manner):
$ svn propget svn:ignore
_.tinderbox.*
_.amd64.*
_.arm.*
_.i386.*
_.ia64.*
_.mips.*
_.pc98.*
_.powerpc.*
_.sparc64.*
This is a resend as Benjamin Kaduk
dropped the
Yuri
from CC line, & Yuri was the original first poster in thread who
my patch would presumably have helped.
Reference:
> From: Benjamin Kaduk
> Date: Sat, 15 Sep 2012 14:49:41 -0400 (EDT)
> Message-id:
Benjamin Kadu
On 16 September 2012 10:23, Julian H. Stacey wrote:
> This is a resend as Benjamin Kaduk
> dropped the
> Yuri
> from CC line, & Yuri was the original first poster in thread who
> my patch would presumably have helped.
>
> Reference:
>> From: Benjamin Kaduk
>> Date: Sat,
On 15.09.2012 17:22, Julian H. Stacey wrote:
> + When running multi user, you cannot write unless you first run this:
> + .br
> + sysctl kern.geom.debugflags=16
>
> I never submitted it as a send-pr,
> anyone think I should submit it to help save people ?
I don't think this is good idea. Setting
On 16 September 2012 10:11, Garrett Cooper wrote:
> I noticed that we have a handful of patterns currently ignored in
> svn:ignore (at least at the top-level… the lower levels don't appear to be
> set in any particular manner):
>
> $ svn propget svn:ignore
> _.tinderbox.*
> _.amd64.*
> _
Am 16.09.2012 11:41, schrieb Chris Rees:
On 16 September 2012 10:23, Julian H. Stacey wrote:
This is a resend as Benjamin Kaduk
dropped the
Yuri
from CC line, & Yuri was the original first poster in thread who
my patch would presumably have helped.
Reference:
From: Benjamin
I recently came across a number of really interesting research papers about
using erasure coding techniques to store data redundantly across a number
of machines. This was pretty exciting for me because I have been looking
for this kind of technology for a while. Simply replicating our data is way
fdisk may be old, but it's a better utility. Better documented, still
referenced in the FreeBSD handbook...
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-steps.html
The fdisk -p and fdisk -f are vital functionality which are only
reluctantly recognized with the backup and r
On 16.09.2012 23:12, Jeff Anton wrote:
> The whole geom system may be very important and may be the way to move
> forward. But if it is so
> important, it's important to bring forward all the important functionality
> that we know from the
> past, i.e. fdisk and bsdlabel or their real useful equ
9 matches
Mail list logo
