It comes with the territory, I'm afraid. Some users will try something once, find a bug or limitation, decide the platform sucks and never touch it again (and if the platform is worthless, why bother filing a bug report.) I've been guilty of it myself quite a few times. First impressions count for a lot, and they can be difficult to control.
> I have friends with computing science degree yet they cannot code or have shipped software.
So do I, but CS degrees are not about memorization. At least not in North America or Europe. For my CS degree, I had to follow the math and deliver code. Toy code of course, but its a long way from "recalling and reciting references." If it had been about memorization I would probably have failed.
I also know people who say they got CS degrees through memorization and the ability to recall and recite references. They are Indian and Chinese. And they can code (even if they believe their degrees do not help.)
How the hell does this lead to stereotyping an entire race? Just so you know India and China have produced a large bulk of academics in computing science, across various educational institutions in North America and Europe. So I find your statement very arrogant and condescending.
Of course you can't memorize your way through a CS course requiring you to write code, but my point is exactly that, school doesn't teach you to actually be able to ship code or write something. It's something one must discover on own terms.
> How the hell does this lead to stereotyping an entire race?
It does not. It is just an anecdote, from three people I know, who were required to memorize stuff, and found their coding ability did not contribute much.
> Just so you know India and China have produced a large bulk of academics in computing science, across various educational institutions in North America and Europe.
> My favorite technical interview question is to ask the candidate about the worst bug they ever wrote.
Are you sure you are getting honest answers? Some candidates may be thinking "He'll never hire me if I admit how stupid I was, so I'll use this secondhand or dumbed-down story instead."
Irrelevant - they talk about a technical issue they're familiar with. I can ask them questions about that issue. It's a good way to gauge their skill level while keeping them on familiar terrain.
It's usually fairly straightforward to see if somebody talks about their own experiences or is retelling a story they simply heard.
Exactly, even if it's not their own story, if they are able to talk intelligently about the subject matter and explain the problem and solution well then i've gained valuable information about the candidate.
Unfortunately i've had a couple of candidates who's response to the question was "I don't really write bugs". Those are the ones I know for sure are lying.
> Later I found out that elance has a loophole where buyers who disputed or cancelled projects are not able to leave feedback.
The mistake many clients make is to request "cancellation". You should request a refund instead (and in the common case where a contractor goes silent, you will get back 100%.) Then mark the job as "complete" and leave feedback, which will be visible in their history (though it will not affect their average star rating.)
Requesting a refund and getting a refund closes the job as not completed, without the ability to leave feedback. The only way to leave feedback is to pay them either full amount or at least for 1 milestone.
Yes. It will truncate the file first, then allocate new blocks for the new random data, likely leaving the old blocks lying around.
You can avoid this with the 'conv=notrunc' option of 'dd'[1]. It will overwrite existing blocks instead of truncating (and possibly reallocating):
notrunc Do not truncate the output file. This will preserve
any blocks in the output file not explicitly written by
dd. The notrunc value is not supported for tapes.
I don't know whether a nearly-empty drive is better or worse than average. But the point is, you had a 1000-block file full of secret data and when you do
> secrets.txt
the file is truncated, freeing blocks 1-999 (usually block 0 is zero-filled.) If you proceed to write random data it will go to newly-allocated blocks. Then a raw read of the original blocks will expose your secret data.
With dd and notrunc, the random data goes to the original blocks, overwriting your secrets.
