Meanwhile, Peter Christensen, in his own blogpost, defined the two as follows:
Hacker: Always trying new things, trying to stretch the limits of what's possible or what exists… Linus Torvalds is a great example of a hacker - he had two giant ideas that few thought were possible - writing a free operating system and doing it with a worldwide collection of volunteers. Once something is functional and successful, the hacker moves on to another hard problem, like a serial entrepreneur.
Engineer: All of the definitions of engineering that I've found were too complicated and missed the point, so I propose this: An engineer is someone who takes something that is known to be possible, and makes it fit within a given, limiting set of criteria. Some common criteria are:
within a fixed budget
meet a performance benchmark
exceed certain reliability requirements
make it aesthetically pleasing
must include a certain capacity
meet arbitrary regulations (accessibility, environmental, paying living wages, etc)
Note that this doesn't mean that an engineer is any less creative than a hacker. On the contrary, the constraints provided by the engineering problem can provoke more creative and original thinking than that of the original invention.
Engineers can become hackers
On the other hand, Kim Guldberg answered, "What is the difference between an engineer and a hacker?" in quora as follows:
For journalists and the general public a hacker is someone who breaks into computer systems stealing information and doing other malicious stuff.
For hackers the term seems to have expanded… Today being a hacker is more a question of mind set than just skill set. It's a curious individual, who has obvious talents and knowledge. He (and today sometimes also she) is somewhat geeky and obsessive in his interests, he is persistent and able to think out of the box. He is not bound by conventions and what is understood as possible or the right way of doing things and he has an open mind.
So the answer to your question must be. If an engineer has the above-mentioned mind set, he can be a hacker if he wishes and work hard at it.
With that beginning, tell us your definitions of hackers and engineers, and explain (if you can) how engineers can become hackers.
Thanks, Junko. I love this discussion. In professional engineering, a hack doesn't mean high quality. So maybe it's a pride thing. BTW, to comment on this article, make sure you log in separately because for some reason this article hangs on the log in screen. Hmmm, unless you have a hack to get around that problem, you'll have to use the workaround for now.
First, we need to define which "hacker" you're referring to. Initially it seems like you're talking about someone with malicious intent. Frankly, I see no correlation between engineers and hackers in that sense. The equipment may be similar but it is the mallice that is the differentiating factor.
Toward the middle of the article you're discussing "hackers" in the sense of people who are building things but aren't necessarily fully educated or involved in their career path. This is the one I'd like to focus on. I think many engineers go home at the end of the day and hack. They find a problem and they solve it, and since they're not doing it for work, they aren't following SOP. They're exploring and chasing passions and obsessions, often only for the purpose of doing it. I think engineers can be hackers, and many uneducated hackers can go on to be engineers.
One interesting thing I've seen is when a hacker is obsessed with a specific technology. They learn everything they can about it, sometimes surpassing professionals in their knowledge. However, they have no interest whatsoever in broadening into all the other subjects that one would have to master to become a professional.
Among engineers who can best think like hackers are those who work on testing, he added.
No surprise. A friend who is a test engineer said the fundamental distinction between a developer and a test engineer is that a developer assumes the code will work, while a test engineer assumes the code will fail. Indeed, getting it to fail is what a test engineer does.
"Hackers" in the pejorative sense are behaving like test engineers. The test engineer wants to break the code and discover how and why it broke, so the code can be changed to make that failure impossible. The hacker is looking for failure points where code can be exploited for malicious purposes. The process is similar. The intended end result is very different.
@caleb, there are many ways to define hackers, and clearly, many people have defined it differently.
But my original intention was, as you can see in the first few graphs of my story:
....Soja and I were discussing issues concerning cars. I was asking him how the best automotive chip suppliers like Freescale can get a few steps ahead of hackers to identify potential security holes.
Soja quipped: "To protect against attacks, you need to think like attackers."
My conversation with this Freescale executive really opened my eyes. For example, established automotive chip suppliers -- usually a full of smart engineers -- do need help from hackers. So that they can think ahead, figuring out which security holes that need to patch in designing their next generation automotive MCU, for example.
In that context, I would like to know whetther design engineers at chip companies can morph themselves into hackers to help that cause, or they are really two different types of people and they probably need to hire external "hackers" to do the job...
well put, DMcCunney. So you are saying in their pursuit of "failure points" in a system, test engineers and hackers are working with a similar mindset. It makes sense. Do you think, then, it is customary within an engineering organization to leverage their own test engineers in finding any weakness of a system that can be hacked?
It's all about motif. A Hacker hacks, that is they break the code, to get inside and perform malicious acts. A Test engineer's motivation is to improve the code once the tests show that the code is not fullproof. The only way to get into the mindset of a hacker is think maleciously. Testing the new code of a tested piece of code is much harder. Hence in systems that require close to 100 percent reliability such as space aircrafts redundancy is built in. In security for commercial systems redundancy should also be built in. It is more expensive but might be worth the cost to ensure reliability is met and made harder for hackers to plunder and steal. The current hacker story going around should be analyzed for its flaws. see: http://www.bloomberg.com/news/2013-07-25/5-hackers-charged-in-largest-data-breach-scheme-in-u-s-.html
Do you think, then, it is customary within an engineering organization to leverage their own test engineers in finding any weakness of a system that can be hacked?
I'm not sure it's deliberately done for that purpose, but crafting code harder to hack will be a side-effect of the test process.
The most common hacker exploit is a buffer overflow. Code manipulates data. It expects to get a certain amount of data, in a certain format, and allocates a chunk of memory to hold the data it's manipulating. What happens if it gets more data than expected? What happens to the excess that won't fit in the buffer? In a buffer overflow exploit, that extra data overflows the buffer, and overwrites some other part of memory. The result may allow the hacker to compromise the system,
Checking for things like buffer overflows in code should be part of the test process. The general rules are "never trust your data", and "never assume that your code can handle every possible condition that might arise when it runs."
Most of the publicized exploits I can think of offhand are in legacy code first written before hacking became common. It simply didn't occur to the developers that someone might deliberately try to overflow a buffer with bad intent. In normal operation a buffer overflow wouldn't happen, so there was no provision to guard against it. Most of the Windows Critical Patches addressed precisely those oversights.
I've heard a similar comment about needing to think like a hacker to be able to prevent hacking, during a presentation at the Black Hat conference. I think it reflects the feeling that there is a different mindset (attitude, belief, morality, whatever) involved. On the one hand, you're looking at something to figure out how to make it work correctly as intended. On the other hand you're looking at something to figure out how to make it do something unintended.
But I think we need to be careful in generalizing the term "hacker" too far. I see two different kinds of folks who fall under that term. One is the person who creates a kind of "quick and dirty" solution to a problem and the other is someone who tries to break into a system for malicious purposes.
In order to answer your question, then, you need to be sure of which type of hacker you are talking about. I think that hackers of the first type (problem solvers) can easily act as engineers if they learn and use formal methods, and engineers become hackers by bypassing formality. Some folks may be so ingrained in using formal methods that they need to learn how to let go, but I think any engineer can be a hacker in this sense. One or the other mode might feel more natural to someone, though, so to some extent moving between hacker and engineer is a bit like speaking two languages - your native one and one you learn later in life. The degree of fluency someone has in this second language (or engineering mode) will vary from person to person.
The second type of hacking, though, involves a gap that is a lot harder to bridge. This kind of hacking is filled with ego, greed, and malice and getting into a mindset of seeking to destroy, pervert, or circumvent a design for gain or pride (so that you can predict avenues of attack and block them) is a lot harder for folks to get into when their natural inclination is to build, refine, and perfect. This kind of hacking can also be learned, no doubt, but requires a much greater mental shft.
So, which group were you asking about in the blog?
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.