If the content is largely dynamic in nature, it won't get cached as the content providers tend to set pragma: no-cache on the headers and set the expires time in the past to force expiry to ensure fresh content. In the case of a LOT of stuff from Yahoo, Amazon, etc. you're going to find that a couple of pictures may cache, but the rest of the site will not be there for that reason.
It's a squid or similar server that is distinctly seperate from the router itself (A router COULD transparently proxy by being an interception proxy- but that's a lot more complicated and I don't think there's a lot of them about because they tend to be more expensive for some reason...).
If your client browsers are hitting static content sites, then YES, it's VERY effective. If your client browsers are hitting dynamic content sites, it's nowhere near as effective because the playground there is evil and broken. There's not a lot of fully HTTP 1.1 compliant caches out there (a requirement for a server to hint at expiry- needed for dynamic content...) and it's purely evil to set up the hinting for caches to work as intended- so nearly every dynamic content site out there (And that's the majority of the sites the average populace hits) set pragma: no-cache on the headers as well as setting an immediate expire time on the content. Dynamic content sites with average caching engines actually cause a degredation in browsing experience for the users as the caching engine never caches the dynamic content.
IPSEC relies on unencrypted headers to work. This "transparent" proxy is a router hack that re-routes port 80 traffic for everything except the proxy server to the same. IPSEC would get flipped to the proxy and break down since it's not in the IPSEC session.
Most proxies blindly resolve requests on behalf of the requestor because it's not really designed to be a "transparent" proxy- it's a router hack that makes it purportedly transparent. They are designed with the HTTP 1.0 or 1.1 proxy server specification from their respective RFC documents. Because of this, there is a relationship that is specified (i.e. the client browser places all HTTP requests to the cache, which then places the request as if it were the client browser. The client browser doesn't do DNS, etc. in this mode of operation) that is not present and is not assumed to be there with the un-proxied mode of operation.
This IS non-compliant with the RFC- it just "works" when you're using the same DNS server.
The host server can flag content as non-cacheable and the cache, if it's properly HTTP 1.0 or 1.1 compliant will merely relay the page to the requestor without caching it.
Unless they're a large ISP, the only thing the cache is going to buy them a benefit on places that everyone hits that has static content because typically, most caches don't work well with the HTTP 1.1 cache hinting and it's difficult to set up for the HTTP 1.1 cache hinting so they usually send the dynamic content with pragma: no-cache in the headers and set the expires value to expire it immediately from the cache as stale. A cache is a web decellerator and buys NOTHING in the way bandwidth savings like most people think it does.
Amazon, Yahoo, et al. all set pragma: no-cache in the headers for a return request.
And you didn't pay attention, no less: His problem is he's using a different root DNS server than the so-called transparent proxy. Because of this, his browser will resolve and place requests correctly, but because the router is set up to NAT those requests and flip them to the caching proxy server, the request is then re-resolved for a DNS entry, etc. If they're not using the same DNS root, the whole thing breaks down.
...most of the "transparent" proxies for HTTP tend to be router NAT hacks for a seperate caching server that is set up as a typical caching proxy. Since it's really a typical proxy with router tricks, it's operating in the usual proxy mode which then expects the proxy to do all DNS, etc. for the request, not the client.
It would be really contorted to achieve the "right" way, so nobody's bothered to come up with a caching engine that worked in the manner needed to do it truely transparently (Sitting on the router, etc.)
It's usually cached by way of using an MD5 hash of the URL requested as an index in most caching servers (I know, I USED to work with a CDN that used several different tricks and we checked out loads of caching engines shortly before they shut it down, looking for an alternative to Squid). If you use the resolved IP address to place the request and use the HTTP header info only for caching index, you won't get a poisoned cache as you described it because IP address that you got the content from doesn't matter, only the request URL that got you there does.
Now, as to why the "transparent" caches don't work like they should... Anyone that knows something of how they're set up would be able to tell you that there is no easy way to achieve the functionality to get the "correct" way with the typical setup. The typical setup usually involves router tricks to NAT the request such that it looks like a seperate caching server is the webserver for your request and then the caching server places the request accordingly.
Unfortunately, with dynamic content out there, a LOT of pages can't be directly cached (and there's nothing to make them so unless you do like epicRealm attempted to do with a CDN or what they and others are attempting to sell right now with an "app accelerator"- there's no current good protocol to tip the cache off that the content is stale so the content providers flag it as uncacheable...) so a "transparent" proxy is of some limited usefulness- unless you've got more than a couple of people placing requests for the same cacheable content, it inserts this big, fat latency and breaks a lot of things (like the subject of this/. discussion) in the process.
Unless it's truely transparent, being part of the router itself, it's probably more of a nuisance than a help, no matter what the ISP says to the contrary. I'd be finding a new ISP because they're being a little more than clueless.
The moment that you have a customer hook up a device to the Internet, you're in violation of the law. The devices you sell would be in a manner affecting interstate commerce.
No, that's not quite what the law sates, but I'd bet good money that it'd take a damned good lawyer and a LOT of money to take a chance on proving that interpretation's not possible with the law as it's written.
...and I choose not to use them. One serious porting effort by one of the games companies was killed because it "ran" in WineX, never mind that it requires a LOT of machine to run any game well in WINE or WineX. I'm sure there's more to come.
...the people proposing this aren't the companies concerned about security, but rather people with a vested interest in selling you a "solution" to your "problem".
If they were interested in security, they'd be suggesting much less agressive reactive measures (even with such draconian measures, something will slip through and present you with the same woes as without them...) and suggesting more proactive ones.
For a while, they were playing fast and loose with the UDMA spec and produced a line of drives that weren't safe for UDMA use- they'd work, but a lot of them would corrupt data if you operated them in UDMA mode.
...whether or not the 802.11 devices are radiating out of their specified allotment. Realize that they're 55MHz away from the XM Radio allotment.
There's pretty much no way that a properly engineered device that meets requirements would be transmitting in a manner objectionable to a device properly designed reciever with that much bandgap.
----------
To put this in perspective:
An NTSC signal requires 6MHz of signal bandwidth per channel.
The XM allocation is a solid nine NTSC channels worth of bandwidth separated.
Most NTSC televisions can cope with having adjacent channels, etc. with minimal problems- this is with a lot less seperation than we see with the 802.11 stuff.
----------
Why can't Sirius do the same thing with something that is supposed to be more tolerant of noise conditions. It should be much narrower in bandwidth and guardband with the compression, etc.
The FCC, if they're on the ball, are going to ask Sirius why their stuff is so sloppy...
I've got a couple of fans that look suspiciously like this that I'd bought ages ago for replacement fans for 486 fansinks. Nifty little fan, motor at the edges of the blades.
Reading the article Mann sounds to me like he was being a complete jerk. In the first place the prices he puts on his equipment sound rather inflated. Just because you spend $500,000 developing a prototype does not mean that the prototype is worth that amount.
Depends. If it cost that much in equipment and time, YES it is worth that much. If it had something of crucial value to his research or to something like ending world hunger, it'd be worth a hell of a lot more.
The reason September 11th worked out the way it did was that people have been taught to give the nice terrorists what they want when they take over the plane- before then, everyone was under the line of thinking that eventually it will all work out and if you don't provoke the terrorists you're less likely to get hurt/killed in the situation.
Problem is, this was never the case to begin with and people have all been largely lucky up to this point. As it has always been, but people didn't realize it until the 11th was that the moment an agressor takes over a plane/ship/etc. and holds you hostage, your life is forfeit and you must win it back either by your actions or someone else must win it back for you. With this in mind, I do not believe that people will placidly sit still with agressors with knives or even handguns. They can nail a few but they're going to be beaten to a bloody pulp by the rest.
Hell, they checked my laptop case coming and going when I went to Houston from Dallas out of Love field. (Clue: Love Field and Intercontinental both are _small_ airports, usually used for commuter flights in and out of Dallas and Houston- they normally don't rate a hand-held bomb detector unit...)
"Seems that the airport security weren't even aware of what the CMH was."
Like the person in that Washington Post Op-Ed piece, I have serious problems with security people that don't know what the Congressional Medal of Honor is or the difference between a fake and live ammo.
"While you're right that some have been burned by the loss of NaN, I can argue that most haven't. I have the latest (free) copy of the software. It is still extensible with python scripting."
For how much longer is that app going to run for you? It depends on a glibc that eventually will change and break Blender on you. It's dependant on a version of Mesa that may/may not change on you and then break Blender on you. At some point, you're going to be frozen in time on your software unless you move to another application or they open source Blender. Now, that may not be a bad thing in and of itself- it does definitely pose problems for you, some could be bad.
If they can't find one or if someone like Red Hat buys them, then it's possible to see it being open sourced. Yes, I know, not likely, but still a possibility...
They were just kind enough to give out a basic version of a fairly powerful 3D app for free to Linux, *BSD, Windows, Solaris, and Irix users. But, then, this IS Slashdot, afterall.
You need PCI slots for things like video, lan, and sound. If they're all on the motherboard you don't need much in the way of PCI slots.
What's so special is that this doesn't NEED a fansink, consumes a teacupfull of power compared to most other modern machines and weighs in somewhere between the prior generation of hardware and the top-end right now. It's enough for using in offices, etc. and is priced at the pricepoint for just the motherboard cost for the other machines.
Slashdot Mirror
If the content is largely dynamic in nature, it won't get cached as the content providers tend to set pragma: no-cache on the headers and set the expires time in the past to force expiry to ensure fresh content. In the case of a LOT of stuff from Yahoo, Amazon, etc. you're going to find that a couple of pictures may cache, but the rest of the site will not be there for that reason.
It's a squid or similar server that is distinctly seperate from the router itself (A router COULD transparently proxy by being an interception proxy- but that's a lot more complicated and I don't think there's a lot of them about because they tend to be more expensive for some reason...).
If your client browsers are hitting static content sites, then YES, it's VERY effective. If your client browsers are hitting dynamic content sites, it's nowhere near as effective because the playground there is evil and broken. There's not a lot of fully HTTP 1.1 compliant caches out there (a requirement for a server to hint at expiry- needed for dynamic content...) and it's purely evil to set up the hinting for caches to work as intended- so nearly every dynamic content site out there (And that's the majority of the sites the average populace hits) set pragma: no-cache on the headers as well as setting an immediate expire time on the content. Dynamic content sites with average caching engines actually cause a degredation in browsing experience for the users as the caching engine never caches the dynamic content.
IPSEC relies on unencrypted headers to work. This "transparent" proxy is a router hack that re-routes port 80 traffic for everything except the proxy server to the same. IPSEC would get flipped to the proxy and break down since it's not in the IPSEC session.
Most proxies blindly resolve requests on behalf of the requestor because it's not really designed to be a "transparent" proxy- it's a router hack that makes it purportedly transparent. They are designed with the HTTP 1.0 or 1.1 proxy server specification from their respective RFC documents. Because of this, there is a relationship that is specified (i.e. the client browser places all HTTP requests to the cache, which then places the request as if it were the client browser. The client browser doesn't do DNS, etc. in this mode of operation) that is not present and is not assumed to be there with the un-proxied mode of operation.
This IS non-compliant with the RFC- it just "works" when you're using the same DNS server.
The host server can flag content as non-cacheable and the cache, if it's properly HTTP 1.0 or 1.1 compliant will merely relay the page to the requestor without caching it.
Unless they're a large ISP, the only thing the cache is going to buy them a benefit on places that everyone hits that has static content because typically, most caches don't work well with the HTTP 1.1 cache hinting and it's difficult to set up for the HTTP 1.1 cache hinting so they usually send the dynamic content with pragma: no-cache in the headers and set the expires value to expire it immediately from the cache as stale. A cache is a web decellerator and buys NOTHING in the way bandwidth savings like most people think it does.
Amazon, Yahoo, et al. all set pragma: no-cache in the headers for a return request.
And you didn't pay attention, no less: His problem is he's using a different root DNS server than the so-called transparent proxy. Because of this, his browser will resolve and place requests correctly, but because the router is set up to NAT those requests and flip them to the caching proxy server, the request is then re-resolved for a DNS entry, etc. If they're not using the same DNS root, the whole thing breaks down.
...most of the "transparent" proxies for HTTP tend to be router NAT hacks for a seperate caching server that is set up as a typical caching proxy. Since it's really a typical proxy with router tricks, it's operating in the usual proxy mode which then expects the proxy to do all DNS, etc. for the request, not the client.
It would be really contorted to achieve the "right" way, so nobody's bothered to come up with a caching engine that worked in the manner needed to do it truely transparently (Sitting on the router, etc.)
It's usually cached by way of using an MD5 hash of the URL requested as an index in most caching servers (I know, I USED to work with a CDN that used several different tricks and we checked out loads of caching engines shortly before they shut it down, looking for an alternative to Squid). If you use the resolved IP address to place the request and use the HTTP header info only for caching index, you won't get a poisoned cache as you described it because IP address that you got the content from doesn't matter, only the request URL that got you there does.
/. discussion) in the process.
Now, as to why the "transparent" caches don't work like they should... Anyone that knows something of how they're set up would be able to tell you that there is no easy way to achieve the functionality to get the "correct" way with the typical setup. The typical setup usually involves router tricks to NAT the request such that it looks like a seperate caching server is the webserver for your request and then the caching server places the request accordingly.
Unfortunately, with dynamic content out there, a LOT of pages can't be directly cached (and there's nothing to make them so unless you do like epicRealm attempted to do with a CDN or what they and others are attempting to sell right now with an "app accelerator"- there's no current good protocol to tip the cache off that the content is stale so the content providers flag it as uncacheable...) so a "transparent" proxy is of some limited usefulness- unless you've got more than a couple of people placing requests for the same cacheable content, it inserts this big, fat latency and breaks a lot of things (like the subject of this
Unless it's truely transparent, being part of the router itself, it's probably more of a nuisance than a help, no matter what the ISP says to the contrary. I'd be finding a new ISP because they're being a little more than clueless.
The moment that you have a customer hook up a device to the Internet, you're in violation of the law. The devices you sell would be in a manner affecting interstate commerce.
No, that's not quite what the law sates, but I'd bet good money that it'd take a damned good lawyer and a LOT of money to take a chance on proving that interpretation's not possible with the law as it's written.
...and I choose not to use them. One serious porting effort by one of the games companies was killed because it "ran" in WineX, never mind that it requires a LOT of machine to run any game well in WINE or WineX. I'm sure there's more to come.
WINE is a bandaid. It's NOT a solution.
Which may well deserve such treatment.
...the people proposing this aren't the companies concerned about security, but rather people with a vested interest in selling you a "solution" to your "problem".
If they were interested in security, they'd be suggesting much less agressive reactive measures (even with such draconian measures, something will slip through and present you with the same woes as without them...) and suggesting more proactive ones.
For a while, they were playing fast and loose with the UDMA spec and produced a line of drives that weren't safe for UDMA use- they'd work, but a lot of them would corrupt data if you operated them in UDMA mode.
...whether or not the 802.11 devices are radiating out of their specified allotment. Realize that they're 55MHz away from the XM Radio allotment.
There's pretty much no way that a properly engineered device that meets requirements would be transmitting in a manner objectionable to a device properly designed reciever with that much bandgap.
----------
To put this in perspective:
An NTSC signal requires 6MHz of signal bandwidth per channel.
The XM allocation is a solid nine NTSC channels worth of bandwidth separated.
Most NTSC televisions can cope with having adjacent channels, etc. with minimal problems- this is with a lot less seperation than we see with the 802.11 stuff.
----------
Why can't Sirius do the same thing with something that is supposed to be more tolerant of noise conditions. It should be much narrower in bandwidth and guardband with the compression, etc.
The FCC, if they're on the ball, are going to ask Sirius why their stuff is so sloppy...
If it's bad publicity with the main customer segment (namely the crowd with the 802.11b stuff...) then it's bad for them instead of good for them.
I've got a couple of fans that look suspiciously like this that I'd bought ages ago for replacement fans for 486 fansinks. Nifty little fan, motor at the edges of the blades.
Reading the article Mann sounds to me like he was being a complete jerk. In the first place the prices he puts on his equipment sound rather inflated. Just because you spend $500,000 developing a prototype does not mean that the prototype is worth that amount.
Depends. If it cost that much in equipment and time, YES it is worth that much. If it had something of crucial value to his research or to something like ending world hunger, it'd be worth a hell of a lot more.
The reason September 11th worked out the way it did was that people have been taught to give the nice terrorists what they want when they take over the plane- before then, everyone was under the line of thinking that eventually it will all work out and if you don't provoke the terrorists you're less likely to get hurt/killed in the situation.
Problem is, this was never the case to begin with and people have all been largely lucky up to this point. As it has always been, but people didn't realize it until the 11th was that the moment an agressor takes over a plane/ship/etc. and holds you hostage, your life is forfeit and you must win it back either by your actions or someone else must win it back for you. With this in mind, I do not believe that people will placidly sit still with agressors with knives or even handguns. They can nail a few but they're going to be beaten to a bloody pulp by the rest.
Hell, they checked my laptop case coming and going when I went to Houston from Dallas out of Love field. (Clue: Love Field and Intercontinental both are _small_ airports, usually used for commuter flights in and out of Dallas and Houston- they normally don't rate a hand-held bomb detector unit...)
"Seems that the airport security weren't even aware of what the CMH was."
Like the person in that Washington Post Op-Ed piece, I have serious problems with security people that don't know what the Congressional Medal of Honor is or the difference between a fake and live ammo.
"While you're right that some have been burned by the loss of NaN, I can argue that most haven't. I have the latest (free) copy of the software. It is still extensible with python scripting."
For how much longer is that app going to run for you? It depends on a glibc that eventually will change and break Blender on you. It's dependant on a version of Mesa that may/may not change on you and then break Blender on you. At some point, you're going to be frozen in time on your software unless you move to another application or they open source Blender. Now, that may not be a bad thing in and of itself- it does definitely pose problems for you, some could be bad.
If they can't find one or if someone like Red Hat buys them, then it's possible to see it being open sourced. Yes, I know, not likely, but still a possibility...
They were just kind enough to give out a basic version of a fairly powerful 3D app for free to Linux, *BSD, Windows, Solaris, and Irix users. But, then, this IS Slashdot, afterall.
...integration.
You need PCI slots for things like video, lan, and sound. If they're all on the motherboard you don't need much in the way of PCI slots.
What's so special is that this doesn't NEED a fansink, consumes a teacupfull of power compared to most other modern machines and weighs in somewhere between the prior generation of hardware and the top-end right now. It's enough for using in offices, etc. and is priced at the pricepoint for just the motherboard cost for the other machines.