Get this and get this straight, using lethal force against someone because they're running away to evade arrest is not acceptable. Whether they're criminal or not is irrelevant.
Nothing I'm asking for demands linguistic prowess beyond basic capability of communicating. This is a prerequisite for effective programming in a group setting. I'm not suggesting a detailed design case study in the comments, I'm suggesting some hint about what to fix or refactor.
"//fixme" is a worthless comment.
"//fixme - this code doesn't scale" is fine
"//fixme - hard coding string length here" is fine
That's all I'm suggesting. A few words, maybe a couple lines in some cases, just enough to give a modicum of context. I really don't believe there is any circumstance where someone capable of producing usable code has any excuse not to at least be able to give some hint about why they don't like what they've done.
I've programmed with a deadline many, many times. I don't see what a deadline has to do with anything.
So somehow you wrote these 10 lines of code that require a complex explanation. That's fine. Somehow you figured out how to do them. If you're working in a professional environment, I presume you figured this out in a notebook or some record of your process that can be preserved. There's nothing wrong with a comment that says "This is complicated, see notebook #n pg x for details" or some other indirect reference to how you figured it out in the first place.
But really, you (and others) seem to be going to ridiculous extremes to justify not being helpful in your comments. In the specific cases I'm thinking about, a programmer senses something is undesirable enough about his code that he's tempted to add "// this is a hack." There is absolutely no reasonable argument that being more helpful than this is EVER prohibitive. You do not have to write the multi-page tome you suggest to be helpful, just give the next coder a clue what you are talking about. Don't make him guess what aspect of your code is a hack. ESPECIALLY if it's a concise piece of code with a complex backstory you need to give him some context to start with. I'm not saying write a thesis, I'm just saying expand a line or two on WHAT ASPECT of your code is a hack, maybe how it's likely to fail, etc. I don't see any reasonable situation where someone would be thinking to themselves, "// this is a hack" without having the ability to give a two line explanation of why the think that.
Do you honestly believe what you wrote? That documenting why you think your code is a hack, or needs to be replaced, or whatever is actually as difficult as fixing it? Sorry, that's absurd. The programmer obviously has some reason for being unhappy with the code. FFS I'm just asking to write that down---not sure where you got the idea that this means documenting "exactly what's wrong with it." If that's too hard for you, get a new job because that's part of programming. Or do you just write some code that doesn't "feel" right and decide you should optimize it later?
When code need to be revised, your own or somebody else's, the first thing I would want to distinguish is whether is is better to modify the existing or to do a complete redesign. You somehow seem to believe that the original writer has better foresight of my current context than I can have.
What are you talking about?
Now quick, what is it about Windows 7 that makes it fragile?
Uhhh, what?
Re:One person's myth is another person's fact.
on
Myths About Code Comments
·
· Score: 3, Insightful
My opinion is you're a stubborn idiot.
Dude, don't be an asshole. Especially when you're about to chastize someone for making assertions and then respond with an even less substantiated steaming pile.
Comments like "yeah, I don't like this either" or "hack, to be fixed later" indicate your team didn't have enough time to do it the right way the first time. It's a warning to whomever makes changes later that something is amiss. If the coder knew what to comment which might be helpful, they'd probably go ahead and implement it. Perhaps you'd like to see "optimize this" or "I have to stop working on this so I can finish my commenting before peer review so we can meet the deadline."
No, comments like that are absolutely useless. When you write them, you know the context a lot better than someone who comes in to debug or extend it months or years later. Obviously you recognize there is or may be an inefficiency fragility to the code. Not having time to sort it out is understandable. Not having time to properly note what about the code is fragile or inefficient? Sorry, that's utter bullshit. Take the three minutes necessary to give the reader a proper explanation of what you don't like about it. "This fails if X possible but unlikely condition occurs," "This is unacceptably slow when more than N rows are returned because of Y," or something is more like it. "I don't have time to be helpful" is a lame excuse for not being very good at your job.
You want a theoretical team which updates comments along with the code, and all peer reviews catch any outstanding comments, your costs are going to skyrocket. The real world requires lots of time to ensure documentation stays up to date, and your focus should be primarily on anything used by external users, second on internal documentation like design or event mapping, and last on code. If you have time and money left.
Yes. The real world requires documentation be kept up to date. Yes, documentation is part of the cost of coding. It takes more than writing code to built a non-trivial program. What's your point?
I really don't understand your position. Looking through the blustery hot air you felt it necessary to inject, you seem to understand that comments and documentation are important when necessary. But then you suggest that useless "fixme" comments are ok? And then you say crap like, "Every compiled application out there is completely documented."
Like you, I'm not a fan of large, boilerplate comments as a rule. However, having reviews that determine whether code is sufficiently commented is quite reasonable. After all, the original programmer is just about the worst person conceivable to determine whether his code needs a comment. Of course it makes sense to him, he just wrote it.
Looking at your examples of cases when comments are/are not needed, I find it amusing that you suggest an external design doc as being preferable to in-code comments, since the effort and cost of keeping this consistent is orders of magnitude greater than for comments. (I don't necessarily disagree, I just find it discordant with your comment.) Obviously endless get/set methods don't need much in the way of comments. But if that's the bulk of your code, you're not doing much. For non-trivial functions and code, I find it very hard to believe you can get away without most of your functions having a header comment that explains the purpose of the function, or at least the meaning and ranges of the arguments.
That has no place in the real world, and maybe neither do people like you.
Your post is spot on. I'd mod up, but I wanted to clarify (I think you'd agree) that there's a difference between a successful experiment that is inconsistent with a theory and a failed experiment. The purpose of an experiment is not to prove a hypothesis, it's to TEST a hypothesis (or to gather data toward that end). Success means you make a useful statement that aids in the test. Failure means the data were not useful. It has nothing to do with the correctness of the theory or hypothesis.
In the specific quote mentioned, the data "not making sense" doesn't mean that they disagreed with what the experimenter was expecting, it means that they came back in a way that "couldn't happen." That is, that something had gone wrong making the experiment a failure. For example, in some tests I was doing a couple years ago with a prototype radio receiver, I needed to measure its noise level. As a signal, I would sweep a resistive load up and down in temperature---the load outputs noise with intensity that depends on its physical temperature. In this case, as a check, I would start with the load at a low temperature, then heat it past the point of interest, and then cool it back to the starting temperature. I would measure twice, once on the way up and once on the way down. What I found was that the results disagreed between the two measurements. That "does not make sense" in the sense of the article---the testing method was flawed.
In a sense, it was a successful test of a hypothesis. The hypothesis was that the receiver behaves in a particular way (which is what you'd consider the REAL hypothesis under test) AND that the test setup was a valid way to measure that. I disproved the joint hypothesis. In this case, it was the latter part that was invalid---the test was invalid---and I could say nothing about the receiver. This was simply a failed experiment. There is no religion going on by my not claiming that receivers don't behave as we think they do when I just discarded my results.
Every now and then, the reason for a failure might be interesting. This is rare, but when it happens can be responsible for amazing discoveries. In my case, it was a problem of thermal equilibrium. My devices were operating in a vacuum at very low temperatures (about 20 Kelvin) and it can be difficult to affix a heater or a thermometer to just the part of a device that you want to heat or measure....
The OP's statements mirror the general misunderstanding of the scientific method that is rampant in the non-scientific community. We need to help people understand this.
Technical employees are not usually "fungible" assets. Finding an exceptional candidate is very difficult, and it's quite possible that he/she will be foreign. The best candidate might be an order of magnitude more benefit for the company as a "good enough" candidate. Not every H-1B employee is chosen just to save a buck. We had a few of them at my old workplace and it wasn't to save a buck. There simply weren't "thousands of qualified americans" for those jobs. This is a myth.
Believe me, I work with numbers far bigger than the population of the US every day. I know that a few thousand people is a tiny fraction of a percent of that population. But that's now how to evaluate the deaths of innocents. It doesn't matter how many people weren't murdered yesterday, a murder is still a terrible thing.
What a lot (all?) of the responses to my post miss is that I'm not justifying the knee-jerk bullshit responses that have resulted from these events. Acknowledging that it's tragic is not the same as giving a carte blanche to the feds to strip us of our civil liberties through the ridiculous "security" measures they've enacted. I'm as outraged, perhaps more, about this as anyone you're likely to meet.
But the reason I'm upset about the security is not simply the stupid "oh but more people die in cars every day" line. You can still try to solve a problem that's not the WORST problem. I fully support reasonable airline security (along the lines of your suggestion). If you CAN prevent any deaths in a reasonable way, of course you should. The problem with the security is that it's not a reasonable rational balance between efficacy and convenience. It's focused on intimidation and the silly show of force to convince people that actions are being taken. That's stupid and wasteful.
So just remember that every time you hear about a death, that's a human life. Someone with a family and loved ones. When that person is murdered or dies in a car accident, I think another human should feel some compassion and not just divide one by 6 billion and decide that it's too small a number to worry about. Don't freak out, but at least think about whether a lesson can be learned.
You have to look at the whole picture. 5000 people dying is a tragedy whatever the context. However, in the case of war, those in charge of the military have (or SHOULD have) decided that if extreme actions (like sending in guys with guns) are not taken, something worse will happen. As silly as it can be made to sound, war in the short term may sometimes be necessary to achieve peace in the long term. If, say, 500,000 lives could have been lost in a direct attack on Berlin in the early 30s but the action would have averted the Holocaust, with the benefit of hindsight we should take that bargain. Feel free to substitute Stalin or other examples if this is too close to Godwinning for you.
The trick is actually making that estimate, especially when other factors get mixed in (how many lives per dollar of oil, how do you value "freedom" or "sovereignty", etc...)
Sorry, I disagree. You don't have to go apeshit crazy in a panic because of it (like our government is all too happy to do), but it's dehumanizing to consider a death as a minor annoyance. Just because lots of other people died doesn't lessen the tragedy. That's the sort of heartless thinking that allows things like the Iraq war to go on: "Sure, a few thousand people might die, but that's peanuts to the death toll in Vietnam so it's an acceptable cost" or the like.
It occurred to me after I posted that the original author may have meant that the security reaction to 9/11 could have been a minor annoyance. That I agree with---no matter the tragedy, it's not reasonable to fuck things up worse in response. This is subtly different from what I mention in the previous paragraph. You do have to do the "economic" analysis of the impact of your actions and decide whether the costs (financial, lives, freedom, etc) are worth the benefits.
As much as I agree that the response to terrorism is often irrational, try to maintain some perspective. Thousands of people dying cannot reasonably be described as a "minor annoyance."
I think you underestimate the value of an established community and the cost of operating a large community site. If slashdot folded, yeah, people would go somewhere else. But that site (or those sites) has (have) to be able to afford the traffic that results. You can't just wave your hands, sprinkle some magic free software pixie dust, and declare that the community will just go to another totally free site. That site will fold too, and eventually there won't be any. For something like youtube... it takes some serious iron to host video for the world. If they aren't allowed to be profitable and it's clear that no one will make a buck, it'll be hard to convince someone to step up.
Furthermore, there is value in the continuity of the site. That is somewhat true for slashdot-- I know there are certain usernames who are likely to be reasonable and worth reading. This is even more true for facebook and the like. No, they don't generate any content of their own. However they do compile it and provide unique tools for creating and sharing and connecting. To say that has no value is absurd. It costs money to run, and it simply isn't going to happen without a back end supporting it.
The unadulterated Internet is great. I had enormous fun in the early days creating my own website and having discussions on forums long before any of this existed. However, these forums and sites create tools that bring it to the lay user in a way that you couldn't dream of a decade ago. That costs money and that's gotta come from somewhere.
Well, at least young'uns like me can learn from 3DR's mistake.
Too bad 3DR didn't learn from the long history of software management blunders, as recorded in, e.g., The Mythical Man-Month. The blunders made by the DNF team read like a table of contents for that book. In particular, mindlessly adding employees to help speed things up in the endgame is usually a recipe for further delay.
Also, if you're aiming for the technically most advanced game out there, using the engine some other guys developed to do it seems like a questionable strategy at best. It's sad. It makes it pretty clear that the original Dukes were accidental successes, at least from a production point of view. The management clearly had no idea how to actually manage the creative process.
Now just how do you feel the modifier "free" is appropriate for such a system?
Just fine, thanks. I'm capable of grasping different meanings for the same word under different circumstances.
Free market does not mean total freedom. It does not mean political freedom. It does not mean software freedom. It means something specific, not just what it sounds sorta like it probably means.
It's the bereaved that I have in mind. Just because you personally don't care how the corpses of your loved ones are treated doesn't mean that no one does.
I think it's reasonable for a professor to prefer that his students not be taking out their aggressions on the cadavers while in his classroom... She is training to work in a position where it's very important to be respectful and professional---it is, after all, a dead human being she'll be working on.
Yeah, and this article is just the evidence you were looking for to support your proffered example. Bravo. Sorry, but in my book the rule of law and freedom entail not having your personal possessions destroyed on the whim of a security thug. Or do you think there's a valid reason for that? Sorry, if they had a legitimate suspicion, the laptop should have really been destroyed. Looks pretty clear that they were abusing their power to punish her for something.
Sorry to double-reply.. but also, firing should not be used as a punishment within a sensible organization. Someone should be fired if they are demonstrably unable to perform their job or if they will somehow harm the organization by their continued employment. They way you describe it is like "they had it coming" in a vengeful sense. If this was simply gross incompetence or flouting of established and well-documented procedures, it's probably evidence this person is unqualified for the position, and in that case I'd support firing. Simply making an error is not a reason to fire an otherwise capable employee.
There's also the possibility that this was a failure at the organizational (i.e., bureaucratic) level rather than solely the fault of one individual. Given the info that was in the article I read, there's no way to make that determination for yourself. At least, not in a reasonable way.
Can you send me a link to their training materials, the ones you must have reviewed in order to categorically state they were sufficiently trained to have known how not to make this technical error?
Perhaps they should be fired. But it depends on the circumstances of the event. To categorically say that someone must be fired because a bad thing happened is laughably shortsighted. Firing someone doesn't solve every problem, sometimes a less knee-jerk CYA reaction is better.
Umm, like the OP implied, refusing to answer questions (aside from perhaps about identity) itself does not constitute constitute resisting arrest. IIRC (and depending on jurisdiction perhaps), it can't even form part of a reasonable suspicion of wrongdoing.
Regardless of how minor a document this is, the people being trusted with classified information that may affect "national security" should be at the very least fired with all clearances revoked when they screw up.
This is as silly as any of the "zero tolerance" policies that get ridiculed so heartily on this site. The appropriate punishment, and I do agree completely that there should be punishment, depends on how this error came to be. Even with good faith efforts in place to do things properly, errors will occur. If your immediate response is to fire and humiliate those who make errors, you deny your organization the ability to "learn" from them. If the error was grossly negligent, that's different, of course, but I don't think you can categorically say that someone committed a firing offense without additional information about the process by which this document was redacted and released.
Um, megabytes are the actual measure of how much of the resource you've used. That is the amount of capacity you're using (MB/s) times the amount of time you're using it (s). MB/s * s = MB. A network line with N GB/s capacity has N GB/s * 86,400 s/day * 30 day/month = XX GB available each month. The fraction of that that you use up is measured in bytes, not bytes/time.
Slashdot Mirror
Get this and get this straight, using lethal force against someone because they're running away to evade arrest is not acceptable. Whether they're criminal or not is irrelevant.
Nothing I'm asking for demands linguistic prowess beyond basic capability of communicating. This is a prerequisite for effective programming in a group setting. I'm not suggesting a detailed design case study in the comments, I'm suggesting some hint about what to fix or refactor.
"//fixme" is a worthless comment.
"//fixme - this code doesn't scale" is fine
"//fixme - hard coding string length here" is fine
That's all I'm suggesting. A few words, maybe a couple lines in some cases, just enough to give a modicum of context. I really don't believe there is any circumstance where someone capable of producing usable code has any excuse not to at least be able to give some hint about why they don't like what they've done.
I've programmed with a deadline many, many times. I don't see what a deadline has to do with anything.
So somehow you wrote these 10 lines of code that require a complex explanation. That's fine. Somehow you figured out how to do them. If you're working in a professional environment, I presume you figured this out in a notebook or some record of your process that can be preserved. There's nothing wrong with a comment that says "This is complicated, see notebook #n pg x for details" or some other indirect reference to how you figured it out in the first place.
But really, you (and others) seem to be going to ridiculous extremes to justify not being helpful in your comments. In the specific cases I'm thinking about, a programmer senses something is undesirable enough about his code that he's tempted to add "// this is a hack." There is absolutely no reasonable argument that being more helpful than this is EVER prohibitive. You do not have to write the multi-page tome you suggest to be helpful, just give the next coder a clue what you are talking about. Don't make him guess what aspect of your code is a hack. ESPECIALLY if it's a concise piece of code with a complex backstory you need to give him some context to start with. I'm not saying write a thesis, I'm just saying expand a line or two on WHAT ASPECT of your code is a hack, maybe how it's likely to fail, etc. I don't see any reasonable situation where someone would be thinking to themselves, "// this is a hack" without having the ability to give a two line explanation of why the think that.
Do you honestly believe what you wrote? That documenting why you think your code is a hack, or needs to be replaced, or whatever is actually as difficult as fixing it? Sorry, that's absurd. The programmer obviously has some reason for being unhappy with the code. FFS I'm just asking to write that down---not sure where you got the idea that this means documenting "exactly what's wrong with it." If that's too hard for you, get a new job because that's part of programming. Or do you just write some code that doesn't "feel" right and decide you should optimize it later?
When code need to be revised, your own or somebody else's, the first thing I would want to distinguish is whether is is better to modify the existing or to do a complete redesign. You somehow seem to believe that the original writer has better foresight of my current context than I can have.
What are you talking about?
Now quick, what is it about Windows 7 that makes it fragile?
Uhhh, what?
My opinion is you're a stubborn idiot.
Dude, don't be an asshole. Especially when you're about to chastize someone for making assertions and then respond with an even less substantiated steaming pile.
Comments like "yeah, I don't like this either" or "hack, to be fixed later" indicate your team didn't have enough time to do it the right way the first time. It's a warning to whomever makes changes later that something is amiss. If the coder knew what to comment which might be helpful, they'd probably go ahead and implement it. Perhaps you'd like to see "optimize this" or "I have to stop working on this so I can finish my commenting before peer review so we can meet the deadline."
No, comments like that are absolutely useless. When you write them, you know the context a lot better than someone who comes in to debug or extend it months or years later. Obviously you recognize there is or may be an inefficiency fragility to the code. Not having time to sort it out is understandable. Not having time to properly note what about the code is fragile or inefficient? Sorry, that's utter bullshit. Take the three minutes necessary to give the reader a proper explanation of what you don't like about it. "This fails if X possible but unlikely condition occurs," "This is unacceptably slow when more than N rows are returned because of Y," or something is more like it. "I don't have time to be helpful" is a lame excuse for not being very good at your job.
You want a theoretical team which updates comments along with the code, and all peer reviews catch any outstanding comments, your costs are going to skyrocket. The real world requires lots of time to ensure documentation stays up to date, and your focus should be primarily on anything used by external users, second on internal documentation like design or event mapping, and last on code. If you have time and money left.
Yes. The real world requires documentation be kept up to date. Yes, documentation is part of the cost of coding. It takes more than writing code to built a non-trivial program. What's your point?
I really don't understand your position. Looking through the blustery hot air you felt it necessary to inject, you seem to understand that comments and documentation are important when necessary. But then you suggest that useless "fixme" comments are ok? And then you say crap like, "Every compiled application out there is completely documented."
Like you, I'm not a fan of large, boilerplate comments as a rule. However, having reviews that determine whether code is sufficiently commented is quite reasonable. After all, the original programmer is just about the worst person conceivable to determine whether his code needs a comment. Of course it makes sense to him, he just wrote it.
Looking at your examples of cases when comments are/are not needed, I find it amusing that you suggest an external design doc as being preferable to in-code comments, since the effort and cost of keeping this consistent is orders of magnitude greater than for comments. (I don't necessarily disagree, I just find it discordant with your comment.) Obviously endless get/set methods don't need much in the way of comments. But if that's the bulk of your code, you're not doing much. For non-trivial functions and code, I find it very hard to believe you can get away without most of your functions having a header comment that explains the purpose of the function, or at least the meaning and ranges of the arguments.
That has no place in the real world, and maybe neither do people like you.
Nyah nyah nanny-nanny-boo-boo neener neener. Grow up.
Your post is spot on. I'd mod up, but I wanted to clarify (I think you'd agree) that there's a difference between a successful experiment that is inconsistent with a theory and a failed experiment. The purpose of an experiment is not to prove a hypothesis, it's to TEST a hypothesis (or to gather data toward that end). Success means you make a useful statement that aids in the test. Failure means the data were not useful. It has nothing to do with the correctness of the theory or hypothesis.
In the specific quote mentioned, the data "not making sense" doesn't mean that they disagreed with what the experimenter was expecting, it means that they came back in a way that "couldn't happen." That is, that something had gone wrong making the experiment a failure. For example, in some tests I was doing a couple years ago with a prototype radio receiver, I needed to measure its noise level. As a signal, I would sweep a resistive load up and down in temperature---the load outputs noise with intensity that depends on its physical temperature. In this case, as a check, I would start with the load at a low temperature, then heat it past the point of interest, and then cool it back to the starting temperature. I would measure twice, once on the way up and once on the way down. What I found was that the results disagreed between the two measurements. That "does not make sense" in the sense of the article---the testing method was flawed.
In a sense, it was a successful test of a hypothesis. The hypothesis was that the receiver behaves in a particular way (which is what you'd consider the REAL hypothesis under test) AND that the test setup was a valid way to measure that. I disproved the joint hypothesis. In this case, it was the latter part that was invalid---the test was invalid---and I could say nothing about the receiver. This was simply a failed experiment. There is no religion going on by my not claiming that receivers don't behave as we think they do when I just discarded my results.
Every now and then, the reason for a failure might be interesting. This is rare, but when it happens can be responsible for amazing discoveries. In my case, it was a problem of thermal equilibrium. My devices were operating in a vacuum at very low temperatures (about 20 Kelvin) and it can be difficult to affix a heater or a thermometer to just the part of a device that you want to heat or measure....
The OP's statements mirror the general misunderstanding of the scientific method that is rampant in the non-scientific community. We need to help people understand this.
Technical employees are not usually "fungible" assets. Finding an exceptional candidate is very difficult, and it's quite possible that he/she will be foreign. The best candidate might be an order of magnitude more benefit for the company as a "good enough" candidate. Not every H-1B employee is chosen just to save a buck. We had a few of them at my old workplace and it wasn't to save a buck. There simply weren't "thousands of qualified americans" for those jobs. This is a myth.
Believe me, I work with numbers far bigger than the population of the US every day. I know that a few thousand people is a tiny fraction of a percent of that population. But that's now how to evaluate the deaths of innocents. It doesn't matter how many people weren't murdered yesterday, a murder is still a terrible thing.
What a lot (all?) of the responses to my post miss is that I'm not justifying the knee-jerk bullshit responses that have resulted from these events. Acknowledging that it's tragic is not the same as giving a carte blanche to the feds to strip us of our civil liberties through the ridiculous "security" measures they've enacted. I'm as outraged, perhaps more, about this as anyone you're likely to meet.
But the reason I'm upset about the security is not simply the stupid "oh but more people die in cars every day" line. You can still try to solve a problem that's not the WORST problem. I fully support reasonable airline security (along the lines of your suggestion). If you CAN prevent any deaths in a reasonable way, of course you should. The problem with the security is that it's not a reasonable rational balance between efficacy and convenience. It's focused on intimidation and the silly show of force to convince people that actions are being taken. That's stupid and wasteful.
So just remember that every time you hear about a death, that's a human life. Someone with a family and loved ones. When that person is murdered or dies in a car accident, I think another human should feel some compassion and not just divide one by 6 billion and decide that it's too small a number to worry about. Don't freak out, but at least think about whether a lesson can be learned.
You have to look at the whole picture. 5000 people dying is a tragedy whatever the context. However, in the case of war, those in charge of the military have (or SHOULD have) decided that if extreme actions (like sending in guys with guns) are not taken, something worse will happen. As silly as it can be made to sound, war in the short term may sometimes be necessary to achieve peace in the long term. If, say, 500,000 lives could have been lost in a direct attack on Berlin in the early 30s but the action would have averted the Holocaust, with the benefit of hindsight we should take that bargain. Feel free to substitute Stalin or other examples if this is too close to Godwinning for you.
The trick is actually making that estimate, especially when other factors get mixed in (how many lives per dollar of oil, how do you value "freedom" or "sovereignty", etc...)
Sorry, I disagree. You don't have to go apeshit crazy in a panic because of it (like our government is all too happy to do), but it's dehumanizing to consider a death as a minor annoyance. Just because lots of other people died doesn't lessen the tragedy. That's the sort of heartless thinking that allows things like the Iraq war to go on: "Sure, a few thousand people might die, but that's peanuts to the death toll in Vietnam so it's an acceptable cost" or the like.
It occurred to me after I posted that the original author may have meant that the security reaction to 9/11 could have been a minor annoyance. That I agree with---no matter the tragedy, it's not reasonable to fuck things up worse in response. This is subtly different from what I mention in the previous paragraph. You do have to do the "economic" analysis of the impact of your actions and decide whether the costs (financial, lives, freedom, etc) are worth the benefits.
As much as I agree that the response to terrorism is often irrational, try to maintain some perspective. Thousands of people dying cannot reasonably be described as a "minor annoyance."
I think you underestimate the value of an established community and the cost of operating a large community site. If slashdot folded, yeah, people would go somewhere else. But that site (or those sites) has (have) to be able to afford the traffic that results. You can't just wave your hands, sprinkle some magic free software pixie dust, and declare that the community will just go to another totally free site. That site will fold too, and eventually there won't be any. For something like youtube... it takes some serious iron to host video for the world. If they aren't allowed to be profitable and it's clear that no one will make a buck, it'll be hard to convince someone to step up.
Furthermore, there is value in the continuity of the site. That is somewhat true for slashdot-- I know there are certain usernames who are likely to be reasonable and worth reading. This is even more true for facebook and the like. No, they don't generate any content of their own. However they do compile it and provide unique tools for creating and sharing and connecting. To say that has no value is absurd. It costs money to run, and it simply isn't going to happen without a back end supporting it.
The unadulterated Internet is great. I had enormous fun in the early days creating my own website and having discussions on forums long before any of this existed. However, these forums and sites create tools that bring it to the lay user in a way that you couldn't dream of a decade ago. That costs money and that's gotta come from somewhere.
irked me
Does that mean it didn't ked you?
Well, at least young'uns like me can learn from 3DR's mistake.
Too bad 3DR didn't learn from the long history of software management blunders, as recorded in, e.g., The Mythical Man-Month. The blunders made by the DNF team read like a table of contents for that book. In particular, mindlessly adding employees to help speed things up in the endgame is usually a recipe for further delay.
Also, if you're aiming for the technically most advanced game out there, using the engine some other guys developed to do it seems like a questionable strategy at best. It's sad. It makes it pretty clear that the original Dukes were accidental successes, at least from a production point of view. The management clearly had no idea how to actually manage the creative process.
Yeah, very bad article. The little paragraph for each entry barely makes sense. Does not deserve your time.
Now just how do you feel the modifier "free" is appropriate for such a system?
Just fine, thanks. I'm capable of grasping different meanings for the same word under different circumstances.
Free market does not mean total freedom. It does not mean political freedom. It does not mean software freedom. It means something specific, not just what it sounds sorta like it probably means.
It's the bereaved that I have in mind. Just because you personally don't care how the corpses of your loved ones are treated doesn't mean that no one does.
I think it's reasonable for a professor to prefer that his students not be taking out their aggressions on the cadavers while in his classroom... She is training to work in a position where it's very important to be respectful and professional---it is, after all, a dead human being she'll be working on.
Yeah, and this article is just the evidence you were looking for to support your proffered example. Bravo. Sorry, but in my book the rule of law and freedom entail not having your personal possessions destroyed on the whim of a security thug. Or do you think there's a valid reason for that? Sorry, if they had a legitimate suspicion, the laptop should have really been destroyed. Looks pretty clear that they were abusing their power to punish her for something.
Sorry to double-reply.. but also, firing should not be used as a punishment within a sensible organization. Someone should be fired if they are demonstrably unable to perform their job or if they will somehow harm the organization by their continued employment. They way you describe it is like "they had it coming" in a vengeful sense. If this was simply gross incompetence or flouting of established and well-documented procedures, it's probably evidence this person is unqualified for the position, and in that case I'd support firing. Simply making an error is not a reason to fire an otherwise capable employee.
There's also the possibility that this was a failure at the organizational (i.e., bureaucratic) level rather than solely the fault of one individual. Given the info that was in the article I read, there's no way to make that determination for yourself. At least, not in a reasonable way.
Can you send me a link to their training materials, the ones you must have reviewed in order to categorically state they were sufficiently trained to have known how not to make this technical error?
Perhaps they should be fired. But it depends on the circumstances of the event. To categorically say that someone must be fired because a bad thing happened is laughably shortsighted. Firing someone doesn't solve every problem, sometimes a less knee-jerk CYA reaction is better.
I have an easy solution to that. Anyone who tries to sell me MLM stuff ceases being my friend.
Umm, like the OP implied, refusing to answer questions (aside from perhaps about identity) itself does not constitute constitute resisting arrest. IIRC (and depending on jurisdiction perhaps), it can't even form part of a reasonable suspicion of wrongdoing.
Regardless of how minor a document this is, the people being trusted with classified information that may affect "national security" should be at the very least fired with all clearances revoked when they screw up.
This is as silly as any of the "zero tolerance" policies that get ridiculed so heartily on this site. The appropriate punishment, and I do agree completely that there should be punishment, depends on how this error came to be. Even with good faith efforts in place to do things properly, errors will occur. If your immediate response is to fire and humiliate those who make errors, you deny your organization the ability to "learn" from them. If the error was grossly negligent, that's different, of course, but I don't think you can categorically say that someone committed a firing offense without additional information about the process by which this document was redacted and released.
Um, megabytes are the actual measure of how much of the resource you've used. That is the amount of capacity you're using (MB/s) times the amount of time you're using it (s). MB/s * s = MB. A network line with N GB/s capacity has N GB/s * 86,400 s/day * 30 day/month = XX GB available each month. The fraction of that that you use up is measured in bytes, not bytes/time.