I always thought that this article read more like "How to become Eric S. Raymond". There's a lot in here that is really pretty painful to read 14 years on; in particular, I find the argument that you have to start off by using a Unix in order to become a proficient hacker to be particularly disingenuous.
The general aspect that I dislike is the idea that there is only one kind of hacker -- the kind that fits into Eric S. Raymond's "the hacker culture". For instance, he gives the monoculture that all hackers speak English; but just a few weeks ago, we saw an article on HN about the old microcomputers of the Soviet Bloc (I wish I could find the link now). And, perhaps, maybe my all-time favorite hacks were executed by demosceners who spoke little-to-no English. Are these people not hackers? I don't think you'd find anyone who could argue that, but they are not part of Eric S. Raymond's monoculture.
The great essay that I have always wanted to read about How to Become a Hacker would be answering the question of how to find joy in the minutiae, and how to put all the little pieces together to make the most interesting things. But this essay is not that.
Yes, the jargon file and this article are mired in specifics that are probably bad. I also don't think the weirdness the jargon file gets into near the end regarding personality archetypes is very valid, interesting or useful, and it has always felt a little creepy to me. But I would say the core principles mentioned at the top of this article are pretty valid:
1. The world is full of fascinating problems waiting to be solved.
2. No problem should ever have to be solved twice.
3. Boredom and drudgery are evil.
4. Freedom is good.
5. Attitude is no substitute for competence.
That seems to capture the hacker spirit pretty well.
One problem with these 5 "core principles" is that they apply just as well to tax accounting. It's the places where ESR writes things that don't apply to contracts law or mechanical engineering where he goes off the rails, which is a telling problem with the essay.
Even more, I would say that several of the later points are very much valid still too. I'm still one of those people that believe that hacking does in fact relate to computers and electronics (!), so I think that learning to program, knowing HTML, being fluent in Unix and the ways of contributing mentioned in the article are still perfectly relevant as of today.
I do agree with jwise0, though, in that the phrasing and some details are way too specific to the author's own experience.
> I find the argument that you have to start off by using a Unix in order to become a proficient hacker to be particularly disingenuous.
While "Unix" is perhaps not a requirement, but he does give a convincing argument why it should be an open source operating system - which significantly reduces the number of options.
Sure, you can be a hacker who uses Windows, but you're locked out of half of what your computer can do. That is a restriction.
Yes, you can work only on the userspace but to me, the essence of being a hacker is having a keen interest in the whole stack. While you're still locked out of your CPU internals, an avid hacker should also have an interest in hardware hacking.
Feel free to disagree, but I'm on ESR's side on this one.
> but you're locked out of half of what your computer can do.
I'm a pretty big Unix guy, I run Linux desktops and FreeBSD servers, but you're going to need to clarify what you mean by that.
What exactly is the restriction? Assuming you're willing to install some drivers and patch some system dlls, you can generally achieve the same things.
You can very easily disable driver signature enforcement in Windows, as I have and as does anyone who writes drivers for Windows platforms or does low-level reverse engineering work on it. I think the balance of "force signing by default but allow it to be turned off" is a pretty good one, works well for Windows drivers and for Android at least.
All of the below (and the parent post) is my opinion. You can disagree with me, and I'm fine with that.
You're unable to study what your computer actually does. You don't have access to the source of anything that happens in kernel space. You can take university OS courses and tinker with the educational toy operating systems, read about Windows internals but to see what you're actually running is different not only at a philosophical level but also practically.
Yes, you can get into kernel space in Windows by doing a driver DLL, so you can make your computer "do" anything, but what you, as a person, will do is a lot different when dealing with a black box rather than a white box. When doing Windows kernel space driver development, you're reading the documentation (and hope that your computer does what it says), when doing that with an open source OS, you can read the source too (and know that the computer does exactly that).
To me (you don't have to agree), the essence of being a computer is that you don't only use your computer to get work done or use it for entertainment. Computers are the entertainment (and perhaps the work too, like in my case in the semiconductor industry).
> You're unable to study what your computer actually does. You don't have access to the source of anything that happens in kernel space. You can take university OS courses and tinker with the educational toy operating systems, read about Windows internals but to see what you're actually running is different not only at a philosophical level but also practically.
Uhm, or I can fire up windbg and trace through my kernel... not sure what you're getting at (though I do miss the days of softice where I could just hit ctrl+d).
Same goes for pretty much everything else you stated too. We have kernel level debuggers, don't blame me if you can't be bothered to learn a little assembly and trace out the knowledge you need.
Sure, it may not be as easy as C, but it's _very_ possible. It just requires some reverse engineering skill too.
If what you were saying was true, I would absolutely agree with you, but as long as ring0 debuggers exist, it won't be. I find reverse engineering just as exciting if not more so than forward engineering most of the time.
Yeah, sure it's possible but it's quite different to actually getting your hands on the source as well as the version history of the source (why is this code here? git blame and you'll know why) and make changes to it if you want.
As I tried to say, it's more of a philosophical and psychological (and practical) thing than actually being impossible.
Reverse engineering is a valuable skill but it's not too fun when you could just look at the source, with variable names, comments and nice formatting. In some cases it might be a nice "puzzle" to solve but that's not how you want to learn how things work.
"Great hackers also generally insist on using open source software. Not just because it's better, but because it gives them more control." Paul Graham said that, though I do somewhat agree about the english thing.
You shouldn't take these as rules but as a guide which the title is indicative of. Sure you can become a hacker while not knowing english but the immense amount of information available on the internet (mostly in english) is just too big to avoid (not impossible as you've indicated with your examples) for beginners.
> Trying to learn to hack on a Microsoft Windows machine or under any other closed-source system is like trying to learn to dance while wearing a body cast.
> Under Mac OS X it's possible, but only part of the system is open source — you're likely to hit a lot of walls, and you have to be careful not to develop the bad habit of depending on Apple's proprietary code. If you concentrate on the Unix under the hood you can learn some useful things.
I think this is still relevant. The best hackers I have known are people who understand things pretty much from top to bottom, and having the source code, and rights to use it are invaluable for that.
If you want to create a business, maybe Mac OS or Windows might be better for you (I get by with Linux just fine though), but if you want to be a "hacker" in the sense of having a thorough understanding of your whole computing environment, then you should probably be using Linux or BSD.
I'd disagree with this. While OS X and Windows are not as transparent as linux, there are enough resources on both that a hacker that wants can go deep on them. In the Windows ecosystem, Mark Russinovich (creator of Sysinternals) and Charles Petzgold readily spring to mind as people who fit the definition of hacker.
The biggest difference is that if you run Windows, you have to be willing to crack open IDA and read some assembly to really get a view of how your system is doing something sometimes.
The main reason I keep a Windows box around is because so many Windows devs seem to think that security through obscurity works and that no one is willing to patch their binaries. Big mistake.
When I read this the first time I printed it out and read it over and over again. It guided me to start my efforts to download linux and learn to program in the 5 languages he mentioned. I took the "learn programming in 10 years" to heart.
It's made me a programmer. The flaws people are talking about in the article, I think, are true but irrelevant because the spirit of the article will still guide people such as me.
His "how to ask questions" article is another great one.
One of my main beefs with ESR has always been his extremely hostile views on infosec hackers, or as he pejoratively calls them "warez d00dz".
The technical proficiency of infosec hackers can be remarkably high, particularly since it requires knowledge in all layers of the stack. To say that someone like Michal Zalewski is not a hacker, is absolutely foolish.
But, according to ESR, if you're more concerned with "breaking" things than "building" them, you're just a juvenile who's gonna get to five to ten in the slammer after realizing you're not too bright. Under this definition, a person with sophisticated reverse engineering and exploit development skills is not a hacker, but someone who bootstraps Rails on a free Unix, is.
I also disagree that not using your real name is for losers, but that one is pretty controversial.
> I also disagree that not using your real name is for losers, but that one is pretty controversial.
It was a more innocent world, back then. I do not go to any measurable lengths to hide my actual name, but I would rather not volunteer it to the social engineering underworld either.
Note that ESR uses a stricter definition of hacker than is usually accepted on HN. On HN, anyone who can write code is free to call themselves a hacker. But that doesn't mean you have the mindset. And to the extent that the hacker community still exists in the sense of this document, it doesn't mean you're a part of that.
I've complained about this before, it's something of a pet peeve of mine. I don't describe myself as a hacker.
(But also a weaker definition in several ways. Hacking in the ESR sense doesn't have to have anything to do with computers. This is in the jargon file, I'm a little surprised that the HOWTO doesn't say anything about it.)
Actually, on HN the definition pg has endorsed for hacker is as a synonym for 'tinkerer' (not his word). It's not necessarily about code, but it is about the mindset of curiosity + adventurous.
But then you have startups recruiting "rockstar hackers", sites that teach you how to become a "hacker" by leraning the newest hip JS framework of this week, and of course, the abominations like the term "growth hacking".
Spirit of hacking, as per pg's definition or the hacker culture, is still strong on HN, but the word hacker itself seems to devaluate quickly. Just like every other term that becomes fashionable, I guess.
The first hackers, instead of eating every piece of algae they encountered, probably tried sticking two or three pieces of algae together, and then used those clumps to propel themselves towards areas with larger concentrations of algae.
This essay is far from perfect. That said, when I first read this I was a Windows user and primarily a Windows desktop application developer, but I'd started to explore what was outside the Microsoft ecosystem by playing with things like Perl and Linux. Reading this document, along with the (far, far better) book The Pragmatic Programmer, helped open my eyes to the world beyond Microsoft.
All this to say: despite the negative comments here, this is worth your time to read.
I read this essay 7 years ago and it was a revelation for me. I started coding right away and 1 year later I had a job as a programmer. This is a must read for all programmers imho.
I loved the part when he mentioned money, sex and social status as distractions...This is such a claustrophobic way of thinking about the stereotypical hacker.
Having met both in person, I think "rude" is rather quite apt in both cases. You can be passionate and principled and not a jerk, or a murderer, or a scoundrel, or even rude.
The general aspect that I dislike is the idea that there is only one kind of hacker -- the kind that fits into Eric S. Raymond's "the hacker culture". For instance, he gives the monoculture that all hackers speak English; but just a few weeks ago, we saw an article on HN about the old microcomputers of the Soviet Bloc (I wish I could find the link now). And, perhaps, maybe my all-time favorite hacks were executed by demosceners who spoke little-to-no English. Are these people not hackers? I don't think you'd find anyone who could argue that, but they are not part of Eric S. Raymond's monoculture.
The great essay that I have always wanted to read about How to Become a Hacker would be answering the question of how to find joy in the minutiae, and how to put all the little pieces together to make the most interesting things. But this essay is not that.