> The other extensions mentioned (like the > ARB_vertex_buffer_object and ARB_occlusion_query) > have been extensions to 1.4 for a while now, and > my GeForce FX 5600 supports them already.:)
ARB_vertex_buffer_object, maybe but ARB_occlusion_query is new (though I think it is a direct promotion from NV_occlusion_query)
As been discussed on BugTraq the latest days, this is not a 'general' vunerablility, rather a bug in Microsoft's XMLHTTP component (nomatter what the whitepaper says).
Acctualy, that was the case before DNS was invented. Even my first book on programming for the Internet recommended that you wrote down the ip's of 'important servers' so you could reach them when the DNS servers stopped working...
Maybe so, but all requests should go to a dns-server at AOL which will cache the results. So if all users make a request for a domain in the same top-domain, there should still only be one request to the root-server.
Finally someone who makes a relevant comment. Though I wonder how the 'search from address bar'-feature has affected the number of non-existent queries.
It obviously seems to be a lot of junk traffic, but the only part we can say is bad requests are part 3 and 4 from the chart. Bad spellings must go to the root since there may be such domains!
It would be nice to analyze the 70% repeated or identical queries, probably lots of traffic can be explained for (or else there are a bunch of administrators out there who need a good manual on bind).
I agree that the half-close is part of the TCP standard, but the way I interpret the article an IIS server would send data through it's part of the socket -- which is closed.
To bad I don't have any Micro$oft boxes in my lan, or I would verify this:)
I was surpries by the big difference between the gcc and icc compiler. Sure gcc ain't vectorizing, but there were huge improvements in gcc-3.x, which promised up to 30% faster code if I remember correctly.
Back in gcc-2.95 many optimazions were hard to implement due to portability, but those issues must have been resolved by now. Right?
I've always wondered what all the glibc overhead (compared to f.i. uClibc) does. I've never noticed any functional difference when setting up a initrd image by using uClibc instead of glibc.
I used to run lids and grsecurity, but now I feel that the acl system in grsecurity is more powerful that that in lids.
Grsecurity's non-acl options are awesome. No setup, and almost all programs work as before (execept some programs that nedd stack execution, but that is a piece of cace to fix.)
BUT (and here comes my main point) the acl system (both in grsecurity and form my earlier experience from lids) needs more debugging. LIDS once released a version where you couldn't run (almost) any program because of the LD_LIBRARY flags, and grsecurity give me kernel panic every now and then. No problem on my system, it gives me and excuse for poking in the kernel source, but I would never use the acl on a production system.
On a related note, there is a warning on http://www.kernel.org/pub/linux/kernel/crypto/v2.4/README.WARNING to the effect that encryption might be a bit broken in 2.4 kernels. I guess you better stick with 2.2 for now if you really need loopback crypto filesystems...
Use cryptoapi instead. It's almost like kerneli (but only compiles as modules) and they have a fix (though maybe not the best).
I'm running a mix between the international kernel patch www.kernel.org/pub/linux/kernel/crypto, (accually http://www.kerneli.org but it hasn't been alive for some time now) and crypto api (which is a branch from kerneli.)
Something needs to be done about the block size problem - the solution from cryptoapi doesn't seem "the right way";-)
The best things about kerneli are the possibility to choose between different encryption algorithms and that it's not filesystem dependent. Though I miss the oppertunity to use the encryption algorithms in userspace programs. (Same thing about the digest algorithms, do thay have any function except for enlarging the kernel size?)
I'm currently testing a pam module that mounts kerneli encrypted home directories, release scheduled a few weeks into the future.
Slashdot Mirror
> The other extensions mentioned (like the :)
> ARB_vertex_buffer_object and ARB_occlusion_query)
> have been extensions to 1.4 for a while now, and
> my GeForce FX 5600 supports them already.
ARB_vertex_buffer_object, maybe but ARB_occlusion_query is new (though I think it is a direct promotion from NV_occlusion_query)
If Mozilla can't render svg files (yet), what's up with the --enable-svg and MOZ_INTERNAL_LIBART_LGPL flags upon compilation?
As been discussed on BugTraq the latest days, this is not a 'general' vunerablility, rather a bug in Microsoft's XMLHTTP component (nomatter what the whitepaper says).
References: RE: TRACE used to increase the dangerous of XSS.
Original posting to Bugtraq
Acctualy, that was the case before DNS was invented. Even my first book on programming for the Internet recommended that you wrote down the ip's of 'important servers' so you could reach them when the DNS servers stopped working...
Maybe so, but all requests should go to a dns-server at AOL which will cache the results. So if all users make a request for a domain in the same top-domain, there should still only be one request to the root-server.
Finally someone who makes a relevant comment. Though I wonder how the 'search from address bar'-feature has affected the number of non-existent queries.
It obviously seems to be a lot of junk traffic, but the only part we can say is bad requests are part 3 and 4 from the chart. Bad spellings must go to the root since there may be such domains!
It would be nice to analyze the 70% repeated or identical queries, probably lots of traffic can be explained for (or else there are a bunch of administrators out there who need a good manual on bind).
I agree that the half-close is part of the TCP standard, but the way I interpret the article an IIS server would send data through it's part of the socket -- which is closed.
:)
To bad I don't have any Micro$oft boxes in my lan, or I would verify this
I was surpries by the big difference between the gcc and icc compiler. Sure gcc ain't vectorizing, but there were huge improvements in gcc-3.x, which promised up to 30% faster code if I remember correctly.
Back in gcc-2.95 many optimazions were hard to implement due to portability, but those issues must have been resolved by now. Right?
I've always wondered what all the glibc overhead (compared to f.i. uClibc) does. I've never noticed any functional difference when setting up a initrd image by using uClibc instead of glibc.
I used to run lids and grsecurity, but now I feel that the acl system in grsecurity is more powerful that that in lids.
Grsecurity's non-acl options are awesome. No setup, and almost all programs work as before (execept some programs that nedd stack execution, but that is a piece of cace to fix.)
BUT (and here comes my main point) the acl system (both in grsecurity and form my earlier experience from lids) needs more debugging. LIDS once released a version where you couldn't run (almost) any program because of the LD_LIBRARY flags, and grsecurity give me kernel panic every now and then. No problem on my system, it gives me and excuse for poking in the kernel source, but I would never use the acl on a production system.
Use cryptoapi instead. It's almost like kerneli (but only compiles as modules) and they have a fix (though maybe not the best).
Something needs to be done about the block size problem - the solution from cryptoapi doesn't seem "the right way"
The best things about kerneli are the possibility to choose between different encryption algorithms and that it's not filesystem dependent. Though I miss the oppertunity to use the encryption algorithms in userspace programs. (Same thing about the digest algorithms, do thay have any function except for enlarging the kernel size?)
I'm currently testing a pam module that mounts kerneli encrypted home directories, release scheduled a few weeks into the future.