On Thu, Jun 21, 2012 at 1:29 PM, Dieter BSD wrote:
>> With very very very few exceptions, all analog NTSC broadcasts have
>> been switched to digital, by the FCC mandated deadline of June 12,
>> 2009.
>
> As long as there remain some NTSC broadcasts, there might be some
> that you wish to watch.
On Mon, Dec 19, 2005 at 08:58:41PM +, [EMAIL PROTECTED] wrote:
> I discovered the user "operator" in UNIX , found it in the
> book "Essential System Administration" by AEleen Frisch, and it has
> features that I would like to use. The book says (on page 131) that
> this user exists on s
In the last episode (Dec 19), [EMAIL PROTECTED] said:
> I discovered the user "operator" in UNIX , found it in the
> book "Essential System Administration" by AEleen Frisch, and it has
> features that I would like to use. The book says (on page 131) that
> this user exists on some BSD syste
>> #define DEVICE2SOFTC(device) ((struct dev_softc
>> *)device_get_softc(device))
>>
>> static void dev_intr(void *arg);
>>
>> struct dev_softc {
>> ...
>> int rid_irq;
>> struct resource* res_irq;
>> void *intr_cookie;
>> ...
>> };
>>
>> static int
>> dev_attach(device_t device)
>>
> #define DEVICE2SOFTC(device) ((struct dev_softc
> *)device_get_softc(device))
>
> static void dev_intr(void *arg);
>
> struct dev_softc {
> ...
> int rid_irq;
> struct resource* res_irq;
> void*intr_cookie;
> ...
> };
>
> static int
> dev_attach(device_t device)
> {
> ...
>
>
> How can I get the process_id of a process when I've the
> process_name from within a C program? Also can the command
You could look at the way its done in
"src/usr.bin/killall/killall.c", or read the manual page
for kvm_getprocs(3).
> kill (pid, SIGCONT) be used to restart a dead daemon proces
maya Haddad writes:
> would you help me in writing network LKM under linux kernel 2.4, small examol
> e would be good.
You sent this to a FreeBSD list, you need to find a Linux list instead.
M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED]
On 14-Dec-01 [EMAIL PROTECTED] wrote:
> In a message dated 12/14/01 10:09:20 AM Eastern Standard Time, CB1001 writes:
>
>> Hi,
>>
>> You claim the 3Coms are no good choice for FBSD. I have always been very
>> satisfied
>> with 3Com905B devices.
>> And a quick search did not reveal any majo
In a message dated 12/14/01 10:09:20 AM Eastern Standard Time, CB1001 writes:
> Hi,
>
> You claim the 3Coms are no good choice for FBSD. I have always been very
> satisfied
> with 3Com905B devices.
> And a quick search did not reveal any major problems with the 3com cards.
A "quick search"
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 29, 2001 4:07 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]
>Subject: Re: (no subject)
>
>
>In a message dated 11/29/20
> Just for historical reasons I have a question...
>
> Is Dennis and Elder Troll or was he cast of the fire and brimstone
> of the BSDi dissolution?
Dennis does something along the lines of building wan cards and selling
them for a number of systems, including FreeBSD. The ironic part, of
course
On Wed, Nov 28, 2001 at 11:27:17PM -0500, [EMAIL PROTECTED] wrote:
> Lets face it. If you were going to sit down and design an interface for frame
> relay, multi-protocol support, etc, you'd have to be smoking something pretty
> strong to come up with netgraph. But its free and there is source
* Eric Melville <[EMAIL PROTECTED]> [011129 13:59] wrote:
> > The concept that "netgraph hooks" are a "leg up" on say, ETs drivers that
> > have integrated bandwidth management and prioritization, WAN bridging
> > support, load balancing and a probably 25% performance advantage is a bit
> > ent
hi,
i am butting in the argument half way but...
although i am new to FreeBSD... what i am saying
is...
even if intel's driver is better... i dont care
about
that because... after all, thats their device...
so.. of course they will make the device driver
better
ecause they were the ones who made
> The concept that "netgraph hooks" are a "leg up" on say, ETs drivers that
> have integrated bandwidth management and prioritization, WAN bridging
> support, load balancing and a probably 25% performance advantage is a bit
> entertaining. Unless you need to do some convoluted encapsulation net
On Wed, 28 Nov 2001 [EMAIL PROTECTED] wrote:
> >As I mentioned above, we CAN license the driver code and the DDK for
> >development. This means that you could produce FreeBSD drivers which we
> >could then distribute in a binary form under a free end-user license.
> >
>
> >Frankly this is the
On Wed, Nov 28, 2001 at 11:27:17PM -0500, [EMAIL PROTECTED] wrote:
>
> The concept that "netgraph hooks" are a "leg up" on say, ETs drivers that
> have integrated bandwidth management and prioritization, WAN bridging
> support, load balancing and a probably 25% performance advantage is a bit
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of
>[EMAIL PROTECTED]
>Sent: Wednesday, November 28, 2001 8:27 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: (no subject)
>
>
>The concept that "netgraph hooks" are a "leg up"
18 matches
Mail list logo