TB --- 2012-03-31 01:00:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-31 01:00:00 - starting HEAD tinderbox run for i386/i386
TB --- 2012-03-31 01:00:00 - cleaning the object tree
TB --- 2012-03-31 01:00:00 - cvsupping the source tree
TB --- 2012-03-31 01:00:00 - /usr/bin/c
Am 30.03.2012 21:36, schrieb Adrian Chadd:
> Let me tell you a story.
>
> Someone decided that ext4 could have a decent speed up if it
> implemented the posix standard for not flushing files on close().
> After all, if you needed it to be guaranteed to be written to disk,
> you would call a flush
Am 29.03.2012 22:52, schrieb Eric van Gyzen:
> Respectfully, no. The default is to store /tmp in UFS, either in its
> own partition (with Auto Defaults) or in / (if no partition was created
> for it), and to refrain from clearing it at boot. Thus, although /tmp
> is not guaranteed to persist in
Hello Alexander Motin,
> Could you collect more information about what's exactly happens
> with the device? Can you execute some camcontrol inquiry or
> camcontrol readcap commands after kernel misdetected size with
> "READ CAPACITY(16)"?
>
> If yes (device is still alive), could you run these
TB --- 2012-03-31 03:13:01 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-31 03:13:01 - starting HEAD tinderbox run for ia64/ia64
TB --- 2012-03-31 03:13:01 - cleaning the object tree
TB --- 2012-03-31 03:13:01 - cvsupping the source tree
TB --- 2012-03-31 03:13:01 - /usr/bin/c
TB --- 2012-03-31 03:14:16 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-31 03:14:16 - starting HEAD tinderbox run for mips/mips
TB --- 2012-03-31 03:14:16 - cleaning the object tree
TB --- 2012-03-31 03:15:05 - cvsupping the source tree
TB --- 2012-03-31 03:15:05 - /usr/bin/c
TB --- 2012-03-31 01:00:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-31 01:00:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2012-03-31 01:00:00 - cleaning the object tree
TB --- 2012-03-31 01:00:00 - cvsupping the source tree
TB --- 2012-03-31 01:00:00 - /usr/bin/c
gmail.com> writes:
> ...
> > One of those reasons people stick/stuck with BSD is that we don't go
> > and change this stuff so quickly.
>
> Yes, it would be a total of ~20 years before we finally decided to switch to
> using TMPFS for /tmp.
> ...
According to TMPFS(5)
"BUGS
The tmpfs k
On Fri, 30 Mar 2012, Adrian Chadd wrote:
On 30 March 2012 17:57, wrote:
C. P. Ghost wrote:
Not clearing /tmp on reboot has been
the norm for way too long and it is too late to change now.
We either evolve or be in a stalemate forever.
No, you do it in a sensible, controlled fashion.
Y
On 30 March 2012 17:57, wrote:
> C. P. Ghost wrote:
>>
>> Not clearing /tmp on reboot has been
>> the norm for way too long and it is too late to change now.
>
>
> We either evolve or be in a stalemate forever.
No, you do it in a sensible, controlled fashion.
You make it really easy for people
C. P. Ghost wrote:
Not clearing /tmp on reboot has been
the norm for way too long and it is too late to change now.
We either evolve or be in a stalemate forever.
It's not just POLA, it also involves deleting data of unaware
users, and that should be avoided.
Mounting on a directory (/tmp)
On Fri, Mar 30, 2012 at 01:46:58PM -0400, John Baldwin wrote:
> ...
> You can actually use that on 8 and 9 as well. I think it's a likely a bug
> that it used VM_MEMATTR_UNCACHED in the first place and that it should have
> been using VM_MEMATTR_UNCACHEABLE all along. (Which is why I've renamed
>
On Friday, March 30, 2012 12:41:12 pm David Wolfskill wrote:
> On Fri, Mar 30, 2012 at 12:18:58PM -0400, John Baldwin wrote:
> > ...
> > I've sent an e-mail to the NVIDIA driver author about how best to fix
this.
> > You can just change the driver to use VM_MEMATTR_UNCACHEABLE instead of
> > VM
TB --- 2012-03-30 20:00:26 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-30 20:00:26 - starting HEAD tinderbox run for mips/mips
TB --- 2012-03-30 20:00:26 - cleaning the object tree
TB --- 2012-03-30 20:01:11 - cvsupping the source tree
TB --- 2012-03-30 20:01:11 - /usr/bin/c
On 30 March 2012 12:42, Chris Rees wrote:
>> Guess what ext4 did? :)
>>
>> Don't mis-estimate POLA.
>
> Well, having thought about what this conversation was *really* about,
> I may have unintentionally derailed it a little.
>
> My original intention was to say to Oliver, please, don't be
> disco
On 30 March 2012 19:36, Adrian Chadd wrote:
> On 30 March 2012 10:56, Chris Rees wrote:
>> On 30 March 2012 17:31, C. P. Ghost wrote:
>>> On Fri, Mar 30, 2012 at 3:18 PM, wrote:
> > However, if you always want to use tmpfs instead of stable storage,
> please do not. Some people expec
Let me tell you a story.
Someone decided that ext4 could have a decent speed up if it
implemented the posix standard for not flushing files on close().
After all, if you needed it to be guaranteed to be written to disk,
you would call a flush routine first, before you called close().
So they did
On 03/30/12 11:15, Steve Kargl wrote:
> On Fri, Mar 30, 2012 at 05:56:06PM +, Chris Rees wrote:
>> On 30 March 2012 17:31, C. P. Ghost wrote:
>>> On Fri, Mar 30, 2012 at 3:18 PM, wrote:
>> However, if you always want to use tmpfs instead of stable storage,
> please do not. Some peop
On 03/26/12 02:55, Kaho Toshikazu wrote:
Hello, Andriy Gapon and ML members,
Date: Sun, 25 Mar 2012 13:15:26 +0300
on 25/03/2012 08:02 Kaho Toshikazu said the following:
Hello Andriy Gapon,
Thank you for your comment.
Message-ID:<4f6d9672.4050...@freebsd.org>
Date: Sat, 24 Mar 2012 11
On Fri, Mar 30, 2012 at 05:56:06PM +, Chris Rees wrote:
> On 30 March 2012 17:31, C. P. Ghost wrote:
> > On Fri, Mar 30, 2012 at 3:18 PM, wrote:
> >>> > However, if you always want to use tmpfs instead of stable storage,
> >>> please do not. Some people expect /tmp to be persistent. This i
On 30 March 2012 17:31, C. P. Ghost wrote:
> On Fri, Mar 30, 2012 at 3:18 PM, wrote:
>>> > However, if you always want to use tmpfs instead of stable storage,
>>> please do not. Some people expect /tmp to be persistent. This is why
>>> /etc/defaults/rc.conf has clear_tmp_enable="NO". Changing
On Fri, Mar 30, 2012 at 3:18 PM, wrote:
>> > However, if you always want to use tmpfs instead of stable storage,
>> please do not. Some people expect /tmp to be persistent. This is why
>> /etc/defaults/rc.conf has clear_tmp_enable="NO". Changing this would break
>> the POLA.
>> >
>> This is a
> > > The default should be clear_tmp_enable="YES"
> > > if only to uncover those broken configurations that expect /tmp to be
> > > persistent.
> >
> > If you want to break POLA and make a lot of people angry, sure.
> > Otherwise no.
> >
>
> I would very much like an example of where /tmp is expe
Am 03/30/12 15:50, schrieb O. Hartmann:
> Sorry for the naiv headline.
>
> I run into massive problems on all of my FreeBSD 10.0-CURRENT driven
> boxes. PostgreSQL rejects accessing OpenLDAP via SSL and all clients
> accessing the database and autheticating users via a SSL/TLS secured
> conection
On Fri, Mar 30, 2012 at 12:18:58PM -0400, John Baldwin wrote:
> ...
> I've sent an e-mail to the NVIDIA driver author about how best to fix this.
> You can just change the driver to use VM_MEMATTR_UNCACHEABLE instead of
> VM_MEMATTR_UNCACHED for now.
>
Thanks; I'd need to make it condition
On Thursday, January 12, 2012 4:08:09 pm John Baldwin wrote:
> On Tuesday, January 03, 2012 7:31:59 pm Adrian Connolly wrote:
> > On 2012/01/04, at 0:37, John Baldwin wrote:
> >
> >
> > > On Monday, January 02, 2012 11:39:10 pm aconnoll...@yahoo.co.jp wrote:
> > >> I am running 9.0-RC3 on an Ace
On Friday, March 30, 2012 9:18:33 am David Wolfskill wrote:
> I track stable/8, stable/9, and head on (different slices on) my laptop
> on a daily basis. I share /usr/local among all of these: while I update
> the installed ports on a daily basis, I'm unwilling to do that 3 times
> daily. :-}
>
>
/tmp is used by eaccelerator for its cache. It's not required to persist but
does prevent the need to regenerate everything after a reboot.
Lucas Holt
On Mar 30, 2012, at 10:43 AM, Chris Rees wrote:
> On 30 Mar 2012 14:26, wrote:
>>
However, if you always want to use tmpfs instead of s
Sorry for the naiv headline.
I run into massive problems on all of my FreeBSD 10.0-CURRENT driven
boxes. PostgreSQL rejects accessing OpenLDAP via SSL and all clients
accessing the database and autheticating users via a SSL/TLS secured
conection to OpenLDAP refuse working. This includes some very
O. Hartmann zedat.fu-berlin.de> writes:
>
> Am 03/29/12 18:14, schrieb David Wolfskill:
> > On Thu, Mar 29, 2012 at 04:18:06PM +0200, O. Hartmann wrote:
> >> I was wondering if there are some objections using TMPFS for /tmp and
> >> /var/run.
> >> ...
> ...
> Linux is using TMPFS filesystems a
On 30 Mar 2012 14:26, wrote:
>
> > > However, if you always want to use tmpfs instead of stable storage,
> > please do not. Some people expect /tmp to be persistent. This is why
> > /etc/defaults/rc.conf has clear_tmp_enable="NO". Changing this would
break
> > the POLA.
> > >
> > This is a mist
TB --- 2012-03-30 12:49:45 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-30 12:49:45 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2012-03-30 12:49:45 - cleaning the object tree
TB --- 2012-03-30 12:49:45 - cvsupping the source tree
TB --- 2012-03-30 12:49:45 - /usr
TB --- 2012-03-30 12:46:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-30 12:46:00 - starting HEAD tinderbox run for mips/mips
TB --- 2012-03-30 12:46:01 - cleaning the object tree
TB --- 2012-03-30 12:46:46 - cvsupping the source tree
TB --- 2012-03-30 12:46:46 - /usr/bin/c
On Fri, 2012-03-30 at 06:18 -0700, David Wolfskill wrote:
> I track stable/8, stable/9, and head on (different slices on) my laptop
> on a daily basis. I share /usr/local among all of these: while I update
> the installed ports on a daily basis, I'm unwilling to do that 3 times
> daily. :-}
>
> T
> > However, if you always want to use tmpfs instead of stable storage,
> please do not. Some people expect /tmp to be persistent. This is why
> /etc/defaults/rc.conf has clear_tmp_enable="NO". Changing this would break
> the POLA.
> >
> This is a mistake.
>
> The default should be clear_tmp_en
I track stable/8, stable/9, and head on (different slices on) my laptop
on a daily basis. I share /usr/local among all of these: while I update
the installed ports on a daily basis, I'm unwilling to do that 3 times
daily. :-}
The x11/nvidia-driver port is one, however, that I've found helpful to
On Mar 30, 2012 6:22 AM, "Eric van Gyzen" wrote:
> However, if you always want to use tmpfs instead of stable storage,
please do not. Some people expect /tmp to be persistent. This is why
/etc/defaults/rc.conf has clear_tmp_enable="NO". Changing this would break
the POLA.
>
This is a mistake.
TB --- 2012-03-30 09:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-03-30 09:40:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2012-03-30 09:40:00 - cleaning the object tree
TB --- 2012-03-30 09:40:00 - cvsupping the source tree
TB --- 2012-03-30 09:40:00 - /usr/bin
On Fri, Mar 30, 2012 at 01:12:42PM +0200, Julien Laffaye wrote:
> On 03/30/2012 01:10 PM, Lars Engels wrote:
> > On Fri, Mar 30, 2012 at 11:12:42AM +0200, Baptiste Daroussin wrote:
> >> Hi,
> >>
> >> On behalf of pkgng crew, I'm happy to announce pkg 1.0-beta9
> >>
> > [...]
> >
> >> Please note th
At 20:23 29/03/2012, you wrote:
Ð Thu, 15 Dec 2011 01:02:03 +0100
"O. Hartmann" пиÑеÑ:
> Just read this on
>
> phoronix.com
>
> Is this finally a chance to get GPGPU on FreeBSD natively supported?
>
> nVidia has a binary driver, supporting well their higher end graphics
> cards on FreeBSD
On 03/30/2012 01:10 PM, Lars Engels wrote:
On Fri, Mar 30, 2012 at 11:12:42AM +0200, Baptiste Daroussin wrote:
Hi,
On behalf of pkgng crew, I'm happy to announce pkg 1.0-beta9
[...]
Please note that normally this will be the last beta version,
So we can expect an official package repositor
On Fri, Mar 30, 2012 at 11:12:42AM +0200, Baptiste Daroussin wrote:
> Hi,
>
> On behalf of pkgng crew, I'm happy to announce pkg 1.0-beta9
>
[...]
> Please note that normally this will be the last beta version,
So we can expect an official package repository with the first RC?
pgptOzA777NGx.
A couple of days ago I updated FreeBSD 10.0-CURRENT and deleted old libs
and old files via "make delete-old-XXX" in /usr/src, as I saw that
Kerberos5/Heimdal got an update.
After that, several server/applications didn't work correctly anymore
due to missing, already deleted libraries.
So i recomp
A few messages here:
1. An open apology to Brooks Davis. I already apologized privately; this is
for all others to know such.
2. Whoever complained about me cross posting on the lists, there are
reasons I do such. Java on FreeBSD on the PowerPC platform includes all
mailing lists here and- at times
Baptiste Daroussin wrote:
> * pkg set -o oldorigin:neworigin allow the user to modify the origin of a
> packages (useful for MOVED)
Can such things be tracked automatically?
I.e. will "pkg upgrade" upgrade moved packages?
___
freebsd-current@freebsd.or
At 02:02 15/12/2011, O. Hartmann wrote:
Just read this on
phoronix.com
Is this finally a chance to get GPGPU on FreeBSD natively supported?
nVidia has a binary driver, supporting well their higher end graphics
cards on FreeBSD 64bit natively.
I do not understand much about the compiler itself
Hi,
On behalf of pkgng crew, I'm happy to announce pkg 1.0-beta9
- changes:
* query -f has been replaced by query -F when querying a package (file) for
consistency with pkg info
* fix autoremove recursion
* pkg set -o oldorigin:neworigin allow the user to modify the origin of a
packages (use
47 matches
Mail list logo
