The Geneva Conventions _always_ apply. What may be open for debate is whether POW status applies; in that instance, the prisoners should have their status determined by competant tribunal as soon as possible. Until their status is determined, they are eligilbe for treatment as POWs. Afterwards, they may be treated as criminals according to criminal law if they are determined to not be POWs.
This is all pretty clear. What the US is doing is in direct contravention.
The ground doesn't give much. If you drop a device 1m to the floor (ie, taking about 1/2 second to fall), it'll be doing 5m/s (1/2 gs) when it hits. Even if it comes to a dead stop rather than bouncing, 68g of acceleration means that it takes 1/100s to do so. If it takes that long and decelerates uniformly, it'll travel an additional 2.5cm in the process. (These are all ballpark figures). ie, deceleration is higher than that.
Note also that shock force doesn't mean you can have the heads reading from the drive when it undergoes that acceleration.
I've used the rhino implementation of javascript as the basis for a scripting engine in a number of projects now. Javascript is lightweight, supports many useful idioms, and with rhino, integrates well with existing apps. Exposing your APIs to a scripting layer is pretty simple.
What particularly attracted me to rhino (apart from being a bit of a js nut) was the security model. That is to say, it has one, and it's pretty well worked out. It's typically nontrivial to add sandboxed scripting support to an application that integrates with the application's model of user permissions*: if you look around, you'll find lots of examples of various scripting languages being plumbed into applications, but typically the scripting layer is available to "admins only" due to these kinds of security concerns.
* even in java, which already has a semi-decent security model**
** It's a lot of work getting security providers to stack properly. Layering application-domain runtime security over an application running inside a container with its own security provider is barely doable.
You're incorrect. The nice -> priority doesn't work that way; and with twos' complement, if you ignore the sign bit then the higher the value of the remainder, the less negative (closer to -1) it is.
You have a precondition that you claim has the intent of preserving a type. If you intend type preservation, then you need NOT ONLY a precondition BUT ALSO a postcondition.
The precondition of a base class may be loosened. The postcondition, however, can only be tightened.
The result, if you permit precondition loosening, is that your example still works and you can still type objects correctly.
One might take the (erroneous) position of rejecting this argument and positing that you should only have to specify a precondition; in that case the intent of the precondition (type preservation) is clearly lost.
So in a nutshell I basically have to disagree: there are reasons to permit the loosening of preconditions, but no reasons to argue that they may be tightened by a derived class. You're still left with an important mechanism for specifying programs.
I think your analogy is broken. Consider a base class, B, with a method f and an attribute x. B.f(x) has the precondition "x>0".
If a derived class, D, follows your precondition rule, then it would be possible to supply an overridden version of f such that: D.f(x) pre "x > 1". Note that objects of type D cannot now be treated as objects of type B, their base class, because they have tightened the preconditions. Preconditions can change - but they can only be loosened. (You can use a D in more situations than using a B; but you can treat a D as a B in all cases.)
So (and putting my statement the right way round: I think the precondition on a base class must entail the precondition on a derived class): your base precondition is "this is labelled as a fruit". The precondition on the derived class can be "this is labelled as a fruit or a vegetable". The precondition on the derived class is entailed if the precondition on the base class holds.
Of course, with your analogy your precondition is actually an invariant and can be applied as a postcondition too: and that is why your analogy appears to cause problems.
"You can do the same thing in any other language but you have to always remember to call super methods when you are doing your pre and post assertions otherwise your subclasses won't adhere to the contract."
Hang about, that doesn't sound quite right. Subclasses can loosen requirements but only tighten outcomes. So your superclass has to call down when checking preconditions (that is, the subclass preconditions must entail the superclass preconditions). Postconditions work the way you describe.
(My Eiffel exposure is about 12 years more out-of-date than yours, but I think the DbC reasoning still stands.)
I'm not sure why it is obvious that javascript (or ecmascript) are _very_ unsuitable for the things you list. It doesn't just run in a browser; don't confuse the language (which I'm a big fan of) with the environment and APIs that it exposes.
Both Rhino and Spidermonkey are two examples of "embeddable" javascript implementations that permit the exposure of library functionality. In the case of Rhino, you pretty much get all of Java's APIs "for free" in the example command-line interpreter.
Dan Brown isn't smart enough to realise he's the kind of idiot Eco was poking fun at in Foucault's.
My first impression when I read DVC was, "this is a cheap knock-off of HBHG". It's also appallingly badly written, not to mention poorly plotted: the "Templar scholar" repeatedly needs to be told basic facts by third parties in the name of exposition. But even worse, the basic grammar is appalling. The book resembles something written by an eight-year-old.
The ultimate insult, however, is how reprints of Eco's books are likened to "the Da Vinci Code" in the blurb on the back. That's enough to make all the descendents of the baby Jesus cry.
An example of how to exploit this: SSO phishing.
on
Cross Site Cooking
·
· Score: 1
SAML implementations (shibboleth, lib aliance etc) for distributed authentication usually include WAYF (where are you from) servers that direct a user to their home site for authentication purposes.
It's often the case that a WAYF implementation will utilise a cookie in order to "remember" the user's home site, permitting either the selection of an appropriate default or the automatic redirection to the user's local SSO origin.
The replacement of that cookie would mean the user doesn't wind up going to their usual origin to authenticate, potentially permitting credential capture.
WAYF implementatinos may mitigate against this by sanity-checking the cookie (only redirecting to members of a federation, for instance) - however, this is an example of how a fairly obscure bug might have wide-reaching consequences.
[[[ The GP said "I guess you're not a fan of the quaint notion that "a better world starts with me". By that (rediculous) theory, you would prioritize getting a haircut while a civilian was murdered in front of you. ]]]
If that's how you interpret it, that says a great deal about you, and is pretty damning.
From a "rational" point of view, what do you need? Enough energy to live?
The danger with "rational" arguments like this is that they avoid moral questions through spurious reductionism. Personally, I feel a moral responsibility toward other moral creatures (I'm european, it goes with the territory). The question is, what's my responsisbility towards other things: more abstract stuff, like the state of the environment, the continued existence of polar bears, etc? I'd answer that as follows: those things deserve moral consideration because of the regard they are held in by other moral beings. I don't particularly care about the reasons: a bunch of fluffy econuts want to preserve polar bears just because it'd make them sad to see such a noble species disappear. It may not be a "rational" argument (and I elide any discussion that ignoring "emotional" arguments is in any way rational) but by what metric does that make it any less relevant?
Use the above. If you feel you _must_ provide 15-minute-accuracy, keep a logbook: either paper, an email address you target, or something similar. It's mostly a question of developing a habit that's relatively uninvasive and that works for you. If you can't remember what you did at the end of the week, use a shorter interval: last 10 minutes of the day, or twice (just before lunch and just at the end of the day).
If you establish working habits that effectively use tools, you may very well be able to use those tools to help track your time. Eg, keep everything (design notes to finished products) under source-code control. Then a simple habit (eg, an update at the start of a session) before you work lets you use pretty simple scripts to extract details of what you were working on (to a project level or finer) which can augment (or possibly replace) your logbook.
Finally, it's worthwhile reviewing your log after you finish a project. Try to understand where your time is going; compare how long you spent no an area against your initial estimates. That can drastically improve your technical estimation skills, which are important as a contractor.
Summary: make it low impact; make it a habit; review the results regularly.
Unlike some of the other comments here, I think you've basically got it. Examples in Java can be as simple as this, too: the "icing" from DI frameworks is that they generally use introspection and reflection to manage object instantiation and to "jsut work" against any set of classes that you'd like to instantiate and supply dependencies to. You can knock that up in Ruby pretty simply; it's as straightforward in Java, too, but the expression of the reflection code is typically more verbose.
Late binding is exactly it. Lots of ways to do it: dependency injection is one approach. Shoving implementations into a tree/namespace of COM objects at well-known locations is another way. The important thing is that the burden of selecting the implementation and instantiating it is not on the class that uses it, but on the framework that provides it.
Slashdot Mirror
The Geneva Conventions _always_ apply. What may be open for debate is whether POW status applies; in that instance, the prisoners should have their status determined by competant tribunal as soon as possible. Until their status is determined, they are eligilbe for treatment as POWs. Afterwards, they may be treated as criminals according to criminal law if they are determined to not be POWs.
This is all pretty clear. What the US is doing is in direct contravention.
"codes" used like that is a term for parallel software that's particularly prevalent amongst the number-crunching crowd.
The ground doesn't give much. If you drop a device 1m to the floor (ie, taking about 1/2 second to fall), it'll be doing 5m/s (1/2 gs) when it hits. Even if it comes to a dead stop rather than bouncing, 68g of acceleration means that it takes 1/100s to do so. If it takes that long and decelerates uniformly, it'll travel an additional 2.5cm in the process. (These are all ballpark figures). ie, deceleration is higher than that.
Note also that shock force doesn't mean you can have the heads reading from the drive when it undergoes that acceleration.
I've used the rhino implementation of javascript as the basis for a scripting engine in a number of projects now. Javascript is lightweight, supports many useful idioms, and with rhino, integrates well with existing apps. Exposing your APIs to a scripting layer is pretty simple.
What particularly attracted me to rhino (apart from being a bit of a js nut) was the security model. That is to say, it has one, and it's pretty well worked out. It's typically nontrivial to add sandboxed scripting support to an application that integrates with the application's model of user permissions*: if you look around, you'll find lots of examples of various scripting languages being plumbed into applications, but typically the scripting layer is available to "admins only" due to these kinds of security concerns.
* even in java, which already has a semi-decent security model**
** It's a lot of work getting security providers to stack properly. Layering application-domain runtime security over an application running inside a container with its own security provider is barely doable.
Yes.
What's wrong with just _shooting_ someone?
You're incorrect. The nice -> priority doesn't work that way; and with twos' complement, if you ignore the sign bit then the higher the value of the remainder, the less negative (closer to -1) it is.
You have a precondition that you claim has the intent of preserving a type. If you intend type preservation, then you need NOT ONLY a precondition BUT ALSO a postcondition.
The precondition of a base class may be loosened. The postcondition, however, can only be tightened.
The result, if you permit precondition loosening, is that your example still works and you can still type objects correctly.
One might take the (erroneous) position of rejecting this argument and positing that you should only have to specify a precondition; in that case the intent of the precondition (type preservation) is clearly lost.
So in a nutshell I basically have to disagree: there are reasons to permit the loosening of preconditions, but no reasons to argue that they may be tightened by a derived class. You're still left with an important mechanism for specifying programs.
I think your analogy is broken. Consider a base class, B, with a method f and an attribute x. B.f(x) has the precondition "x>0".
If a derived class, D, follows your precondition rule, then it would be possible to supply an overridden version of f such that: D.f(x) pre "x > 1". Note that objects of type D cannot now be treated as objects of type B, their base class, because they have tightened the preconditions. Preconditions can change - but they can only be loosened. (You can use a D in more situations than using a B; but you can treat a D as a B in all cases.)
So (and putting my statement the right way round: I think the precondition on a base class must entail the precondition on a derived class): your base precondition is "this is labelled as a fruit". The precondition on the derived class can be "this is labelled as a fruit or a vegetable". The precondition on the derived class is entailed if the precondition on the base class holds.
Of course, with your analogy your precondition is actually an invariant and can be applied as a postcondition too: and that is why your analogy appears to cause problems.
"You can do the same thing in any other language but you have to always remember to call super methods when you are doing your pre and post assertions otherwise your subclasses won't adhere to the contract."
Hang about, that doesn't sound quite right. Subclasses can loosen requirements but only tighten outcomes. So your superclass has to call down when checking preconditions (that is, the subclass preconditions must entail the superclass preconditions). Postconditions work the way you describe.
(My Eiffel exposure is about 12 years more out-of-date than yours, but I think the DbC reasoning still stands.)
I'm not sure why it is obvious that javascript (or ecmascript) are _very_ unsuitable for the things you list. It doesn't just run in a browser; don't confuse the language (which I'm a big fan of) with the environment and APIs that it exposes.
Both Rhino and Spidermonkey are two examples of "embeddable" javascript implementations that permit the exposure of library functionality. In the case of Rhino, you pretty much get all of Java's APIs "for free" in the example command-line interpreter.
Dan Brown isn't smart enough to realise he's the kind of idiot Eco was poking fun at in Foucault's.
My first impression when I read DVC was, "this is a cheap knock-off of HBHG". It's also appallingly badly written, not to mention poorly plotted: the "Templar scholar" repeatedly needs to be told basic facts by third parties in the name of exposition. But even worse, the basic grammar is appalling. The book resembles something written by an eight-year-old.
The ultimate insult, however, is how reprints of Eco's books are likened to "the Da Vinci Code" in the blurb on the back. That's enough to make all the descendents of the baby Jesus cry.
Spot on. His thinking is flawed and newtonian.
Parent needs modding up.
SAML implementations (shibboleth, lib aliance etc) for distributed authentication usually include WAYF (where are you from) servers that direct a user to their home site for authentication purposes.
It's often the case that a WAYF implementation will utilise a cookie in order to "remember" the user's home site, permitting either the selection of an appropriate default or the automatic redirection to the user's local SSO origin.
The replacement of that cookie would mean the user doesn't wind up going to their usual origin to authenticate, potentially permitting credential capture.
WAYF implementatinos may mitigate against this by sanity-checking the cookie (only redirecting to members of a federation, for instance) - however, this is an example of how a fairly obscure bug might have wide-reaching consequences.
If that were truly the case then a more accurate use of the polygraph would be to switch the labels on the "lie" and "truth" blinkenlights :-)
[[[
The GP said "I guess you're not a fan of the quaint notion that "a better world starts with me". By that (rediculous) theory, you would prioritize getting a haircut while a civilian was murdered in front of you.
]]]
If that's how you interpret it, that says a great deal about you, and is pretty damning.
That's one day of his time. Probably worth it.
Just out of curiosity (since you mention "civilised countries"), are you pro-death-penalty?
An _adjustable_ spanner is adjustable. A spanner isn't.
If you prefer sex to pretty much anything else, you're clearly not doing pretty much anything else right.
Your definition of "European liberal" does not describe those parties and groups in Europe who identify themselves as "liberal". Quite the opposite.
:-)
The main difference is that in the US, "liberal" appears to be a perjorative term
From a "rational" point of view, what do you need? Enough energy to live?
The danger with "rational" arguments like this is that they avoid moral questions through spurious reductionism. Personally, I feel a moral responsibility toward other moral creatures (I'm european, it goes with the territory). The question is, what's my responsisbility towards other things: more abstract stuff, like the state of the environment, the continued existence of polar bears, etc? I'd answer that as follows: those things deserve moral consideration because of the regard they are held in by other moral beings. I don't particularly care about the reasons: a bunch of fluffy econuts want to preserve polar bears just because it'd make them sad to see such a noble species disappear. It may not be a "rational" argument (and I elide any discussion that ignoring "emotional" arguments is in any way rational) but by what metric does that make it any less relevant?
Use the above. If you feel you _must_ provide 15-minute-accuracy, keep a logbook: either paper, an email address you target, or something similar. It's mostly a question of developing a habit that's relatively uninvasive and that works for you. If you can't remember what you did at the end of the week, use a shorter interval: last 10 minutes of the day, or twice (just before lunch and just at the end of the day).
If you establish working habits that effectively use tools, you may very well be able to use those tools to help track your time. Eg, keep everything (design notes to finished products) under source-code control. Then a simple habit (eg, an update at the start of a session) before you work lets you use pretty simple scripts to extract details of what you were working on (to a project level or finer) which can augment (or possibly replace) your logbook.
Finally, it's worthwhile reviewing your log after you finish a project. Try to understand where your time is going; compare how long you spent no an area against your initial estimates. That can drastically improve your technical estimation skills, which are important as a contractor.
Summary: make it low impact; make it a habit; review the results regularly.
Unlike some of the other comments here, I think you've basically got it. Examples in Java can be as simple as this, too: the "icing" from DI frameworks is that they generally use introspection and reflection to manage object instantiation and to "jsut work" against any set of classes that you'd like to instantiate and supply dependencies to. You can knock that up in Ruby pretty simply; it's as straightforward in Java, too, but the expression of the reflection code is typically more verbose.
Late binding is exactly it. Lots of ways to do it: dependency injection is one approach. Shoving implementations into a tree/namespace of COM objects at well-known locations is another way. The important thing is that the burden of selecting the implementation and instantiating it is not on the class that uses it, but on the framework that provides it.