Children, children! You goll-darned whippersnappers with your "ATs" and 3.5" so-called "floppies" need to respect your elders! Why, I has me here my original XT keyboard, and I likes it!
I've only seen older Apple keyboards do this. Every other keyboard I've found puts them on F/J. Personally, I find both of them easy to adapt to, but when I went from an F/J keyboard to a D/K keyboard, my first several sentences all started out with gibberish because I was accustomed to the F/J layout and I'd mis-place my hands.
Do you have examples of other keyboards that put the dimples on D/K?
I never realized how much I relied on the home-row dimples until one day I sat down at an older Apple keyboard. It had the dimples on the D and K keys instead of F and J. I wondered why so often I'd go to type and start banging away jibberish, and then I looked down and noticed the difference. Modern Apple keyboards have switched to the F/J convention, thankfully.
I recall reading somewhere that your middle fingers' tips are supposedly more sensitive than your index fingers' tips, which is why they did that. Who knows... Does anyone know if other keyboards put dimples on D/K?
Indeed! I've been coming to this site since 1997 or 1998, back when the RC5 encryption challenge was going on. I was introduced to Slashdot by someone I who was on the team I was on. He asked me "Is/. down?" My response was, more or less, "Huh?" He decompressed his question for me, and in doing so, introduced me to a site that I'd quickly become hooked to. To this day, it's in my top three sites to visit daily: Slashdot, FARK and LWN.
How many of the rest of us "old timers" remember when/who introduced them to Slashdot? Or their first brush with Goatse? Or the introduction of moderation, then meta-moderation? Or the first time you saw "*BSD is dying" and felt the urge to check out the numbers on Altavista? (Remember Altavista?)
I imagine my UID would be lower if I had registered right away. I don't remember how long I put it off. But, at least I ended up with a prime number.:-)
You'll note that I did say you'd need to be careful with the information when it's outside the bag. That's true whether the password gets stored on the phone, or the phone makes the user type the password every time it's used. If the password only gets stored in RAM, though, you can do things such as wipe buffers immediately after use, etc. to at least limit the size of the window involved. Finding the right bytes in the right VM page (after hacking your way to get access in the VM!!) isn't nearly as trivial as knowing what file to grab in the filesystem. And, if you're able to walk the VM at your leisure, I suspect you've got bigger problems to worry about.
Proper segmentation would prevent run-time attacks that allow you to view RAM that you're not supposed to see when the device is in a normal operating mode. What about devices like the police forensic scanners, that conceivably could use something like JTAG to dump all the flash, without any cooperation from the host OS? I guess at that point we're into a discussion as to what threat models matter most and which ones we're trying to solve, so we can fix the goalposts.
An alternative to security by obscurity would be to have an actual secured device-specific key on the device, and an encryption block that has sole access to that key. I've actually architected products in the past that have such things, and one of the use models was "user's bag of sensitive data", where you could put items in the bag (passwords, credit card #s, etc.) in a secure manner, and only pull them out as needed. You need to be careful with how you handle the information once it's outside the bag, but the main point is if someone takes the bag (the SQLite database, in this instance), it's valueless to an attacker.
The bag itself could be stored encrypted in whatever bulk storage is convenient, with a key that's only physically accessible to the encryption engine. The key is "device specific", meaning each chip gets a random key blasted into it in the factory. You couldn't take the secure bag image from one phone and plop it on another and read it.
Lest this sounds like science fiction, it isn't. The same technology is used and widely deployed for DRM and other such purposes. Heck, TPM does this same stuff. It could be used to protect your passwords, but there isn't as much money or emphasis on implementing that.
So let me see if I follow: If I use stored procedures for everything, then when I change DBs, I won't have to rewrite everything, just the stored procedures. But didn't I use the stored procedures for everything? What part am I not rewriting again?
Not all compilers will optimize that out. The embedded compiler I use still outputs an initializer record for that. Marking it 'static' means I actually get a copy of the initializer record in every compilation unit that includes the constant, which is even "better".
You can do this in C++ pretty easily by overloading the bitwise OR operator on the enum. Thus, when you have an enum type that you know is safe to manipulate as a set of orthogonal (or mostly orthogonal) bitfield values (such as the macros that define flags for open(), for example), you can add the appropriate "operator|" to work on that type.
Example:
#include <iostream>
using namespace std;
enum foo
{
FRED = 1,
WILMA = 2,
BARNEY = 4,
BETTY = 8
};
foo operator | (foo lhs, foo rhs)
{
return (foo)((unsigned)lhs | (unsigned)rhs);
}
int main()
{
foo bar = FRED | WILMA | BARNEY | BETTY;
cout << bar << endl;
}
This prints "15".
As I recall, enums can have the integer value of any of the enums defined in the set, or any of the bit patterns formed by ORing any combination of members of the enum set. So, this is entirely legit code.
What's with all these specs? That keep ending in question marks? And don't form complete sentences? And aren't even questions? But end with question marks anyway?
Lessee.. my Bluetooth headset has to transmit as far as my pocket, whereas my phone potentially has to transmit up to a couple miles. Which one do you suppose would cause the greatest amount of harm?
Your 100mW is way off base. That's a maximum transmit power for a Class 1 BT device with a range of 100m. A typical Bluetooth headset is a Class 2 2.5mW, 10m range device. 2.5mW is 1/40th of Class 1's max power output. According to this article, a Bluetooth headset SAR can be as low as 0.001W/kg, which is a few orders of magnitude smaller than for a cell phone.
How else do you suppose they can get away with such a minuscule battery and still offer decent talk time?
Urgl... one of my favorite treats in China when I visited it recently was the pickled vegetables! Dammit! Not to mention the fact that I drink coffee like most people breathe air.... I'm screwed.
Well, try an experiment: Set your phone next to some powered-on computer speakers. At least w/ GSM phones you'll find you hear the "boppita-boppita-bop" of a sync every dozen minutes or so (widely variable), but most of the time its silent. If you get an SMS or a phonecall, though, your speakers will scream like a banshee.
Always-on and always-associated phones don't actually consume much bandwidth, and therefore don't represent much transmit power. At least, when you're well within range.
Granted, my experience has been in a major city with mostly good reception. If you're further from a tower, it could be much worse than that.
Ever use a Bluetooth earpiece? That's my primary use model: Bluetooth earpiece in my ear, and phone in pocket or elsewhere. I'm not radiating GSM into my brain, but I'm certainly radiating it into my leg if the phone's in my pocket. If I had one of those belt clips that allowed me to put my phone more "front and center", I could see it radiating into other, more sensitive areas.
Of course, to apply the SAR ratings they report for phone-to-ear to your 'nads, you'd pretty much have to hold the phone in your crotch. While I can see that happening, I doubt it's a primary use model. Pocket or desk or car cup holder or similar seems more likely when you have a Bluetooth earpiece.
Slashdot Mirror
Careful... you're gonna hurt yourself planting your tongue so firmly in your cheek...
Children, children! You goll-darned whippersnappers with your "ATs" and 3.5" so-called "floppies" need to respect your elders! Why, I has me here my original XT keyboard, and I likes it!
I've only seen older Apple keyboards do this. Every other keyboard I've found puts them on F/J. Personally, I find both of them easy to adapt to, but when I went from an F/J keyboard to a D/K keyboard, my first several sentences all started out with gibberish because I was accustomed to the F/J layout and I'd mis-place my hands.
Do you have examples of other keyboards that put the dimples on D/K?
I never realized how much I relied on the home-row dimples until one day I sat down at an older Apple keyboard. It had the dimples on the D and K keys instead of F and J. I wondered why so often I'd go to type and start banging away jibberish, and then I looked down and noticed the difference. Modern Apple keyboards have switched to the F/J convention, thankfully.
I recall reading somewhere that your middle fingers' tips are supposedly more sensitive than your index fingers' tips, which is why they did that. Who knows... Does anyone know if other keyboards put dimples on D/K?
Well, you haven't forgotten him, only blocked him out. The two are different things....
For the nostalgic, I saved a screen cap...
When I first read that in your original post, I thought "well played!" *chuckle*
Oh, and who can forget JonKatz?
Indeed! I've been coming to this site since 1997 or 1998, back when the RC5 encryption challenge was going on. I was introduced to Slashdot by someone I who was on the team I was on. He asked me "Is /. down?" My response was, more or less, "Huh?" He decompressed his question for me, and in doing so, introduced me to a site that I'd quickly become hooked to. To this day, it's in my top three sites to visit daily: Slashdot, FARK and LWN.
How many of the rest of us "old timers" remember when/who introduced them to Slashdot? Or their first brush with Goatse? Or the introduction of moderation, then meta-moderation? Or the first time you saw "*BSD is dying" and felt the urge to check out the numbers on Altavista? (Remember Altavista?)
I imagine my UID would be lower if I had registered right away. I don't remember how long I put it off. But, at least I ended up with a prime number. :-)
Well, you could connect over... *drumroll please* ...WiFi!
You'll note that I did say you'd need to be careful with the information when it's outside the bag. That's true whether the password gets stored on the phone, or the phone makes the user type the password every time it's used. If the password only gets stored in RAM, though, you can do things such as wipe buffers immediately after use, etc. to at least limit the size of the window involved. Finding the right bytes in the right VM page (after hacking your way to get access in the VM!!) isn't nearly as trivial as knowing what file to grab in the filesystem. And, if you're able to walk the VM at your leisure, I suspect you've got bigger problems to worry about.
Proper segmentation would prevent run-time attacks that allow you to view RAM that you're not supposed to see when the device is in a normal operating mode. What about devices like the police forensic scanners, that conceivably could use something like JTAG to dump all the flash, without any cooperation from the host OS? I guess at that point we're into a discussion as to what threat models matter most and which ones we're trying to solve, so we can fix the goalposts.
You may've missed the part where I said "Heck, TPM does this same stuff." TPM itself isn't evil. It can be put to good uses also.
An alternative to security by obscurity would be to have an actual secured device-specific key on the device, and an encryption block that has sole access to that key. I've actually architected products in the past that have such things, and one of the use models was "user's bag of sensitive data", where you could put items in the bag (passwords, credit card #s, etc.) in a secure manner, and only pull them out as needed. You need to be careful with how you handle the information once it's outside the bag, but the main point is if someone takes the bag (the SQLite database, in this instance), it's valueless to an attacker.
The bag itself could be stored encrypted in whatever bulk storage is convenient, with a key that's only physically accessible to the encryption engine. The key is "device specific", meaning each chip gets a random key blasted into it in the factory. You couldn't take the secure bag image from one phone and plop it on another and read it.
Lest this sounds like science fiction, it isn't. The same technology is used and widely deployed for DRM and other such purposes. Heck, TPM does this same stuff. It could be used to protect your passwords, but there isn't as much money or emphasis on implementing that.
Har har. Nice truncation on the sentence there.
You forgot to specify which character gets the comic-relief one liners...
So let me see if I follow: If I use stored procedures for everything, then when I change DBs, I won't have to rewrite everything, just the stored procedures. But didn't I use the stored procedures for everything? What part am I not rewriting again?
Yeah, because most hum......................ans totally sto..........p and start tal............king with random p-p-p-p-p-p-p-pauses.
Not all compilers will optimize that out. The embedded compiler I use still outputs an initializer record for that. Marking it 'static' means I actually get a copy of the initializer record in every compilation unit that includes the constant, which is even "better".
You can do this in C++ pretty easily by overloading the bitwise OR operator on the enum. Thus, when you have an enum type that you know is safe to manipulate as a set of orthogonal (or mostly orthogonal) bitfield values (such as the macros that define flags for open(), for example), you can add the appropriate "operator|" to work on that type.
Example:
#include <iostream>
using namespace std;
enum foo
{
WILMA = 2,
BARNEY = 4,
BETTY = 8
};
foo operator | (foo lhs, foo rhs)
{
}
int main()
{
cout << bar << endl;
}
This prints "15".
As I recall, enums can have the integer value of any of the enums defined in the set, or any of the bit patterns formed by ORing any combination of members of the enum set. So, this is entirely legit code.
What's with all these specs? That keep ending in question marks? And don't form complete sentences? And aren't even questions? But end with question marks anyway?
Lessee.. my Bluetooth headset has to transmit as far as my pocket, whereas my phone potentially has to transmit up to a couple miles. Which one do you suppose would cause the greatest amount of harm?
Your 100mW is way off base. That's a maximum transmit power for a Class 1 BT device with a range of 100m. A typical Bluetooth headset is a Class 2 2.5mW, 10m range device. 2.5mW is 1/40th of Class 1's max power output. According to this article, a Bluetooth headset SAR can be as low as 0.001W/kg, which is a few orders of magnitude smaller than for a cell phone.
How else do you suppose they can get away with such a minuscule battery and still offer decent talk time?
Sometimes. It's not terribly pleasant, though. *h000rk!*
Urgl... one of my favorite treats in China when I visited it recently was the pickled vegetables! Dammit! Not to mention the fact that I drink coffee like most people breathe air.... I'm screwed.
Well, try an experiment: Set your phone next to some powered-on computer speakers. At least w/ GSM phones you'll find you hear the "boppita-boppita-bop" of a sync every dozen minutes or so (widely variable), but most of the time its silent. If you get an SMS or a phonecall, though, your speakers will scream like a banshee.
Always-on and always-associated phones don't actually consume much bandwidth, and therefore don't represent much transmit power. At least, when you're well within range.
Granted, my experience has been in a major city with mostly good reception. If you're further from a tower, it could be much worse than that.
Ever use a Bluetooth earpiece? That's my primary use model: Bluetooth earpiece in my ear, and phone in pocket or elsewhere. I'm not radiating GSM into my brain, but I'm certainly radiating it into my leg if the phone's in my pocket. If I had one of those belt clips that allowed me to put my phone more "front and center", I could see it radiating into other, more sensitive areas.
Of course, to apply the SAR ratings they report for phone-to-ear to your 'nads, you'd pretty much have to hold the phone in your crotch. While I can see that happening, I doubt it's a primary use model. Pocket or desk or car cup holder or similar seems more likely when you have a Bluetooth earpiece.