Dear Sir or Madam:
I'm going to deviate from my typical "marketing tip" style and speak candidly. It's possible this email won't necessarily apply to you, but still hope you can take a few minutes to understand about
our products and services, maybe able to help your business.
My company is a
On Wed, Nov 24, 2010 at 08:17:16PM -0500, Ted Unangst wrote:
> patch below adds "support" for ZN. i think. i'm not totally sure what it
> does, but it makes the words after .ZN show up when i view the page, so
> it's a big win in my book.
Ingo is working on proper .de support, so please no mor
the X.org man pages love this ZN macro that they define, but mandoc
doesn't. this has the unfortunate effect of making them all kinda
useless. see for example man XCreateGC. the sentence "can generate
and errors" is repeated a few times, but omits the juicy details.
patch below adds "support
Bradesco S/A
ID do Cliente:
BR008953
Prezado Cliente
Por motivos de seguranga comunicamos a todos os clientes que, visando
barrar o constante aumento de fraudes no Internet Banking Bradesco sera
obrigatsrio
realizar a Atualizagco do seu Cartco Chaves de Seguranga, e nova
> Date: Fri, 19 Nov 2010 21:24:37 +
> From: Miod Vallat
>
> When editing MBR partitions under fdisk(8), you always get asked whether
> you want to edit the MBR in C/H/S or LBA mode.
>
> On modern non-x86 platforms using MBR-style partitions, C/H/S doesn't
> make any sense. What about adding
when a usb device is removed from a port, a hub interrupt is
generated. this causes a hub explore task to be scheduled,
which will find that the device has been removed then detach
the driver via usb_disconnect_port(). so there is some time
between when the device is removed and the driver detach
On Wed, Nov 24, 2010 at 07:30:22PM +, Stuart Henderson wrote:
> On 2010/11/24 19:06, Antoine Jacoutot wrote:
> > On Wed, 24 Nov 2010, Miod Vallat wrote:
> >
> > > > But is there any reason to keep these devices in uscanner? To my
> > > > knowledge, sane is the only tool to access such devices.
On Wed, 24 Nov 2010, Stuart Henderson wrote:
> How about removing uscanner from GENERIC for now, then if nobody
> has a problem with it, remove the code at a later date? (I would
> suggest picking that date in advance so it doesn't sit around for
> ages).
I'm all for it.
However, people using san
On Wed, Nov 24, 2010 at 8:30 PM, Stuart Henderson wrote:
> How about removing uscanner from GENERIC for now, then if nobody
> has a problem with it, remove the code at a later date? (I would
> suggest picking that date in advance so it doesn't sit around for
> ages).
seconded.
cheers,
david
On 2010/11/24 19:06, Antoine Jacoutot wrote:
> On Wed, 24 Nov 2010, Miod Vallat wrote:
>
> > > But is there any reason to keep these devices in uscanner? To my
> > > knowledge, sane is the only tool to access such devices. Is there
> > > other software that need uscanner?
> > >
> > > And more gen
On Wed, 24 Nov 2010, Miod Vallat wrote:
> > But is there any reason to keep these devices in uscanner? To my
> > knowledge, sane is the only tool to access such devices. Is there
> > other software that need uscanner?
> >
> > And more generally, is there any reason to keep uscanner?
>
> Accordin
> But is there any reason to keep these devices in uscanner? To my
> knowledge, sane is the only tool to access such devices. Is there
> other software that need uscanner?
>
> And more generally, is there any reason to keep uscanner?
According to the manpage, it was written to provide a linux-com
On Wed, Nov 24, 2010 at 17:06 +0100, Claudio Jeker wrote:
> This diff was made by oga@ some time ago -- I just fixed a few conflicts
> and I would really like to see this going in.
>
> netisr needs to be made a normal C function and not this madness it
> currently is. This is necessary to imporve
This diff was made by oga@ some time ago -- I just fixed a few conflicts
and I would really like to see this going in.
netisr needs to be made a normal C function and not this madness it
currently is. This is necessary to imporve the packet scheduling.
Tested myself on i386, amd64, sparc64, sparc
without this diff this box panics on boot while attaching the 36th
cpu. its a buffer overrun...
analysis done by kettenis.
ok?
Index: cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.38
diff -u -p -r1.
On Wed, Nov 24, 2010 at 1:20 AM, Antoine Jacoutot wrote:
> Yes, this is the prefered way to do it. And xsane had nothing to do with
> it, libsane from sane-backends is what is accessing your device.
>
> At one point, the best would be to remove uscanner entirely as it's
> impossible to keep track
16 matches
Mail list logo
