I can't see myself recommending this guide to anyone. A few things stand out:
- the invitation to "go away" if you confuse ESR's definition of hacking with the definition the general public uses.
- the suggestion that hacking is something for those with above-average talent for programming. Perhaps you should keep reading if you count yourself as above average?
- the proposal of a system for learning how to hack that is apparently so robust that it is self-evident. No examples need be brought in to support this proposal, nor does it need to defend itself from alternative systems.
- it is suggested that hacking is the only way for software architects to train their design sense. Ok, sure.
The biggest problem I have is that the vast majority of ESR's suggestions are really good ones. I agree with plenty of things he's saying. I just wish, like many open source products, it was packaged in a more digestible fashion, so I could recommend it to less experienced friends.
* to me, his opening line means that you should "go away" if your reason for reading this article was to learn how to commit cybercrime
* "above-average" could also be interpreted several ways. Perhaps most programmers have an above-average talent for programming, which is part of what attracted them to it in the first place? In this interpretation, the people who have below-average talent give up and choose to do something that they are talented at.
I think this guide has a good place for children who are interested in computers and get in trouble for messing with their schools network. Many of these kids will have absorbed media which does not really understand the diffrence between being a software engineer and breaking into computers. They may not know about the FOSS/unix world. I think giving this to them would do them a lot of good.
My main problem with it is that ESR is unable to differentiate between being a good programmer and being ESR.
Really what we need is a guide written by a prominent member of the FOSS community who can show budding programmers what's out there in modern FOSS(this was written in 1996) without couching it in language designed to sate the author's ego.
"My main problem with it is that ESR is unable to differentiate between being a good programmer and being ESR."
This line really identifies what my issue with ESR is. I've skimmed over his writings, and he definitely mixes the skill of being a hacker with his own beliefs about what that person should think and how that person should act. That theme definitely runs in his blog - the technical aspects of are great, but there's definitely a lot of humble bragging going on as well as most of the commentors being nothing more than an echo chamber.
I read ESR's How to Become a Hacker about 10 years ago, and it was what turned me from a kid who spent a lot of time on computers and was interested in them into a programmer.
Similarly for How to Ask Questions the Smart Way, which is an article I want to link to people, but when I check that it actually applies I often abort.
I think I agree to some degree, but I think I would still recommend this to a friend if they asked about something related.
At best, at least for me, I think it would be nice to have a process for someone who hasn't figured out what works for them best, so they can at least be knowledgeable of and refer to a way of approaching a task they want to achieve if they feel like they don't have one. And at worse, it would save me time trying to codify my way of doing things and trying to tailor it to who is asking.
It was also kind of interesting reading this, and thinking "this process seems too rigid for me", as I was thinking about how yesterday I decided to hack at firefox's http client and set the user agent based on the current most popular user-agent field from the public data released by companies like statcounter or the most frequent user agent sent over a local network while at the same time thinking, "if I followed this more closely I could have saved some time in some places".
I read it without consideration about the author. Overall I thought it was good general information and took note of the sincerity of the tone to urge readers to snuggle "post-coital esp. with virgin". Was expecting more diving into kinky human sexuality but perhaps seems more like the author is trying to educate the basics to us his brethren.
The key point takeaway for me is how you create cheap consumer level electronics with a research team behind it. (Hint - Nokia's investment in R&D depends on them expecting to get lots customers)
Con: There is contention that this order of magnitude increase in pixels is not useful to image quality. And proprietary algo's on embdeded hardware in the camera module (7px "sampling" -> 1px "stored") is not available.
Pro: In some cases, there is contention that this innovative smartphone camera increases signal to noise ratio, so maybe we live with the black-box of the hardware to get better images downstream. And if "gimmicks" like this huge camera sensor sell units, we can expect more cheaply available units for mass deployment of the hardware/software.
-> Thus for hacking we're riding the wave of mass adoption of what we're once esoteric technologies - high-end digital image sensors.
so how are people coming up with zero-day vulnerabilities all the time? How are these people able to find a way to inject code in pdf or word documentation year after year? Is software forever vulnerable, even ones written by huge number of engineers?
I imagine having a huge number of engineers actually increases the chances that software is vulnerable. This is because bugs often arise when different people are making different assumptions about what some code does or doesn't do.
It always makes me uneasy when I have to go and make modifications to other people's code, especially in the workplace where you usually don't have the luxury of time to fully understand the code base.
> If you think “hacking” has anything to do with computer crime or security breaking and came here to learn that, you can go away now. There's nothing for you here.
This. I don't think the author realizes that the reality out there is complex. You can "hack" for "good" or for "bad". Open-source is about not putting a moral judgment about what you want to achieve.
- the invitation to "go away" if you confuse ESR's definition of hacking with the definition the general public uses.
- the suggestion that hacking is something for those with above-average talent for programming. Perhaps you should keep reading if you count yourself as above average?
- the proposal of a system for learning how to hack that is apparently so robust that it is self-evident. No examples need be brought in to support this proposal, nor does it need to defend itself from alternative systems.
- it is suggested that hacking is the only way for software architects to train their design sense. Ok, sure.
The biggest problem I have is that the vast majority of ESR's suggestions are really good ones. I agree with plenty of things he's saying. I just wish, like many open source products, it was packaged in a more digestible fashion, so I could recommend it to less experienced friends.