Search Results

Search found 5 results on 1 pages for 'bortzmeyer'.

Page 1/1 | 1 

  • DPMS does not work: the monitor is not switched off

    - by bortzmeyer
    I have a monitor which was properly switched off by my Debian PC when unused. I attached it to another machine and, this times, it is never switched off. In /etc/X11/xorg.conf, I have: Section "Monitor" Identifier "Generic Monitor" Option "DPMS" It is recognized when X11 starts: (II) Loading extension DPMS ... (II) VESA(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display ... (**) Option "dpms" (**) VESA(0): DPMS enabled The operating system is Debian stable "lenny". The graphics card is: 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrate d Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device 2a6f Flags: bus master, fast devsel, latency 0, IRQ 5 Memory at fe900000 (32-bit, non-prefetchable) [size=512K] I/O ports at b080 [size=8] Memory at d0000000 (32-bit, prefetchable) [size=256M] Memory at fe800000 (32-bit, non-prefetchable) [size=1M] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-Capabilities: [d0] Power Management version 2 X11 is: X.Org X Server 1.4.2 Release Date: 11 June 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.2-10.lenny2) Current Operating System: Linux ludwigVII 2.6.26-2-686 #1 SMP Sun Jun 21 04:57:3 8 UTC 2009 i686 Build Date: 08 June 2009 09:12:57AM

    Read the article

  • Using u32 together with extension headers (how to jump over them?)

    - by bortzmeyer
    I'm trying to filter on some parts of the payload, for an IPv6 packet with extension headers (for instance Destination Options). ip6tables works fine with conditions like --proto udp or --dport 109, even when the packet has extension headers. Netfilter clearly knows how to jump over Destination Options to find the UDP header. Now, I would like to use the u32 module to match a byte in the payload (say "I want the third byte of the payload to be 42). If the packet has no extension headers something like --u32 "48&0x0000ff00=0x2800"` (48 = 40 bytes for the IPv6 header + 8 for the UDP header) works fine, If the packet has a Destination Options, it no longer matches. I would like to write a rule that will work whether the packet has Destination Options or not. I do not find a way to tell Netfilter to parse until the UDP header (something that it is able to do, otherwise --dport 109 would not work) then to leave u32 parse the rest. I'm looking for a simple way, otherwise, as BatchyX mentions, I could write a kernel module doing what I want.

    Read the article

  • Thread-local storage segfaults on NetBSD only?

    - by bortzmeyer
    Trying to run a C++ program, I get segmentation faults which appear to be specific to NetBSD. Bert Hubert wrote the simple test program (at the end of this message) and, indeed, it crashes only on NetBSD. % uname -a NetBSD golgoth 5.0.1 NetBSD 5.0.1 (GENERIC) #0: Thu Oct 1 15:46:16 CEST 2009 +stephane@golgoth:/usr/obj/sys/arch/i386/compile/GENERIC i386 % g++ --version g++ (GCC) 4.1.3 20080704 prerelease (NetBSD nb2 20081120) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % gdb thread-local-storage-powerdns GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386--netbsdelf"... (gdb) run Starting program: /home/stephane/Programmation/C++/essais/thread-local-storage-powerdns Program received signal SIGSEGV, Segmentation fault. 0x0804881b in main () at thread-local-storage-powerdns.cc:20 20 t_a = new Bogo('a'); (gdb) On other Unix, it works fine. Is there a known issue in NetBSD with C++ thread-local storage? #include <stdio.h> class Bogo { public: explicit Bogo(char a) { d_a = a; } char d_a; }; __thread Bogo* t_a; int main() { t_a = new Bogo('a'); Bogo* b = t_a; printf("%c\n", b->d_a); }

    Read the article

  • SQL indexes for "not equal" searches

    - by bortzmeyer
    The SQL index allows to find quickly a string which matches my query. Now, I have to search in a big table the strings which do not match. Of course, the normal index does not help and I have to do a slow sequential scan: essais=> \d phone_idx Index "public.phone_idx" Column | Type --------+------ phone | text btree, for table "public.phonespersons" essais=> EXPLAIN SELECT person FROM PhonesPersons WHERE phone = '+33 1234567'; QUERY PLAN ------------------------------------------------------------------------------- Index Scan using phone_idx on phonespersons (cost=0.00..8.41 rows=1 width=4) Index Cond: (phone = '+33 1234567'::text) (2 rows) essais=> EXPLAIN SELECT person FROM PhonesPersons WHERE phone != '+33 1234567'; QUERY PLAN ---------------------------------------------------------------------- Seq Scan on phonespersons (cost=0.00..18621.00 rows=999999 width=4) Filter: (phone <> '+33 1234567'::text) (2 rows) I understand (see Mark Byers' very good explanations) that PostgreSQL can decide not to use an index when it sees that a sequential scan would be faster (for instance if almost all the tuples match). But, here, "not equal" searches are really slower. Any way to make these "is not equal to" searches faster? Here is another example, to address Mark Byers' excellent remarks. The index is used for the '=' query (which returns the vast majority of tuples) but not for the '!=' query: essais=> EXPLAIN ANALYZE SELECT person FROM EmailsPersons WHERE tld(email) = 'fr'; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------ Index Scan using tld_idx on emailspersons (cost=0.25..4010.79 rows=97033 width=4) (actual time=0.137..261.123 rows=97110 loops=1) Index Cond: (tld(email) = 'fr'::text) Total runtime: 444.800 ms (3 rows) essais=> EXPLAIN ANALYZE SELECT person FROM EmailsPersons WHERE tld(email) != 'fr'; QUERY PLAN -------------------------------------------------------------------------------------------------------------------- Seq Scan on emailspersons (cost=0.00..27129.00 rows=2967 width=4) (actual time=1.004..1031.224 rows=2890 loops=1) Filter: (tld(email) <> 'fr'::text) Total runtime: 1037.278 ms (3 rows) DBMS is PostgreSQL 8.3 (but I can upgrade to 8.4).

    Read the article

  • legit emails in junkbox

    - by acidzombie24
    Hey this is actually a reverse question. My personal email ([email protected]) is winding up in many peoples junkbox and I have no idea why. What may the cause be? Is it because it has the word Entrepreneur (and programmer) in my sig? is it because my first name is unique(european like)? Its driving me crazy. I sent out dozens of business emails a month to people I just meet so its actually hurting me much more then others :( -edit- I also want to mention this is non spam. Typically I email people I meet and say hi or to follow up. I was requested by someone to send him an email so I can test something, so I did and he replied to me 10 days later telling me he found it in his junk, like many others have said to me. -edit- bortzmeyer suggested emailing [email protected] I did and here are the results SPF check: pass DomainKeys check: pass DKIM check: pass Sender-ID check: pass SpamAssassin check: ham ---------------------------------------------------------- SpamAssassin check details: ---------------------------------------------------------- SpamAssassin v3.2.5 (2008-06-10) Result: ham (-2.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message

    Read the article

1