I recently purchased 3 Noctua NF-S12 fans, two of the 1200 rpm variety, and one of the 800 rpm variety. I very much like the reduction in volume. If I put my ear within a foot of the 1200s, I can hear a slight clicking sound. Any further away, and I hear a gentle whoosh of air passing through.
After listening to the NF-S12-1200s, I wondered how the NF-S12-800 compared. The clicking is a little more quiet, but not by much. The main difference is that the airflow is less audible, which is to be expected, considering that it pushes less air.
Also, if you add the Ultra Low Noise Adapter to the 1200s, they seem to be almost identical to the 800s, perhaps pushing a little less air. If I were to make the purchase again, I would just buy the 1200s, and if necessary, use an ULNA to mimic the performance of an 800.
The NF-S12s are quiet enough that, if I had the option, I might buy an NF-S12 that ran at 1400 rpm, and use the UNLA if I wanted anything quieter. I’m pretty sure that Noctua chose 1200 rpm for a reason, though.
From my last explorations, I summarize:
cat /dev/input/device | hexdump, where device is the device listed if you do
ls -l /dev/input/by-id/, to see exactly what data your usb input devices (mice, possibly keyboards) are sending.
To skip the formatting, you can use a nice feature of hexdump to format things for you. Try this:
# cat /dev/input/event3 | hexdump -e '12/2 "%04x "' -e '"\n"'
Formatting may not be perfect, but you should be able to get it to work. I much prefer the realtime display.
If you want to decipher the output, look at my overview in the previous post.
As an aside, /dev/input/mouse1 exists, but it seems to filter out keypresses, while the raw event file does not.
I don’t know that I will have time to continue this anytime in the near future. Although I haven’t fixed my side-scrolling, I’m fine with things as they are for now.
Campus Plaza, at BYU, currently has one of the worst network setups I have seen.
I’m getting 1% packet while restricted to the wireless, but if I go past the router, I get anywhere from 2-50% packet loss. After pinging google 20000 times (on two separate days), I have had an average of 3% packet loss and an average of 19% packet loss, respectively.
Suffice it to say, I am not well pleased.
Also, I don’t need your firewall. Your closing of port 22 is a bit of a bother. Please, just plug me in to the internet, and let me protect myself.
David Young suggested that I talk to the JESS guys, as implementing backward chaining on top of our existing data structure (a Rete network) could be quite convenient.
They turned me down, which is not too surprising, considering that it is licensed commercially. Nevertheless, I’ve found some other sources on implementing backward chaining on a Rete network.
I haven’t read them yet, but they could prove useful.
I’m going to list various types of backward chaining, along with implementations that follow a given type
WAM (Warren’s Abstract Machine)
- most Prologs…
TOAM (Tree-Oriented Abstract Machine)
Specialized (backward and forward chaining on the same structure)
- JESS – Built on top of a Rete network
- CLIPS/R2 – Uses ‘Rete II’, which adds backward chaining and hashed memories
Not sure yet
- Mandarax – contains implementations of 4 inference engines, at least one of which is backward chaining
- Eulersharp – “backward-chaining reasoner enhanced with Euler path detection”