Yes but I think uk predated ISO3166. Are you sure? As far as I can make out, ISO3166 two-letter codes date from 1974, whereas Janet and the DNS both date from the early eighties. Not 100% conclusive, I admit—can you find a souce that dates "xxx.uk" (or "uk.xxx";-) to the early seventies?
The UK domain was created before the standardisation of country domains which is why we have UK and not the Ukraine who had to have UKR. In fact the TLDs are based on ISO3166 two-letter country codes - the UK is 'uk' and Ukraine is 'ua'. There is no '.ukr' TLD.
Technically we're also GB since the top level domains were based upon the same scheme as the country recognition for cars. No, the car labels are separate - they are based on a UN standard, and they don't quite match up to ISO3166/TLDs (for example, the Spanish TLD is ".es", but Spanish cars display "E").
Absolutely. But you must still sue for breach of contract. The terms for termination are within the contract.
Are you sure about all this? And are you a lawyer? I only ask because people who are lawyers (albeit ones who couldn't be said to be unbiased) would say that the GPL is a licence, not a contract. If you are a lawyer I would be genuinely fascinated in a detailed rebuttal of that article:-)
Well, no. The license exists. There's no way to go back in time to make it not exist. That cat is already out of the bag.
Until you give notice of termination of the license, it is still in effect and you're still not bound by your legal promise not to sue for infringement.
[I assume you mean "you're still bound":-) ].
Perhaps that's why the GPL has the following section?
8. Termination.
You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).
...that is, giving notice in advance that performing certain actions will terminate the licence.
For sure. But in this case it's the fact that it's unethical that has caused the law to be brought about (as opposed to, say, campaign contributions). I'm not daft enough to be suggesting that there is always a link between legality and ethics. That would be silly.
Re:Why bother keeping corporate policies up to dat
on
When Ethics and IT Collide
·
· Score: 2, Insightful
2. Someone looking at kiddie porn isn't an "ethical problem" either - its a legal problem! Like in "against the law".
Sure it's an ethical problem! That's why it's against the law.
Thanks for clarifying that you're pandering to provincialism. IMHO, that's just as bad as the douchebag who "corrected" you for using "maths" instead of "math."
Just because England is where the language originated doesn't make your particular dialect any more "correct" than any other dialect.
By hinting at exactly which meaning of "native English" I was referring to, I was acknowledging that there are actually other meanings of that phrase that are equally valid—I wasn't saying that mine was more correct (and if it came across like that, I apologise!)
Mathematics (pl.) originally denoted the mathematical sciences collectively, including geometry, astronomy, optics. Math is the Amer.Eng. shortening, attested from 1890; the British preference, maths is attested from 1911. So "maths" is a neologism here, and "math" is the older form.
Who said anything about neologisms? I only said it was an Americanism—that is, a word or phrase commonly used in American English but not other dialects: nothing wrong with that (and after all, there are plenty of Britishisms; I usually discover this when my American friends start looking at me oddly after I've said something!). It's what makes language interesting:-).
(Though I'd dispute that that evidence is conclusive proof that "math" is older than "maths"—only that it survives older in print. It's entirely possible that at that time such shortenings were more acceptable in American publications than British ones—that sort of thing seems to come in and out of fashion periodically...)
I don't mean to troll here, but what exactly was the point of linking to the Wikipedia article about England? Only to clarify that by "native English" I meant people from England, as opposed to any other definition:). You're right, the article doesn't back up my point at all—but over here everyone does say "maths" rather than "math". I believe this is true in most English-speaking countries; "math" is an Americanism...
Only non-native English speakers says "maths". It's "math", or if you must "mathematics" Carry on. Wrong. Native English speakers say "maths". Where are you from?
If I have a die that is weighted to land on 5 or 6 almost every time, it's not random.
It is random, it just isn't fair.
What's more, you can use it to generate fair, random 0s and 1s: throw it twice, and if you get 5-6, that's a 0; if you get 6-5, that's a 1. If you get two of the same number (5-5/6-6), repeat from the start. Assuming the throws are independent (i.e. it has no memory), and the probabilities of 5&6 are both greater than zero, you'll get a 0 or 1 with equal probability.
The article plays a similar trick, but it uses a hash function to even out the probabilities...
My programs perform isomorphic computations. Sure, using functional syntax I'll get a result like "f(x) = y". And using logical syntax, I'll get something along the lines of "|- f(x,y)". (Or if I just did it with the same interpreter, f(x,y) = #t. (Are you going to complain about the syntactic sleight of hand there too?)
I have no problem with the syntax, I have a problem with the results: the logic program (as Jhan pointed out) can answer the question "What pairs (X, Y) of numbers sum to 2", giving the answer {(0, 2), (1, 1), (2, 0)} (allowing flexibility for syntax, as you request;-). The corresponding functional program can't do that—indeed it cannot return any values other than True or False. So the computations are certainly not isomorphic.
The technical sense is the only sense that matters in technical discussions. I'll take your explanation as a concession of the point.
You're perfectly free to take my comment any way you like. However, if you read carefully, you'll find that the "technical" sense in which unification is involved at all is one which doesn't actually support your argument.
By the way, a unification, if it exists, is unique up to isomorophism.
No. As you quoted to me from Wikipedia: "If any common substitution instance of s and t is also an instance of u, u is called minimal unification.". There can be many unifications of two terms, but at most one minimal unification. In lattice terms, a unification is an upper bound for the terms; the minimal unification is the (unique) least upper bound.
If you know of a computer that can store arbitrary integers (let alone a set of arbitrary cardinality), I suggest you buy stock now.
Who said anything about storing arbitrary integers? I merely suggested that a functional program can compute a function on values from an infinite domain. Granted, a particular computer only has finite memory. But unfortunately for your proof, the computer does not need to store an entire value in memory to calculate a function of it. Take the example I suggested, of adding one to every element of a list: the computer can read in one value of the list, add one to it, output that number, then repeat—using hardly any storage at all. What's more, with a lazy functional language such as Haskell, that is how the computation will actually proceed: values are read from the input as they are needed, and output as they are produced. For arbitrarily large values of n, you can input a list of length n (on the terminal, or via the network), and the (finite) computer will produce the result as it goes along. There are clearly an infinite number of such lists. As you said in a previous post, "QED".
You're trolling, right? I have already done this, twice. The answer lies in the meaning of beta-reduction in the context of truth functions. (More succinctly, truth functions ARE FUNCTIONS). There's no need to "translate" the program, because application of truth functions is a specialized form of functional evaluation.
You've successfully shown that there is an injection from the space of logic program syntax into the space of functional program syntax—but the injection is not program-preserving. The languages impose very different semantics, as discussed above—in the logic language you can get a list of results; in the functional one, you can't.
The fact that logic programming languages use specialized unification algorithms is immaterial to this point. They are still computing the "substitution instance" join of the truth functional values of certain sentences.
Rubbish. You can't compute a substitution instance join of a truth functional value, as it's defined on syntax, not functions.
Thanks for the discussion. It's been entertaining:-)
The right word to use here is "correct", not "disingenuous."
No, your assertion is not correct. The programs are not the same, because they do not perform the same computation. Though the "add" relation that they define is the same, the functions that you can ask the language to evaluate are not the same. If I'm writing a program, I'm not just concerned about the fact that it contains a definition of a particular mathematical object—I need to know what it will tell me about that object, that is, what function of it will be evaluated. The fact that two programs calculate different functions and give different answers is not a trivial one:)
The model for evaluation in a logical programming language is called "unification". Well done.
Guess how functional programming languages are evaluated.
By unification! Only in a technical sense. When it is said that logic programming languages use "unification", they are overloading the term to mean that they use a particular algorithm (the "unification" algorithm) that gives the most general unification, and they use this to search for all ways of satisfying a given relation. Functional languages only give at most one way a relation can be satisfied (which is, after all, what makes a relation a function!).
Only, instead of just considering truth functions (they are included), arbitrary functions are evaluated. Logical programming is, trivially, a specialized form of functional programming. One that deals with truth functions. The fact that logical programming languages use different algorithms to compute the join is a mere implementation detail and irrelevant to this point.
No, it isn't. It's relevant because it produces different results!
The "hard" part is showing that every functional program has an equivalent logical program. Since these are all finite domains, a brute force approach is fine. Take a function F (as a set). For each element (x,y) in F, declare that f(x) = y is true using the logical language's syntax. Use short-hand syntax if you'd like. Q.E.D
Nice try, but no! Finite domains? The domain of a function in a functional program can be infinite. Take the identity function: that should be pretty clear. Or a function that adds one to each element of a list of integers. There are an infinite number of such lists (take the list that contains n instances of the number 7, for any natural number n). So your proof falls down.
And you haven't even proven the other half of the equivalence, that logic programs can be trivially rewritten as functional languages. Give some evidence for that: a program is equivalent to the function it computes, so given that the logic program given before computes all numbers x, y for which the relation "sum" holds for sum(x, y, 10), how would you transform the program to give that list of numbers in a functional language?
You're going to shit bricks when you realize just how trivial the transformation is. It's already in a functional language. A truth functional language. A truth function is a function that takes a sentence to a truth value.
That's just disingenuous. True, you could write the definitions of "add" from the Prolog program (with trivial adjustments for syntax) in Haskell, and it would define the same "add" function, in a purely mathematical sense. But it wouldn't be the same program.
Sure, it would answer queries such as "is add(2,3,5) true"? But it would be quite useless for the queries that the GP posed, even the basic "what value of X satisfies add(2,3,X)?". Answering that sort of question, using the truth function as a base, would require applying the truth function to a (potentially infinite) sequence of values, and the selection and generation of that sequence is definitely nontrivial. So the claim that functional and logic programming languages are "trivially" equivalent is yet to be demonstrated:)
Given the deficiencies of systrace (and ptrace) it is unlikely that this feature will be present in any future sudo release.
That's a shame...
Granted, as the paper shows, it's of no use as a feature for preventing your box from getting pwned. But the it can still be useful: often I'm more worried about the system being brought down by local users with root access, than by external forces. These users can be trusted not to break things deliberately, or overwrite the logs, but not necessarily to remember everything they've recently done when something goes wrong. ("Oh, yeah, I deleted/etc/passwd. Didn't think it was important, so I didn't tell you I'd done it. Is that why I can't log in then?")
That is just such complete nonsense. Firstly fibre is not "far" more expensive than copper, it is a bit more expensive. However look at the cost of a 10Gbps switch, and now tell me that the cost of fibre is prohibitive. If you can afford the switch you can sure as hell afford a few fibre patch leads. Not only that I bet it will be CX4 type Infiniband cables which are not cheap, and far more trouble in a rack than a fibre patch lead. I'd be surprised if they did that—the biggest advantage of copper over fibre is that everyone still has it! If you're going to move to Infiniband (multi-coax) cables, you might as well go for fibre as you say...—
What beats me is why they are bothering with multimode fibre. The cost of stocking both types quickly outweighs the slight increase in cost for single mode. There are plenty of places where it's practical and economical just stocking multimode fibre...
No, it's a syntax error. "The other 95% of programmers" refers to the complete set of programmers, less excluded subset. He defined that subset as himself, instead of himself plus others who can code properly; improper usage of "The other" is what caused his dependent clause to be false.
You can argue all you like, but it's still not a syntax error. It is, I grant you, not strictly speaking the correct choice of words—but since one could make the statement 100% correct by changing the situation (i.e. by systematically killing off programmers in their thousands until only 20 remain in the world[1]), but without changing the phrase, it is most certainly a gramatically correct sentence—even if the semantics are wrong in the given context.
[1] This would, of course, be taking the phrase "grammar nazi" to a whole new level...
E.g., saying "you should first make a disposable low-cost prototype" is good and fine. But I can tell you first hand that in a lot of cases the client has no clue what's the difference between a HTML prototype and a full working program. A lot (most?) non-technical clients think the hard part is placing the buttons or getting the colours right, so if the prototype looked right, that must be almost ready as the application goes.
Very true—non-technical people judge how ready your application is and how well it is built by how pretty it looks. A useful technique for dealing with this problem is to turn it to your advantage: for your prototype, make sure it is as ugly as possible while still achieving its aims (e.g. mismatched fonts, badly aligned fields, poorly chosen colours, blocky graphics etc). With luck, your customers will agree that it sort of does the right thing, but couldn't possibly be used as a basis for future work. For your beta, tidy up the formatting and get it about right, but leave the graphics and colours still looking patchy. Then for the final release, make sure everything looks slick and pixel-perfect.
This (sadly) can be a much more effective way of managing people's expectations than repeatedly telling them, "This is only a prototype and doesn't really work..."
Perhaps there should be a standard for SSL SMTP that is widely used, falling back to normal SMTP where needed You mean, like RFC2487, implemented in Exim, Postfix, Sendmail, MS Exchange,...?:-)
Assuming your switch supports it, you could use 802.11q packet tagging and vlans. Got there before me! Though I think you mean 802.1Q. Someone else suggested connecting this thing to a Linksys WRT54G* router as a "network processor". The switch built into the WRT units supports 802.1Q, so the single ethernet interface would not be a problem.
I'm going to get a business method patent on "waiting for patents to expire". How will that help you? By the time someone has made use of the claims in your patent, your patent will have expired so you won't be able to sue them;-)
600W (or more) of microwave energy though, pretty much has to have -some- shielding. Yes, of course it does:-) I didn't mean to suggest that there are microwave ovens out there with little or no shielding (at least, I certainly hope not!)—just pointing out that the shielding is not perfect, and certainly the energy that leaks out is of the right order of magnitude to be able to interfere with wireless networks...
It's cheaper to build a well sealed oven then it is to build a bigger microwave generator. And it's cheaper still to build a not-very-well-sealed oven with a lower power emitter, and hope that your customers don't complain! Microwaves certainly do emit interference in the 2.4GHz band: if you've ever used one of those video sender/receiver pairs that operate in the 2.4GHz range (eg these) you'll know how the picture and sound become unwatchable whenever a microwave oven is in use in a nearby room...
Slashdot Mirror
Yeah, they revalued the lira in 2005.
Are you sure about all this? And are you a lawyer? I only ask because people who are lawyers (albeit ones who couldn't be said to be unbiased) would say that the GPL is a licence, not a contract. If you are a lawyer I would be genuinely fascinated in a detailed rebuttal of that article :-)
Well, no. The license exists. There's no way to go back in time to make it not exist. That cat is already out of the bag.
Until you give notice of termination of the license, it is still in effect and you're still not bound by your legal promise not to sue for infringement.
[I assume you mean "you're still bound" :-) ].
Perhaps that's why the GPL has the following section?
...that is, giving notice in advance that performing certain actions will terminate the licence.
For sure. But in this case it's the fact that it's unethical that has caused the law to be brought about (as opposed to, say, campaign contributions). I'm not daft enough to be suggesting that there is always a link between legality and ethics. That would be silly.
Sure it's an ethical problem! That's why it's against the law.
Hey hey, not so fast :-)
Thanks for clarifying that you're pandering to provincialism. IMHO, that's just as bad as the douchebag who "corrected" you for using "maths" instead of "math."
Just because England is where the language originated doesn't make your particular dialect any more "correct" than any other dialect.
By hinting at exactly which meaning of "native English" I was referring to, I was acknowledging that there are actually other meanings of that phrase that are equally valid—I wasn't saying that mine was more correct (and if it came across like that, I apologise!) Mathematics (pl.) originally denoted the mathematical sciences collectively, including geometry, astronomy, optics. Math is the Amer.Eng. shortening, attested from 1890; the British preference, maths is attested from 1911. So "maths" is a neologism here, and "math" is the older form.Who said anything about neologisms? I only said it was an Americanism—that is, a word or phrase commonly used in American English but not other dialects: nothing wrong with that (and after all, there are plenty of Britishisms; I usually discover this when my American friends start looking at me oddly after I've said something!). It's what makes language interesting :-).
(Though I'd dispute that that evidence is conclusive proof that "math" is older than "maths"—only that it survives older in print. It's entirely possible that at that time such shortenings were more acceptable in American publications than British ones—that sort of thing seems to come in and out of fashion periodically...)
It is random, it just isn't fair.
What's more, you can use it to generate fair, random 0s and 1s: throw it twice, and if you get 5-6, that's a 0; if you get 6-5, that's a 1. If you get two of the same number (5-5/6-6), repeat from the start. Assuming the throws are independent (i.e. it has no memory), and the probabilities of 5&6 are both greater than zero, you'll get a 0 or 1 with equal probability.
The article plays a similar trick, but it uses a hash function to even out the probabilities...
I have no problem with the syntax, I have a problem with the results: the logic program (as Jhan pointed out) can answer the question "What pairs (X, Y) of numbers sum to 2", giving the answer {(0, 2), (1, 1), (2, 0)} (allowing flexibility for syntax, as you request ;-). The corresponding functional program can't do that—indeed it cannot return any values other than True or False. So the computations are certainly not isomorphic.
The technical sense is the only sense that matters in technical discussions. I'll take your explanation as a concession of the point.You're perfectly free to take my comment any way you like. However, if you read carefully, you'll find that the "technical" sense in which unification is involved at all is one which doesn't actually support your argument.
By the way, a unification, if it exists, is unique up to isomorophism.No. As you quoted to me from Wikipedia: "If any common substitution instance of s and t is also an instance of u, u is called minimal unification.". There can be many unifications of two terms, but at most one minimal unification. In lattice terms, a unification is an upper bound for the terms; the minimal unification is the (unique) least upper bound.
If you know of a computer that can store arbitrary integers (let alone a set of arbitrary cardinality), I suggest you buy stock now.Who said anything about storing arbitrary integers? I merely suggested that a functional program can compute a function on values from an infinite domain. Granted, a particular computer only has finite memory. But unfortunately for your proof, the computer does not need to store an entire value in memory to calculate a function of it. Take the example I suggested, of adding one to every element of a list: the computer can read in one value of the list, add one to it, output that number, then repeat—using hardly any storage at all. What's more, with a lazy functional language such as Haskell, that is how the computation will actually proceed: values are read from the input as they are needed, and output as they are produced. For arbitrarily large values of n, you can input a list of length n (on the terminal, or via the network), and the (finite) computer will produce the result as it goes along. There are clearly an infinite number of such lists. As you said in a previous post, "QED".
You're trolling, right? I have already done this, twice. The answer lies in the meaning of beta-reduction in the context of truth functions. (More succinctly, truth functions ARE FUNCTIONS). There's no need to "translate" the program, because application of truth functions is a specialized form of functional evaluation.You've successfully shown that there is an injection from the space of logic program syntax into the space of functional program syntax—but the injection is not program-preserving. The languages impose very different semantics, as discussed above—in the logic language you can get a list of results; in the functional one, you can't.
The fact that logic programming languages use specialized unification algorithms is immaterial to this point. They are still computing the "substitution instance" join of the truth functional values of certain sentences.Rubbish. You can't compute a substitution instance join of a truth functional value, as it's defined on syntax, not functions.
Thanks for the discussion. It's been entertaining :-)
No, your assertion is not correct. The programs are not the same, because they do not perform the same computation. Though the "add" relation that they define is the same, the functions that you can ask the language to evaluate are not the same. If I'm writing a program, I'm not just concerned about the fact that it contains a definition of a particular mathematical object—I need to know what it will tell me about that object, that is, what function of it will be evaluated. The fact that two programs calculate different functions and give different answers is not a trivial one :)
The model for evaluation in a logical programming language is called "unification". Well done. Guess how functional programming languages are evaluated.By repeated beta reduction?
By unification! Only in a technical sense. When it is said that logic programming languages use "unification", they are overloading the term to mean that they use a particular algorithm (the "unification" algorithm) that gives the most general unification, and they use this to search for all ways of satisfying a given relation. Functional languages only give at most one way a relation can be satisfied (which is, after all, what makes a relation a function!). Only, instead of just considering truth functions (they are included), arbitrary functions are evaluated. Logical programming is, trivially, a specialized form of functional programming. One that deals with truth functions. The fact that logical programming languages use different algorithms to compute the join is a mere implementation detail and irrelevant to this point.No, it isn't. It's relevant because it produces different results!
The "hard" part is showing that every functional program has an equivalent logical program. Since these are all finite domains, a brute force approach is fine. Take a function F (as a set). For each element (x,y) in F, declare that f(x) = y is true using the logical language's syntax. Use short-hand syntax if you'd like. Q.E.DNice try, but no! Finite domains? The domain of a function in a functional program can be infinite. Take the identity function: that should be pretty clear. Or a function that adds one to each element of a list of integers. There are an infinite number of such lists (take the list that contains n instances of the number 7, for any natural number n). So your proof falls down.
And you haven't even proven the other half of the equivalence, that logic programs can be trivially rewritten as functional languages. Give some evidence for that: a program is equivalent to the function it computes, so given that the logic program given before computes all numbers x, y for which the relation "sum" holds for sum(x, y, 10), how would you transform the program to give that list of numbers in a functional language?That's just disingenuous. True, you could write the definitions of "add" from the Prolog program (with trivial adjustments for syntax) in Haskell, and it would define the same "add" function, in a purely mathematical sense. But it wouldn't be the same program.
Sure, it would answer queries such as "is add(2,3,5) true"? But it would be quite useless for the queries that the GP posed, even the basic "what value of X satisfies add(2,3,X)?". Answering that sort of question, using the truth function as a base, would require applying the truth function to a (potentially infinite) sequence of values, and the selection and generation of that sequence is definitely nontrivial. So the claim that functional and logic programming languages are "trivially" equivalent is yet to be demonstrated :)
That's a shame...
Granted, as the paper shows, it's of no use as a feature for preventing your box from getting pwned. But the it can still be useful: often I'm more worried about the system being brought down by local users with root access, than by external forces. These users can be trusted not to break things deliberately, or overwrite the logs, but not necessarily to remember everything they've recently done when something goes wrong. ("Oh, yeah, I deleted /etc/passwd. Didn't think it was important, so I didn't tell you I'd done it. Is that why I can't log in then?")
You can argue all you like, but it's still not a syntax error. It is, I grant you, not strictly speaking the correct choice of words—but since one could make the statement 100% correct by changing the situation (i.e. by systematically killing off programmers in their thousands until only 20 remain in the world[1]), but without changing the phrase, it is most certainly a gramatically correct sentence—even if the semantics are wrong in the given context.
[1] This would, of course, be taking the phrase "grammar nazi" to a whole new level...
Very true—non-technical people judge how ready your application is and how well it is built by how pretty it looks. A useful technique for dealing with this problem is to turn it to your advantage: for your prototype, make sure it is as ugly as possible while still achieving its aims (e.g. mismatched fonts, badly aligned fields, poorly chosen colours, blocky graphics etc). With luck, your customers will agree that it sort of does the right thing, but couldn't possibly be used as a basis for future work. For your beta, tidy up the formatting and get it about right, but leave the graphics and colours still looking patchy. Then for the final release, make sure everything looks slick and pixel-perfect.
This (sadly) can be a much more effective way of managing people's expectations than repeatedly telling them, "This is only a prototype and doesn't really work..."
(Yes, I know, I know...)