Vista comes with APIs for condition variables and reader-writer locks so you don't have to spend 15 minutes writing your own.
Well, fifteen minutes writing, plus ten years of programming experience to be sure that you aren't going to create a deadlock in some obscure circumstance.
Or, you know, typical undergraduate-level education in concurrent programming best-practice for avoiding such issues.
For example, it used to be that a socket handle was not a synchronization object, so you couldn't integrate select() calls with other synchronization primitives. Maybe that's been fixed, but if it isn't sockets, it will be something else.
[...] The WSAEventSelect function behaves exactly like the WSAAsyncSelect function. However, instead of causing a Windows message to be sent on the occurrence of an FD_XXX network event (for example, FD_READ and FD_WRITE), an application-designated event object is set. [...]
WSAEventSelect has been available since NT 3.51 / Win95. Are you sure you know what you're talking about? What "something else" do you mean, because I've never encountered anything I can't synchronise on in Windows.
PThreads gives you condition variables. They are harder to program, but once you understand them, you can use them to synchronize on absolutely anything. You aren't dependent on the OS to have foreseen your special needs and provided special synchronization primitives to meet them.
Please explain to me how (without creating an additional thread, something I could do equally in any OS) I can use a condition variable to catch an event that isn't specifically supported.
If you really want the Win32 model, it is easy enough to build it on top of PThreads, but there is no way to build PThreads on top of Win32.
I abhor the use of the word "enjoy" in the media and by marketing people in particular. Form fields may *have* protection; they do not *enjoy* protection because they aren't fucking conscious. And nobody enjoys, say, the protection of car insurance. I don't sit at home feeling all warm and fuzzy because I've just taken out some policy.
Seeing this in tech news just shows how much this has spread. I no longer want to use the word enjoy at all because every time I hear it, I am reminded of this usage and feel a twinge of annoyance.
I want my English language back from these idiots!
Online Etymology Dictionary enjoy c.1380, [...] Sense of "have the use or benefit of" first recorded c.1430. [...]
I doubt that Koingo, as serious Mac developers, would go to such lengths as to use a pirated key just to "investigate the competition". Which is why I suspect that they "embellished" their story about permanently losing data.
Who's to say that they didn't have data they wanted to keep in that directory (e.g. screen caps they'd taken with the trial version during some project or other)?
A few days ago reading up on good C++ coding techniques I came across Stroustrup's (creator of C++) page citing the coding rules used when working on the Joint Strike Fighter. Reading through the various rules used, this one caught my attention:
AV Rule 25 (MISRA Rule 127)
The time handling functions of library shall not be used.
I got to thinking if we had any decent alternatives (at least in C++). And yes there are alternatives and all of them looked equally bad to me. Looks like the F22 guys might have had the same problem finding and using a robust fault tolerant time library.
Why would you need to use a library? The only format you're likely to need in such software is milliseconds offset from some suitable epoch. As long as your hardware can produce such a time value, you're fine.
Well, of course they do. I think what the OP was unable to believe was that such an idiotic, beginners' level mistake as *crashing when the date changes backwards* could be made by the kind of experienced, highly-paid programmer who typically works on military avionics software. The Therac-25 issue was a concurrency one. Admittedly, a rather stupid one, but they are of a class that's generally harder to avoid and/or predict.
... I do know a little legal theory, and it occurs to me that:
a) the passage that denies permission to run Vista Home et al in a VM is rather ambiguous, in that it could just be a clarification that the rule that allows you to run the higher-end versions in a virtual machine *at the same time* as a real machine doesn't apply. I'd really like to here official comment from MS's lawyers about how they intended this to be interpreted, and so far I haven't seen any.
b) Even if the ambiguity is only small, it still seems to be there to me, and the rule of contra proferentem should mean it is interpreted in the consumer's favour.
c) It might not make a difference anyway. As I understand it (and I'll admit my understanding of this area is rather fuzzy, because it is a very obscure corner of contract law that I've only heard about once, so I could be completely wrong), for a contract term to be enforceable, one or the other party must derive some legitimate benefit from it. I don't see what legitimate benefit MS derive from restricting the use of their products in this fashion.
Is there anything worse than law opinions on slashdot? That's a general complaint.
Not really, no. I happen to think that one was substantially above average, though.
Specifically, the images found on a computer that hadn't been hacked, a diary, and an eyewitness surely made the tainted evidence on the original computer unneeded.
Yes, however I was talking about generalities, not this specific case. In this specific case, the fact that he admitted the offence means the evidence itself is totally irrelevant.
Even if the original images had been the only thing, ISP records would likely have buried him if he wasn't being careful.
Would they? Depends on a lot of things. Was he using ISP servers for access? Does the ISP keep logs, and if so for how long? Does the ISP log HTTP requests across its network that don't use its servers. These aren't trivially answerable, and in a large number of cases the answers to all of them will be 'no'. I know that for me the answers are 'no' (as in I never use my ISP servers for anything, except outgoing e-mail, which there's no suggestion in this case of being incriminating), 'probably but irrelevant because of the first answer', and 'no'.
So, no, I don't think that's anything like as clear cut as you suggest. There's a chance his ISP would have something on him, but not a very large one.
But, basically, the legal opinion I was giving is approximately sound. I know this because in one case it has been used successfully. Admittedly, that wasn't in the USA, but the basic laws involved are very similar.
This case seems a bit more worrying because the person who placed the trojan also submitted the evidence, but really any trojan could be enough to place the evidence in doubt - if this is thrown out on those grounds then anyone who commits crime via computer can make sure it has a trojan and have all of the evidence thrown out. That won't happen - what will happen is that forensics will get better and better at working out what is genuine evidence in digital media and what is fake.
There have been cases thrown out in the UK on precisely these grounds. I think the reality is that data forensics is very hit & miss. Sometimes historical information about what has been on the disk will be easily retrievable. Other times, it will not be feasible. Correlating the age of different versions of different sectors may be totally impossible, and that would be an important step in the kind of analysis you're talking about -- without it, it may be impossible to put a firm date on the relative ages of a variety of files, so who is to say whether the trojan or the porn was there first?
Slashdot liberal bias (AKA. fired IBM employee deprived of "rights" to view pornography on company dollar).
Read here before deciding anything about this case. IBM did not have a written policy against using their computers this way, therefore it should not have been a firing offence: the employee should have received a warning for it first. This strikes me as a perfectly reasonable conclusion -- do you have any grounds for arguing that he shouldn't have a right to be warned before being fired for something that is not considered by the company's general policy a serious offence?
Logical, since you have *no right* in the first place to view child pornography in this country in the first place.
Yes, but you do have a right to be free from unwarranted search and seizure.
Que the next YRO article, where someone claims the "right" to commit a crime.
You mean either 'cue' or 'queue', I'm not entirely sure which. Can you point me to any article within the last, say, 6 months, where anyone has claimed such a thing?
Do you want to try reading the article. It's dated yesterday, and describes how the 'illegal search & seizure' conclusion of a lower court was overturned by the federal appeals court, following which the judge admitted the offence.
In the big picture of things, If he didnt touch a child... is he really guilty of anything?
Based on the article, he possibly did, but the evidence against him was inadmissable due to the length of time that had passed (some kind of legal protection, presumably intended to protect people against testimonies from false memories).
I'd toss out the conviction of the judge based on an illegal search and seizure,
Illegal search & seizure is the wrong grounds. First, the search was conducted by a Canadian who was not acting as an agent of US authorities, therefore isn't bound by US law. I'm not sure, but I think the court that overturned the decision that it was illegal is correct.
But, the fact that he installed the trojan on the PC the images were found on means that we must trust that he did not place the images there himself. Now, the fact that the judge admitted the offence in the end means presumably he did not, but there would likely be no clear way of telling in the case that he hadn't.
Isn't the hacker in legal trouble for downloading the same 3,000 pictures? (How else did he know the content was illegal?) He had to download them to his computer to view them, thereby committing the same crime as the guy he outed.
No. In most countries, and I think Canada is included, you're legally clear as long as you don't keep copies, i.e. you take necessary steps to report to an appropriate authority (not usually legally necessary, but you would be allowed to do it) and then wipe them from your computer's disks. Making sure you get any cached copies. You have to have intentionally created or kept copies, in knowledge of the contents, for the relevant laws to come into play.
Credit card companies justify their ridiculous interest rates by pointing to the losses the "have to eat" when credit card fraud happens. Since they no longer have to eat those losses, where's my rate cut, you theiving bastards?
They're talking about a different kind of fraud. They're talking about people who steal identities, use them to apply for high-limit cards, then go on a spending spree before disappearing and never being seen again.
There's nobody they can charge in these circumstances.
I'd use a define( 'APP_PATH', value ), instead of a variable, at least it can't be overridden by GET/POST/REQUEST variables directly if a bright guy enables global vars.
As long as you ensure it's set in every top level file (and I usually use just one for each site), it can't be overridden by external vars, even with register globals on -- that happens before code starts executing.
Again your confusion is due to your misunderstanding, not any fault with PHP.
My point is that it's difficult to understand. I do understand it, believe me, which is why I used it as an example. *But* I constantly see people getting confused by this behaviour. It doesn't match their internal model of theway they thought the language worked.
I don't know if that behaviour is right or wrong in a formal sense.
I'm not saying its wrong. I know that according to the language design it's complete correct. I *am* saying it's counterintuitive, and evidence that something is wrong with the design.
If you're a programmer and you don't see huge problems with both the design of PHP itself and the standard library you should just quit now and find another hobby/profession.
I'm a programmer. I work with PHP. I see a hell of a lot of problems with its design and implementation. Am I ready to dump it and switch to something better? You bet. I've been waiting for the chance for the last 5 years or more.
Can I actually do this?
No. The marketplace is such that if I implement my solutions in any other environment, I'm cutting myself out of large chunks of the market simply because people might choose a hosting provider that doesn't support whatever alternative language I choose to use.
If you were such a great programmer, you would know better, and you wouldn't be using PHP in the first place.
You know, a lot of us PHP programmers don't use the language out of choice. We use it because either (a) the boss insists on it, or (b) we're programming for deployment to a choice of web hosting providers that is out of our control, and know that PHP is the only scripting environment that we can rely on the availability of.
Unless you see a workable solution for people in either of these situations, shut up.
1. Pascal programs cannot be modular -- they are defined in a single file that starts 'program;' and continues until the matching 'end' statement. If you are using standard pascal (as most of the universities that used it as a teaching language restricted themselves to), you cannot use 'unit' (which is unsupported in many implementations, being I believe a Borland innovation) or C-style '#include' (which was supported in the implementation at my university, but we were explicitly instructed not to use it).
2. Pascal only recognises a single sized integer type. No longints or shorts or anything like that.
3. Pascal has no means to take the address of a variable (i.e. the equivalent of C's & operator).
4. Pascal does not allow a file to be contained in a structure. They are only allowed to be declared as top-level variables.
5. Pascal does not have any mechanism to open a file with an arbitrary filename. Files are declared as variables, and are implicitly associated with an OS file. Typically, the name used is the same as the variable's name, but this is not standardised. You can (according to the standard) implicitly create files to match those named on the command line (see section 'header files'), but this mechanism isn't widely supported.
Is this enough reason for Pascal (as standardised, and as originally implemented by Wirth) not to be a useful real-world language?
Of course, the variety of extended Pascals available make it a substantially more useful language.
Slashdot Mirror
Vista comes with APIs for condition variables and reader-writer locks so you don't have to spend 15 minutes writing your own.
Well, fifteen minutes writing, plus ten years of programming experience to be sure that you aren't going to create a deadlock in some obscure circumstance.
Or, you know, typical undergraduate-level education in concurrent programming best-practice for avoiding such issues.
WSAEventSelect has been available since NT 3.51 / Win95. Are you sure you know what you're talking about? What "something else" do you mean, because I've never encountered anything I can't synchronise on in Windows.
PThreads gives you condition variables. They are harder to program, but once you understand them, you can use them to synchronize on absolutely anything. You aren't dependent on the OS to have foreseen your special needs and provided special synchronization primitives to meet them.
Please explain to me how (without creating an additional thread, something I could do equally in any OS) I can use a condition variable to catch an event that isn't specifically supported.
If you really want the Win32 model, it is easy enough to build it on top of PThreads, but there is no way to build PThreads on top of Win32.
Which is presumably how come there are no pthread implementations available on windows.
Seeing this in tech news just shows how much this has spread. I no longer want to use the word enjoy at all because every time I hear it, I am reminded of this usage and feel a twinge of annoyance.
I want my English language back from these idiots!
You'll have to go a long way back to claim this one.
A software license (be it EULA or something else) is not a contract.
Bollocks. An EULA is a contract that grants a license in exchange for certain conditions on the usage of the licensed material.
I doubt that Koingo, as serious Mac developers, would go to such lengths as to use a pirated key just to "investigate the competition". Which is why I suspect that they "embellished" their story about permanently losing data.
Who's to say that they didn't have data they wanted to keep in that directory (e.g. screen caps they'd taken with the trial version during some project or other)?
Strangely enough, when I RTFA to try to compare them, all I see is that exact same link on the page.
I would assume they did, but the simulation was unrealistic in some fashion that caused the bug not to trigger.
A few days ago reading up on good C++ coding techniques I came across Stroustrup's (creator of C++) page citing the coding rules used when working on the Joint Strike Fighter. Reading through the various rules used, this one caught my attention:
AV Rule 25 (MISRA Rule 127)
The time handling functions of library shall not be used.
I got to thinking if we had any decent alternatives (at least in C++). And yes there are alternatives and all of them looked equally bad to me. Looks like the F22 guys might have had the same problem finding and using a robust fault tolerant time library.
Why would you need to use a library? The only format you're likely to need in such software is milliseconds offset from some suitable epoch. As long as your hardware can produce such a time value, you're fine.
Yes, Virginia. Software bugs can and do kill.
Well, of course they do. I think what the OP was unable to believe was that such an idiotic, beginners' level mistake as *crashing when the date changes backwards* could be made by the kind of experienced, highly-paid programmer who typically works on military avionics software. The Therac-25 issue was a concurrency one. Admittedly, a rather stupid one, but they are of a class that's generally harder to avoid and/or predict.
... I do know a little legal theory, and it occurs to me that:
a) the passage that denies permission to run Vista Home et al in a VM is rather ambiguous, in that it could just be a clarification that the rule that allows you to run the higher-end versions in a virtual machine *at the same time* as a real machine doesn't apply. I'd really like to here official comment from MS's lawyers about how they intended this to be interpreted, and so far I haven't seen any.
b) Even if the ambiguity is only small, it still seems to be there to me, and the rule of contra proferentem should mean it is interpreted in the consumer's favour.
c) It might not make a difference anyway. As I understand it (and I'll admit my understanding of this area is rather fuzzy, because it is a very obscure corner of contract law that I've only heard about once, so I could be completely wrong), for a contract term to be enforceable, one or the other party must derive some legitimate benefit from it. I don't see what legitimate benefit MS derive from restricting the use of their products in this fashion.
Is there anything worse than law opinions on slashdot? That's a general complaint.
Not really, no. I happen to think that one was substantially above average, though.
Specifically, the images found on a computer that hadn't been hacked, a diary, and an eyewitness surely made the tainted evidence on the original computer unneeded.
Yes, however I was talking about generalities, not this specific case. In this specific case, the fact that he admitted the offence means the evidence itself is totally irrelevant.
Even if the original images had been the only thing, ISP records would likely have buried him if he wasn't being careful.
Would they? Depends on a lot of things. Was he using ISP servers for access? Does the ISP keep logs, and if so for how long? Does the ISP log HTTP requests across its network that don't use its servers. These aren't trivially answerable, and in a large number of cases the answers to all of them will be 'no'. I know that for me the answers are 'no' (as in I never use my ISP servers for anything, except outgoing e-mail, which there's no suggestion in this case of being incriminating), 'probably but irrelevant because of the first answer', and 'no'.
So, no, I don't think that's anything like as clear cut as you suggest. There's a chance his ISP would have something on him, but not a very large one.
But, basically, the legal opinion I was giving is approximately sound. I know this because in one case it has been used successfully. Admittedly, that wasn't in the USA, but the basic laws involved are very similar.
This case seems a bit more worrying because the person who placed the trojan also submitted the evidence, but really any trojan could be enough to place the evidence in doubt - if this is thrown out on those grounds then anyone who commits crime via computer can make sure it has a trojan and have all of the evidence thrown out. That won't happen - what will happen is that forensics will get better and better at working out what is genuine evidence in digital media and what is fake.
There have been cases thrown out in the UK on precisely these grounds. I think the reality is that data forensics is very hit & miss. Sometimes historical information about what has been on the disk will be easily retrievable. Other times, it will not be feasible. Correlating the age of different versions of different sectors may be totally impossible, and that would be an important step in the kind of analysis you're talking about -- without it, it may be impossible to put a firm date on the relative ages of a variety of files, so who is to say whether the trojan or the porn was there first?
Slashdot liberal bias (AKA. fired IBM employee deprived of "rights" to view pornography on company dollar).
Read here before deciding anything about this case. IBM did not have a written policy against using their computers this way, therefore it should not have been a firing offence: the employee should have received a warning for it first. This strikes me as a perfectly reasonable conclusion -- do you have any grounds for arguing that he shouldn't have a right to be warned before being fired for something that is not considered by the company's general policy a serious offence?
Logical, since you have *no right* in the first place to view child pornography in this country in the first place.
Yes, but you do have a right to be free from unwarranted search and seizure.
Que the next YRO article, where someone claims the "right" to commit a crime.
You mean either 'cue' or 'queue', I'm not entirely sure which. Can you point me to any article within the last, say, 6 months, where anyone has claimed such a thing?
Do you want to try reading the article. It's dated yesterday, and describes how the 'illegal search & seizure' conclusion of a lower court was overturned by the federal appeals court, following which the judge admitted the offence.
In the big picture of things, If he didnt touch a child... is he really guilty of anything?
Based on the article, he possibly did, but the evidence against him was inadmissable due to the length of time that had passed (some kind of legal protection, presumably intended to protect people against testimonies from false memories).
I'd toss out the conviction of the judge based on an illegal search and seizure,
Illegal search & seizure is the wrong grounds. First, the search was conducted by a Canadian who was not acting as an agent of US authorities, therefore isn't bound by US law. I'm not sure, but I think the court that overturned the decision that it was illegal is correct.
But, the fact that he installed the trojan on the PC the images were found on means that we must trust that he did not place the images there himself. Now, the fact that the judge admitted the offence in the end means presumably he did not, but there would likely be no clear way of telling in the case that he hadn't.
Isn't the hacker in legal trouble for downloading the same 3,000 pictures? (How else did he know the content was illegal?) He had to download them to his computer to view them, thereby committing the same crime as the guy he outed.
No. In most countries, and I think Canada is included, you're legally clear as long as you don't keep copies, i.e. you take necessary steps to report to an appropriate authority (not usually legally necessary, but you would be allowed to do it) and then wipe them from your computer's disks. Making sure you get any cached copies. You have to have intentionally created or kept copies, in knowledge of the contents, for the relevant laws to come into play.
Credit card companies justify their ridiculous interest rates by pointing to the losses the "have to eat" when credit card fraud happens. Since they no longer have to eat those losses, where's my rate cut, you theiving bastards?
They're talking about a different kind of fraud. They're talking about people who steal identities, use them to apply for high-limit cards, then go on a spending spree before disappearing and never being seen again.
There's nobody they can charge in these circumstances.
I'd use a define( 'APP_PATH', value ), instead of a variable, at least it can't be overridden by GET/POST/REQUEST variables directly if a bright guy enables global vars.
As long as you ensure it's set in every top level file (and I usually use just one for each site), it can't be overridden by external vars, even with register globals on -- that happens before code starts executing.
Again your confusion is due to your misunderstanding, not any fault with PHP.
My point is that it's difficult to understand. I do understand it, believe me, which is why I used it as an example. *But* I constantly see people getting confused by this behaviour. It doesn't match their internal model of theway they thought the language worked.
I don't know if that behaviour is right or wrong in a formal sense.
I'm not saying its wrong. I know that according to the language design it's complete correct. I *am* saying it's counterintuitive, and evidence that something is wrong with the design.
*facepalm* Made the same mistake twice in a row.
Meant to write:
$t = hello; echo $t;
and
echo $"t";
If you're a programmer and you don't see huge problems with both the design of PHP itself and the standard library you should just quit now and find another hobby/profession.
I'm a programmer. I work with PHP. I see a hell of a lot of problems with its design and implementation. Am I ready to dump it and switch to something better? You bet. I've been waiting for the chance for the last 5 years or more.
Can I actually do this?
No. The marketplace is such that if I implement my solutions in any other environment, I'm cutting myself out of large chunks of the market simply because people might choose a hosting provider that doesn't support whatever alternative language I choose to use.
If you were such a great programmer, you would know better, and you wouldn't be using PHP in the first place.
You know, a lot of us PHP programmers don't use the language out of choice. We use it because either (a) the boss insists on it, or (b) we're programming for deployment to a choice of web hosting providers that is out of our control, and know that PHP is the only scripting environment that we can rely on the availability of.
Unless you see a workable solution for people in either of these situations, shut up.
Huh? Since when is Pascal not a useful real-world language? This is the first time I've ever heard this claim.
;' and continues until the matching 'end' statement. If you are using standard pascal (as most of the universities that used it as a teaching language restricted themselves to), you cannot use 'unit' (which is unsupported in many implementations, being I believe a Borland innovation) or C-style '#include' (which was supported in the implementation at my university, but we were explicitly instructed not to use it).
Since according to ISO pascal:
1. Pascal programs cannot be modular -- they are defined in a single file that starts 'program
2. Pascal only recognises a single sized integer type. No longints or shorts or anything like that.
3. Pascal has no means to take the address of a variable (i.e. the equivalent of C's & operator).
4. Pascal does not allow a file to be contained in a structure. They are only allowed to be declared as top-level variables.
5. Pascal does not have any mechanism to open a file with an arbitrary filename. Files are declared as variables, and are implicitly associated with an OS file. Typically, the name used is the same as the variable's name, but this is not standardised. You can (according to the standard) implicitly create files to match those named on the command line (see section 'header files'), but this mechanism isn't widely supported.
Is this enough reason for Pascal (as standardised, and as originally implemented by Wirth) not to be a useful real-world language?
Of course, the variety of extended Pascals available make it a substantially more useful language.