How can having the extra button on the keyboard (in the form of meta keys), and therefore requiring the use of two hands be better than having the extra button on the mouse? The one-button adherents have never given me a convincing explanation.
Try this experiment:
Get a friend, some duct tape, a Mac Pro mouse and any multi-button mouse you choose. Have your friend tape all the fingers of each of your hands together. Leave your fingertips exposed. Take more tape and tape your thumbs down as well.
You now have two club-like appendages. You should be able to hunt-n-peck on the keyboard without major difficulties.
Now go use the multi-button mouse. How easy is it to properly click on a particular mouse button? How easy is it to maneuver the mouse at the same time? How easy is it to hit a screen target with each button click? How well does the scroll wheel work for you?
Now try the same functions using the single-button Pro mouse and the modifier keys.
I always thought Hagar, Yurak, Lotor and Zarkon were pitiful strategists. Consider:
One of Hagar's beasts was usually a match for any one Lion. Why didn't Yurak order Hagar to make six of the damn things, land five of them on equidistant points on the surface of Arus, and then use the sixth to dismantle one lion? Bingo, no more Voltron.
Seriously though, how many people that work at those "high-level" (sic) facilities, bring 6/12 packs to work everyday.
A lot.
Secure facilities are a pain in the butt to get in and out of, for obvious reasons. As a result, most facility personnel run snack bars inside the secured area. These snack bars buy supplies in bulk, usually from SAM's or Costco or similar big-box stores. Depending on size, these little co-ops can go through several hundred sodas per week.
For one thing, I was under the impression that when it comes to most products, cheapness rules, [...]
Of course, people do buy lots of iPods, so I could be completely wrong.
You're completely wrong.
Form factor, looks, and 'coolness' are all decision factors. Cost is important, but not most important. The continued viability of Nike is an obvious example.
It represents many years' worth of HID research. It's not the end-all, be all of HID, but it's one helluvalot better than nothing.
Sounds like the PowerPoint Method to me.
on
Matrix Decision Making
·
· Score: 2, Insightful
Color me skeptical, but I find it hard to believe that complex issues can be reduced to a simple 2x2 matrix. My initial impression is such a method will do nothing than promote false dichotomies to the detriment of real analysis.
It does, however, sound like the ideal method to present choices in PowerPoint.
You should read the work on SPKI by Carl Ellison, Ron Rivest, et.al. Your X.509 name is, effectively, meaningless-- worse than meaningless, it's assumed to be global when in fact it's local. Most of X.509's implementation problems stem from this simple fact.
Once you free yourself from the concept using human-readable names, you'll realize that in any PKI-- including X.509-- it's only the key that matters. Since the key is unique (the chances of two people randomly selecting the same key are infinitesimal) the key itself is used as the name.
The fact that the public key is cryptographically bound to the private key is all that's needed for authentication.
Binding a key to a person-- now, there's a real problem. But X.509 doesn't solve that. In fact, *no* PKI *can* solve that problem. You only solve it by having good policies issuing and protecting private key storage.
There are privacy problems inherent in X.509 that should make you nervous. There is no way to do an anonymous transaction (say, via cash) secured with an X.509 certificate because your *name*, not the key, is the important part of X.509. That means you must always reveal your name.
In addition, an X.509 certificate can bind any number of attributes to that name, and it's up to the CA-- not you-- to decide what those are. Once they're in the certificate, *you cannot decide not to provide them*. Kinda takes away your control over your private information.
Look up the work of Carl Ellison & Ron Rivest and others on X.509 and privacy, particularly in contrast to how SPKI handles things.
X.509 binds names to keys; it's the name that matters in an X.509 system. But because there aren't enough bits in the human-language name to uniquely identify every entity of interest in the network, X.509 is based on X.500 naming, which mates the human-language name (common name, or CN) with that name's position in the global directory. Together they form the distinguished name, or DN.
X.500 naming, however, presumes a single, global namespace. The X.500 directory was intended to be a single directory for the entire planet providing unique, inescapable names for everyone.
Yeah, right. Like that's going to happen.
As a result, X.509 is carved into literally hundreds of local namespaces. But since we're stuck with the *name* as the principal, we have to use that X.509 name *globally*. There are multiple ugly kludges to get around the name problems as a result.
This makes X.509 complex, fragile, and difficult to deploy correctly.
But everyone (potentially) has a globally unique identifier-- the public part of an RSA key. Randomly generated, 2^42 512-bit RSA keys have a probability of colliding on the order of 2^(-429); even the SHA-1 hashes have a collision chance of 2^(-77). Keep in mind that we use 1024-bits as the default nowadays.
So if you use the public key as a name, it solves a whole raft of problems.
This is what SPKI/SDSI does. SPKI is key-centric; names are a local convenience; keys are bound to names instead of the other way around, and all names are local to that key. Every participant has a key pair. The public part is the identifier for the keyholder, and the keyholder authenticates himself simply by proving that he has the private part.
Keep in mind that the whole issue of binding keys to actual people can't be addressed by a PKI, it has to be addressed by strong key storage and access controls and is the same across for X.509 and PGP/GPG as it is for SPKI.
This is similar to the web of trust, but I don't need introducers (well-connected keys) to make it work right.
SPKI goes on to recognize that since authentication is simple, what we really need from SPKI is authorization. The whole of SPKI is intended to define a flexible method of allowing authorization *and authorization delegation* in a simple, distributed fashion. SPKI defines an authorization *language* so that authorizations can be chained *without the SPKI library knowing what the tokens actually mean*. This means that a single library can handle the permission sets of all applications. In addition, the language rules prevent all entities in the chain of delegations from being able to exceed the permissions he was granted.
Achieving the same under X.509 (using attribute certificates, for example) is next to impossible. ACs don't delegate (well, the standard itself says technically you can but you *shouldn't*); aren't truly distributed (i.e., the AC acts as a single choke point in granting permissions, which SPKI avoids), and doesn't model the way trust naturally flows in an organization of people (whereas SPKI allows you to source and pass around trusts in more natural ways).
Very cool stuff. SPKI shows up in all kinds of places. Carl Ellison's homepage provides the best jumping-off point if you want to learn more:
A level playing field would be if the people in India were as free to seek higher-paying jobs in the US as corporations are free to send capital to India.
*That* would be a level playing field.
Don't believe me? Read _Wealth of Nations_ again (what, you haven't read it?)-- Smith *specifically* predicates his theory on the free movement of *both* capital and labor.
We have the former, not the latter; therefore the field isn't level.
Apple SmartCard support is built with the DoD Common Access Card (CAC) in mind. To work with another PKI you'll need to make modifications.
Pather already includes the Apple Federal SmartCard Package, but you should download and read the docs from Apple Suport. It's essentially MUSCLE with tweaks. Enable it via 'sudo cac_setup' and disable it with 'sudo cac_setup -off'. The details are in/etc/authorization.cac.
Generally, the framework validates the private key on the card, then reads attributes from the card (by default, the DoD EDI-PI from the Demographics container) and maps this attribute against Open Directory accounts. It's pretty flexible, and it shouldn't take a lot of work to make it work with another PKI.
You're too dependent on your gear, sir. I've shot plenty of (IMHO) quality sports work with my K-1000. There's more than enough exposure latitude in the film you should be using for fast work to allow for snap shooting. That's part of photography that's overlooked by more casual amateurs-- film selection should reflect the intended subject.
The unmentioned advantages of an all manual camera:
1) Better performance at climate extremes. I don't have to concern myself with anything other than fogging in cold weather. How are your lithium batteries at -10degF?
2) Fewer failure modes. In fact, the K-1000 has no electronic failures. I don't think I've had a battery in mine for... 10 years? I shoot mostly nature work these days, and use a handheld self-powered meter. When your battery dies, you're SOL unless you brought a backup-- and every ounce counts when you're three days from anywhere and carrying everything on your back.
A poster above complained about the 1/60 flash sync. That poster is forgetting that 1/60 is the *standard*. Anything higher than that is a *bonus*, but all cameras default to 1/60; this allows for dumb flashes (rather than electronically synced) to be used to control the exposure rather than using the camera's shutter or aperture.
Slashdot Mirror
Actually, rural farm computing can have a significant impact as long as it comes with effective communications.
http://www.squeakland.org
http://www.squeak.org
foo isLiteralEqual bar.
'Nuff said.
[Progressive taxation] also reduces absolute liberty. How about you move to Denmark then?
Translation: "I got mine, the rest of you can fuck off and die."
[...] you foist off on us the western-centric view that internet access is as vital to third world economies as it is to western economies.
Yes, indeed it is.
How can having the extra button on the keyboard (in the form of meta keys), and therefore requiring the use of two hands be better than having the extra button on the mouse? The one-button adherents have never given me a convincing explanation.
Try this experiment:
Get a friend, some duct tape, a Mac Pro mouse and any multi-button mouse you choose. Have your friend tape all the fingers of each of your hands together. Leave your fingertips exposed. Take more tape and tape your thumbs down as well.
You now have two club-like appendages. You should be able to hunt-n-peck on the keyboard without major difficulties.
Now go use the multi-button mouse. How easy is it to properly click on a particular mouse button? How easy is it to maneuver the mouse at the same time? How easy is it to hit a screen target with each button click? How well does the scroll wheel work for you?
Now try the same functions using the single-button Pro mouse and the modifier keys.
You should 'get it' by this point.
Not quite. The inside of an Alcubierre bubble is causually decoupled from the negative energy shell. So once you turn it on, you can't turn it off...
I always thought Hagar, Yurak, Lotor and Zarkon were pitiful strategists. Consider:
One of Hagar's beasts was usually a match for any one Lion. Why didn't Yurak order Hagar to make six of the damn things, land five of them on equidistant points on the surface of Arus, and then use the sixth to dismantle one lion? Bingo, no more Voltron.
Seriously though, how many people that work at those "high-level" (sic) facilities, bring 6/12 packs to work everyday.
A lot.
Secure facilities are a pain in the butt to get in and out of, for obvious reasons. As a result, most facility personnel run snack bars inside the secured area. These snack bars buy supplies in bulk, usually from SAM's or Costco or similar big-box stores. Depending on size, these little co-ops can go through several hundred sodas per week.
For one thing, I was under the impression that when it comes to most products, cheapness rules, [...]
Of course, people do buy lots of iPods, so I could be completely wrong.
You're completely wrong.
Form factor, looks, and 'coolness' are all decision factors. Cost is important, but not most important. The continued viability of Nike is an obvious example.
Apple's Human Interface Guidelines is a good place to start, and is online for free.
It represents many years' worth of HID research. It's not the end-all, be all of HID, but it's one helluvalot better than nothing.
Color me skeptical, but I find it hard to believe that complex issues can be reduced to a simple 2x2 matrix. My initial impression is such a method will do nothing than promote false dichotomies to the detriment of real analysis.
It does, however, sound like the ideal method to present choices in PowerPoint.
That's not a compliment, just so we're clear.
Under the couch. This is why God invented Bluetooth.
You should read the work on SPKI by Carl Ellison, Ron Rivest, et.al. Your X.509 name is, effectively, meaningless-- worse than meaningless, it's assumed to be global when in fact it's local. Most of X.509's implementation problems stem from this simple fact.
Once you free yourself from the concept using human-readable names, you'll realize that in any PKI-- including X.509-- it's only the key that matters. Since the key is unique (the chances of two people randomly selecting the same key are infinitesimal) the key itself is used as the name.
The fact that the public key is cryptographically bound to the private key is all that's needed for authentication.
Binding a key to a person-- now, there's a real problem. But X.509 doesn't solve that. In fact, *no* PKI *can* solve that problem. You only solve it by having good policies issuing and protecting private key storage.
Regulation is Bad!
Unless, of course, it reinforces your personal prejudices or furthers your religious agenda.
There are privacy problems inherent in X.509 that should make you nervous. There is no way to do an anonymous transaction (say, via cash) secured with an X.509 certificate because your *name*, not the key, is the important part of X.509. That means you must always reveal your name.
In addition, an X.509 certificate can bind any number of attributes to that name, and it's up to the CA-- not you-- to decide what those are. Once they're in the certificate, *you cannot decide not to provide them*. Kinda takes away your control over your private information.
Look up the work of Carl Ellison & Ron Rivest and others on X.509 and privacy, particularly in contrast to how SPKI handles things.
X.509 binds names to keys; it's the name that matters in an X.509 system. But because there aren't enough bits in the human-language name to uniquely identify every entity of interest in the network, X.509 is based on X.500 naming, which mates the human-language name (common name, or CN) with that name's position in the global directory. Together they form the distinguished name, or DN.
X.500 naming, however, presumes a single, global namespace. The X.500 directory was intended to be a single directory for the entire planet providing unique, inescapable names for everyone.
Yeah, right. Like that's going to happen.
As a result, X.509 is carved into literally hundreds of local namespaces. But since we're stuck with the *name* as the principal, we have to use that X.509 name *globally*. There are multiple ugly kludges to get around the name problems as a result.
This makes X.509 complex, fragile, and difficult to deploy correctly.
But everyone (potentially) has a globally unique identifier-- the public part of an RSA key. Randomly generated, 2^42 512-bit RSA keys have a probability of colliding on the order of 2^(-429); even the SHA-1 hashes have a collision chance of 2^(-77). Keep in mind that we use 1024-bits as the default nowadays.
So if you use the public key as a name, it solves a whole raft of problems.
This is what SPKI/SDSI does. SPKI is key-centric; names are a local convenience; keys are bound to names instead of the other way around, and all names are local to that key. Every participant has a key pair. The public part is the identifier for the keyholder, and the keyholder authenticates himself simply by proving that he has the private part.
Keep in mind that the whole issue of binding keys to actual people can't be addressed by a PKI, it has to be addressed by strong key storage and access controls and is the same across for X.509 and PGP/GPG as it is for SPKI.
This is similar to the web of trust, but I don't need introducers (well-connected keys) to make it work right.
SPKI goes on to recognize that since authentication is simple, what we really need from SPKI is authorization. The whole of SPKI is intended to define a flexible method of allowing authorization *and authorization delegation* in a simple, distributed fashion. SPKI defines an authorization *language* so that authorizations can be chained *without the SPKI library knowing what the tokens actually mean*. This means that a single library can handle the permission sets of all applications. In addition, the language rules prevent all entities in the chain of delegations from being able to exceed the permissions he was granted.
Achieving the same under X.509 (using attribute certificates, for example) is next to impossible. ACs don't delegate (well, the standard itself says technically you can but you *shouldn't*); aren't truly distributed (i.e., the AC acts as a single choke point in granting permissions, which SPKI avoids), and doesn't model the way trust naturally flows in an organization of people (whereas SPKI allows you to source and pass around trusts in more natural ways).
Very cool stuff. SPKI shows up in all kinds of places. Carl Ellison's homepage provides the best jumping-off point if you want to learn more:
http://world.std.com/~cme/html/spki.html
A level playing field would be if the people in India were as free to seek higher-paying jobs in the US as corporations are free to send capital to India.
*That* would be a level playing field.
Don't believe me? Read _Wealth of Nations_ again (what, you haven't read it?)-- Smith *specifically* predicates his theory on the free movement of *both* capital and labor.
We have the former, not the latter; therefore the field isn't level.
Apple SmartCard support is built with the DoD Common Access Card (CAC) in mind. To work with another PKI you'll need to make modifications.
/etc/authorization.cac.
Pather already includes the Apple Federal SmartCard Package, but you should download and read the docs from Apple Suport. It's essentially MUSCLE with tweaks. Enable it via 'sudo cac_setup' and disable it with 'sudo cac_setup -off'. The details are in
Generally, the framework validates the private key on the card, then reads attributes from the card (by default, the DoD EDI-PI from the Demographics container) and maps this attribute against Open Directory accounts. It's pretty flexible, and it shouldn't take a lot of work to make it work with another PKI.
This is exactly what he's warning about in his book. I highly recommend it.
The Internet was designed with the intelligence at the edge for a reason-- to prevent this kind of nonsense.
Rhetoric.
The benefit of a classical education.
If you were typesetting math textbooks, your failure to use TeX is your own fault and problem.
WP *and* Word were/are the wrong tool for that job.
Actually, a lot of MS's website is Akamaized.
And Akamai uses Debian GNU/Linux.
The disadvantage to digital in this regard is it's tempting to over-edit-- discarding pictures it too easy.
And I won't get into archiving. I have family negatives that are a century old...
Perhaps the best solution is what I've been considering: shoot on film, and digitize with a negative scanner.
You're too dependent on your gear, sir. I've shot plenty of (IMHO) quality sports work with my K-1000. There's more than enough exposure latitude in the film you should be using for fast work to allow for snap shooting. That's part of photography that's overlooked by more casual amateurs-- film selection should reflect the intended subject.
... 10 years? I shoot mostly nature work these days, and use a handheld self-powered meter. When your battery dies, you're SOL unless you brought a backup-- and every ounce counts when you're three days from anywhere and carrying everything on your back.
The unmentioned advantages of an all manual camera:
1) Better performance at climate extremes. I don't have to concern myself with anything other than fogging in cold weather. How are your lithium batteries at -10degF?
2) Fewer failure modes. In fact, the K-1000 has no electronic failures. I don't think I've had a battery in mine for
A poster above complained about the 1/60 flash sync. That poster is forgetting that 1/60 is the *standard*. Anything higher than that is a *bonus*, but all cameras default to 1/60; this allows for dumb flashes (rather than electronically synced) to be used to control the exposure rather than using the camera's shutter or aperture.