Barney Cordoba wrote this message on Wed, Aug 13, 2014 at 14:58 -0700:
> This kind of stupidity really irritates me. The commercial use of FreeBSD is
> the only reason that there is a project, and anyone with 1/2 a brain knows
> that companies with products based on freebsd can't just upgrade the
Barney,
I think everyone on-list understand you’re upset. You’ve made that clear.
However, (and I’ll put my vendor hat on), the project does not exist solely for
the benefit of the companies who choose to use it in their product(s).
Given same, your statement that “the commercial use of FreeB
This kind of stupidity really irritates me. The commercial use of FreeBSD is
the only reason that there is a project, and anyone with 1/2 a brain knows that
companies with products based on freebsd can't just upgrade their tree every
time some geek gets around to writing a patch. Maybe its the r
It's not an either/or. Until last July there was both. Like F'ing Intel isn't
making enough money to pay someone to maintain a FreeBSD version.
On Wednesday, August 13, 2014 2:24 PM, Jim Thompson wrote:
> On Aug 13, 2014, at 8:24, Barney Cordoba via freebsd-net
> wrote:
>
> Negative Pr
Hello list.
(sorry for posting twice, patch seems to be too big to be posted as
attachment).
I've been hacking ipfw for a while and It seems there is something ready
to test/review in projects/ipfw branch.
Main user-visible changes are related to tables:
1) Tables are now identified by nam
Barney Cordoba via freebsd-net wrote this message on Wed, Aug 13, 2014 at 06:24
-0700:
> Ok. It was a lot more convenient when it was a standalone module/tarball so
> you didn't have to surgically extract it from the tree and spend a week
> trying to get it to compile with whatever version you h
> On Aug 13, 2014, at 8:24, Barney Cordoba via freebsd-net
> wrote:
>
> Negative Progress is inevitable.
Many here undoubtedly consider the referenced effort to be the opposite.
Jim
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.or
Hello,
While trying to setup a bridge using if_bridge with a single bce
interface I've hit the following error on 10.0-RELEASE (it doesn't
happen all the times):
NMI ISA 20, EISA ff
NMI ISA 30, EISA ff
NMI ISA 20, EISA ff
NMI ... going to debugger
NMI ... going to debugger
NMI ISA 20, EISA ff
N
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187341
--- Comment #5 from commit-h...@freebsd.org ---
A commit references this bug:
Author: ae
Date: Wed Aug 13 15:48:10 UTC 2014
New revision: 269944
URL: http://svnweb.freebsd.org/changeset/base/269944
Log:
MFC r269306:
Add new rule to s
Ok. It was a lot more convenient when it was a standalone module/tarball so you
didn't have to surgically extract it from the tree and spend a week trying to
get it to compile with whatever version you happened to be running. So if
you're running 9.1 or 9.2 you could still use it seamlessly.
N
The table is sent through an out of band message with a specific head to the
synthetic NIC. The driver on the guest side understands it and treats it as a
update of send table.
Do you mean the host OS put the tx queue selection directly on the receive
packet descriptor? It is a very good idea.
11 matches
Mail list logo
