Perhaps they could paint a line on the side of a large vessel floating in water and see if the containers displace enough water to submerge the line. Oh wait, that's what they do with all container ships. It's impossible for the whole ship to be over weight. It is possible to have a poorly distributed load, but that's not likely to cause the type of accident that happened here (it would more likely lead to capsizing).
Overweight containers are more of a financial issue than a safety issue. Leaving 500 containers on the dock or leaving under-loaded are both bad for business.
Almost everyone's doing it wrong, that's why it doesn't seem to work in practice. 99% of the "agile" efforts I've seen used agile as an excuse to avoid whatever part of the SDLC annoyed them most.
Microsoft created registration-free COM and.Net assemblies over ten years ago. Both improve on the old registry-based library locating technologies. Picking on Microsoft for this is like picking on Ford for building the Edsel.
So, you're saying that art, music and software have no value, because they can be copied
I never said that. I was only pointing out that your analogy was flawed because it was a buggy whip argument. If there were a major technological shift that made soda free, then stores would not sell it, and all of the stock on the shelves would be given away. What do you think happened to all of the buggy whips on store shelves after the transition to automobiles?
You're entire attack on my nullification of your argument was to assume I meant the most ridiculous thing possible and then attack that.
If you want me to make a more concrete argument, then here it is: the people who are pushing DRM today are in the distribution business. They used be a valuable and necessary part of getting music into the hands of consumers. Their services will be no longer needed soon, so they should find something else to do for a living before the well dries up.
If I walk into your store and steal a soda YOU the owner of the store have nothing to sell.
If you make copies for free, I have nothing to sell.
If soda becomes copyable, then it becomes worthless. Same thing happens when a store buys two sets of Super Bowl hats and shirts printed with each team as the winner. Once one of the teams loses, half are junk. All in all, the world would be a better place if food became free (maybe not soda, but still), regardless of the fact that an entire industry would be out of business. Do you really want me to pull out the buggy whip argument?
I'm going to give your co-worker a hint: that voluntary training is increasing your worth in the marketplace. It's not just an advantage to your current employer.
I've worked for a training provider and seen this from the other side. Increasing your marketplace value is actually a negative for the employer. From that point forward the company has a higher chance of losing you. Some employers would contract with us for special training that omits sections that are big on the certification test and not relevant to the work the employee is doing for the company. I'm not suggesting that this was a good thing, but it shows that certification isn't necessarily a win-win.
Unfortunately, that would block pretty much all outbound calls from call centers. Any call center I've ever worked with calls for multiple clients. They attach the number of the calling campaign to the caller id, not their own number, since no one ever wants to call the call center, they want to call "tech support for Acme Bearings" or whatever. The client doesn't want the number tied to the call center because they use that number on all of their advertising copy. If the number were owned by the call center, then the client couldn't switch to another one. Even corporations that don't do outbound calling like to do fancy stuff like put their main switchboard number on the caller id of the calls placed from all of their sites.
So, in reality, most commercial calls use spoofed caller id. The whole system is based on it. It's technically trivial to put some data on a call that charges an arbitrary amount to the other parties phone bill. The only thing that keeps the whole system in check is the fear of getting caught. With systems like this, there will always be scammers.
That's because if schools taught people how to properly test security, the government would label them terrorist breeding grounds.
Not really. My team has a great track record of our products passing security scans. We've never used mock hacking to find security issues in our code. We simply do rigorous code reviews against solid security principals. Some teams around us do the whole code-hack-fix thing, and they have a lot of security fix work every time the pen-testing tool is updated or changed.
I laugh every time I hear a colleague come back from some security class they were sent to and I find out that they spent five days running ten-year-old exploit tools against unpatched servers.
You're an idiot. You signed something under threat of prison / arrest without bothering to consult a lawyer. No amount of mention of poverty, trust, or even just plain intimidation should have made you do such a thing without first consulting a lawyer.
And here is the harm in the "If you're not guilty you have nothing to worry about" attitude. A lot of people act as if nothing can hurt them if they've done nothing wrong. These same people tend to look on those that protect themslves as guilty. The student may have been trying to appear innocent by cooperating instead of "acting guilty" by lawyering up so this would just blow over.
I always considered readability and maintainability to be implicit technical requirements for any project.
I look at it a bit differently. I consider readability and maintainability a core part of the craft of programming. I don't expect anyone to ask for them and I wouldn't compromise on them even if I were explicitly asked to do so. In my opinion, writing bad code is like being a doctor and taking shortcuts like not properly cleaning your instruments. Sure, you might be successful for a while. But, eventually it's going to cause problems.
I tend to ask "what requirements does this code fail to meet?" And very often, the reviewer has invented his own new requirement!
Given the bad code I run into, my answer would usually be "when it fails, there is no way to figure out what went wrong". Just because the business requirements didn't specify error handling and logging doesn't mean it is superfluous.
The bug I triaged today involved a UI where if you added a record to a table and pushed the save button twice, it would make two rows in the database. The underlying problem was that the original programmer sprinkled a bunch of status flags all over the place in a highly disorganized manner and he forgot to clear the "new" flag after saving. If I fix it by clearing the flag after save, it will still be bad code, even if it meets all of the requirements. Whether code is good/bad and whether it works/doesn't are two different questions.
It could be that your organization has a high tolerance for bad code. If defects are unlikely to cause major problems and fixes are easy to apply, then bad code might be OK. But, it's still bad code. If all of your code has to be validated by an expensive third before deployment and defect cost lives or a lot of money, then you really should write good code.
Wait, being a good arguer is a problem to be wary of? Often, the better arguer is the one who sees the problem the clearest. Also, the inability to defend a position can be a sign of cargo-cultism. I'm much more wary of someone who calls everything they do a "best practice" without ever being able to describe the benefits of said practice. That's how hungarian naming gets adopted.
It won't be long before companies figure out how to get them to work. The Phillips L-Prize bulb uses the LED as a source of photons to excite a phosphorescent material. The actual light that the bulb emits comes from the outer surface of the bulb, so directionality of the LED is irrelevant, as long as they can excite enough of the phosphor.
... and when web sites require membership, the newspaper industry will bounce back. The public is not obligated to support anyone's business model.
This isn't "oh no, you're going to kill the Internet", this is about both sides having some level of power and letting the web mature to a point where everyone is happy. That won't happen if consumers don't voice their opinion. There's no social contract here, just a bunch of people that discovered that they can make money by putting ad supported content on the web. When that becomes a poor way to make money, some will do something else and some will become really good at getting ads through the filters. The world will move on.
Actually the most frustrating thing Climate Change Deniers have done is to frame the discussion around whether it's happening and whether it's anthropomorphic. Of course it's happening and who cares if it's our fault. All that's important is: 1. How will it affect us. 2. What are our options?
I've seen very little discussion framed as "It will cost us X trillions to execute plan A and if we don't, ignoring it will cost Y trillions." Instead, we get drivel like "We didn't take care of the planet and we ruined it, now we need to curb fossil fuel use." I've yet to see any specific plan that will both be likely to actually work and is likely to cost less than the cost of the disaster that it will avoid. Instead we get a bunch of people saying it will be the end of the world. The world won't end... hundreds of millions of people may die and previously valuable land may become worthless, but the remainder of humanity will get along just fine.
Of course it is. That's hundreds of years of cultural integration of employers demanding to have salary negotiations kept secret. It's always in the worker's interest for these negotiation to be public and always in the employer's interest to have them secret. So, your statement boils down to "It's always been like this". That's not new information. What is new is that a labor board has now stated that it's your right to discuss this information and it's illegal to prevent this discussion.
This is a step forward in a better direction than labor unions. The problem I've always had with Unions is that you need to sign on with a slightly less abusive group to protect you from a more abusive group, you don't get to go your own way. Requiring open discussions of labor conditions is a step closer to a transparent labor market and more fair wages.
There was piracy without copy protection in the cassette tape days, and the recording business survived. They will survive just fine without DRM in the future. TiVo is a good example to learn from. Much money was made in the past on the assumption that people would watch commercials. TiVo and similar devices allowed a significant fraction of consumers to skip commercials. The ham-fisted approach would have been to make the fast-forward button illegal. The proper approach, that the market took, was to move many of the advertisements into the program.
DRM is a ham-fisted way to preserve a business model that is losing relevancy. The correct solution is to create new business models.
I hire a lot in IT. I started out by disregarding any resume with a provable lie on it. I quickly learned that 95% of the resumes that made it through pre-screening had blatant lies on them. Most of those weren't even the candidates fault, the employment agency they worked with put the lies on there to ensure that the resume made it to my desk (and it worked!!).
Now, I trust references from trusted sources first, things I learn from an interview second, and never trust a resume. It's a huge pain in the ass and I long for the old days when a piece of paper was a good summary of the history of a candidate. The last guy I hired came strongly recommended by my neighbor - he's working out well. The guy before him did very well on the phone interview, but it wasn't worth flying him out for a face-to-face interview for a four month contract job. We fired him after six days; we're pretty sure he had someone else do the interview for him.
Not really. Nitromethane has poor energy content, but makes for 4000HP engines. The amount of air you can pump through an engine is fixed by the displacement and maximum RPM of the components, and the fuel is limited by the amount of air that that quantity of fuel properly mixes with. Gasoline works at about a 13:1 ratio with air, alcohol at 6:1 and nitromethane at 2:1. So, for one revolution of a one liter engine, you can put through 1 unit of gasoline, 2.5 units of alcohol, or 6.4 units of nitromethane (with a unit being the amount of gasoline that properly mixes with one liter of air). Factoring in energy content, that makes alcohol capable of 30% more power and nitromethane capable of 75% more power, with no other modifications than a change of fuel and mixture adjustment. Add the cooling benefit of more liquid fuel being vaporized and it gets even better. Nitromethane engines use so much fuel that it's possible to hydro-lock them (the entire combustion chamber fills with incompressible liquid fuel - and very bad things happen).
If you're super good at programming clean secure C/C++ you might want to program your own webserver (servers like Apache are easier to use, yes, but they release security patches to them all the time, so they aren't THAT secure. A dedicated single program that only does a few things is likely to have less vulnerabilities).
That's the worst idea I've ever heard. Apache and IIS both average less than ten discovered meaningful vulnerabilities per year. Making a secure HTTP server is way harder than you think it is.
Use SSL or some other form of secure transport (https). This will insure (well not insure, but make it more difficult) that even if someone is able to snatch your user's packets (like if they are in Starbucks or something), they will have to decrypt them before they get a token (by which time it will have expired).
Look up Cross-Site Request Forgery, it's a whole class of attack that makes the browser do the hard work for you. This is a great example of a case where using a framework instead of rolling your own is best. Most authentication frameworks had some CSRF protections in them before most web developers even knew it was a problem to be worried about (for example, marking session cookies as HttpOnly).
Perhaps they could paint a line on the side of a large vessel floating in water and see if the containers displace enough water to submerge the line. Oh wait, that's what they do with all container ships. It's impossible for the whole ship to be over weight. It is possible to have a poorly distributed load, but that's not likely to cause the type of accident that happened here (it would more likely lead to capsizing).
Overweight containers are more of a financial issue than a safety issue. Leaving 500 containers on the dock or leaving under-loaded are both bad for business.
We already have Torx for that.
Almost everyone's doing it wrong, that's why it doesn't seem to work in practice. 99% of the "agile" efforts I've seen used agile as an excuse to avoid whatever part of the SDLC annoyed them most.
Microsoft created registration-free COM and .Net assemblies over ten years ago. Both improve on the old registry-based library locating technologies. Picking on Microsoft for this is like picking on Ford for building the Edsel.
So, you're saying that art, music and software have no value, because they can be copied
I never said that. I was only pointing out that your analogy was flawed because it was a buggy whip argument. If there were a major technological shift that made soda free, then stores would not sell it, and all of the stock on the shelves would be given away. What do you think happened to all of the buggy whips on store shelves after the transition to automobiles?
You're entire attack on my nullification of your argument was to assume I meant the most ridiculous thing possible and then attack that.
If you want me to make a more concrete argument, then here it is: the people who are pushing DRM today are in the distribution business. They used be a valuable and necessary part of getting music into the hands of consumers. Their services will be no longer needed soon, so they should find something else to do for a living before the well dries up.
So... they want to reinvent RADIUS... again.
If I walk into your store and steal a soda YOU the owner of the store have nothing to sell.
If you make copies for free, I have nothing to sell.
If soda becomes copyable, then it becomes worthless. Same thing happens when a store buys two sets of Super Bowl hats and shirts printed with each team as the winner. Once one of the teams loses, half are junk. All in all, the world would be a better place if food became free (maybe not soda, but still), regardless of the fact that an entire industry would be out of business. Do you really want me to pull out the buggy whip argument?
I'm going to give your co-worker a hint: that voluntary training is increasing your worth in the marketplace. It's not just an advantage to your current employer.
I've worked for a training provider and seen this from the other side. Increasing your marketplace value is actually a negative for the employer. From that point forward the company has a higher chance of losing you. Some employers would contract with us for special training that omits sections that are big on the certification test and not relevant to the work the employee is doing for the company. I'm not suggesting that this was a good thing, but it shows that certification isn't necessarily a win-win.
Unfortunately, that would block pretty much all outbound calls from call centers. Any call center I've ever worked with calls for multiple clients. They attach the number of the calling campaign to the caller id, not their own number, since no one ever wants to call the call center, they want to call "tech support for Acme Bearings" or whatever. The client doesn't want the number tied to the call center because they use that number on all of their advertising copy. If the number were owned by the call center, then the client couldn't switch to another one. Even corporations that don't do outbound calling like to do fancy stuff like put their main switchboard number on the caller id of the calls placed from all of their sites.
So, in reality, most commercial calls use spoofed caller id. The whole system is based on it. It's technically trivial to put some data on a call that charges an arbitrary amount to the other parties phone bill. The only thing that keeps the whole system in check is the fear of getting caught. With systems like this, there will always be scammers.
That's because if schools taught people how to properly test security, the government would label them terrorist breeding grounds.
Not really. My team has a great track record of our products passing security scans. We've never used mock hacking to find security issues in our code. We simply do rigorous code reviews against solid security principals. Some teams around us do the whole code-hack-fix thing, and they have a lot of security fix work every time the pen-testing tool is updated or changed.
I laugh every time I hear a colleague come back from some security class they were sent to and I find out that they spent five days running ten-year-old exploit tools against unpatched servers.
You're an idiot. You signed something under threat of prison / arrest without bothering to consult a lawyer. No amount of mention of poverty, trust, or even just plain intimidation should have made you do such a thing without first consulting a lawyer.
And here is the harm in the "If you're not guilty you have nothing to worry about" attitude. A lot of people act as if nothing can hurt them if they've done nothing wrong. These same people tend to look on those that protect themslves as guilty. The student may have been trying to appear innocent by cooperating instead of "acting guilty" by lawyering up so this would just blow over.
I always considered readability and maintainability to be implicit technical requirements for any project.
I look at it a bit differently. I consider readability and maintainability a core part of the craft of programming. I don't expect anyone to ask for them and I wouldn't compromise on them even if I were explicitly asked to do so. In my opinion, writing bad code is like being a doctor and taking shortcuts like not properly cleaning your instruments. Sure, you might be successful for a while. But, eventually it's going to cause problems.
I tend to ask "what requirements does this code fail to meet?" And very often, the reviewer has invented his own new requirement!
Given the bad code I run into, my answer would usually be "when it fails, there is no way to figure out what went wrong". Just because the business requirements didn't specify error handling and logging doesn't mean it is superfluous.
The bug I triaged today involved a UI where if you added a record to a table and pushed the save button twice, it would make two rows in the database. The underlying problem was that the original programmer sprinkled a bunch of status flags all over the place in a highly disorganized manner and he forgot to clear the "new" flag after saving. If I fix it by clearing the flag after save, it will still be bad code, even if it meets all of the requirements. Whether code is good/bad and whether it works/doesn't are two different questions.
It could be that your organization has a high tolerance for bad code. If defects are unlikely to cause major problems and fixes are easy to apply, then bad code might be OK. But, it's still bad code. If all of your code has to be validated by an expensive third before deployment and defect cost lives or a lot of money, then you really should write good code.
Wait, being a good arguer is a problem to be wary of? Often, the better arguer is the one who sees the problem the clearest. Also, the inability to defend a position can be a sign of cargo-cultism. I'm much more wary of someone who calls everything they do a "best practice" without ever being able to describe the benefits of said practice. That's how hungarian naming gets adopted.
XP already uses NTLMv2. You really want to make it refuse to do NTLMv1 and LM. The link in the summary tells you how.
It won't be long before companies figure out how to get them to work. The Phillips L-Prize bulb uses the LED as a source of photons to excite a phosphorescent material. The actual light that the bulb emits comes from the outer surface of the bulb, so directionality of the LED is irrelevant, as long as they can excite enough of the phosphor.
... and when web sites require membership, the newspaper industry will bounce back. The public is not obligated to support anyone's business model.
This isn't "oh no, you're going to kill the Internet", this is about both sides having some level of power and letting the web mature to a point where everyone is happy. That won't happen if consumers don't voice their opinion. There's no social contract here, just a bunch of people that discovered that they can make money by putting ad supported content on the web. When that becomes a poor way to make money, some will do something else and some will become really good at getting ads through the filters. The world will move on.
I've opened the side door of a plane at 15,000 feet. It's standard operating procedure for skydiving.
My 2560x1440 needs dual DVI. But, my cheapo GeForce 250 card has no problem driving it.
Actually the most frustrating thing Climate Change Deniers have done is to frame the discussion around whether it's happening and whether it's anthropomorphic. Of course it's happening and who cares if it's our fault. All that's important is: 1. How will it affect us. 2. What are our options?
I've seen very little discussion framed as "It will cost us X trillions to execute plan A and if we don't, ignoring it will cost Y trillions." Instead, we get drivel like "We didn't take care of the planet and we ruined it, now we need to curb fossil fuel use." I've yet to see any specific plan that will both be likely to actually work and is likely to cost less than the cost of the disaster that it will avoid. Instead we get a bunch of people saying it will be the end of the world. The world won't end... hundreds of millions of people may die and previously valuable land may become worthless, but the remainder of humanity will get along just fine.
Of course it is. That's hundreds of years of cultural integration of employers demanding to have salary negotiations kept secret. It's always in the worker's interest for these negotiation to be public and always in the employer's interest to have them secret. So, your statement boils down to "It's always been like this". That's not new information. What is new is that a labor board has now stated that it's your right to discuss this information and it's illegal to prevent this discussion.
This is a step forward in a better direction than labor unions. The problem I've always had with Unions is that you need to sign on with a slightly less abusive group to protect you from a more abusive group, you don't get to go your own way. Requiring open discussions of labor conditions is a step closer to a transparent labor market and more fair wages.
There was piracy without copy protection in the cassette tape days, and the recording business survived. They will survive just fine without DRM in the future. TiVo is a good example to learn from. Much money was made in the past on the assumption that people would watch commercials. TiVo and similar devices allowed a significant fraction of consumers to skip commercials. The ham-fisted approach would have been to make the fast-forward button illegal. The proper approach, that the market took, was to move many of the advertisements into the program.
DRM is a ham-fisted way to preserve a business model that is losing relevancy. The correct solution is to create new business models.
I hire a lot in IT. I started out by disregarding any resume with a provable lie on it. I quickly learned that 95% of the resumes that made it through pre-screening had blatant lies on them. Most of those weren't even the candidates fault, the employment agency they worked with put the lies on there to ensure that the resume made it to my desk (and it worked!!).
Now, I trust references from trusted sources first, things I learn from an interview second, and never trust a resume. It's a huge pain in the ass and I long for the old days when a piece of paper was a good summary of the history of a candidate. The last guy I hired came strongly recommended by my neighbor - he's working out well. The guy before him did very well on the phone interview, but it wasn't worth flying him out for a face-to-face interview for a four month contract job. We fired him after six days; we're pretty sure he had someone else do the interview for him.
Not really. Nitromethane has poor energy content, but makes for 4000HP engines. The amount of air you can pump through an engine is fixed by the displacement and maximum RPM of the components, and the fuel is limited by the amount of air that that quantity of fuel properly mixes with. Gasoline works at about a 13:1 ratio with air, alcohol at 6:1 and nitromethane at 2:1. So, for one revolution of a one liter engine, you can put through 1 unit of gasoline, 2.5 units of alcohol, or 6.4 units of nitromethane (with a unit being the amount of gasoline that properly mixes with one liter of air). Factoring in energy content, that makes alcohol capable of 30% more power and nitromethane capable of 75% more power, with no other modifications than a change of fuel and mixture adjustment. Add the cooling benefit of more liquid fuel being vaporized and it gets even better. Nitromethane engines use so much fuel that it's possible to hydro-lock them (the entire combustion chamber fills with incompressible liquid fuel - and very bad things happen).
If you're super good at programming clean secure C/C++ you might want to program your own webserver (servers like Apache are easier to use, yes, but they release security patches to them all the time, so they aren't THAT secure. A dedicated single program that only does a few things is likely to have less vulnerabilities).
That's the worst idea I've ever heard. Apache and IIS both average less than ten discovered meaningful vulnerabilities per year. Making a secure HTTP server is way harder than you think it is.
Use SSL or some other form of secure transport (https). This will insure (well not insure, but make it more difficult) that even if someone is able to snatch your user's packets (like if they are in Starbucks or something), they will have to decrypt them before they get a token (by which time it will have expired).
Look up Cross-Site Request Forgery, it's a whole class of attack that makes the browser do the hard work for you. This is a great example of a case where using a framework instead of rolling your own is best. Most authentication frameworks had some CSRF protections in them before most web developers even knew it was a problem to be worried about (for example, marking session cookies as HttpOnly).