Don't get confused by the maintainable code caveat. That was merely to suggest that there are alternate viewpoints to an absolute rule of "shorter is better".
Slightly longer programs may be better in some specific cases, but as a general rule I'd still avoid writing a paragraph where a line would do.
Do not underestimate the ability for certain cultures to cause species endangerment through some idea that it is fashionable or somehow medicinal. That's why rhinos and elephants have been facing critical existence failure.
I'd be more amused if it was an article decrying the current lack of proofreading for news outlets.
Typos are not grammar errors, really. They're errors in composition. No one who makes a typo is asserting that they properly spelled something they typo'ed and they would invariably correct the error upon noticing it. On board with no edit feature, or articles that were posted and not proofread, you will see more typos.
Well knowing answers is one level of learning. Analysis is another level of learning, and can be difficult to truly capture on a test.
More to the point, knowing answers that you just use to pass a tollbooth like a standardized test is not actually knowledge, because it generally does not sink in.
Yes, the students who know how to do those things will actually do well, but a test taking atmosphere is not always the most conducive to recollection of such information even for those people who do know the answers.
And I say this as someone who usually does fairly well on tests, enough so that I got into my first choice school for college. I think people with good knowledge, but poor test taking skills suffer from that atmosphere, and that same atmosphere encourages them to remember that knowledge as traumatic, rather than associate it with learning interesting things.
Well some teachers are people who care more about education than making money. They want the challenge of helping inner city youth, for instance.
Such people definitely exist.
And now, they could end up fired for taking on a challenge that most of us would consider laudable, even saintly.
Don't get me wrong, there are shitty teachers who skate by and do well with good union coverage, but I am not sure the testing metric is really a good process unless we actually want our students to maximize their short term memory and test taking skills.
Well, the amount of metrics is not really at issue here. Both no metrics and bad metrics represent the same state: non-existent applicable data.
No metrics is considered "better" because it avoids putting unwarranted faith in potentially bad data. But I'd argue that bad data moves us forward as long as it can be exposed to criticism. Having no data is simply shrugging our shoulders and refusing to even attempt to measure for fear of bad data.
Data is neither bad nor good, it is merely applicable or non applicable to what we are attempting to investigate. You only have a bad outcome when you act on non-applicable data as applicable data and that only happens when you follow a bad process.
For instance, I'd argue that making a decision based on data presented by a health food company who has no incentive to give you fully qualified and applicable data, but instead has an incentive to sell products is a bad process.
The data, unless fabricated, is still probably good data, but for another application. I wouldn't necessarily stop measuring 'trans-fats' or 'omega-3 fatty acids' in foods, even if I determined that using that measure as a product selection point causes bad outcomes in terms of unnecessary purchases.
The most productive coder is the coder who writes only the number of lines of code that are required (and not a line more), and who does so the quickest.
If you take three hours to develop 10 lines of code that are completely optimized, whereas the other guy just started typing and found the same solution in 1000 lines in the same amount of time, who was the most productive? You've both solved the problem, but the first person only has 10 lines of code to their name. Is he less productive? Certainly not as long as both met the requirements.
It *is* up for debate as to whether the less verbose coder is *better*. You might think so, but there are other considerations involved like what was sacrificed to do the job in only 10 lines. Shorter is not necessarily better, especially for maintainability, if perl scripts are anything to go on.
Yes, encryption is a joke, but you're also supposed to actually delete customer PII after a certain point in PCI as well. I doubt that all of those 37 million users had signed up in the last year or had even used the website in the last year. At least some substantial fraction of that number should have been safe from their CC data being nabbed that way, if the right policies had been enacted and in place.
It is 100% cool to start a new job at 45. Just don't expect to be paid like you've been doing the new job for 20 years. Or even 5.
Mind you, I don't believe someone has to "pay their dues". That's a bullshit reason for seniority pay. Experience is a practical set of skills and knowledge which you could only pick up by doing, but not everyone who grows old in a job actually accumulates experience.
The problem with switching jobs is that it can be prohibitive, but I'd say that there is always going to be a price to be paid to do that. It's hard to avoid. I need someone who can do the job because for us all to get paid, we need to be able to put out a product that pays the bills. If you're 45 and only have a fraction of those skills I either have to
a) hire someone who has what you are missing or b) somehow operate things while you are learning and risk failure.
Both of those scenarios are reality for an employer. It isn't like I want to dash your dreams of a new career, you know. But we're not a school. I can't pay you while you figure out what you want to do with your life. At some point, you have to take responsibility for intelligently transitioning yourself safely to a new career. Finding what you love is great, but it should not be a snap decision.
I have heard that the best determinator of success in development isn't stuff like Agile methodology or even management styles or age, it is having a group of people on the "same page". That could mean people who all like comic books, but realistically, it means people who all work with the same general mindset.
If you're an Agile shop and you have Agile believers, you're going to do Agile well.
If you have a bunch of waterfall people who love waterfall, they're going to waterfall like no one's business. And who is to say that waterfall doesn't work? It put people on the Moon, groundbreaking software was written in that manner. It can certainly work, if done well. And people who think it is great and who advocate for it will do it well.
Of course this can extend to the hours you like to work, or if you prefer to work remotely and use collaboration tools, as opposed to being together in an office.
The real problem comes when you have serious conflicts on how to get things done. People who are forced to use Agile, but secretly (or not secretly) hate it will quickly turn it into a bastardized version that doesn't work well. People who like Agile in a waterfall shop will chafe against the planning and specification requirements, and consequently, have a much higher chance of doing those vital tasks poorly.
Against those sorts of conflicts, I don't think that your race or sex or even age makes any difference in your ability to work together outside of what you have been taught about how you do your work. If you have a white guy and a black girl and an asian guy who all love Agile, they're going to succeed at that. The age or race or sex issues come about from how people in those groups approaches the methodology. If Methodology X was made up by a bunch of young white brogrammers, it may emphasis certain things that a brogrammer would do well or would prefer. However, if you had an older female of a different race or ethnic group who really "got" that methodology, I'd bet that she would be highly successful at it.
So if you are going to bias, it should be for methodology or at least, true openness to work in the desired methodology. The only time I have seen real break downs is when some people are not willing to at least bend to work together in the same way. They may accept your "orders" to do things in that manner, but you can tell that they will be ducking around the methodology every time you aren't looking, and in that way, causing eventually serious issues. And of course, they will be in constant conflict with other team members.
You don't have to be friends with your teammates to do good work. In fact, that can sometimes even be distracting. But you do need to go about your work in a way that is comprehensible and agreeable to the whole team so you can interact successfully. That's what makes any sort of team work.
I've had people work for me who at at least ten years older. I certainly wouldn't refuse to hire someone simply because they were older than I am. I would say that the only times I think age really has sort of come into it is the more indirect scenarios were the older people tend to come from big companies where they settled into a certain specialized role. As a manager at a smaller company, I don't need specialists, I need flexible generalists.
Many of those people pretty much crater out at that point. I asked a Linux admin candidate with a MS in Computer Security how to configure Apache. He had no idea. Of course, he could have said, "I tend to only use nginx" or something, but the reality was that his previous job was writing processes. In the past, he had worked with Linux a fair bit, but realistically, he was useless. His skills were so rusty that the rust itself had decayed to its component iron and oxygen atoms.
Of course, if you get a relatively bright candidate, it is certainly worth trying to see if they can pick up the easy tasks like web server configuration again, but then the big age-related whammy hits: they made a high salary as that sort of niche specialist due to their specialization and they want that while you train them to do a job they really can't do and often don't want to do.
And that is the point where their resume ends up in the reject pile. That's not age discrimination, but it is something you run into with people who are older. They get locked into what they've worked on, and they've become too comfortable with their salary and niche role. Then they get laid off and, surprise, surprise, no one wants a Systems Engineer/Analyst XII, and certainly no one wants to pay them what such a position would make at their previous firm for the privilege of teaching them to do their job.
I have only one word of advice to people getting older. Have relevant skills that are up to date. Even if you don't use them everyday in your specialist role. Do not get complacent. Someday, you'll need to get another job where your current specialization is only "nice to have". You don't need to be young to succeed, but you cannot sit on your ass, and older folks tend to start believing that they are able to get by with "experience". Forget about that. Stop thinking you get seniority just because you're old.
I had the same experience once. Turns out that the hiring VP had doubts about my budget experience (this was for a management job). Which was fine because I was a relatively new manager at the time and my past experience was less about having to make out formal budgets, so my answers did sound vague. What I didn't understand is why I got all the way past the CEO interview for him to decide that. It's not like there wasn't plenty of time for the VP to consider that over the next week or so between interviews.
When I was finally able to read the Slashdotted article, the people at ALM made it sound like they knew who it was and that it was someone technically related to the site, but not actually employed.
So, some sort of consultant or contractor. I wouldn't think a reputable security consultant would out them like this, as that would impact the trust other clients would have in them going forward, and you'd think they'd understand how easy it would be to finger them as the culprit.
Now a contract developer, sysadmin, tester, or something like that is certainly a possibility.
They probably don't on the public part of site itself, but at they same time, they needed a CC and couldn't be bothered to get their hands on some other CC#, so they used their own. If they get the CC bill, and not their spouse, they may have been 99% safe from discovery... unless someone outed their CC information from the site itself to a public list, obviously.
“Our one apology is to Mark Steele (Director of Security),” the manifesto reads. “You did everything you could, but nothing you could have done could have stopped this.”
Now that makes it sound like an insider job. If the Security boss did his job, then he'd have dealt with most remote attack vectors, which implies that they were hit from a very unlikely place, or by insiders who knew the ins and outs of the setup.
Or it could mean that, like at many places, the IS team did their best to secure things, but their requests for better practices and code were ignored. Which makes it sound even more like an insider.
I'll be interested to see who this is. And discovery of who it is may well happen if they were an insider. If you're an insider, it means that you're already on a very short list of people to investigate. Even W. Mark Felt was pegged by some people as the most likely candidate for being Deep Throat because you can frequently align the relatively short list with who has the most to gain or lose and who knows enough.
Yeah, but would you pay to get a delete from a criminal organization when the supposedly legit operation failed to do so? It is true that some of these criminal organizations have been known to have good "customer service" since their business model relies on someone actually trusting them to do what they say they are going to do, but it's still a huge gamble.
If I were one of those folks, I'd start rehearsing how I'd break it to my wife. That and/or start looking into divorce lawyers. Not doing anything and praying, ironically, might be your only other option.
Not only legal to delete the transactions from their online site, but if they were following PCI, required after a certain point.
They could certainly have kept all of that for a longer period in their accounting system, but it is not clear to me that this is what was hacked, as that should have been a non-public system.
Also, all PII and cardholder data should be encrypted, so either ALM didn't encrypt the data, used shit encryption, or there was an insider. Knowing many companies, any of the three is a likely option. Of course, I don't know if they have bothered with PCI compliance, but if there was ever a non-bank entity that should have it is this....
I'm not suggesting that we have to subject the systems to more tests than any reasonable human would have to, but at the same time, the response was to the assertion that humans have never been tested in vehicles.
Humans have certainly been tested in just about every common circumstance and in many that are very uncommon. It is not too much to ask to make sure the vehicles that would replace human drivers can at least handle all expected common situations.
The point is not that humans are better, but that they are a well tested group. That's a big difference. Enough so that there is confidence on how most humans react in most situations, be it well or poorly. We don't have that same information for AVs yet. And it will likely change with refinements.
I'd think the tests could be done in just the space of less than five years, if they put their minds to it. Those people who are calling for mandatory autonomous vehicles should be clamoring for well rounded testing. It is better to fail a few tests and reconfigure than it is for people to die and have everyone freaked out about AV's for years afterward.
Yes, but compare the rate which it might happen between people and automated systems. People do call the police all the time, but that's not the same thing as every vehicle on the road becoming the eyes of the government on you.
Just like it is not Orwellian to call the police when you suspect a crime is in progress, but it is Orwellian to have cameras on every house reporting any suspicious activity back to central. It isn't the reporting, it is the panopticon nature of the sensors. People do suspicious sorts of things every day that are meaningless, would you like to be dinged for every one of them?
Actually, from my experience, they may have a good reason, but the most likely reason is impatience with their lane. And it is frequently combined with sudden acceleration from a low speed, or even a stop, where the offender sees an opening to accelerate into so that they can just go faster. And no signal. There's no turn to be made, they often proceed for miles afterward on the same road.
Unless unfamiliar with the area, most people know when they need to get over to make their turn without having to generate a car accident. Of course, there are times when you really have to get into the right lane to exit and the cars form a solid line to the side of you. In that case, you should turn on your signal well back and provide notice you are moving over.
I hate to do it, but there are times where I will close with someone in front of me because I don't trust the person acting erratically in the other lane to be aware enough to provide a signal and enough time for me to react to their sudden move. While that does take me into the danger zone, I have excellent brakes, and I am aware of my position and am prepared to stop suddenly.
Unfortunately, I am also aware that this puts me in more danger, regardless, and I will try and let the erratic driver ahead unless I feel like they will cause me to end up in a rear end collision with them (where I will bear the presumption of guilt because I was behind and THEY cut down the safe driving distance I was attempting to maintain and no witnesses will likely come forward to support my assertion).
Autonomous driving will be nice if it rids us of those sorts of drivers, but honestly, those are the sorts of people who you will have to pry the steering wheel and stick shift from their cold dead hands.
Personally, I don't want to be unable to drive my own car, but I would be more than happy to have roads where I'd be required to turn on autonomous driving, if everyone else was also required to do the same. There's no need for me to operate my car manually when I am going to work, unless it is some sort of mixed environment where the autonomous driving mode only serves to have me doing 35mph in the right lane in ultrasafe mode to avoid the idiots zooming around at all speeds.
Speaking of speed. You know what will really encourage people to adopt autonomous driving? Faster road speeds and higher speed limits. Then you'll see people jumping all over them so that they can get to work at 90-100mph with no discernible loss of safety.
Brakes which have passed a yearly inspection (or any inspection) can still fail. It is just significantly more unlikely. Brake failure is always an option, and shouldn't be hand waved away.
However, the better way of explaining it is that it's the equivalent of worrying about dying of a dog bite when we've found a potential means to cure cancer. Dealing with the more likely case is much more useful than worrying about edge cases at the same time. Dog bites are still a potentially fatal situation, but you don't end a cancer program because the program doesn't deal with the possibility of dog bites.
Car accidents (and death) are still going to happen, even with autonomous vehicles. And some of those accidents will come from issues specific to the autonomous systems (ie. sensor or processor malfunctions) and from issues that were not addressed (like suddenly failing brakes).
Same here. I always seem to be getting hit while at a full stop. One winter a ramp got backed up off a highway in snowy conditions. It was a little unexpected, but I stopped with plenty of distance to spare......and then I watched in the rearview as the guy behind me didn't brake in time and slid right into my rear end. No time to move in that scenario.
The scenario for avoidance is definitely one that should be added, because while I didn't manage to get out of the way, a computer might have been able to roll me off to the shoulder and avoid the hit.
Personally, I see a great advantage to use of self-driving cars on highways and in urban areas, although I wonder how well it would really do with local driving in congested areas.
Humans *have* been tested in all of those conditions. As a group, humans have over 100 years of test time in vehicles in all weather, including on the Moon. We know that humans can handle all of those. What has not happened are tests in those conditions for self-driving vehicles.
Yes, there is great variance between humans, but in general, humans are quite capable of negotiating all of those conditions, if they put their mind to it.
The computer has some inherent advantages, particularly in regard to scenarios where humans are more likely to be inattentive or distracted. In the end, this should make driving safer, but don't dismiss the need for more testing just because the self-driving cars have some important advantages. Probable advantages or not, the tests still have to be done.
You'd probably still be guilty of a lesser charge. You just wouldn't be smacked with the most gigantic penalty or most draconian criminal charge that they might level at you.
Note that even a misdemeanor on your record, even if it is a relatively light one, is enough to disqualify you from a position like his if you do what he did. I've heard of people who have convictions where HR remarked that if they'd only had a DWI or an assault charge instead of a theft, they could have been hired (if it was clear that they were cleaned up), but due to contracts with clients and insurance policies, any person with a theft on their record can't be placed in a position where money might change hands or be controlled by their code. It will vary based on who it is, of course, but his work in the financial industry is over. And honestly, despite the company's attempt to throw the kitchen sink at him, he really only needed to be convicted of petty theft under the wrong circumstances to end that line of work for him.
Hacking? No problem, if he'd only broken into some government system. Just don't, under any circumstances, steal or even look at electronic representations of money, if you manage get into a system.
Not synonyms, but private addressing is a good way to help enforce access around internal networks that don't need outside to inside access. You can certainly set up routing that does the same thing, but you want defense in depth whenever you can.
Slashdot Mirror
Don't get confused by the maintainable code caveat. That was merely to suggest that there are alternate viewpoints to an absolute rule of "shorter is better".
Slightly longer programs may be better in some specific cases, but as a general rule I'd still avoid writing a paragraph where a line would do.
Do not underestimate the ability for certain cultures to cause species endangerment through some idea that it is fashionable or somehow medicinal. That's why rhinos and elephants have been facing critical existence failure.
I'd be more amused if it was an article decrying the current lack of proofreading for news outlets.
Typos are not grammar errors, really. They're errors in composition. No one who makes a typo is asserting that they properly spelled something they typo'ed and they would invariably correct the error upon noticing it. On board with no edit feature, or articles that were posted and not proofread, you will see more typos.
Well knowing answers is one level of learning. Analysis is another level of learning, and can be difficult to truly capture on a test.
More to the point, knowing answers that you just use to pass a tollbooth like a standardized test is not actually knowledge, because it generally does not sink in.
Yes, the students who know how to do those things will actually do well, but a test taking atmosphere is not always the most conducive to recollection of such information even for those people who do know the answers.
And I say this as someone who usually does fairly well on tests, enough so that I got into my first choice school for college. I think people with good knowledge, but poor test taking skills suffer from that atmosphere, and that same atmosphere encourages them to remember that knowledge as traumatic, rather than associate it with learning interesting things.
Well some teachers are people who care more about education than making money. They want the challenge of helping inner city youth, for instance.
Such people definitely exist.
And now, they could end up fired for taking on a challenge that most of us would consider laudable, even saintly.
Don't get me wrong, there are shitty teachers who skate by and do well with good union coverage, but I am not sure the testing metric is really a good process unless we actually want our students to maximize their short term memory and test taking skills.
Well, the amount of metrics is not really at issue here. Both no metrics and bad metrics represent the same state: non-existent applicable data.
No metrics is considered "better" because it avoids putting unwarranted faith in potentially bad data. But I'd argue that bad data moves us forward as long as it can be exposed to criticism. Having no data is simply shrugging our shoulders and refusing to even attempt to measure for fear of bad data.
Data is neither bad nor good, it is merely applicable or non applicable to what we are attempting to investigate. You only have a bad outcome when you act on non-applicable data as applicable data and that only happens when you follow a bad process.
For instance, I'd argue that making a decision based on data presented by a health food company who has no incentive to give you fully qualified and applicable data, but instead has an incentive to sell products is a bad process.
The data, unless fabricated, is still probably good data, but for another application. I wouldn't necessarily stop measuring 'trans-fats' or 'omega-3 fatty acids' in foods, even if I determined that using that measure as a product selection point causes bad outcomes in terms of unnecessary purchases.
Was he wrong?
The most productive coder is the coder who writes only the number of lines of code that are required (and not a line more), and who does so the quickest.
If you take three hours to develop 10 lines of code that are completely optimized, whereas the other guy just started typing and found the same solution in 1000 lines in the same amount of time, who was the most productive? You've both solved the problem, but the first person only has 10 lines of code to their name. Is he less productive? Certainly not as long as both met the requirements.
It *is* up for debate as to whether the less verbose coder is *better*. You might think so, but there are other considerations involved like what was sacrificed to do the job in only 10 lines. Shorter is not necessarily better, especially for maintainability, if perl scripts are anything to go on.
Yes, encryption is a joke, but you're also supposed to actually delete customer PII after a certain point in PCI as well. I doubt that all of those 37 million users had signed up in the last year or had even used the website in the last year. At least some substantial fraction of that number should have been safe from their CC data being nabbed that way, if the right policies had been enacted and in place.
It is 100% cool to start a new job at 45. Just don't expect to be paid like you've been doing the new job for 20 years. Or even 5.
Mind you, I don't believe someone has to "pay their dues". That's a bullshit reason for seniority pay. Experience is a practical set of skills and knowledge which you could only pick up by doing, but not everyone who grows old in a job actually accumulates experience.
The problem with switching jobs is that it can be prohibitive, but I'd say that there is always going to be a price to be paid to do that. It's hard to avoid. I need someone who can do the job because for us all to get paid, we need to be able to put out a product that pays the bills. If you're 45 and only have a fraction of those skills I either have to
a) hire someone who has what you are missing or
b) somehow operate things while you are learning and risk failure.
Both of those scenarios are reality for an employer. It isn't like I want to dash your dreams of a new career, you know. But we're not a school. I can't pay you while you figure out what you want to do with your life. At some point, you have to take responsibility for intelligently transitioning yourself safely to a new career. Finding what you love is great, but it should not be a snap decision.
I have heard that the best determinator of success in development isn't stuff like Agile methodology or even management styles or age, it is having a group of people on the "same page". That could mean people who all like comic books, but realistically, it means people who all work with the same general mindset.
If you're an Agile shop and you have Agile believers, you're going to do Agile well.
If you have a bunch of waterfall people who love waterfall, they're going to waterfall like no one's business. And who is to say that waterfall doesn't work? It put people on the Moon, groundbreaking software was written in that manner. It can certainly work, if done well. And people who think it is great and who advocate for it will do it well.
Of course this can extend to the hours you like to work, or if you prefer to work remotely and use collaboration tools, as opposed to being together in an office.
The real problem comes when you have serious conflicts on how to get things done. People who are forced to use Agile, but secretly (or not secretly) hate it will quickly turn it into a bastardized version that doesn't work well. People who like Agile in a waterfall shop will chafe against the planning and specification requirements, and consequently, have a much higher chance of doing those vital tasks poorly.
Against those sorts of conflicts, I don't think that your race or sex or even age makes any difference in your ability to work together outside of what you have been taught about how you do your work. If you have a white guy and a black girl and an asian guy who all love Agile, they're going to succeed at that. The age or race or sex issues come about from how people in those groups approaches the methodology. If Methodology X was made up by a bunch of young white brogrammers, it may emphasis certain things that a brogrammer would do well or would prefer. However, if you had an older female of a different race or ethnic group who really "got" that methodology, I'd bet that she would be highly successful at it.
So if you are going to bias, it should be for methodology or at least, true openness to work in the desired methodology. The only time I have seen real break downs is when some people are not willing to at least bend to work together in the same way. They may accept your "orders" to do things in that manner, but you can tell that they will be ducking around the methodology every time you aren't looking, and in that way, causing eventually serious issues. And of course, they will be in constant conflict with other team members.
You don't have to be friends with your teammates to do good work. In fact, that can sometimes even be distracting. But you do need to go about your work in a way that is comprehensible and agreeable to the whole team so you can interact successfully. That's what makes any sort of team work.
I've had people work for me who at at least ten years older. I certainly wouldn't refuse to hire someone simply because they were older than I am. I would say that the only times I think age really has sort of come into it is the more indirect scenarios were the older people tend to come from big companies where they settled into a certain specialized role. As a manager at a smaller company, I don't need specialists, I need flexible generalists.
Many of those people pretty much crater out at that point. I asked a Linux admin candidate with a MS in Computer Security how to configure Apache. He had no idea. Of course, he could have said, "I tend to only use nginx" or something, but the reality was that his previous job was writing processes. In the past, he had worked with Linux a fair bit, but realistically, he was useless. His skills were so rusty that the rust itself had decayed to its component iron and oxygen atoms.
Of course, if you get a relatively bright candidate, it is certainly worth trying to see if they can pick up the easy tasks like web server configuration again, but then the big age-related whammy hits: they made a high salary as that sort of niche specialist due to their specialization and they want that while you train them to do a job they really can't do and often don't want to do.
And that is the point where their resume ends up in the reject pile. That's not age discrimination, but it is something you run into with people who are older. They get locked into what they've worked on, and they've become too comfortable with their salary and niche role. Then they get laid off and, surprise, surprise, no one wants a Systems Engineer/Analyst XII, and certainly no one wants to pay them what such a position would make at their previous firm for the privilege of teaching them to do their job.
I have only one word of advice to people getting older. Have relevant skills that are up to date. Even if you don't use them everyday in your specialist role. Do not get complacent. Someday, you'll need to get another job where your current specialization is only "nice to have". You don't need to be young to succeed, but you cannot sit on your ass, and older folks tend to start believing that they are able to get by with "experience". Forget about that. Stop thinking you get seniority just because you're old.
I had the same experience once. Turns out that the hiring VP had doubts about my budget experience (this was for a management job). Which was fine because I was a relatively new manager at the time and my past experience was less about having to make out formal budgets, so my answers did sound vague. What I didn't understand is why I got all the way past the CEO interview for him to decide that. It's not like there wasn't plenty of time for the VP to consider that over the next week or so between interviews.
When I was finally able to read the Slashdotted article, the people at ALM made it sound like they knew who it was and that it was someone technically related to the site, but not actually employed.
So, some sort of consultant or contractor. I wouldn't think a reputable security consultant would out them like this, as that would impact the trust other clients would have in them going forward, and you'd think they'd understand how easy it would be to finger them as the culprit.
Now a contract developer, sysadmin, tester, or something like that is certainly a possibility.
They probably don't on the public part of site itself, but at they same time, they needed a CC and couldn't be bothered to get their hands on some other CC#, so they used their own. If they get the CC bill, and not their spouse, they may have been 99% safe from discovery... unless someone outed their CC information from the site itself to a public list, obviously.
“Our one apology is to Mark Steele (Director of Security),” the manifesto reads. “You did everything you could, but nothing you could have done could have stopped this.”
Now that makes it sound like an insider job. If the Security boss did his job, then he'd have dealt with most remote attack vectors, which implies that they were hit from a very unlikely place, or by insiders who knew the ins and outs of the setup.
Or it could mean that, like at many places, the IS team did their best to secure things, but their requests for better practices and code were ignored. Which makes it sound even more like an insider.
I'll be interested to see who this is. And discovery of who it is may well happen if they were an insider. If you're an insider, it means that you're already on a very short list of people to investigate. Even W. Mark Felt was pegged by some people as the most likely candidate for being Deep Throat because you can frequently align the relatively short list with who has the most to gain or lose and who knows enough.
Yeah, but would you pay to get a delete from a criminal organization when the supposedly legit operation failed to do so? It is true that some of these criminal organizations have been known to have good "customer service" since their business model relies on someone actually trusting them to do what they say they are going to do, but it's still a huge gamble.
If I were one of those folks, I'd start rehearsing how I'd break it to my wife. That and/or start looking into divorce lawyers. Not doing anything and praying, ironically, might be your only other option.
Not only legal to delete the transactions from their online site, but if they were following PCI, required after a certain point.
They could certainly have kept all of that for a longer period in their accounting system, but it is not clear to me that this is what was hacked, as that should have been a non-public system.
Also, all PII and cardholder data should be encrypted, so either ALM didn't encrypt the data, used shit encryption, or there was an insider. Knowing many companies, any of the three is a likely option. Of course, I don't know if they have bothered with PCI compliance, but if there was ever a non-bank entity that should have it is this....
I'm not suggesting that we have to subject the systems to more tests than any reasonable human would have to, but at the same time, the response was to the assertion that humans have never been tested in vehicles.
Humans have certainly been tested in just about every common circumstance and in many that are very uncommon. It is not too much to ask to make sure the vehicles that would replace human drivers can at least handle all expected common situations.
The point is not that humans are better, but that they are a well tested group. That's a big difference. Enough so that there is confidence on how most humans react in most situations, be it well or poorly. We don't have that same information for AVs yet. And it will likely change with refinements.
I'd think the tests could be done in just the space of less than five years, if they put their minds to it. Those people who are calling for mandatory autonomous vehicles should be clamoring for well rounded testing. It is better to fail a few tests and reconfigure than it is for people to die and have everyone freaked out about AV's for years afterward.
Yes, but compare the rate which it might happen between people and automated systems. People do call the police all the time, but that's not the same thing as every vehicle on the road becoming the eyes of the government on you.
Just like it is not Orwellian to call the police when you suspect a crime is in progress, but it is Orwellian to have cameras on every house reporting any suspicious activity back to central. It isn't the reporting, it is the panopticon nature of the sensors. People do suspicious sorts of things every day that are meaningless, would you like to be dinged for every one of them?
Actually, from my experience, they may have a good reason, but the most likely reason is impatience with their lane. And it is frequently combined with sudden acceleration from a low speed, or even a stop, where the offender sees an opening to accelerate into so that they can just go faster. And no signal. There's no turn to be made, they often proceed for miles afterward on the same road.
Unless unfamiliar with the area, most people know when they need to get over to make their turn without having to generate a car accident. Of course, there are times when you really have to get into the right lane to exit and the cars form a solid line to the side of you. In that case, you should turn on your signal well back and provide notice you are moving over.
I hate to do it, but there are times where I will close with someone in front of me because I don't trust the person acting erratically in the other lane to be aware enough to provide a signal and enough time for me to react to their sudden move. While that does take me into the danger zone, I have excellent brakes, and I am aware of my position and am prepared to stop suddenly.
Unfortunately, I am also aware that this puts me in more danger, regardless, and I will try and let the erratic driver ahead unless I feel like they will cause me to end up in a rear end collision with them (where I will bear the presumption of guilt because I was behind and THEY cut down the safe driving distance I was attempting to maintain and no witnesses will likely come forward to support my assertion).
Autonomous driving will be nice if it rids us of those sorts of drivers, but honestly, those are the sorts of people who you will have to pry the steering wheel and stick shift from their cold dead hands.
Personally, I don't want to be unable to drive my own car, but I would be more than happy to have roads where I'd be required to turn on autonomous driving, if everyone else was also required to do the same. There's no need for me to operate my car manually when I am going to work, unless it is some sort of mixed environment where the autonomous driving mode only serves to have me doing 35mph in the right lane in ultrasafe mode to avoid the idiots zooming around at all speeds.
Speaking of speed. You know what will really encourage people to adopt autonomous driving? Faster road speeds and higher speed limits. Then you'll see people jumping all over them so that they can get to work at 90-100mph with no discernible loss of safety.
Brakes which have passed a yearly inspection (or any inspection) can still fail. It is just significantly more unlikely. Brake failure is always an option, and shouldn't be hand waved away.
However, the better way of explaining it is that it's the equivalent of worrying about dying of a dog bite when we've found a potential means to cure cancer. Dealing with the more likely case is much more useful than worrying about edge cases at the same time. Dog bites are still a potentially fatal situation, but you don't end a cancer program because the program doesn't deal with the possibility of dog bites.
Car accidents (and death) are still going to happen, even with autonomous vehicles. And some of those accidents will come from issues specific to the autonomous systems (ie. sensor or processor malfunctions) and from issues that were not addressed (like suddenly failing brakes).
Same here. I always seem to be getting hit while at a full stop. One winter a ramp got backed up off a highway in snowy conditions. It was a little unexpected, but I stopped with plenty of distance to spare... ...and then I watched in the rearview as the guy behind me didn't brake in time and slid right into my rear end. No time to move in that scenario.
The scenario for avoidance is definitely one that should be added, because while I didn't manage to get out of the way, a computer might have been able to roll me off to the shoulder and avoid the hit.
Personally, I see a great advantage to use of self-driving cars on highways and in urban areas, although I wonder how well it would really do with local driving in congested areas.
Humans *have* been tested in all of those conditions. As a group, humans have over 100 years of test time in vehicles in all weather, including on the Moon. We know that humans can handle all of those. What has not happened are tests in those conditions for self-driving vehicles.
Yes, there is great variance between humans, but in general, humans are quite capable of negotiating all of those conditions, if they put their mind to it.
The computer has some inherent advantages, particularly in regard to scenarios where humans are more likely to be inattentive or distracted. In the end, this should make driving safer, but don't dismiss the need for more testing just because the self-driving cars have some important advantages. Probable advantages or not, the tests still have to be done.
You'd probably still be guilty of a lesser charge. You just wouldn't be smacked with the most gigantic penalty or most draconian criminal charge that they might level at you.
Note that even a misdemeanor on your record, even if it is a relatively light one, is enough to disqualify you from a position like his if you do what he did. I've heard of people who have convictions where HR remarked that if they'd only had a DWI or an assault charge instead of a theft, they could have been hired (if it was clear that they were cleaned up), but due to contracts with clients and insurance policies, any person with a theft on their record can't be placed in a position where money might change hands or be controlled by their code. It will vary based on who it is, of course, but his work in the financial industry is over. And honestly, despite the company's attempt to throw the kitchen sink at him, he really only needed to be convicted of petty theft under the wrong circumstances to end that line of work for him.
Hacking? No problem, if he'd only broken into some government system. Just don't, under any circumstances, steal or even look at electronic representations of money, if you manage get into a system.
Not synonyms, but private addressing is a good way to help enforce access around internal networks that don't need outside to inside access. You can certainly set up routing that does the same thing, but you want defense in depth whenever you can.