Saw a guy getting ready to board the train this morning. His bike had a sticker on it that said "People powered - no oil (wars) required."
Uh huh.
What do you think they use to fill the tank of that locomotive at the front of the train you're about to board? Last I heard, CalTrain hasn't switched to biodiesel.
And even if he were so principled that he decided he would bike all the way to where he was going... Did they use canola oil to grease the chain on that bike?
You want to say that you're taking the train to cut down on our dependence on foreign oil, that's fine. Me? I take the train because I can sit here and blog or watch a movie or whatever instead of having to deal with traffic.
But it's ludicrous to self-righteously claim to be opting completely out of our petroleum-diven lifestyle. Even more so when you do it while boarding a train.
Monday, August 30, 2010
Sunday, August 29, 2010
Power Supplies - The latest irritating technology stumbling block
For the third time in a week, an electronic gizmo in our house has failed in the same way: its low-bid Chinese wall-wart power supply has failed.
A power supply simply needs to take household power and turn it (usually) into either 12 volts or 5 volts DC with somewhere between 500 and, oh, say, 2000 mA of current.
This is a problem that has been solved for well over 50 years now. It's not complicated. It really, really isn't. Even if you throw in the safety requirements of UL it shouldn't cost more than a couple of dollars (when you're talking about buying in bulk). Of course, for the consumer to go out and buy a replacement, it's more like $10-$20 every time one of these damn things blows out. And they seem to last about 2 years.
Really?
Have we become that disposable a society?
The big problem is that when a device dies, the majority of consumers aren't going to be equipped or technically savvy to diagnose the problem and realize that simply replacing the wall-wart is enough. No, they'll run out to the store and buy a new device. And guess what it'll come with!
So I'll start off the hall of shame right now. Here are the devices that I've had to replace the power supply well, well prior to the end of the device's useful life:
HDHomeRun - This is now actually the second time in about 5 years that the wall wart has died. The first time, Silicon Dust had a recall program and replaced it at no cost. Apparently, they replaced it with one that was just as shitty. UPDATE: Silicon Dust says that they switched vendors a couple years ago, and that the first replacement was sent before they did so. They are going to replace the power supply free of charge, and this time using the new vendor's supply that has not been quite so problematic.
Roku - The wall wart for the Netflix player died on us this week. According to the searching I've done, this is something fairly frequent. Roku's FAQ has suggestions for diagnosing power supply failure, and their store has a replacement supply for $10 - both of which suggest that this issue has come up frequently enough for them to prepare a response.
Apple - I bought an AirPort Express from my nephew. It tested fine at his apartment, but when I plugged it in at home, it had failed. And, again, the Internet is alive with reports of these dying and suggested repair strategies. This is a much worse failure, because the power supply is internal to the unit, and it is impossible to non-destructively open the case.
TrendNet - I bought two Gigabit Ethernet switches at Fry's. Both of them experienced power supply failure within a year of purchase.
All of these companies should be ashamed of themselves. There's just no excuse for selling a device with a power supply that doesn't outlive the device by a factor of at least 5.
A power supply simply needs to take household power and turn it (usually) into either 12 volts or 5 volts DC with somewhere between 500 and, oh, say, 2000 mA of current.
This is a problem that has been solved for well over 50 years now. It's not complicated. It really, really isn't. Even if you throw in the safety requirements of UL it shouldn't cost more than a couple of dollars (when you're talking about buying in bulk). Of course, for the consumer to go out and buy a replacement, it's more like $10-$20 every time one of these damn things blows out. And they seem to last about 2 years.
Really?
Have we become that disposable a society?
The big problem is that when a device dies, the majority of consumers aren't going to be equipped or technically savvy to diagnose the problem and realize that simply replacing the wall-wart is enough. No, they'll run out to the store and buy a new device. And guess what it'll come with!
So I'll start off the hall of shame right now. Here are the devices that I've had to replace the power supply well, well prior to the end of the device's useful life:
HDHomeRun - This is now actually the second time in about 5 years that the wall wart has died. The first time, Silicon Dust had a recall program and replaced it at no cost. Apparently, they replaced it with one that was just as shitty. UPDATE: Silicon Dust says that they switched vendors a couple years ago, and that the first replacement was sent before they did so. They are going to replace the power supply free of charge, and this time using the new vendor's supply that has not been quite so problematic.
Roku - The wall wart for the Netflix player died on us this week. According to the searching I've done, this is something fairly frequent. Roku's FAQ has suggestions for diagnosing power supply failure, and their store has a replacement supply for $10 - both of which suggest that this issue has come up frequently enough for them to prepare a response.
Apple - I bought an AirPort Express from my nephew. It tested fine at his apartment, but when I plugged it in at home, it had failed. And, again, the Internet is alive with reports of these dying and suggested repair strategies. This is a much worse failure, because the power supply is internal to the unit, and it is impossible to non-destructively open the case.
TrendNet - I bought two Gigabit Ethernet switches at Fry's. Both of them experienced power supply failure within a year of purchase.
All of these companies should be ashamed of themselves. There's just no excuse for selling a device with a power supply that doesn't outlive the device by a factor of at least 5.
Thursday, August 26, 2010
Key Wrapping with HSMs
Using PKCS11 with JCE means that you can use HSMs to house your private keys, which protects them from theft or misappropriation. And that's a very good thing.
With JCE, you use instances of subclasses of Key to perform cryptographic operations. Keys can be PublicKey, PrivateKey or SecretKey objects. SecretKey objects represent keys to use with a symmetric algorithm, like AES. PublicKey and PrivateKey objects comprise a key pair used for asymmetric algorithms, like RSA.
What PKCS11 does is replace SecretKey and PrivateKey objects with sham objects that represent index numbers into the HSM. When you ask JCE to perform a cryptographic operation with those keys, it instead actually delegates the task to the HSM. The HSM will look up the keys, use them internally, and return the result to you. When done that way, the secret material never leaves the HSM.
But what happens when you have to manage potentially thousands of keys? That's too many to store in the limited storage space of an HSM, and having the HSM root through its storage to find the key you want isn't what it was designed best to do.
No, instead you should use a database to store all of the keys. But the problem is that the database isn't cryptographically protected the same way an HSM is.
The solution is in the Cipher class wrap() and unwrap() methods.
What you do is you establish a SecretKey in your HSM. Give it an alias of "WrappingKey" or something of that sort. If you ask your HSM to generate such a key internally, then it will never be allowed to leave the HSM. That's a good thing. You then generate whatever keys you need and use the Cipher wrap() method to turn the private key material into an encrypted byte array. You can write that byte array to the database with confidence, since there's no use you can make of that byte array without the secret key that was used to encrypt it, which is safely encased in the HSM.
Now what if you want to use it?
You fetch the bytes from the database again and use the same Cipher object to unwrap the key. What you'll get is a PrivateKey. But as we've seen, PrivateKeys that you get from an HSM are just sham objects. You don't actually get to see that PrivateKey - it is merely a reference to the key in the HSM. You then can use the HSM to perform whatever crypto operation you need to do on that key. The HSM doesn't permanently store the unwrapped key - as soon as the sham object gets dereferenced, the PKCS11 module will tell the HSM to throw it away. But done in this way, the unencrypted form of the private key never leaves the HSM, nor does the encryption key that wraps and unwraps it. Your database can be used to keep track of the potentially millions of private keys you need to keep track of, but no human eyes will ever get to see even one of them.
With JCE, you use instances of subclasses of Key to perform cryptographic operations. Keys can be PublicKey, PrivateKey or SecretKey objects. SecretKey objects represent keys to use with a symmetric algorithm, like AES. PublicKey and PrivateKey objects comprise a key pair used for asymmetric algorithms, like RSA.
What PKCS11 does is replace SecretKey and PrivateKey objects with sham objects that represent index numbers into the HSM. When you ask JCE to perform a cryptographic operation with those keys, it instead actually delegates the task to the HSM. The HSM will look up the keys, use them internally, and return the result to you. When done that way, the secret material never leaves the HSM.
But what happens when you have to manage potentially thousands of keys? That's too many to store in the limited storage space of an HSM, and having the HSM root through its storage to find the key you want isn't what it was designed best to do.
No, instead you should use a database to store all of the keys. But the problem is that the database isn't cryptographically protected the same way an HSM is.
The solution is in the Cipher class wrap() and unwrap() methods.
What you do is you establish a SecretKey in your HSM. Give it an alias of "WrappingKey" or something of that sort. If you ask your HSM to generate such a key internally, then it will never be allowed to leave the HSM. That's a good thing. You then generate whatever keys you need and use the Cipher wrap() method to turn the private key material into an encrypted byte array. You can write that byte array to the database with confidence, since there's no use you can make of that byte array without the secret key that was used to encrypt it, which is safely encased in the HSM.
Now what if you want to use it?
You fetch the bytes from the database again and use the same Cipher object to unwrap the key. What you'll get is a PrivateKey. But as we've seen, PrivateKeys that you get from an HSM are just sham objects. You don't actually get to see that PrivateKey - it is merely a reference to the key in the HSM. You then can use the HSM to perform whatever crypto operation you need to do on that key. The HSM doesn't permanently store the unwrapped key - as soon as the sham object gets dereferenced, the PKCS11 module will tell the HSM to throw it away. But done in this way, the unencrypted form of the private key never leaves the HSM, nor does the encryption key that wraps and unwraps it. Your database can be used to keep track of the potentially millions of private keys you need to keep track of, but no human eyes will ever get to see even one of them.
Think ahead, people!
Folks, really now.
If you're in a line for a ticket machine, and there are people behind you, you should take the opportunity you have while waiting to go digging through the Bag of Holding you call a purse to pull out your credit card and have it handy for when you get to the front of the line.
I mean, it can't be a surprise that you're going to use it. Yes, I can see that if you're unfamiliar with the machine, you won't know exactly when or how it will demand your card or cash, but what else is it going to do? Ask for a retinal scan or a DNA sample?
If you're in a line for a ticket machine, and there are people behind you, you should take the opportunity you have while waiting to go digging through the Bag of Holding you call a purse to pull out your credit card and have it handy for when you get to the front of the line.
I mean, it can't be a surprise that you're going to use it. Yes, I can see that if you're unfamiliar with the machine, you won't know exactly when or how it will demand your card or cash, but what else is it going to do? Ask for a retinal scan or a DNA sample?
Wednesday, August 25, 2010
Safety reminder
While I was waiting for the train this morning, I observed a situation which could easily have resulted in someone being killed.
The Northbound #231 train was approaching the Santa Clara station. Because of its design, passengers for Northbound trains must cross the Southbound track in order to board the train. To mitigate this, Caltrain has a "hold-out" rule that forbids more than one train from passing through the station at one time, plus they tell the passengers to always wait on the far platform until the train they intend to board has arrived.
There is a southbound express train that rolls through Santa Clara shortly before the 231 is scheduled to arrive. This morning, it was running late.
So looking to the right from the platform, everyone could plainly see the 231 train approaching to arrival. If you didn't also look to the left, you would not, however, have seen that Southbound express also approaching.
Now, only one train can come through at a time, so the two trains get on the radio and decide who's going to go first. This morning, the 231 decided they would hold-out, probably because the other train was late and wasn't going to stop in any event.
So if you weren't careful, you'd have looked to the right, seen the 231 train approaching, not noticed it was actually stopping short of the station. You then might have stepped onto the Southbound track to cross over to the other platform and disappeared in a puff of pink fog as the Southbound express roared through at 79 mi/hr.
Now, to be fair, CalTrain is actually as we speak retrofitting the station with a tunnel so that no passenger will ever need to set foot on an active railroad track ever again. And 6 or so months from now when they're done, that'll be a good thing. And the construction has actually improved the sight-lines to the North, which is the predominant danger.
But in the meantime, if you use that station, please, please be careful. The rest of us don't need to have our morning commute fouled up by having to wait for the coroner to mop you up. I get to make that joke, because it nearly happened to me.
The Northbound #231 train was approaching the Santa Clara station. Because of its design, passengers for Northbound trains must cross the Southbound track in order to board the train. To mitigate this, Caltrain has a "hold-out" rule that forbids more than one train from passing through the station at one time, plus they tell the passengers to always wait on the far platform until the train they intend to board has arrived.
There is a southbound express train that rolls through Santa Clara shortly before the 231 is scheduled to arrive. This morning, it was running late.
So looking to the right from the platform, everyone could plainly see the 231 train approaching to arrival. If you didn't also look to the left, you would not, however, have seen that Southbound express also approaching.
Now, only one train can come through at a time, so the two trains get on the radio and decide who's going to go first. This morning, the 231 decided they would hold-out, probably because the other train was late and wasn't going to stop in any event.
So if you weren't careful, you'd have looked to the right, seen the 231 train approaching, not noticed it was actually stopping short of the station. You then might have stepped onto the Southbound track to cross over to the other platform and disappeared in a puff of pink fog as the Southbound express roared through at 79 mi/hr.
Now, to be fair, CalTrain is actually as we speak retrofitting the station with a tunnel so that no passenger will ever need to set foot on an active railroad track ever again. And 6 or so months from now when they're done, that'll be a good thing. And the construction has actually improved the sight-lines to the North, which is the predominant danger.
But in the meantime, if you use that station, please, please be careful. The rest of us don't need to have our morning commute fouled up by having to wait for the coroner to mop you up. I get to make that joke, because it nearly happened to me.
Tuesday, August 24, 2010
On grey water duming
Environmentalists are often amusing in the contradictory positions they're willing to take. The latest example is the ban on cruise ships dumping grey water within 3 miles of shore.
At first, that sounds like something that you'd sort of expect to be a bad thing. But then how do you reconcile that with cities being incentivised to use grey water for irrigating parks and other public places? If it's illegal to dump it in Monterey Bay, how ought it to be a good idea to spray it on the lawn at the local public park?
Just to be clear, grey water is not sewage (that is, toilet output). Grey water is water that has been used, but other than for septic reasons. Think water from showers. So if shower water shouldn't be dumped in the bay, then should people be allowed to swim in it?
And is making the cruise ship wait until it's 3 miles offshore significant? If it's dumping while the tide is going in, the tide will carry it right into shore.
Norman, coordinate.
At first, that sounds like something that you'd sort of expect to be a bad thing. But then how do you reconcile that with cities being incentivised to use grey water for irrigating parks and other public places? If it's illegal to dump it in Monterey Bay, how ought it to be a good idea to spray it on the lawn at the local public park?
Just to be clear, grey water is not sewage (that is, toilet output). Grey water is water that has been used, but other than for septic reasons. Think water from showers. So if shower water shouldn't be dumped in the bay, then should people be allowed to swim in it?
And is making the cruise ship wait until it's 3 miles offshore significant? If it's dumping while the tide is going in, the tide will carry it right into shore.
Norman, coordinate.
VTA, CalTrain and Clipper
We're quickly running up against a situation here.
Caltrain has said that we should switch from paper monthly passes to Clipper monthly passes starting in October.
A 2+ zone CalTrain monthly pass gives you local fare credit on VTA busses and light rail. I use this every once in a while to take the #60 bus home from the Santa Clara CalTrain station.
VTA does not yet take Clipper. VTA has yet to issue any statement of any kind as to when they might. There are Clipper terminals installed on every VTA bus I have ridden on this year, so far as I can remember, but they're covered over by plastic "out of order" bags.
I'd be happy if VTA would just come out and say when they expect to remedy this situation.
Caltrain has said that we should switch from paper monthly passes to Clipper monthly passes starting in October.
A 2+ zone CalTrain monthly pass gives you local fare credit on VTA busses and light rail. I use this every once in a while to take the #60 bus home from the Santa Clara CalTrain station.
VTA does not yet take Clipper. VTA has yet to issue any statement of any kind as to when they might. There are Clipper terminals installed on every VTA bus I have ridden on this year, so far as I can remember, but they're covered over by plastic "out of order" bags.
I'd be happy if VTA would just come out and say when they expect to remedy this situation.
Monday, August 23, 2010
Microcell report
The latest rumors about the microcell are that AT&T and Cisco are working on what sounds like a fairly major overhaul. The rumor mill is talking about a hardware upgrade, which would mean AT&T would swap out all of the units deployed so far.
That the problems that we are having with the microcell couldn't be fixed with a simple software update would be astonishing to me. From what I've read from people who have analyzed the pictures of the microcell motherboard in FCC filings, the chipsets being used certainly seem like they'd be capable of handling the workload without any trouble. The only possible problem I could imagine would be that they maybe didn't give the thing enough RAM, since the speculation is that the board is running some sort of Linux variant (specifically, BusyBox) at least at the higher levels.
A lot of the speculation has centered around the upload cap, but that doesn't quite ring true, at least for us, since the problems have always been that we got garbling on the calling party's audio, which has nothing to do with the upload data channel.
But, perhaps, the CPU gets maxed out trying to deal with audio and data at the same time. But then, wouldn't we get bidirectional garbling?
And shame on AT&T for not being more forthcoming about the problem, their plan for fixing it, and the timing of that plan. They've had plenty of time to figure out what's going on. It's one thing to sell an opaque appliance device to your customers and tell them nothing about how it works so long as it actually works. But you can't just sell a box that doesn't work and then just refuse to say anything out loud about what you're going to do.
Apple's "death touch" iPhone 4 antenna problem and the response is a stark contrast. Apple responded in less than a month with their analysis of the problem and their action plan for working around the problem. Their analysis, by their claim at least, is that the problem was/is much less widespread than has been made out, and they've said that anyone who wants one can have a free case.
AT&T, by contrast, has remained silent for months (at least) about this problem, that from all appearances is a show-stopper for huge numbers of people who have bought the device.
Oh, and they tested this thing for almost two years prior to rolling it out.
AT&T, you're making it real, real hard to stay loyal. You really are.
That the problems that we are having with the microcell couldn't be fixed with a simple software update would be astonishing to me. From what I've read from people who have analyzed the pictures of the microcell motherboard in FCC filings, the chipsets being used certainly seem like they'd be capable of handling the workload without any trouble. The only possible problem I could imagine would be that they maybe didn't give the thing enough RAM, since the speculation is that the board is running some sort of Linux variant (specifically, BusyBox) at least at the higher levels.
A lot of the speculation has centered around the upload cap, but that doesn't quite ring true, at least for us, since the problems have always been that we got garbling on the calling party's audio, which has nothing to do with the upload data channel.
But, perhaps, the CPU gets maxed out trying to deal with audio and data at the same time. But then, wouldn't we get bidirectional garbling?
And shame on AT&T for not being more forthcoming about the problem, their plan for fixing it, and the timing of that plan. They've had plenty of time to figure out what's going on. It's one thing to sell an opaque appliance device to your customers and tell them nothing about how it works so long as it actually works. But you can't just sell a box that doesn't work and then just refuse to say anything out loud about what you're going to do.
Apple's "death touch" iPhone 4 antenna problem and the response is a stark contrast. Apple responded in less than a month with their analysis of the problem and their action plan for working around the problem. Their analysis, by their claim at least, is that the problem was/is much less widespread than has been made out, and they've said that anyone who wants one can have a free case.
AT&T, by contrast, has remained silent for months (at least) about this problem, that from all appearances is a show-stopper for huge numbers of people who have bought the device.
Oh, and they tested this thing for almost two years prior to rolling it out.
AT&T, you're making it real, real hard to stay loyal. You really are.
Tuesday, August 17, 2010
Teachable moment
In all of the fussing I've been doing over our Internet connection and the microcell lately, I came to discover that the latency on our connection had suddenly become about 40 ms, where it used to be much, much lower than that.
This happened after I had swapped out the Netopia modem/router combo for a separate Speedstream 5100 modem and a Linksys E1000 router.
I just couldn't believe that a separate PPPoE router would add that sort of latency to the connection. In trying to figure it out, I put an Ethernet switch in between the modem and router so I could conveniently connect a laptop simultaneously up to that segment to talk to the modem to get its current line quality metrics and such.
Well, long story short, over the weekend, our link not only had the high latency but started dropping 3-5% of the packets. That's enough packet loss to make the connection seem like EDGE. It was horrible.
Well, we had AT&T come out to check the line, and the technician reported that when he plugged his own laptop in, he saw the latency (as I did), but the packet loss went away.
Turns out the home-made Ethernet cable I had made to go between the modem and router was bad.
That's the one piece of equipment in the mix that I never tested and assumed was good.
Oops.
The latency, it turns out, was caused by the DSLAM putting us in interleaved mode rather than fast-path. So the tech changed that up. Our first-hop latency when the connection is not being used is now an astonishing 7 milliseconds (from quack).
So big ups to AT&T - at least the part of AT&T that runs our DSL line. The Microcell folks... well, the jury is still out...
This happened after I had swapped out the Netopia modem/router combo for a separate Speedstream 5100 modem and a Linksys E1000 router.
I just couldn't believe that a separate PPPoE router would add that sort of latency to the connection. In trying to figure it out, I put an Ethernet switch in between the modem and router so I could conveniently connect a laptop simultaneously up to that segment to talk to the modem to get its current line quality metrics and such.
Well, long story short, over the weekend, our link not only had the high latency but started dropping 3-5% of the packets. That's enough packet loss to make the connection seem like EDGE. It was horrible.
Well, we had AT&T come out to check the line, and the technician reported that when he plugged his own laptop in, he saw the latency (as I did), but the packet loss went away.
Turns out the home-made Ethernet cable I had made to go between the modem and router was bad.
That's the one piece of equipment in the mix that I never tested and assumed was good.
Oops.
The latency, it turns out, was caused by the DSLAM putting us in interleaved mode rather than fast-path. So the tech changed that up. Our first-hop latency when the connection is not being used is now an astonishing 7 milliseconds (from quack).
So big ups to AT&T - at least the part of AT&T that runs our DSL line. The Microcell folks... well, the jury is still out...
Sunday, August 1, 2010
Apple Wireless Keyboard and Magic Trackpad - Together At Last
Why Apple didn't design this in as an option I'll never understand.
As I explained in my last post, using a Mac Mini as an HTPC hasn't been quite ideal until now. The Magic Trackpad plus the Wireless Keyboard make ideal bedfellows for the mini in the living room... If only they were joined at the hip.....
Achieving this isn't too difficult. The most desirable factor for this is that the two should be as rigidly attached as possible, yet the bond can't be permanent, since you wind up with the power button of the keyboard jammed right against the battery door of the trackpad (or vice versa if you're left-handed). So some sort of Velcro attachment is the best mechanism I could think of. The only trouble is that velcro can shift laterally to some extent. So I went with a 3M product called Dual-Lock. It's like velcro, except that it's genderless and since both sides of it are made of stiff plastic, it tends to be much better at holding still.
I found the stuff at Orchard Supply (Home Depot didn't carry it), in a two-pack of 3"x1" pieces (it's actually a 4-pack - there are four pieces, which makes two complete fasteners). I also bought an 8x10 sheet of .Lexan. I used a hacksaw to make a 6"x3" sheet and attached one strip to each end and two about a half inch apart straddling the middle. I then stuck the mating pieces on, peeled back the adhesive and stuck the keyboard and trackpad on.
So, There! I fixed it!
It's not absolute perfection. With the whole thing in your lap, you notice that there's really nowhere to rest your palms, like there would be on a real laptop. And you have to watch out that your left pinky doesn't accidentally contact the trackpad and skitter your mouse pointer off on a tangent. Also, because of the thickness of the whole thing and its proximity to the bottom of the trackpad, the rubber feet won't ever touch the desk if you set it down. This makes the mechanical buttons in the trackpad useless, unfortunately. But if you don't provide a stiff support for the bottom half of the connection, it won't be as stable as this solution allows.
As I explained in my last post, using a Mac Mini as an HTPC hasn't been quite ideal until now. The Magic Trackpad plus the Wireless Keyboard make ideal bedfellows for the mini in the living room... If only they were joined at the hip.....
Achieving this isn't too difficult. The most desirable factor for this is that the two should be as rigidly attached as possible, yet the bond can't be permanent, since you wind up with the power button of the keyboard jammed right against the battery door of the trackpad (or vice versa if you're left-handed). So some sort of Velcro attachment is the best mechanism I could think of. The only trouble is that velcro can shift laterally to some extent. So I went with a 3M product called Dual-Lock. It's like velcro, except that it's genderless and since both sides of it are made of stiff plastic, it tends to be much better at holding still.
I found the stuff at Orchard Supply (Home Depot didn't carry it), in a two-pack of 3"x1" pieces (it's actually a 4-pack - there are four pieces, which makes two complete fasteners). I also bought an 8x10 sheet of .Lexan. I used a hacksaw to make a 6"x3" sheet and attached one strip to each end and two about a half inch apart straddling the middle. I then stuck the mating pieces on, peeled back the adhesive and stuck the keyboard and trackpad on.
So, There! I fixed it!
It's not absolute perfection. With the whole thing in your lap, you notice that there's really nowhere to rest your palms, like there would be on a real laptop. And you have to watch out that your left pinky doesn't accidentally contact the trackpad and skitter your mouse pointer off on a tangent. Also, because of the thickness of the whole thing and its proximity to the bottom of the trackpad, the rubber feet won't ever touch the desk if you set it down. This makes the mechanical buttons in the trackpad useless, unfortunately. But if you don't provide a stiff support for the bottom half of the connection, it won't be as stable as this solution allows.
Subscribe to:
Posts (Atom)