Three months ago I purchased a new GPU to replace a non-UEFI capable GTX560 Ti
(MSI). The
choice was the MSI GTX 960 Gaming 4G. Apart from the part, that this GPU
doesn't show the
performance boost on FreeBSD CURRENT, even with the most recent BLOB from
nVidia, 367.18,
I realized that after the
On 03/06/2016 17:23, Bob Eager wrote:
> Why not just use odd numbered releases? That's what I do. They have a
> longer support cycle.
Remember though that this model is changing with 11.0 release. With the
new model, it's the 11.x family as a whole that has the long term
support and individual re
On 04/06/2016 13:45, Matthew Seaman wrote:
On 03/06/2016 17:23, Bob Eager wrote:
Why not just use odd numbered releases? That's what I do. They have a
longer support cycle.
Remember though that this model is changing with 11.0 release. With the
new model, it's the 11.x family as a whole that
On 06/03/16 10:53, Lowell Gilbert wrote:
Patrick Powell writes:
Suppose that you have a portA which is a dependency of a lot of other ports.
You also have a portB which is a replacement/update/upgrade for portA.
PortB provides replacements for the executables generated/supplied by
PortA but
On 04/06/2016 14:50, Grzegorz Junka wrote:
>
> On 04/06/2016 13:45, Matthew Seaman wrote:
>> On 03/06/2016 17:23, Bob Eager wrote:
>>> Why not just use odd numbered releases? That's what I do. They have a
>>> longer support cycle.
>> Remember though that this model is changing with 11.0 release.
On 06/04/16 09:24, Matthew Seaman wrote:
On 04/06/2016 14:50, Grzegorz Junka wrote:
On 04/06/2016 13:45, Matthew Seaman wrote:
On 03/06/2016 17:23, Bob Eager wrote:
Why not just use odd numbered releases? That's what I do. They have a
longer support cycle.
Remember though that this model is c
On 2016/06/04 16:14, William A. Mahaffey III wrote:
> One point of order if I may: It was stated earlier in the thread that
> binary compatibility throughout a major release cycle (X.n-R, as 'n'
> varies) is a specification. That is not explicitly addressed in the
> above URL's, as far as I can see
On Sat, Jun 04, 2016 at 06:20:24PM +0100, Matthew Seaman wrote:
> On 2016/06/04 16:14, William A. Mahaffey III wrote:
> > One point of order if I may: It was stated earlier in the thread that
> > binary compatibility throughout a major release cycle (X.n-R, as 'n'
> > varies) is a specification. Th
On 06/ 3/16 08:17 AM, Franco Fichtner wrote:
> Hi there,
>
>> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need
>> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you
On 06/ 3/16 08:17 AM, Franco Fichtner wrote:
> Hi there,
>
>> On 01 Jun 2016, at 2:12 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> There is a main difference - if you upgraded from 9.2 to 9.3, you don't need
>> to recompile (reinstall) all ports, but if you upgraded from 9.3 to 10.x you
Hello Facter FreeBSD maintainers!
Since Facter's move to a C/C++ codebase, a lot of facts have gone missing
on FreeBSD machines. As a dabbler in FreeBSD I want to help fix this! :)
I've opened a ticket to track it here (
https://tickets.puppetlabs.com/browse/FACT-1428) and I've been working on
ge
Hi!
> Since Facter's move to a C/C++ codebase, a lot of facts have gone missing
> on FreeBSD machines. As a dabbler in FreeBSD I want to help fix this! :)
Very nice! I'm no puppet or facter user, but I can probably help
with the ports part.
Can you explain the state of factor for us ? We have 3.
Hi,
I submitted a new patch for math/R 3.3.0 (
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207425). Could someone
please take look at it?
Thanks a lot!
2016-05-22 22:31 GMT+02:00 Fernando Herrero Carrón :
>
> El 22 may. 2016 11:59 a. m., "Kurt Jaeger" escribió:
> >
> > Hi!
> >
> > > > Ig
13 matches
Mail list logo