So my brother asked me if I could cross a camera magmount with my gorillapod, and I've been considering how to do that.
The tricky part is replacing a gorillapod foot with a magnet. My current though is to take the existing foot off the link chain, put the head of a bolt in the recess left behind, and secure the bolt by filling the recess with some sort of ceramic or plaster. Then I'd screw on one of these.
The only thing I really don't like about it is that, compared to my existing magmount, which uses one of these rubber feet, the magnetized gorillapod is going to be hell on surfaces I attach it to; K&J doesn't make the rubber feet for the right size of magnet, and I definitely don't need the 75lb of surface force provided by their 32mm mounting magnets, which is the smallest size they offer the rubber feet for. (I use one of those 32mm magnets as the basis to my existing magmount, and that's more than enough to keep my camera affixed to the top of my car while driving down the freeway. (By the way; the reactions you get from people when you start drivingdown the road with what looks like a DSLR on top of your camera can be hilarious; the magmount is low profile enough to not be obvious. I should paint the camera orange/black or something so people get the idea that it's supposed to be there.) So I've got two things to resolve before I build it. First, how to make plaster (or some better material equally as cheap to get/make/use.) Second, How to put a protective coating on the magnets so they don't scratch painted surfaces.
Monday, March 8, 2010
The problem I see with IPETEE
So I just stumbled across this article. It's funny, cause I gave it some thought a few months ago, and there are a few problems with end-to-end encryption as a means of concealment.
First, activity indicates activity. So you connect to a tracker that manages prohibited data. Prohibited how? Doesn't matter. Whether encrypted or not, you have a connection between you and a server managing prohibited data.
Ok, fine. You jump that hurdle by using something like Tor.
Second, there's more than just data, there's metadata. So you don't know what exactly is in a TCP or UDP stream, but you can learn things about it, just the same. What do you know about the packet size? Time between packets? Is a constant data rate maintained? How long does the connection last? Certain types of traffic aren't bandwidth-sensitive, but rather latency-sensitive. VOIP is going to have a distinct pattern. Torrenting is going to have a specific pattern. It's techniques like these that allow forensic specialists to detect hidden TrueCrypt volumes.
Third, encryption doesn't eliminate the data, it just obscures it, and not perfectly. Even aside from the possibility of cracking the encryption key, it's possible to guesstimate what kind of data an encrypted bitstream represents. I've read of that being used on encrypted hard drives, for example.
First, activity indicates activity. So you connect to a tracker that manages prohibited data. Prohibited how? Doesn't matter. Whether encrypted or not, you have a connection between you and a server managing prohibited data.
Ok, fine. You jump that hurdle by using something like Tor.
Second, there's more than just data, there's metadata. So you don't know what exactly is in a TCP or UDP stream, but you can learn things about it, just the same. What do you know about the packet size? Time between packets? Is a constant data rate maintained? How long does the connection last? Certain types of traffic aren't bandwidth-sensitive, but rather latency-sensitive. VOIP is going to have a distinct pattern. Torrenting is going to have a specific pattern. It's techniques like these that allow forensic specialists to detect hidden TrueCrypt volumes.
Third, encryption doesn't eliminate the data, it just obscures it, and not perfectly. Even aside from the possibility of cracking the encryption key, it's possible to guesstimate what kind of data an encrypted bitstream represents. I've read of that being used on encrypted hard drives, for example.
Thursday, March 4, 2010
Ground drove my computer loopy.
So I've spent the last seven hours trying to get my desktop to boot something, anything, that's a full operating system. For much of the time, the system was hanging randomly between POST and loading the boot sector, and for much of the rest of the time, it was consistently hanging when I tried to load a Linux kernel. I even wound up going so far as to flash my BIOS, because I couldn't think of anything else to try that made any sort of sense.
The flash upgrade had gotten me to the point where I could at least load boot sectors again, and I was able to run memtest off of live CDs, but I couldn't seem to boot into 32-bit or 64-bit Linux, either my installed version or from a couple Xubuntu live CDs.
I was beginning to suspect some sort of weird flash corruption that was preventing me from using graphics card features, or possibly from switching to protected mode or x64 mode. (I don't know how memtest86+ works, as far as accessing all 8GB of my RAM. I'm pretty sure the BIOS is still in Real mode when it runs its initial sweep, but maybe it's bouncing back and forth between Real and Protected during POST.)
The thought of another outlay to continue having a nice computer at home was not appealing.
Finally, a few minutes ago, I realized something. I had two relatively new pieces of hardware attached to the computer: An APC UPS and a powered USB hub. I disconnected the USB connection between the UPS and the computer, and disconnected the hub, and rebooted the computer. The 32-bit Xubuntu live CD came right up. Huh. Reboot, throw in the 64-bit Xubuntu live CD, and *that* came right up. Huh.
I haven't tried booting off my hard disk yet, and I think that'll require some grub command-line magic to deal with device reordering stemming from the BIOS upgrade and CMOS changes. However, I think it's ultimately workable.
What I think happened is that the connection of the UPS and the powered hub to the computer via USB led to a ground loop that was messing with the internals of the USB controller on the motherboard. See, the powered hub isn't plugged into the UPS; it's a fair bit away from the computer, and I'll have to run an extension cord to get the UPS's power to it. As long as the operating system didn't try to do too much with that USB controller, things worked fine. That meant I could get into BIOS and tweak things, and it meant I could get into grub and memtest without too much trouble. Well, sortof. Remember how, before the flash upgrade, the system would hang at a random point between POST and loading the bootloader. I think the flash upgrade may have changed part of how it dealt with the USB controller, with the newer version inadvertently working around some of the ground-loop-induced weirdness.
So, yeah. A little more experience for those weird situations.
The flash upgrade had gotten me to the point where I could at least load boot sectors again, and I was able to run memtest off of live CDs, but I couldn't seem to boot into 32-bit or 64-bit Linux, either my installed version or from a couple Xubuntu live CDs.
I was beginning to suspect some sort of weird flash corruption that was preventing me from using graphics card features, or possibly from switching to protected mode or x64 mode. (I don't know how memtest86+ works, as far as accessing all 8GB of my RAM. I'm pretty sure the BIOS is still in Real mode when it runs its initial sweep, but maybe it's bouncing back and forth between Real and Protected during POST.)
The thought of another outlay to continue having a nice computer at home was not appealing.
Finally, a few minutes ago, I realized something. I had two relatively new pieces of hardware attached to the computer: An APC UPS and a powered USB hub. I disconnected the USB connection between the UPS and the computer, and disconnected the hub, and rebooted the computer. The 32-bit Xubuntu live CD came right up. Huh. Reboot, throw in the 64-bit Xubuntu live CD, and *that* came right up. Huh.
I haven't tried booting off my hard disk yet, and I think that'll require some grub command-line magic to deal with device reordering stemming from the BIOS upgrade and CMOS changes. However, I think it's ultimately workable.
What I think happened is that the connection of the UPS and the powered hub to the computer via USB led to a ground loop that was messing with the internals of the USB controller on the motherboard. See, the powered hub isn't plugged into the UPS; it's a fair bit away from the computer, and I'll have to run an extension cord to get the UPS's power to it. As long as the operating system didn't try to do too much with that USB controller, things worked fine. That meant I could get into BIOS and tweak things, and it meant I could get into grub and memtest without too much trouble. Well, sortof. Remember how, before the flash upgrade, the system would hang at a random point between POST and loading the bootloader. I think the flash upgrade may have changed part of how it dealt with the USB controller, with the newer version inadvertently working around some of the ground-loop-induced weirdness.
So, yeah. A little more experience for those weird situations.
Depth perception and optics
It's often an assumption that two or more vision sources are required for depth perception. That's not strictly true; on one hand, there's simple experience that can teach a monocular person to recognize distances.
On the other hand, there's this idea I had...
*sidetrack*
It stemmed from thinking about image stacking in HDR photos. Image stacking is simply taking several photos of the same object, where the only change between them is a known, measured characteristic of the photograph recording. Typically, in HDR, it's your exposure adjustment, or how much light you demand your camera collect before saving off the frame. Since your camera's sensor can only precisely measure a finite range of light levels, taking several frames where you move that range around allows you to increase the amount of detail you've captured in bright and dark areas.
However, image stacking needn't *only* be done with exposure adjustments. The concept of stacking applies for any variable you can measurably control while observing a scene, and it just happens that exposure adjustment is the most immediately useful setting to vary.
*end sidetrack*
*second sidetrack*
And now a brief bit about aperture width and depth-of-field. A camera's aperture is the hole that allows light to pass through and land on its sensor. It's exactly analogous to your pupil. The larger your pupil, the more light passes through and lands on your retina. The smaller your pupil, the less light lands on your retina.
One weird side effect of optics and aperture size, though, has to do with focusing. With a narrow aperture (such as when you're outside on a bright, snow-covered day), your depth-of-field is very large, meaning that you can see near objects in focus just as well as you can see distant objects, with no additional effort on the part of your lens. (either that of your eye or of your camera) On the other hand, when the aperture is very wide (Indoors, lights off, etc.), the depth of field is very narrow. That means that you (or your camera) need to adjust the configuration of your lens in order to focus on near or distant objects, regardless of whether you have one or two eyes.
All this boils down to one interesting fact: You can know where your field of focus is if you know your aperture size and your lens configuration.
*end second sidetrack*
What all this means is that you could take several images, each with known aperture and lens characteristics, and learn how far away objects in the scene are simply by observing how in-focus each area of your scene for each known field of focus.
So, yes, you could have calculable measured distances to objects in your scene simply by stacking images of that scene where you know the focus range of each of those snaps.
Honestly, though, I think this applies more to machine vision than human vision. It's also probably most useful right now for telescopes.
On the other hand, there's this idea I had...
*sidetrack*
It stemmed from thinking about image stacking in HDR photos. Image stacking is simply taking several photos of the same object, where the only change between them is a known, measured characteristic of the photograph recording. Typically, in HDR, it's your exposure adjustment, or how much light you demand your camera collect before saving off the frame. Since your camera's sensor can only precisely measure a finite range of light levels, taking several frames where you move that range around allows you to increase the amount of detail you've captured in bright and dark areas.
However, image stacking needn't *only* be done with exposure adjustments. The concept of stacking applies for any variable you can measurably control while observing a scene, and it just happens that exposure adjustment is the most immediately useful setting to vary.
*end sidetrack*
*second sidetrack*
And now a brief bit about aperture width and depth-of-field. A camera's aperture is the hole that allows light to pass through and land on its sensor. It's exactly analogous to your pupil. The larger your pupil, the more light passes through and lands on your retina. The smaller your pupil, the less light lands on your retina.
One weird side effect of optics and aperture size, though, has to do with focusing. With a narrow aperture (such as when you're outside on a bright, snow-covered day), your depth-of-field is very large, meaning that you can see near objects in focus just as well as you can see distant objects, with no additional effort on the part of your lens. (either that of your eye or of your camera) On the other hand, when the aperture is very wide (Indoors, lights off, etc.), the depth of field is very narrow. That means that you (or your camera) need to adjust the configuration of your lens in order to focus on near or distant objects, regardless of whether you have one or two eyes.
All this boils down to one interesting fact: You can know where your field of focus is if you know your aperture size and your lens configuration.
*end second sidetrack*
What all this means is that you could take several images, each with known aperture and lens characteristics, and learn how far away objects in the scene are simply by observing how in-focus each area of your scene for each known field of focus.
So, yes, you could have calculable measured distances to objects in your scene simply by stacking images of that scene where you know the focus range of each of those snaps.
Honestly, though, I think this applies more to machine vision than human vision. It's also probably most useful right now for telescopes.
A quick note and idea on fuel efficiency...
...because it's been churning in my head since last Tuesday, and I haven't written it out yet.
When I was driving to South Carolina and back, I discovered I was going 80mph without pushing the car's engine much at all. (The amount of work I was asking the engine to do might have kept me going 55 or 60mph, normally. Maybe 65mph on the average downgrade on I-77.) It took me a while, but I finally came up with a plausible reason this happened.
I had merged onto the freeway, found myself embedded in a large pack of big-rigs semis, hadn't settled into traffic enough to set cruise, and had to move to get out of the way of traffic shifts to let another batch of traffic merge in. I signaled, changed lanes to the left and accelerated--and felt my jaw drop when I saw I was effortlessly going 80mph.
What I think happened was that the sparse pack of semis (and filler of smaller vehicles) spanning three lanes had caused the volume of air covering I-77 to be moving roughly uniform in line with traffic, not too far from the speed of traffic. In effect, the traffic had created its own wind tunnel, and you didn't have to be dangerously close to the back-end of a semi to get a drafting effect.
So what would happen if you took a long stretch of road (such as an under-river or through-mountain tunnel) and set up blowers pushing air in in the direction of traffic flow? Given the reduction in air drag, how much would you save on fuel economy? Would the energy involved in maintaining a 15mph tail wind in dense-traffic areas be greater than the aggregate saved energy in vehicle fuel? How much of an impact on local pollution would it have? By pulling energy from the electrical grid rather than car engines, you can move the atmospheric cost of energy generation away from areas where it could cause health problems. (Places with high pollution due to vehicle emissions might find that useful...)
Anyway, it was an interesting experience, and leads to a lot of interesting questions.
When I was driving to South Carolina and back, I discovered I was going 80mph without pushing the car's engine much at all. (The amount of work I was asking the engine to do might have kept me going 55 or 60mph, normally. Maybe 65mph on the average downgrade on I-77.) It took me a while, but I finally came up with a plausible reason this happened.
I had merged onto the freeway, found myself embedded in a large pack of big-rigs semis, hadn't settled into traffic enough to set cruise, and had to move to get out of the way of traffic shifts to let another batch of traffic merge in. I signaled, changed lanes to the left and accelerated--and felt my jaw drop when I saw I was effortlessly going 80mph.
What I think happened was that the sparse pack of semis (and filler of smaller vehicles) spanning three lanes had caused the volume of air covering I-77 to be moving roughly uniform in line with traffic, not too far from the speed of traffic. In effect, the traffic had created its own wind tunnel, and you didn't have to be dangerously close to the back-end of a semi to get a drafting effect.
So what would happen if you took a long stretch of road (such as an under-river or through-mountain tunnel) and set up blowers pushing air in in the direction of traffic flow? Given the reduction in air drag, how much would you save on fuel economy? Would the energy involved in maintaining a 15mph tail wind in dense-traffic areas be greater than the aggregate saved energy in vehicle fuel? How much of an impact on local pollution would it have? By pulling energy from the electrical grid rather than car engines, you can move the atmospheric cost of energy generation away from areas where it could cause health problems. (Places with high pollution due to vehicle emissions might find that useful...)
Anyway, it was an interesting experience, and leads to a lot of interesting questions.
Wednesday, March 3, 2010
I finally realized why shutter glasses make sense.
A shutter glasses system allows the video source to provide two video channels, one for each eye. That lets you have stereovision, so you get depth perception for whatever you're watching.
So do polarized light systems like IMAX's linearly-polarized glasses, and Real3D's circularly-polarized glasses.
So why do shutter glasses make sense? There's nothing about the concept that limits you to two video channels. You could have four, or eight, or even sixteen, once the technology's chronometric precision increases enough. It's time-division multiplexing for the visual field.
That's going to have major, major implications for video games. No more splitscreen forcing you to have only half or a quarter of your normal visual field; you and your three buddies can each have the full frame to themselves.
It might even give rise to a new form of cinema, one where both the protagonist's and antagonist's stories are told at the same time, but the viewer has to choose which one they're watching.
So do polarized light systems like IMAX's linearly-polarized glasses, and Real3D's circularly-polarized glasses.
So why do shutter glasses make sense? There's nothing about the concept that limits you to two video channels. You could have four, or eight, or even sixteen, once the technology's chronometric precision increases enough. It's time-division multiplexing for the visual field.
That's going to have major, major implications for video games. No more splitscreen forcing you to have only half or a quarter of your normal visual field; you and your three buddies can each have the full frame to themselves.
It might even give rise to a new form of cinema, one where both the protagonist's and antagonist's stories are told at the same time, but the viewer has to choose which one they're watching.
Monday, March 1, 2010
Software vs hardware RAID
There are three common types of RAID implementations: "hardware"(high-end RAID cards), BIOS-level software(low-end RAID cards) and system daemon-level software(such as the md daemon on Linux).
The RAID support that comes built-in with your motherboard is *probably* software RAID implemented in your system BIOS. Most small RAID cards have their functionality implemented in on-card BIOS that gets loaded when the system boots. As with system-software RAID setups like md, these RAID setups consume your system CPU and RAM as they churn to perform the calculations associated with your RAID configuration, including things like ECC and parity calculations.
All of this is best-known as "software" RAID.
The funky thing? "Hardware" RAID is also done in software, albeit software that executes on a dedicated processor on your RAID card. (As opposed to your system CPU.) You upgrade this software whenever you upgrade the firmware on the card.
So here's what I'd like to see...An Open Source hardware RAID card. All it would amount to is a multi-port SATA controller connected to an onboard CPU, passing data back to the host operating system via the PCIe bus.
The firmware would be built by, well, I dunno. The folks who like md, but don't like running it on their core system. The folks who want to play around with experimental RAID configurations and ideas. The folks who want to try putting LVM into "hardware." There are plenty of possibilities.
Put a fallback firmware set on the card, in case of flash upgrade failure, to avoid bricking the thing.
I'd hit that.
The RAID support that comes built-in with your motherboard is *probably* software RAID implemented in your system BIOS. Most small RAID cards have their functionality implemented in on-card BIOS that gets loaded when the system boots. As with system-software RAID setups like md, these RAID setups consume your system CPU and RAM as they churn to perform the calculations associated with your RAID configuration, including things like ECC and parity calculations.
All of this is best-known as "software" RAID.
The funky thing? "Hardware" RAID is also done in software, albeit software that executes on a dedicated processor on your RAID card. (As opposed to your system CPU.) You upgrade this software whenever you upgrade the firmware on the card.
So here's what I'd like to see...An Open Source hardware RAID card. All it would amount to is a multi-port SATA controller connected to an onboard CPU, passing data back to the host operating system via the PCIe bus.
The firmware would be built by, well, I dunno. The folks who like md, but don't like running it on their core system. The folks who want to play around with experimental RAID configurations and ideas. The folks who want to try putting LVM into "hardware." There are plenty of possibilities.
Put a fallback firmware set on the card, in case of flash upgrade failure, to avoid bricking the thing.
I'd hit that.
Subscribe to:
Posts (Atom)