Why? My experience with Javascript is that it's a rather nice merger of object oriented and functional programming methodologies, rivaling Smalltalk in many ways (not the least of which is ubiquity).
No, you can't. The only way this would work is if the counter variable was a class variable, which greatly limits the utility of anonymous inner classes. Fundamentally, this is because Java has no concept of lexical closures, something which is at the heart of Javascript. This is a *huge* pain in the ass, IMHO (especially if you're used to LISP, Smalltalk, Perl, Ruby, or even the semi-crippled Python), and makes things like the collection classes far less useful.
'course, if you've grown up in the C++-derived world, you probably have no idea what a closure is, let alone the useful programming constructs it enables, such as higher-order functions.
Uhuh. What's your point? In the case of DX, the designers are also acting as the ARB. So? Heck, that just further disputes the idea that "[the] glue is (ultimately) dictating to the materials what properties they must possess", since clearly they are dictating nothing, but rather working with hardware/software vendors to design an API which fits the needs of the game developers.
The kit in question is available from a number of vendors. I got one with me from Aladin marketed under the name of eToken, supports standard x509 certificates and if it will be bought in the quantities.gov will buy it the price will be in the sub 10$ range. It is only moderately more expensive now.
Uhh, there are more than just PKI-based kits available. For example, you could go with SNK cards. In this case, the service to be accessed generates a challenge code. You then enter your pin and the challenge into the SNK, and it generates a response. Yes, the cards need to be registered with the auth system, but that seems easier to manage than a full PKI infrastructure.
That's the wrong way to look at it. The DX guys are, in essence, acting as the negotiators between the game developers and the hardware manufacturers. The game dev folks tell the DX people what they'd like, in terms of feature set. The DX people then work with the hardware manufacturers to implement those features. It really does make a lot of sense. The game developers get what they need, in terms of feature set and APIs. The DX folks then get to work with the hardware manufacturers to ensure that the required capabilities are available and relatively consistent across hardware vendors.
Re:A New Core Class in College?
on
PGP & GPG
·
· Score: 1
Well, in my particular case, I don't use my keypair for signing/authenticating things. I primarily use it for encryption of my own data, so I don't feel the need to be ultra paranoid about these things.
Re:Mil Grade Crypto... IS defined :-P
on
PGP & GPG
·
· Score: 1
I'm not sure why I'm bothering, here, but... "military grade" means something because it is assumed that, in a given application, the military will require greater security than I will. Therefore, if someone says "for job X, military grade is Y", then if I need to perform job X, I'll use Y, because the military believes it's sufficient for their needs, and thus it's likely sufficient for mine.
Re:Mil Grade Crypto... IS defined :-P
on
PGP & GPG
·
· Score: 2, Insightful
Perhaps there is a secret they only need to keep secure for 30 minutes, or they have an old PC. So in this case, a 40-bit cipher would be sufficient to protect their data in that case. So would that make a 40-bit cipher military-grade encryption?
For that particular application, absolutely. And if I find myself in a similar situation, then I can safely do the same since, if the military feels that's sufficient to protect their likely-more-important data, then I probably can, too.
Is this really that difficult to understand?
Re:Mil Grade Crypto... IS defined :-P
on
PGP & GPG
·
· Score: 1
No, the point is the military would never be so stupid as to select such weak ciphers. Or, I would hope that's the case. Therefore, my point is that *if* they chose 56-bit DES, than that would mean it's quite strong. Of course, we know it isn't, so the military probably isn't using that cipher.
Put another way, if the military chooses a cipher, I trust it's strong enough to protect my, presumably less important, data. Therefore, yes, the term "military-grade" does have some meaning.
This is one of the craziest, most twisted, least democratic things I have ever heard of an allegedly democratic government doing.
You're kidding, right? You actually think this is worse than, say, illicit, illegal domestic spying? Or lying to the American public in order to justify war?
Jebus, forget about that, how about the run of the mill stuff that goes on in the US:
* Institutionalized Bribary (aka "lobbying"). * The whole concept of riders to bills. * Gerrymandering.
The list goes on. And yet you think all these things are *less* twisted and *more* democratic? Honestly, I think you need to reevaluate your priorities.
While, I too, think that a stronger central governement would be more efficient, it would never work. I live in Montreal, and I would say that you have to live here (or anywhere in Quebec) to really understand what the whole independance mouvement is all about. The core PQ and BQ voter will probably never trust the federal gouvernement because they feel it's "foreign"...
Heh, and what's funny is that the exact same sentiment is felt out here in western Canada. Perhaps Canada is more united than we think! United in our universal distrust of the feds...:)
Re:Mil Grade Crypto... IS defined :-P
on
PGP & GPG
·
· Score: 1
If the Army today decides to uses 56-bit DES, does that mean it is military-grade encryption?
If they feel 56-bit DES is sufficient to protect their data, then yes, it's military-grade.
Re:A New Core Class in College?
on
PGP & GPG
·
· Score: 1
It's also not user friendly. I had been playing with GPG for a while, but I discovered a important fragility in the system: keeping a private key for years on end for encrypted files is very difficult for casual users. It is really easy to inadvertently lose the private key.
Anyone who understands the least bit about public key cryptography will back up their private key. Multiple times. Personally, I have my private key on my home computer, my PDA, and a CD-ROM that I keep stored in a box along with my passport and other valuables.
Well this is just silly. If I'm creating an HD-DVD disc, I'm going to choose encoding options so that I can get the highest quality possible. So, for HD-DVDs with little extra content, I'll probably choose a higher bitrate, and vice versa. Either way, the ultimate goal will be to use as much of the available disc space as possible, otherwise it's just wasted.
The death of privacy is GOOD. The only people that care about it are the ones who shouldn't be doing what they're doing ANYWAY.
How odd... because I'm guessing more kids than not have, at some point, bitched and complained because they wanted their own room with a door they can close, and preferably lock, specifically so they can have *privacy*.
In relation to what you said, something else often quoted is the loss of ice in Antarctica (Ross Ice Shelf). But ice in some areas of Antarctica is actually increasing.
You do realize that can be interpreted as evidence *for* the existence of global warming, don't you? See, it goes like this: increased global temperatures == increased ocean temperatures. Increased ocean temperatures == increased evaporation. Increased evaporation == increased snowfall. Increased snowfall == thickening of affected areas of the ice caps.
Unfortunately, this doesn't offset the massive chunks of ice that have been observed breaking off the antarctic shelf...
Uhh, the cable cos can, and already do, use private address spaces for their settop boxes, and this is the way it'll stay. There's no way a cable company will want their DSTB population externally reachable. As such, the IP address shortage is a non-issue for them.
Again, you're missing the point. The problem, here, isn't with.NET. The problem is with rewriting products. What MS is implying by their actions is that, in the vast majority of cases, embarking on product rewrites is a bad idea. Wow, shocker there. But, because of your own biases, you're assuming that implies something about.NET when, IMHO, it doesn't.
Huh, no kidding.:) So, OOC, why do most satellite receivers I've seen need to be plugged into a telephone line to make use of things like PPV services?
Did anybody else find that the most shocking/suprising part of the article?
Not at all. OTOH, I work in the cable space. In short, there are laws in the books which severely limit the data which can be sent back from a DSTB. As for their purpose, that seems pretty obvious: in the world of digital cable, *something* needs to decode the cable signal and display it on your TV.
I thought.net would guarantee security and security was the number one priority at MS. The browser is something that really really needs to be secure.
I completely agree. However, the man-decades required to rewrite something as complex as IE on a still-maturing platform are almost certainly better spent fixing the existing codebase. Or would you prefer MS released a brand new product with a whole raft of new bugs, rather than fixing up the already-mature product they have at hand?
Frankly, I think your problem is that you're assuming that No Rewrite ==.NET Bad, as opposed to the more sensible conclusion that rewriting, in general, is almost always bad idea. Or haven't you heard of Second System Syndrome?
Slashdot Mirror
I hate javascript way too much for that
Why? My experience with Javascript is that it's a rather nice merger of object oriented and functional programming methodologies, rivaling Smalltalk in many ways (not the least of which is ubiquity).
No, you can't. The only way this would work is if the counter variable was a class variable, which greatly limits the utility of anonymous inner classes. Fundamentally, this is because Java has no concept of lexical closures, something which is at the heart of Javascript. This is a *huge* pain in the ass, IMHO (especially if you're used to LISP, Smalltalk, Perl, Ruby, or even the semi-crippled Python), and makes things like the collection classes far less useful.
'course, if you've grown up in the C++-derived world, you probably have no idea what a closure is, let alone the useful programming constructs it enables, such as higher-order functions.
That negotiation can be done with an ARB as well.
Uhuh. What's your point? In the case of DX, the designers are also acting as the ARB. So? Heck, that just further disputes the idea that "[the] glue is (ultimately) dictating to the materials what properties they must possess", since clearly they are dictating nothing, but rather working with hardware/software vendors to design an API which fits the needs of the game developers.
The kit in question is available from a number of vendors. I got one with me from Aladin marketed under the name of eToken, supports standard x509 certificates and if it will be bought in the quantities .gov will buy it the price will be in the sub 10$ range. It is only moderately more expensive now.
Uhh, there are more than just PKI-based kits available. For example, you could go with SNK cards. In this case, the service to be accessed generates a challenge code. You then enter your pin and the challenge into the SNK, and it generates a response. Yes, the cards need to be registered with the auth system, but that seems easier to manage than a full PKI infrastructure.
That's the wrong way to look at it. The DX guys are, in essence, acting as the negotiators between the game developers and the hardware manufacturers. The game dev folks tell the DX people what they'd like, in terms of feature set. The DX people then work with the hardware manufacturers to implement those features. It really does make a lot of sense. The game developers get what they need, in terms of feature set and APIs. The DX folks then get to work with the hardware manufacturers to ensure that the required capabilities are available and relatively consistent across hardware vendors.
Well, in my particular case, I don't use my keypair for signing/authenticating things. I primarily use it for encryption of my own data, so I don't feel the need to be ultra paranoid about these things.
I'm not sure why I'm bothering, here, but... "military grade" means something because it is assumed that, in a given application, the military will require greater security than I will. Therefore, if someone says "for job X, military grade is Y", then if I need to perform job X, I'll use Y, because the military believes it's sufficient for their needs, and thus it's likely sufficient for mine.
Perhaps there is a secret they only need to keep secure for 30 minutes, or they have an old PC. So in this case, a 40-bit cipher would be sufficient to protect their data in that case. So would that make a 40-bit cipher military-grade encryption?
For that particular application, absolutely. And if I find myself in a similar situation, then I can safely do the same since, if the military feels that's sufficient to protect their likely-more-important data, then I probably can, too.
Is this really that difficult to understand?
No, the point is the military would never be so stupid as to select such weak ciphers. Or, I would hope that's the case. Therefore, my point is that *if* they chose 56-bit DES, than that would mean it's quite strong. Of course, we know it isn't, so the military probably isn't using that cipher.
Put another way, if the military chooses a cipher, I trust it's strong enough to protect my, presumably less important, data. Therefore, yes, the term "military-grade" does have some meaning.
This is one of the craziest, most twisted, least democratic things I have ever heard of an allegedly democratic government doing.
You're kidding, right? You actually think this is worse than, say, illicit, illegal domestic spying? Or lying to the American public in order to justify war?
Jebus, forget about that, how about the run of the mill stuff that goes on in the US:
* Institutionalized Bribary (aka "lobbying").
* The whole concept of riders to bills.
* Gerrymandering.
The list goes on. And yet you think all these things are *less* twisted and *more* democratic? Honestly, I think you need to reevaluate your priorities.
While, I too, think that a stronger central governement would be more efficient, it would never work. I live in Montreal, and I would say that you have to live here (or anywhere in Quebec) to really understand what the whole independance mouvement is all about. The core PQ and BQ voter will probably never trust the federal gouvernement because they feel it's "foreign" ...
:)
Heh, and what's funny is that the exact same sentiment is felt out here in western Canada. Perhaps Canada is more united than we think! United in our universal distrust of the feds...
If the Army today decides to uses 56-bit DES, does that mean it is military-grade encryption?
If they feel 56-bit DES is sufficient to protect their data, then yes, it's military-grade.
It's also not user friendly. I had been playing with GPG for a while, but I discovered a important fragility in the system: keeping a private key for years on end for encrypted files is very difficult for casual users. It is really easy to inadvertently lose the private key.
Anyone who understands the least bit about public key cryptography will back up their private key. Multiple times. Personally, I have my private key on my home computer, my PDA, and a CD-ROM that I keep stored in a box along with my passport and other valuables.
When people criticize Americans for driving SUVs to the grocery store, they should remember that it means Americans can afford SUVs.
No, it means Americans are far more willing to go into massive debt so they can keep up with the Jones'.
Well this is just silly. If I'm creating an HD-DVD disc, I'm going to choose encoding options so that I can get the highest quality possible. So, for HD-DVDs with little extra content, I'll probably choose a higher bitrate, and vice versa. Either way, the ultimate goal will be to use as much of the available disc space as possible, otherwise it's just wasted.
The death of privacy is GOOD. The only people that care about it are the ones who shouldn't be doing what they're doing ANYWAY.
How odd... because I'm guessing more kids than not have, at some point, bitched and complained because they wanted their own room with a door they can close, and preferably lock, specifically so they can have *privacy*.
In relation to what you said, something else often quoted is the loss of ice in Antarctica (Ross Ice Shelf). But ice in some areas of Antarctica is actually increasing.
You do realize that can be interpreted as evidence *for* the existence of global warming, don't you? See, it goes like this: increased global temperatures == increased ocean temperatures. Increased ocean temperatures == increased evaporation. Increased evaporation == increased snowfall. Increased snowfall == thickening of affected areas of the ice caps.
Unfortunately, this doesn't offset the massive chunks of ice that have been observed breaking off the antarctic shelf...
LOL. Yes, at the edges of the network, hosts will have to switch from comparing 4 bytes to comparing a whopping *16*. NOOOOOO!
Uhh, the cable cos can, and already do, use private address spaces for their settop boxes, and this is the way it'll stay. There's no way a cable company will want their DSTB population externally reachable. As such, the IP address shortage is a non-issue for them.
IPv6 addresses are four times the size of IPv4 addresses. That means additional computation is necessary to handle the simplest IP tasks (routing.)
Uhh... what? One of the big advantages of IPv6 over IPv4 is that it will make routing *easier*, thanks to the hierarchical address space.
Again, you're missing the point. The problem, here, isn't with .NET. The problem is with rewriting products. What MS is implying by their actions is that, in the vast majority of cases, embarking on product rewrites is a bad idea. Wow, shocker there. But, because of your own biases, you're assuming that implies something about .NET when, IMHO, it doesn't.
Huh, no kidding. :) So, OOC, why do most satellite receivers I've seen need to be plugged into a telephone line to make use of things like PPV services?
Did anybody else find that the most shocking/suprising part of the article?
Not at all. OTOH, I work in the cable space. In short, there are laws in the books which severely limit the data which can be sent back from a DSTB. As for their purpose, that seems pretty obvious: in the world of digital cable, *something* needs to decode the cable signal and display it on your TV.
Uhh... and remind me how upstream works, again?
I thought .net would guarantee security and security was the number one priority at MS. The browser is something that really really needs to be secure.
.NET Bad, as opposed to the more sensible conclusion that rewriting, in general, is almost always bad idea. Or haven't you heard of Second System Syndrome?
I completely agree. However, the man-decades required to rewrite something as complex as IE on a still-maturing platform are almost certainly better spent fixing the existing codebase. Or would you prefer MS released a brand new product with a whole raft of new bugs, rather than fixing up the already-mature product they have at hand?
Frankly, I think your problem is that you're assuming that No Rewrite ==