Exhause into the wall cavity? Seems restrictive
on
Computer Room Hot?
·
· Score: 1
After checking out the site, it seems that all you do is drill a 1.5" hole in your wall, screw on a bracket over the hole so the hose can connect easily, and then connect it to the output of your PS fan.
Somehow, I think reducing the output from 80mm down to a 1.5" tube is going to cause air flow restrictions. But then, on top of that, you direct the exhaust into a wall cavity, which is designed not to allow air to pass thru? What if the wall is full of fiberglass insulation, or even worse, blown-in cellulose or that expanding foam stuff?
I would think that a better solution would be something along the lines of a "clothes dryer vent", with a direct connection to the outside (you know, they have the little louvred doors that "blow" open from the exhaust air). Plus, dryer vent pipe is around 4" if I remember correctly, which would have significantly less airflow restriction than a 1.5" tube.
Flex-hose in a variety of sizes is commonly used in work shops all over the place. See for example:
In order to prevent the traffic from even reaching Apache (I know about using SetEnvIf and VirtualHosts to clean up the log files, but the traffic still hits the web server), I'd like to be able to detect requests for default.ida, cmd.exe, etc. and then have those IP addresses automatically added to a WEBVIRUS chain for 'iptables'. It would start with something like this to send any HTTP traffic to the WEBVIRUS chain:
which would insert the offending IP as the first entry in the WEBVIRUS chain. (LOGNDROP is just a rate-limited logging chain). Now the infected machine is effectively black-holed, preventing any further requests from even reaching Apache or the log files.
The tricky part is getting something like the following to work in Apache so it can call 'iptables' to add the offending IP:
"rsync is an open source utility that provides fast incremental file transfer. rsync is freely available under the GNU General Public License."
"Xdelta is released under a BSD-style license" and features a "delta-compression algorithm, including diff- and patch-like utilities. Xdelta uses a fast, linear-time, and linear-space algorithm that works well on both binary and text files." Newer versions support "XDFS", the "Xdelta File System", "making it a reliable solution for delta-compressed file storage".
I'd be very interested in working on a "ZapStation" like device, even if only to control my MP3 collection! The key to success (IMHO) is usability by the average user (read: visitors to the house, the wife, etc.), and to me, that means a nice, crisp user interface/display (especially when connected via S-Video).
The problem is, most S-Video converters that I've seen suck, and do not come close to the quality and clarity of a TiVo or ReplayTV-type interface. These interfaces are crystal clear, colorful, and easy-to-use.
If I could find some way to get a Linux box to display a similar-quality user interface via S-Video, I'd be much more apt to start programming something. Does anybody even know what resolution the TiVo or ReplayTV "renders" the UI at?
Ideally, I'd love something that had an S-Video input as well. Most of the time, the input would just pass directly through to the output. But when necessary (i.e., user starts pushing buttons on the remote or the phone rings), the Linux box could overlay information on top of the existing S-Video signal (such as current song title, caller ID information, etc.). Obviously, this would have to degrade the S-Video signal very little (or not at all) or it would be "unacceptable" to many. If there was no S-Video input signal present, then the output could be some sort of music-visualization screen saver, useful information (what song is currently playing and what song is next, etc.) or just plain "blank".
The new "dongle" version is great, since it doesn't require you to void the warranty on your Palm. But what is the point of "teasing" everybody with the cool new design without a lot of details so others could reproduce it? ("And no, i don't know a cheap source for the parts")
Given the non-standard connector used on the Palm devices, at least the guy could have described how he obtained the parts for his prototype dongle (listed the part number of an existing cable that he hacked or whatever), or listed the Palm connector specs so you could try to search for something that might work. Instead you get a schematic and nothing else to go on. Kind of a bummer.
The one cable I've found that I can see providing the necessary connector for the Palm V series is the programming cable included with the "Palm V Travel Kit". Spending $50 just so you can cut up a perfectly good cable seems a bit steep though...
Has anybody else managed to locate a low-cost source for just the connectors, for either the Palm III or Palm V style cases?
Slashdot Mirror
Somehow, I think reducing the output from 80mm down to a 1.5" tube is going to cause air flow restrictions. But then, on top of that, you direct the exhaust into a wall cavity, which is designed not to allow air to pass thru? What if the wall is full of fiberglass insulation, or even worse, blown-in cellulose or that expanding foam stuff?
I would think that a better solution would be something along the lines of a "clothes dryer vent", with a direct connection to the outside (you know, they have the little louvred doors that "blow" open from the exhaust air). Plus, dryer vent pipe is around 4" if I remember correctly, which would have significantly less airflow restriction than a 1.5" tube.
Flex-hose in a variety of sizes is commonly used in work shops all over the place. See for example:
http://www.oneida-air.com/ductwork/flexhose.htm
I would think using parts available from sites like the above would allow a significantly better "exhaust" system to be home-grown...
iptables -t filter -A INPUT -i ${INET_IFACE} -p tcp --dport http -j WEBVIRUS
The default entry in WEBVIRUS chain would be to jump to the INETIN chain (or ACCEPT if that is what you want) if no matches were found:
iptables -t filter -A WEBVIRUS -j INETIN
Then, if there was some way to have Apache call 'iptables' each time it detected a "virus" hit (this is the part I haven't figure out yet...)
iptables -t filter -I WEBVIRUS -i ${INET_IFACE} -s ${host} -j LOGNDROP
which would insert the offending IP as the first entry in the WEBVIRUS chain. (LOGNDROP is just a rate-limited logging chain). Now the infected machine is effectively black-holed, preventing any further requests from even reaching Apache or the log files.
The tricky part is getting something like the following to work in Apache so it can call 'iptables' to add the offending IP:
RewriteRule ^(/(scripts|msadc|MSADC|./winnt)|.*(default\.ida|[ NX]{30}|c\+dir)) /cgi-bin/webvirus.pl [L,T=a
pplication/x-httpd-cgi]
Anybody have any ideas or seen any solutions that have integrated web-virus detection with iptables filtering?
"rsync is an open source utility that provides fast incremental file transfer. rsync is freely available under the GNU General Public License."
"Xdelta is released under a BSD-style license" and features a "delta-compression algorithm, including diff- and patch-like utilities. Xdelta uses a fast, linear-time, and linear-space algorithm that works well on both binary and text files." Newer versions support "XDFS", the "Xdelta File System", "making it a reliable solution for delta-compressed file storage".
I'd be very interested in working on a "ZapStation" like device, even if only to control my MP3 collection! The key to success (IMHO) is usability by the average user (read: visitors to the house, the wife, etc.), and to me, that means a nice, crisp user interface/display (especially when connected via S-Video).
The problem is, most S-Video converters that I've seen suck, and do not come close to the quality and clarity of a TiVo or ReplayTV-type interface. These interfaces are crystal clear, colorful, and easy-to-use.
If I could find some way to get a Linux box to display a similar-quality user interface via S-Video, I'd be much more apt to start programming something. Does anybody even know what resolution the TiVo or ReplayTV "renders" the UI at?
Ideally, I'd love something that had an S-Video input as well. Most of the time, the input would just pass directly through to the output. But when necessary (i.e., user starts pushing buttons on the remote or the phone rings), the Linux box could overlay information on top of the existing S-Video signal (such as current song title, caller ID information, etc.). Obviously, this would have to degrade the S-Video signal very little (or not at all) or it would be "unacceptable" to many. If there was no S-Video input signal present, then the output could be some sort of music-visualization screen saver, useful information (what song is currently playing and what song is next, etc.) or just plain "blank".
The new "dongle" version is great, since it doesn't require you to void the warranty on your Palm. But what is the point of "teasing" everybody with the cool new design without a lot of details so others could reproduce it? ("And no, i don't know a cheap source for the parts")
Given the non-standard connector used on the Palm devices, at least the guy could have described how he obtained the parts for his prototype dongle (listed the part number of an existing cable that he hacked or whatever), or listed the Palm connector specs so you could try to search for something that might work. Instead you get a schematic and nothing else to go on. Kind of a bummer.
The one cable I've found that I can see providing the necessary connector for the Palm V series is the programming cable included with the "Palm V Travel Kit". Spending $50 just so you can cut up a perfectly good cable seems a bit steep though...
Has anybody else managed to locate a low-cost source for just the connectors, for either the Palm III or Palm V style cases?