I think the parent was trying to make a joke. The joke was that they were videos but the operating system was going so slow that they only seemed like screenshots.
And quite likely impossible for all the companies to block anything, too. Let's please stick to realistic solutions. The only companies that are going to run a site like this are Google, Yahoo, and MS. Browsers can query all three, but the most likely thing they're going to do is block something if any of the three calls it malicious.
Plus, if someone actually suggested doing that, I'd bet you'd be in here claiming it's a privacy violation faster than Bush can contradict himself. After all, you'd be sending your browsing history to three times as many satanic search organizations.
Yes, Google screwed up. I'm sure they'll fix it. Get over it. It's not the end of the world. In fact, it's still better than what you suggest, even with a false positive every so often.
The real reason they don't skip generations is because it's not cost effective. Intel is making a killing on its tick/tock model where they shrink the process in one model and change the architecture in the next. This way, they can pipeline. They can have their semiconductor people working out how to make it smaller while the VHDL people are throwing together a new chip. They each have twice as long as if they were coordinated, delays in one don't necessarily affect the other, and everybody is kept busy.
If they wanted to skip a generation, then the fab guys would probably take longer, which means they'd have a time when they weren't pumping out new, incrementally better CPUs to sell to people. They'd make less money, and the consumer would have to wait longer to get something better.
Several people here have pointed out several methods where employers can ask IT applicants to submit code samples or answer code questions during an interview. This seems to be a fair method, as long as applicants are warned beforehand.
I'm sorry, I misread this completely. You said during an interview and I read it as before an interview. I don't disagree with this statement at all, then. I'm going to bed.
The problem with testing is that it adds another layer of mistrust in the job interview process.
This seems very strange to me. If I ask you to write some code for me, how does that indicate I don't trust you in some way? Also, in a job interview, why should I trust you? You haven't proven yourself in any way. You have to earn trust and you have to prove yourself. Both of these things are perfectly reasonable.
Several people here have pointed out several methods where employers can ask IT applicants to submit code samples or answer code questions during an interview. This seems to be a fair method, as long as applicants are warned beforehand.
And it's pretty useless because of exactly what you describe you did: You can look up answers, you can get other people to write the tests for you, and, worst of all, it doesn't tell me, the interviewer, anything about you. If I ask you to write some code, I care less about you getting it perfect than you demonstrating how you write code. If you can't put two lines together for 30 minutes, but eventually get it exactly right, that's a problem. If you have an off-by-one error or forgot a semicolon, well, who cares? Especially if you can find the error if I ask you about it.
Skim the resumes you get to determine which ones *generally* match the skills you are looking for, then pick a resume at random and hire that person.
I wonder if you've ever done interviews before. This is the worst possible way to hire someone. Pick at random? The only way that works is if you can't distinguish the candidates in any way. But we know we can do that. We can, on the average, determine whether a candidate is suited for a position or not. It's hard, and it's imperfect, but we can do better than randomly picking people. I would not want to work at a place where they didn't constantly strive to hire top notch people.
Good luck finding a job with decent coworkers, then.
I wouldn't want to work for a place that *didn't* test this. Think about it. Who would your coworkers be in such an environment? Unless they're all people who know each other personally, you're probably looking at people who sound good and look good on paper. Such is our industry.
As someone who interviews other people (yes, the engineers decide how best to interview other engineers at the place I work, what a concept) we always test coding along with many other things. It's by far the most effective way we have to screen applicants. But I freely admit that it still sucks. It's really hard to tell in an hour if someone is any good or not. That's why references are also important, and it's important to be skilled at interviewing. A lot of people are really bad at it. But, when used correctly, it can be effective.
Let me list some of the common errors that people make. I think it is really these errors that are the problem, not the idea of testing. Really, the idea of testing isn't at all confined to CS and the original post is completely wrong in that regard.
First, people tend to ask trick questions, like how do you count the number of bits in a byte (the old x &= (x - 1) trick). These types of questions don't help you assess the candidate at all. Typically, the candidate either has seen it before or gets the trick, or they don't get it at all. It's not a test of programming ability, problem solving ability, or any other useful skill.
Second, people ask questions that are unsuitable for the candidate. For example, you don't ask someone who spent 10 years writing kernel code what the "final" keyword does in Java. The questions need to be tailored to the candidate's experience.
Third, interviewers often ignore the resume. The resume has a wealth of information that you can ask about. You can ask specific questions about things the person did (assuming he can talk about them) and see what his role was. Bad candidates will often say things like, "I helped do X" and, when probed about how they helped, they can't really answer except to say that someone else did the hard parts.
Fourth, many interviewers tend to focus on meaningless trivia, or, alternatively, spend time on one question when the candidate clearly doesn't know the answer. If the candidate can't answer the question, move on to something else. It's demoralizing and doesn't give you any new information if he's just flailing about helplessly. You may admire his fighting spirit, but you really need to give the candidate a chance to impress you. Maybe he just missed that one question.
Finally, interviewers need to make the candidate comfortable. Don't walk into an interview, hand over a 100 line program listing, and say "find the bug." Introduce yourself, talk about the resume, ask what things he's worked on, what problems he's had to solve and so forth. It helps put the candidate at ease because most people like talking about their accomplishments. You get a feel for what the candidate is capable of and can tailor the rest of your interview to the candidate. And it gets dialog going so it's a much more social atmosphere than a formal exam.
If all these things are considered, testing can be respectful and useful. I think most candidates go into a job interview hoping they get a chance to show off their strengths, and I suspect your complaint is that a lot of interview processes don't give that to candidates. That's a shame and illustrates a problem with how the interview is conducted. But testing is still necessary and just because it's often done poorly doesn't mean we should stop it altogether.
Compiler-dependent means "implementation defined" which is a technical term in the C standard meaning that the operation will do something (i.e. it's not undefined) but what it does is left to the compiler writer. Also, it's implied when you ask a C or C++ question that you're talking about the standard unless you specify otherwise.
This is sorta offtopic, but the problem is that any C compiler is free to reorder code if it doesn't cross sequence points. E.g. if you do foo(bar(), baz()), then the compiler can call bar() and baz() in any order it likes. With i = i++, there is no sequence point and i is being written twice in the same statement. Just because you can assign an ordering that gives it a well defined result doesn't mean that the more general problem is solved, again because the compiler can put the two writes in whatever order it likes given the lack of a sequence point.
In other words, the compiler could, quite legally, do another order where it reads 0 from i, sets i to 0 (for the assignment), then increments i to 1 (for the post-increment).
Actually threads would protect against a null pointer because it would cause an exception that could then kill only that thread. What threads can't protect against is random memory being used as pointers, if the memory contains a pointer to allocated pages it will write over that memory and nothing can catch it.
That's a pretty naive view of threads. First, if you have a segfault, the process dies, not just the thread. If you catch the fault (you can do this only on Windows, not Unix) and kill the thread, the process is in an undefined state because it is always unsafe to kill a thread that didn't voluntarily die, for pretty obvious reasons. It is unsafe to continue the process after such an event, threads or no.
This isn't a debate because I've already agreed with you (and accused you of nothing except not knowing the actual data rate of the phone line), and I never said any of those things you claim I said, either. Where I come from, that's called missing the point.
I see clearly you have no ability to understand what you've read as you demonstrated in this post and the other post you made in the other article in response to me. I will therefore not bother responding any further.
I've heard this argument before. I don't really buy it for a few reasons. First, what happens if you exonerate him the day after he dies in prison from old age? Or, in the more likely case, he's never exonerated? Wouldn't it have been better for him (if we accept that lethal injection or whatever is more merciful) that he have been killed?
Second, I think we should use capital punishment only in the most certain of cases. Same for life-without-parole, really, since I think they are both tantamount to the same thing.
Every time you lock up a man, you are taking the risk that you are punishing an innocent man. We accept this as part of society and the death penalty is no different. Every punishment is already carried out on the assumption that it is accurate.
The point is irrelevant to the article, but go way up the thread and the thread started by someone saying that unlimited didn't exist. Your claim seemed to be, therefore, that unlimited exists only for multicast, which is also not true.
I'm always mildly amused by people who suggest that life imprisonment is somehow better than the death penalty. I think it's just a way to ease our own guilt. But I believe that locking someone up for all time is a worse fate than death, but we confer harsher punishments when we do not have the stomach for the more merciful approach. But hey, what do I know? I'm not on death row.
I think you might want to check your bible. God punished the Israelites because they didn't murder the Canaanites, plus he also accepted one human sacrifice and coerced another guy to commit murder, stopping him just before the knife fell. And that guy sired an entire kingdom as a reward for being willing to murder his son. So, all in all, I should expect Reiser to do pretty well by god.
My point was there is such a thing as an unlimited service, even when limited to unicast to arbitrary destinations. As far as I knew, that's what the discussion was about. It seems now it's about significant bandwidth consumers. Please define significant. As far as I'm concerned, 5 Mbit/s down is also a trivial amount, yet Comcast will let you download at that rate only for 5 days before you hit your limit.
Another thing is that the telephone switching network is less efficient than the internet because it allocates the resources needed to send the call from one place to another, so in theory, if you can make a call, there's enough bandwidth to handle the call. The same is not true for setting up TCP connections. I'll leave it to your imagination to figure out how that might affect things.
But obviously, you're right (even if you do misrepresent the bandwidth of the telphone network by a factor of three). The telephone network uses less bandwidth because the data it's transmitting is smaller, and because you generally don't leave the phone off the hook when you go to sleep, whereas you might download files or whatever when you sleep.
Even real unlimited internet connections aren't. You still have a rate cap and the most you can download is your max rate times 720 hours. There's no real reason that any lower limit needs to exist other than the ISPs not wanting to expand their infrastructure.
That's idiotic. They already had a conviction. They made the deal so they would have the body for the victim's family, and so they could avoid appellate court.
After reading that strip, I went to the wikipedia article on Deconstructionism, read it, and then still had no idea what Deconstructionism was. I'm pretty sure it doesn't actually mean anything.
That seems like a really bad idea. You're trying to encode something, presumably to keep it secret, given "secret" information that was given to you by somebody else.
That's sorta my point. If you feel like seriously continuing this (stupid) argument, feel free to point out which of my links disagrees with what I said, since you haven't done that yet. For now, I've just thrown you in with the rest of the Slashdotters who lack any reading comprehension skills.
I should also point out that your link also agrees with me. First, it says, "Average in this sense" and, when they give a definition of average, which I link to above, has "A number that typifies a set of numbers of which it is a function" as the first definition. Arithmetic mean is the second definition. So maybe you'd like to try another source that agrees with you? I'm yet to find one.
Slashdot Mirror
I think the parent was trying to make a joke. The joke was that they were videos but the operating system was going so slow that they only seemed like screenshots.
And quite likely impossible for all the companies to block anything, too. Let's please stick to realistic solutions. The only companies that are going to run a site like this are Google, Yahoo, and MS. Browsers can query all three, but the most likely thing they're going to do is block something if any of the three calls it malicious.
Plus, if someone actually suggested doing that, I'd bet you'd be in here claiming it's a privacy violation faster than Bush can contradict himself. After all, you'd be sending your browsing history to three times as many satanic search organizations.
Yes, Google screwed up. I'm sure they'll fix it. Get over it. It's not the end of the world. In fact, it's still better than what you suggest, even with a false positive every so often.
Meh, I'm a software engineer. VHDL, Verilog, it's all the same to me. :-)
But seriously, that is something I've always wondered about.
Nanometers aren't discrete units, you know.
The real reason they don't skip generations is because it's not cost effective. Intel is making a killing on its tick/tock model where they shrink the process in one model and change the architecture in the next. This way, they can pipeline. They can have their semiconductor people working out how to make it smaller while the VHDL people are throwing together a new chip. They each have twice as long as if they were coordinated, delays in one don't necessarily affect the other, and everybody is kept busy.
If they wanted to skip a generation, then the fab guys would probably take longer, which means they'd have a time when they weren't pumping out new, incrementally better CPUs to sell to people. They'd make less money, and the consumer would have to wait longer to get something better.
Several people here have pointed out several methods where employers can ask IT applicants to submit code samples or answer code questions during an interview. This seems to be a fair method, as long as applicants are warned beforehand.
I'm sorry, I misread this completely. You said during an interview and I read it as before an interview. I don't disagree with this statement at all, then. I'm going to bed.
The problem with testing is that it adds another layer of mistrust in the job interview process.
This seems very strange to me. If I ask you to write some code for me, how does that indicate I don't trust you in some way? Also, in a job interview, why should I trust you? You haven't proven yourself in any way. You have to earn trust and you have to prove yourself. Both of these things are perfectly reasonable.
Several people here have pointed out several methods where employers can ask IT applicants to submit code samples or answer code questions during an interview. This seems to be a fair method, as long as applicants are warned beforehand.
And it's pretty useless because of exactly what you describe you did: You can look up answers, you can get other people to write the tests for you, and, worst of all, it doesn't tell me, the interviewer, anything about you. If I ask you to write some code, I care less about you getting it perfect than you demonstrating how you write code. If you can't put two lines together for 30 minutes, but eventually get it exactly right, that's a problem. If you have an off-by-one error or forgot a semicolon, well, who cares? Especially if you can find the error if I ask you about it.
Skim the resumes you get to determine which ones *generally* match the skills you are looking for, then pick a resume at random and hire that person.
I wonder if you've ever done interviews before. This is the worst possible way to hire someone. Pick at random? The only way that works is if you can't distinguish the candidates in any way. But we know we can do that. We can, on the average, determine whether a candidate is suited for a position or not. It's hard, and it's imperfect, but we can do better than randomly picking people. I would not want to work at a place where they didn't constantly strive to hire top notch people.
Good luck finding a job with decent coworkers, then.
I wouldn't want to work for a place that *didn't* test this. Think about it. Who would your coworkers be in such an environment? Unless they're all people who know each other personally, you're probably looking at people who sound good and look good on paper. Such is our industry.
As someone who interviews other people (yes, the engineers decide how best to interview other engineers at the place I work, what a concept) we always test coding along with many other things. It's by far the most effective way we have to screen applicants. But I freely admit that it still sucks. It's really hard to tell in an hour if someone is any good or not. That's why references are also important, and it's important to be skilled at interviewing. A lot of people are really bad at it. But, when used correctly, it can be effective.
Let me list some of the common errors that people make. I think it is really these errors that are the problem, not the idea of testing. Really, the idea of testing isn't at all confined to CS and the original post is completely wrong in that regard.
First, people tend to ask trick questions, like how do you count the number of bits in a byte (the old x &= (x - 1) trick). These types of questions don't help you assess the candidate at all. Typically, the candidate either has seen it before or gets the trick, or they don't get it at all. It's not a test of programming ability, problem solving ability, or any other useful skill.
Second, people ask questions that are unsuitable for the candidate. For example, you don't ask someone who spent 10 years writing kernel code what the "final" keyword does in Java. The questions need to be tailored to the candidate's experience.
Third, interviewers often ignore the resume. The resume has a wealth of information that you can ask about. You can ask specific questions about things the person did (assuming he can talk about them) and see what his role was. Bad candidates will often say things like, "I helped do X" and, when probed about how they helped, they can't really answer except to say that someone else did the hard parts.
Fourth, many interviewers tend to focus on meaningless trivia, or, alternatively, spend time on one question when the candidate clearly doesn't know the answer. If the candidate can't answer the question, move on to something else. It's demoralizing and doesn't give you any new information if he's just flailing about helplessly. You may admire his fighting spirit, but you really need to give the candidate a chance to impress you. Maybe he just missed that one question.
Finally, interviewers need to make the candidate comfortable. Don't walk into an interview, hand over a 100 line program listing, and say "find the bug." Introduce yourself, talk about the resume, ask what things he's worked on, what problems he's had to solve and so forth. It helps put the candidate at ease because most people like talking about their accomplishments. You get a feel for what the candidate is capable of and can tailor the rest of your interview to the candidate. And it gets dialog going so it's a much more social atmosphere than a formal exam.
If all these things are considered, testing can be respectful and useful. I think most candidates go into a job interview hoping they get a chance to show off their strengths, and I suspect your complaint is that a lot of interview processes don't give that to candidates. That's a shame and illustrates a problem with how the interview is conducted. But testing is still necessary and just because it's often done poorly doesn't mean we should stop it altogether.
Compiler-dependent means "implementation defined" which is a technical term in the C standard meaning that the operation will do something (i.e. it's not undefined) but what it does is left to the compiler writer. Also, it's implied when you ask a C or C++ question that you're talking about the standard unless you specify otherwise.
This is sorta offtopic, but the problem is that any C compiler is free to reorder code if it doesn't cross sequence points. E.g. if you do foo(bar(), baz()), then the compiler can call bar() and baz() in any order it likes. With i = i++, there is no sequence point and i is being written twice in the same statement. Just because you can assign an ordering that gives it a well defined result doesn't mean that the more general problem is solved, again because the compiler can put the two writes in whatever order it likes given the lack of a sequence point.
In other words, the compiler could, quite legally, do another order where it reads 0 from i, sets i to 0 (for the assignment), then increments i to 1 (for the post-increment).
Actually threads would protect against a null pointer because it would cause an exception that could then kill only that thread. What threads can't protect against is random memory being used as pointers, if the memory contains a pointer to allocated pages it will write over that memory and nothing can catch it.
That's a pretty naive view of threads. First, if you have a segfault, the process dies, not just the thread. If you catch the fault (you can do this only on Windows, not Unix) and kill the thread, the process is in an undefined state because it is always unsafe to kill a thread that didn't voluntarily die, for pretty obvious reasons. It is unsafe to continue the process after such an event, threads or no.
This isn't a debate because I've already agreed with you (and accused you of nothing except not knowing the actual data rate of the phone line), and I never said any of those things you claim I said, either. Where I come from, that's called missing the point.
I see clearly you have no ability to understand what you've read as you demonstrated in this post and the other post you made in the other article in response to me. I will therefore not bother responding any further.
I've heard this argument before. I don't really buy it for a few reasons. First, what happens if you exonerate him the day after he dies in prison from old age? Or, in the more likely case, he's never exonerated? Wouldn't it have been better for him (if we accept that lethal injection or whatever is more merciful) that he have been killed?
Second, I think we should use capital punishment only in the most certain of cases. Same for life-without-parole, really, since I think they are both tantamount to the same thing.
Every time you lock up a man, you are taking the risk that you are punishing an innocent man. We accept this as part of society and the death penalty is no different. Every punishment is already carried out on the assumption that it is accurate.
The point is irrelevant to the article, but go way up the thread and the thread started by someone saying that unlimited didn't exist. Your claim seemed to be, therefore, that unlimited exists only for multicast, which is also not true.
I'm always mildly amused by people who suggest that life imprisonment is somehow better than the death penalty. I think it's just a way to ease our own guilt. But I believe that locking someone up for all time is a worse fate than death, but we confer harsher punishments when we do not have the stomach for the more merciful approach. But hey, what do I know? I'm not on death row.
I take more of the old bible view of murder
I think you might want to check your bible. God punished the Israelites because they didn't murder the Canaanites, plus he also accepted one human sacrifice and coerced another guy to commit murder, stopping him just before the knife fell. And that guy sired an entire kingdom as a reward for being willing to murder his son. So, all in all, I should expect Reiser to do pretty well by god.
My point was there is such a thing as an unlimited service, even when limited to unicast to arbitrary destinations. As far as I knew, that's what the discussion was about. It seems now it's about significant bandwidth consumers. Please define significant. As far as I'm concerned, 5 Mbit/s down is also a trivial amount, yet Comcast will let you download at that rate only for 5 days before you hit your limit.
Another thing is that the telephone switching network is less efficient than the internet because it allocates the resources needed to send the call from one place to another, so in theory, if you can make a call, there's enough bandwidth to handle the call. The same is not true for setting up TCP connections. I'll leave it to your imagination to figure out how that might affect things.
But obviously, you're right (even if you do misrepresent the bandwidth of the telphone network by a factor of three). The telephone network uses less bandwidth because the data it's transmitting is smaller, and because you generally don't leave the phone off the hook when you go to sleep, whereas you might download files or whatever when you sleep.
Even real unlimited internet connections aren't. You still have a rate cap and the most you can download is your max rate times 720 hours. There's no real reason that any lower limit needs to exist other than the ISPs not wanting to expand their infrastructure.
That's idiotic. They already had a conviction. They made the deal so they would have the body for the victim's family, and so they could avoid appellate court.
You mean like my unlimited long distance plan let's me do?
After reading that strip, I went to the wikipedia article on Deconstructionism, read it, and then still had no idea what Deconstructionism was. I'm pretty sure it doesn't actually mean anything.
That seems like a really bad idea. You're trying to encode something, presumably to keep it secret, given "secret" information that was given to you by somebody else.
That's exactly what this project is doing, and it took them years to find it. So no, it wouldn't be quicker.
Not when they are this big. It'd be too hard to work with and there are too few known primes this large for it to be secure.
That's sorta my point. If you feel like seriously continuing this (stupid) argument, feel free to point out which of my links disagrees with what I said, since you haven't done that yet. For now, I've just thrown you in with the rest of the Slashdotters who lack any reading comprehension skills.
I was going to ignore your post until I saw the sig:
Oh, the irony.
I should also point out that your link also agrees with me. First, it says, "Average in this sense" and, when they give a definition of average, which I link to above, has "A number that typifies a set of numbers of which it is a function" as the first definition. Arithmetic mean is the second definition. So maybe you'd like to try another source that agrees with you? I'm yet to find one.