So you want to be a python full-stack developer?

So you want to become a full-stack developer...

Businesses love to hire full-stack developers. But with more options at every place in the stack, becoming a full-stack developer seems harder than ever.

Take a look at any job advertisement, and you'll find a dizzying list of technical requirements: half a dozen languages, a handful of database systems, a couple of the latest Javascript frameworks, Android & iOS knowledge, and deployment techniques and technologies... all before you get into more theoretical stuff like machine learning and big data.
If you hope to break in to the industry, these job postings can leave you feeling lost and hopeless. After all, by the time you learn all of the technologies that these businesses require, a whole new set of technologies will have replaced them. What's an up-and-coming full-stack developer to do?

First, define your MVP

I don't mean the "minimally viable product" that you hear all over the place these days. I mean "minimally viable proficiency."
Do you know what full-stack means in the first place? If not, you can't begin to learn everything you need to work as a full-stack developer. You'll spend your time learning anything and everything that comes across your path... which might work, but which will undoubtedly take a lot more time than learning a single stack and then building on your knowledge.
You can work on many different kinds of stacks. I'll focus on web applications, because I've spent the majority of my career working on them and I know this stack best. For web software, I define a basic stack as follows:

• HTML
• CSS
• Javascript
• one general-purpose programming language (Ruby, Python, PHP, etc)
• one relational database system (Postgres, MySQL, Oracle, etc)
• one web server (nginx, Apache, etc)
• one deployment operating system (Ubuntu, CentOS, FreeBSD, etc)
• one version-control system (git. don't bother with the etc)

If you select one technology for each part of the stack, you can create a lot of useful software, all on your own. This will make you valuable to any business, and give you the option to create software independently if you want.
Many people ask, "What's the best language to learn?" or "What database should I use?" and in my experience, it really doesn't matter which one you pick first. Sure, each has its benefits and drawback, but as long as you choose reasonably popular technologies then your initial choices won't make a huge difference. By learning a whole stack, you will gain the context you need to learn alternate technologies for each part of the stack.

Learn by doing, always

I admit that I've read books and blogs, listened to podcasts, and watched screencasts as much as anybody. I have learned a lot from them... but I've learned a lot more whenever I've actually sat down to create software, no matter how frustrating or painful I sometimes find the experience.
I listed eight components of a minimum stack for web development... you have a lot to learn! Every minute that you spend on blogs, podcasts, and screencasts means a minute you don't spend creating software.
Employers want to know that you can solve their problems. Blogs and podcasts don't solve problems for employers. Following blogs and podcasts can indicate to employers that you have an active interest in technology... but a list of projects you've worked on flat-out demonstrates it.
If you build and ship even a simple software system, you will solve far more problems than you ever will by passively consuming educational content. You will develop core skills that you need to succeed as a developer - reading documentation, grokking error messages, and learning the capabilities of the tools available to you.
At the end of it, you will have a system that you can show people. You'll have made decisions and tradeoffs, and you can talk about them with people. You will understand what parts work well, and what parts don't work so well. You'll have advanced your abilities in a way that you can grow on.

Build on your new knowledge

Learning each part of a stack sets you up to learn new options in that stack. If you know one general-purpose language, you can learn a second quite easily. Your third and fourth languages will seem like pieces of cake. Knowing several general-purpose languages only makes it marginally easier to learn a database system... you've learned related skills like reading documentation and grokking error messages, but you don't have any of the core context needed to understand databases.
Don't fall for the trap of thinking that if you know three languages, it will give you three times as many job options. You will compete against a pool of developers in each language. If those developers know databases, or deployment, or any other part of the stack, and you don't, then you won't compare favorably to any of them.
If you know every part of a full stack, you have real options. You can create valuable systems all on your own - no job required. You can work with businesses that have yet to define a technology stack for themselves. You can compete with other developers in your chosen language, confident that you can work on any part of the stack. Most of all, you can learn alternate technologies to augment your existing skills.
When you know a couple programming languages, you can work as a programmer. When you know HTML / CSS / Javascript, you can work as a front-end developer. When you know MySQL and Postgres and Oracle, you can work as a DBA. When you know Ubuntu and CentOS and FreeBSD you can work as a sysadmin.
When you know all parts of a stack, you can get stuff done.
You won't have to worry about the next hot thing. Businesses always want to hire people who can get stuff done. You'll have the context and abilities you need to learn the next hot thing, and add it to your resume.

But what about...?

Of course, my minimum stack rejects a lot of the stuff that's hot right now. I couldn't call it "minimum" if I included everything, now I could I?
I don't mean to suggest that you should never learn the following technologies... but I strongly feel that learning these before learning a minimum stack will set your career back several months or years. By all means, learn them after you've gotten a handle on a basic web stack.

iOS and Android

Nope. iOS and Android operating systems both run web browsers just fine.
If you want to write games, or native apps, then learn to program iOS and/or Android.
The web won't go away any time soon. You can create valuable software for the rest of your life without ever worrying about native operating systems.

NoSQL

Nope. Most programmers and businesses I've met that use NoSQL, do so because they don't know how to use SQL properly. Mean? Maybe. Sad? Yup. And totally true.
NoSQL can make a lot of sense in a lot of use cases - but if you haven't worked professionally as a developer, then you likely won't have access to the sorts of use cases where NoSQL technologies make more sense than SQL databases.
SQL won't go away any time soon. You can create valuable software for the rest of your life without ever worrying about NoSQL technologies.

Machine learning

You can have a lot of fun with machine learning, but once again, you simply don't need it to in order to create valuable software.

Your action plan

Now that I've discussed what a full stack looks like and why you should learn one, I want to lay out an action plan for learning.

1. Learn basic HTML - code up basic pages, link between them, etc
2. Deploy your HTML site to production - a hosting provider, heroku, etc
3. Learn one backend language and integrate it into HTML - if you use a web framework, make it the lightest one you can
4. Set up a virtual server for deployment - AWS, digital ocean, linode, etc
5. Deploy your dynamic application to production
6. Learn one relational database system and integrate it in to your app
7. Learn basic CSS to make it look good
8. Learn Javascript to provide client-side behavior

Congratulations, you've now made it to v1.0 as a full-stack web developer. Upgrade yourself by learning new technologies as your interest and energy compel you.

Put all your stuff on GitHub, and you can show it off to potential employers. You can tell them the story of how you created software, of how you learned to create software, and how you plan to continue learning to create software.
Most of all, you can now create software... and you never have to stop.

source : http://www.rubysteps.com/articles/2014/so-you-want-to-become-a-full-stack-developer/

Gamification of education

Les 7 styles d'apprentissage

les tags html

autres ressources

Develop a website

Web Development TECHNOLOGIES in 2015

MAP LINK 

https://coggle.it/diagram/52e97f8c5a143de239005d1b/56212c4e4c505e0045c0d3bda59b77e5977c2c9bd40f3fd0b451bdcf8da4aa52

So What Does a Web Developer Actually Do?

The short answer: They build and maintain websites.

But what exactly that looks like varies widely depending on the type of job the developer works at. The good part is that web developers are in high demand and so, though they work very hard, they're generally able to command comfortable salaries and healthy work/life balances. It's a profession that rewards people who are natural problem solvers and who enjoy building things.

A more detailed explanation, from degreedictionary:

Web Developer Job Duties

Your job as a Web developer is to present your clients' products and services to a wide audience by creating attractive, functional websites. You will likely be asked to identify potential site users and design a website to appeal to these constituents. Your work may include meeting with clients to discuss their desires for a website or discuss how to keep their website functioning and up to date. You might construct the layout of a website, creating a visually interesting home page and user-friendly design. You may also write the content for the website.

After a website is up and running, you'll make sure that the site is functional on all Web browsers, periodically testing and updating it as needed. A client may also need you to include interactive capabilities on their site using Visual Basic or Java programming languages.

Where You Work

Web developers may work for large corporations, small companies or as freelancers. Most positions will have you working 40 hours a week, while others - especially freelance positions - enjoy flexible schedules. Occasionally, you may be required to work during the weekend or other non-standard business hours in order to perform website maintenance or in the case of an emergency.

Other Skills

You need to have a familiarity with technology and understand how computers and web servers operate. You will also need to be familiar with many software programs, Web applications and Web programming languages, such as hypertext markup language (HTML), Ruby on Rails and C++. Since this is a very client-based, project-oriented field, you must be able to communicate effectively, set goals and meet deadlines. You must also be creative and have a grasp of art and design principles.

The key take-aways here are:

• Developers often work on behalf of clients who are trying to get their product or service out onto the web.
• The work is typically very project-focused and involves collaborating with a team of people who help coordinate the client's needs with the end product.
• Not all devs work for external clients... The "client" could just be your tech company, organization, government etc. who needs a website or web application built
• It's a lot of fun, you actually get to build things that people use, and you get to play with lots of new toys. What's not to love?

Important Distinctions

"Front End" vs "Back End" Developers

Front End:

"Front End" typically refers to the stuff that you actually see on the website in the browser. This covers how the content is presented including all the little user interface elements like menus and dropdowns and transitions and modals.

A front end developer will often focus heavily on understanding HTML, CSS, and Javascript since these languages live in the browser. They aren't necessarily focused on making things look "pretty" (which is often left to a designer), but rather making sure that the information is presented effectively and the user's interaction with the web page is as smooth as possible. These days we're executing more and more code in the browser itself.

Back End:

"Back End" typically refers to the guts of the application which live on the server. The back end is more focused on making sure all the right data gets sent out to the browser. It's the portion of iceberg below the surface... lots of stuff needs to go correctly to hand off data to the front end so it can be displayed.

Google may be a relatively straightforward search engine from our point of view, but they employ an army of engineers to make sure that all the moving parts you don't see are working properly.

Full Stack:

"Full Stack" developers marry the two sides into one. While each "end" involves learning a significant amount of information, a full stack developer can comfortably speak both database and browser. These days the trend is to seek developers with a great working knowledge of both ends (which is what we're teaching here).

Optional Reading

• Udacity blog: 3 Web Dev Careers Decoded: Front-End vs Back-End vs Full Stack.

Web Developer vs Web Designer

So, if we've got back end developers and front end developers, who makes the website actually look pretty? Who pulls together the images and logos and color schemes? That's the web designer's job. While they have historically been less inclined to handle the actual coding of the page, these days even designers are expected to roll up their sleeves and code a bit. Some of the best web developers come from design backgrounds.

Optional Readings

• Wikipedia lays out the breadth of the web design profession in theirentry on web design.
• Part fact and part juvenile humor, this infographic lays out the differences between web developers and designers.
• And another snarky infographic for your entertainment...

Web Sites vs Web Applications

Not everyone can agree what differentiates the two, but generally web sites are more about displaying static (unchanging) content and web applications require a "smart" server running code (that you're going to learn to write) to produce dynamic content.

For a more concrete example, think of going to a regular web site as just opening a document (say, an e-book) from your hard drive. Your computer will locate it, open it, and display it for you.

Going to a site run by a web application is the same principle but the e-book is no longer just sitting there waiting to be opened. Your request for the e-book is caught by a sneaky little application which checks what you're asking for and then dynamically generates your e-book for you, fully customized (okay, maybe it just has an extra line that says "this e-book was opened on" and then today's date).

That's more or less the difference between a server just serving up a static HTML file and dynamically generating one by using a bit of Ruby on Rails code.

source : http://www.theodinproject.com/introduction-to-web-development/what-a-web-developer-does?ref=home

How I learned to stop worrying and love the code

I’m learning to code. I’ve been on again off again with it for about two years now. But I've only very recently started to feel like I could actually achieve something. I had a lot of unlearning and confidence building to do first.

I want to share with you some of the difficulties (all 8 of them) that have killed my momentum dead in its tracks. As much as this is an admission of my failings, it’s also hopefully a guide to the types of misconceptions and anxieties that people like me — people newly learning to code—may have.

If you’re a teacher of The Code, then please, take heed. May my loud-mouthed admissions make it easier for you to get through to your students.

1. Jargon-ese

Hey gang, how about you nest that expression in my function so we can debug that damned command line and Git push the hell outta here?!

As awesome as these words are, they’re a huge barrier to learning how to code. It has been one of my biggest stumbling blocks to feeling competent.

I found that treating it as you would learning a language really helped. Start small, take pains to understand and remember the vocabulary, and once you’ve learnt a word — use it. Top up your knowledge on Memrise. But just like you wouldn’t expect to learn a language in a few weeks, you aren’t going to feel confident speaking tech till you’re a couple of months in. Don’t get disheartened.

2. The Fear

Above anything else it’s been The Fear that’s been the hardest to get over. The Fear is the stream of thoughts that runs a bit like this: “Ugh I’ll never catch up, there’s too much to learn. Even if I started now I won’t be competent till I’m 30! Everyone is already so far ahead. I can’t even split this damn string! I’m getting it all wrong. I’m never going to get anywhere. Maybe I’m not cut out for this? I’m never going to be able to contribute anything useful. I’m just a drag on everyone’s time.”

The Fear is made worse when people use words like “just” or “obviously”. I dislike these two words. They should be nowhere near a learning environment. “You just have to setup a github page”, “obviously you just put the semi-colon here”. All that these words do is belittle the person who did the asking.

“I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.” — Dune, Frank Herbert

It’s important that you look after yourself, if you find that you’re filled with terror at getting things wrong, figure out why. Take the time to unravel the unpleasant thoughts. Concentrate on what you’ve achieved, and the work you’ve done to get there. Ground yourself in rose-tinted reality. Be kind to yourself.

3. Equals is a lie: = ≠ =

My entire academic life I have been taught that this weird modernist hamburger of a symbol ‘=’ means equivalent to. This is a thought that is not compatible with programming, and indeed royally screws everything up given half the chance. It took a while before I came across anything that told me that it’s much better to think of = as “assignment” not “equivalence”. So the next time I saw something like:

hello = 4
hello = hello + 1

I didn’t have an existential breakdown. Or feel like an idiot. And not feeling like an idiot is a big part of continuing to learn how to code.

4. Stop asking questions

I know, I know, I’m meant to be like “guys, question everything! Questions are great!” but honestly, stop asking questions. You don’t need to know how it all works before you start building something.

You don’t need to understand how a web server works to make a webpage. You don’t need to understand how Python makes a query to a database to use that data.

I was paralysed for too long asking questions, I just ended up reading a lot. I wish I had just thrown myself into building things from the get go. Unlearning that was difficult.

5. Never gonna set you up

Getting things installed and set up is where 70% of your time goes when you’re starting out. Heck, even more! I remember whole days dedicated to just installing a damn module. This is normal. You aren’t doing anything wrong. Keep at it, it gets easier.

…But not that much easier. Setting up is something that fully fledged developers still battle with. There are so many different tools out there that try to solve this problem — so don’t convince yourself that it’s an easy fix that you’re getting wrong. It’s not. You’re trying to solve a hard one.

6. Web stuff is programming stuff

For the longest god damn time I was under this weird misconception that coding for the web was a completely different task to programming. I considered them completely different disciplines with no transferable skills between them. I imagine I thought this because everything is kept so separate when you begin to learn; you either do the HTML tutorial or the Python one, and never the twain shall meet.

The spell was broken whilst I was watching the end of the first lesson in Udacity’s Introduction to Computer Science. Dave describes creating a Web Crawler and he uttered the following line which blew my tiny little mind:

“ ‘a href equals’ is how we start the link, that’s followed by a string which is surrounded by double quotes, similarly to a string in python…between the double quotes is a URL”

No longer was I just adding adding a URL, adding content, to a tag, I was assigning it a string. This may not be an epiphany for some of you but allow me to share my notes as I realise the immensity of this:

Web Crawler finds webpages through links
Starts from seed page and follows links to new webpages — a link tree
View source code
a href = “string”
omg its just a string!?!!

All of a sudden I had an appreciation for the fact that it was all part of the same ecosystem.

7. Don’t be resentful of help

As a defensive manoeuvre I’ve seen a few people go down the route of taking offence at being corrected. I’ve done it too. I know that asking for help is hard and getting things wrong can be embarrassing. Be clear about when you want help, and when you don’t. Be wary of alienating the people who are trying to help you. There’s a difference between constructive and unconstructive criticism, it’s important not to confuse the two.

8. No matter what, keep going.

Even if it takes you 2 months, or 2 years to build that one thing, keep going.You’ll find that with time your anxieties quieten, and your confidence slowly builds.

It’s an excellent feeling.

My tips on how to plan a game, stay motivated and get it finished

Introduction

The question of how to motivate oneself or finish a huge project is a very common question here. I wanted to share my personal methods.

This guide was originally posted here on /r/gamedev 8 months ago. I'm reposting it for those that missed it and to update it with new lessons learned.

NB: This primarily applies to very small indie teams or solo developers such as myself, but some of the methods could be applied to specific tasks within a larger team.

Who am I? Where is the proof that my methods work? I'm a solo developer with more than 5000 hours of work into my current game, taking it from prototype to a 100+ hour playable game. The game is arriving on Steam in less than two weeks. You can see it here.

_

Getting Started

Most games revolve around a 10-30 second gameplay experience that is repeated endlessly. I first heard this concept described as a core foundation behind the design of Halo. This is the core of your game and if this isn't fun, it's unlikely the final game will be fun either.

• Decide on the key concepts and gameplay elements that are at the core of your game.
• Don't waste weeks or months planning out every last detail for your game. (I first read this tip from Minecraft's Notch)
• Start work on it now. Don't procrastinate. (Also advised by Notch) Start as you mean to go on. As Nike says 'Just Do It'.

_

Passion and Dedication

Choose a game genre you fully understand and are passionate about.

• Without passion you will never get it finished.
• Without dedication you will never get it finished. If you struggle with this then practice it in any avenue of life. Learn how to finish things before embarking on bigger things.
• You will have more success making a game for an audience you fully understand that is small, than for a bigger audience that you don't understand. You need to know what your audience wants if you want to have a chance of pleasing them.
• Make a game that you passionately want to play.

_

The Prototype

The goal of the prototype is to create that core 10-30 second experience to ensure that it's as fun in reality as it was in your imagination.

• If it's not fun, tweak it until it is.
• Don't waste time on fancy graphics at this stage
• If you can't make it fun now don't assume that adding more crap around it will make it fun later. That's highly unlikely.
• Once it's fun, continue to add the core features (in a very rough but functional way) that you believe are essential to your game concept. It's better to make sure the whole concept works now before you waste too much time on a dud.

The prototype can take anything from an hour to a month depending on the complexity of your final game.

If it's not enjoyable now it's unlikely that it ever will be. Don't build a game on broken foundations.

_

The Master Plan

Now that you have a decent prototype it's time to plan out in a very rough way your schedule for the project. If you don't have a schedule you will fumble around endlessly wasting time and never get the thing done.

List all the core features that your game will need.

• Don't detail how you will achieve them. You may not even know how you will achieve them at this stage. Just list them. Also, list all the essentials that every game needs eventually - things like save game functionality, a website, rebindable keys possibly.
• Do this in broad strokes. We are not looking to list every minute detail here, just an overview of the big picture - each big job.
• Once you have your list, estimate how long each job in the list will take and write it next to it.
• Total up the time for everything. Now double it! Seriously. Even if you are very conservative in your estimates, almost everything is going to take longer than you expect, and you are going to run into endless jobs that you never predicted.
• If the final total is not something that you think you can achieve reduce the scale of your project and repeat the above process until you arrive at something manageable.

_

Breakdown the Master Plan - Chunks

• Split all the jobs in the master plan into 'Chunks'.
• If your planned game will take two years you may want to break the list down into 'Chunks' that will each take three months each.
• If your planned game will take 3 months in total, break it down into 2 week 'Chunks'
• List your 'Chunks' in the order that they should be completed.

_

Take the first 'Chunk' and break it down - 'Pieces'

Even if your game is only planned to take 3 months to complete, you are still going to have a lot of work in each 'Chunk'.

Break the first 'Chunk' down into a new list of 'Pieces'. Again, don't get into details here. A 'Piece' might be something like - 'Create a basic GUI Interface' or 'Create assets for game feature X'.

Be sure that you have enough time to complete your 'Pieces' for that 'Chunk' in the timescale you have allocated. If not, you may need to move back up the plan and reduce the scale of your project.

_

Breakdown this first 'Piece' of the first 'Chunk' - Immediate Job List

Each 'Piece' might be still quite complex, and you may not know how to achieve it yet. As an example, our first 'Piece' might be something as broad as 'Implement the user interface' that could take two weeks to achieve. Now break that down into another wide brush stroke list, for example:

• Implement the start screen
• Implement the menu system
• Implement the HUD system
• Etc

Once again don't detail each job yet. Just list the jobs.

_

Breakdown the first Job in your Immediate Job List

By now you get the idea. Hopefully each job in our 'Immediate Job List' will take no more than a day or two. For smaller projects you will probably be already down to jobs that should only take a couple of hours and you can skip this stage.

So for example we might break down 'Implement Start Screen' into this new list:

• Create the background
• Create the main menu (New Game, Start Game, Options, Quit)
• Implement the code to make the main menu function.
• Add some juicy special effects to make it look nice.

_

Pick a job and break it down

So let's imagine we have chosen the job 'Implement the code to make the main menu function'.

Finally we are at the micro scale. We now plan in detail how to achieve this single job. Break it down again. List each little piece of the job that needs to be done.

It's a good idea to also now have a rough idea how you will achieve each little piece before getting started. This will help you predict problems that may occur with your chosen method.

This shouldn't take more than 5-10 minutes. Maybe longer if it's a complex problem that you need to do some research on first.

Now do it!

Rince and repeat stepping backwards through the processes. Do all the little jobs to complete a job on your 'Immediate Job List' Then pick a new 'Piece' of a 'Chunk' and create a new 'Immediate Job List'

Then do it!

_

The advantages of this method

• It's structured with timescales in place to get it all done.
• The plan is all broad strokes that shouldn't take long to list initially.
• It breaks down massively complex systems into tiny, easy, bite-sized pieces.
• You only get down to details just before actually implementing something that will be finished in a few hours.
• No sooner have you planned the details than you are implementing them while the problem is still fresh in your mind. This keeps motivation levels high and saves time. You aren't trying to remember something you planned six months ago.
• You get to strike jobs off your list quickly. Don't underestimate how motivating this is. You see progression happening in a visual way constantly. There is nothing better than seeing a job list disappear.

_

Staying Motivated

Don't procrastinate

• If you ever allow yourself to think 'I can't be bothered right now', push it out of your mind and get working immediately. Don't give it any time to fester and gain traction.
• We are stupid creatures. We live by habit. If we allow ourselves to not work because 'we can't be bothered' this becomes a habit and it will happen more and more. Don't let it start. Do the opposite - get in the habit of just doing it and then it becomes easy to just do it.
• However, if you are in the habit of just doing it, and you get a strong feeling of 'I can't be bothered' you are likely genuinely tired and need more sleep, or you're overworked. See below.

_

Don't Overwork - a recommended work schedule.

Applies only to full-time development

There is a reason the average working week is 40 hours. This has been proven over time to achieve efficient results. This is especially true in a concentration intensive job like game development.

• Do 8 hour days, 5 days a week
• Take a 5 minute break to get up and walk around once every 45 mins. Give your brain a break.
• Take the weekend off to relax, recharge, and motivate yourself for the following week.
• Get enough sleep. Don't underestimate this tip.
• Take a week off once every 3 months. This is essential or you will burn out. You need time away from thinking about something or you fry your brain so it's of no use to you.
• You will be more efficient and get more done by not overworking. Overwork makes our brain go around in circles while problem solving. If we are fresh, problems get solved very easily.

By not overworking, and getting enough sleep, your motivation levels will always stay high. - Well at least until mid way through Friday :)

The only times I feel like 'I can't be bothered today' is when I'm genuinely physically tired from lack of sleep or because I've overworked recently.

_

Get it out there

• As soon as you have a playable alpha get it into the hands of your target audience.
• Player feedback is essential to making a great game.
• Listen to all feedback. You may not act on it, but you need a solid reason why you aren't acting on it.
• As your game expands, get more people playing it.
• You might have an ultimate goal of getting it on to Steam, but put it out there on a smaller platform once you have a stable product. Price it so that it offers value for money at that early stage. You are doing this not to make money but for experience and to get motivated from player feedback. You will also find out if you are wasting your time.

_

Conclusion

I hope this is useful info for some of you. It's not going to work for everyone but it's worked for me and I'm still motivated after nearly three years of development.

Comment devenir un hacker

Auteur: Eric Steven Raymond < Thyrsus Enterprises >

Traducteur: Thomas Gil < thomasgil.com >

Relectrice: Marion Nougueret < NewBornA >

Traduction de la révision 1.49 du 21 novembre 2014 du document original How To Become A Hacker

Copyright © 2001 Eric S. Raymond

Table des matières

Pourquoi ce document?Qu'est-ce qu'un hacker?L'attitude du hacker

1. Le monde regorge de problèmes fascinants à résoudre.
2. Aucun problème ne devrait être résolu deux fois.
3. Le diable est dans l'ennui et la corvée.
4. Vive la liberté.
5. L'attitude ne remplace pas la compétence.

Les compétences essentielles du hacker

1. Apprenez à programmer.
2. Procurez-vous un Unix open-source et apprenez à vous en servir.
3. Familiarisez-vous avec le World Wide Web et sachez écrire en HTML.
4. Travaillez votre anglais véhiculaire.

Le statut dans la culture hacker

1. Ecrivez des logiciels open-source
2. Aidez à tester et à déverminer des logiciels open-source
3. Publiez des informations utiles
4. Contribuez au bon fonctionnement de l'infrastructure
5. Soutenez la culture hacker elle-même

Le lien hacker / nerdEléments de styleNote historique: hacking, open source et logiciel libreAutres ressourcesQuestions fréquentes

Pourquoi ce document?

En tant qu'éditeur du dictionnaire du jargon et auteur de quelques autres documents populaires de même nature, d'enthousiastes nouveaux venus sur le Web me demandent souvent par mail "comment pourrais-je devenir un maître hacker?". En 1996, il ne semblait pas exister d'autre document sur le Web ciblant cette question vitale, j'ai donc commencé à rédiger celui-ci. De nombreux hackers le considèrent maintenant comme une référence, j'imagine que cela lui en donne le statut. Toutefois, je ne revendique aucune autorité exclusive dans ce domaine; si vous n'appréciez pas ce que vous lisez ici, écrivez votre propre FAQ.

Si vous avez sous les yeux une copie de ce document, sachez que sa dernière version se trouve ici: http://catb.org/~esr/faqs/hacker-howto.html.

Note: vous trouverez ci-après une liste de questions fréquentes. Assurez-vous de la lire deux fois avant de me solliciter par email à propos de ce document.

De nombreuses traductions de ce document sont disponibles: Arabe Biélorusse Chinois (Simplifié), Tchèque, Danois, Hollandais, Estonien, Allemand, Grec Italien Hébreu, Japonais, Lithuanien, Norvégien,Perse Portugais (Brésilien), Roumain Espagnol, Turc, et Suédois. Comme ce document évolue de temps en temps, ses traductions peuvent être plus ou moins obsolètes.

Le diagramme "cinq points dans neuf cases" qui illustre ce document s'appelle un planeur. C'est un motif simple aux propriétés mathématiques surprenantes dans une simulation mathématique appelée le jeu de la vie qui fascine les hackers depuis de nombreuses années. Je pense qu'il constitue un bon emblème visuel pour représenter ce que sont les hackers: abstraits, apparemment un peu mystérieux de prime abord mais donnant accès à un univers régi par sa propre logique complexe. Lisez ceci pour en savoir plus à propos de l'emblème planeur.

Si vous trouvez ce document utile, n'hésitez pas à me laisser un pourboire sur Gittip. Et envisagez également d'en laisser aux hackers qui ont produit le code que vous utilisez et auquel vous accordez du crédit. De nombreuses petites donations récurrentes deviennent rapidement significatives et peuvent libérer le temps de travail nécessaire aux personnes qui vous ont fait ces cadeaux pour en produire davantage.

Qu'est-ce qu'un hacker?

Le dictionnaire du jargon propose plusieurs définitions du terme "hacker", la plupart étant liées aux aptitudes techniques et à la joie de résoudre des problèmes et de repousser les limites. Ceci dit, si vous souhaitez savoir comment devenir un hacker, seules deux d'entre elles sont vraiment pertinentes.

Il existe une communauté, une culture partagée de développeurs experts et de magiciens du réseau dont l'histoire remonte, il y a plusieurs décennies, aux premiers ordinateurs à temps partagé et aux premières expériences ARPAnet. Les adeptes de cette culture ont donné naissance au terme "hacker". Les hackers ont bâti Internet. Les hackers ont fait du système d'exploitation Unix ce qu'il est aujourd'hui. Les hackers font tourner le réseau mondial, le World Wide Web. Si vous faites partie de cette culture, si vous y avez contribué et que d'autres membres vous connaissent et vous qualifient de hacker, vous êtes un hacker.

L'état d'esprit du hacker ne se limite pas au monde du logiciel. Certains appliquent l'attitude du hacker à d'autres domaines tels que l'électronique ou la musique; en fait, on la retrouve aux plus hauts niveaux de n'importe quelle science ou art. Les hackers logiciels reconnaissent ces âmes soeurs et peuvent elles aussi les qualifier de "hackers"; et certains prétendent que la nature du hacker est complètement indépendante du domaine exercé. Mais dans la suite de ce document, nous nous focaliserons sur les compétences et l'attitude des hackers logiciels et sur les traditions de cette culture partagée qui a accouché du terme "hacker".

D'autres personnes s'auto-proclament hackers, haut et fort, pourtant ils n'en sont rien. Il s'agit essentiellement d'adolescents de sexe masculin qui adorent s'introduire par effraction dans les ordinateurs et pirater les lignes téléphoniques. Les véritables hackers les appellent "crackers" et ne veulent rien avoir affaire avec eux. La plupart des véritables hackers trouvent que les crackers sont fainéants, irresponsables, pas très malins, et objectent que de circonvenir à un système de sécurité ne fait pas plus de vous un hacker que de démarrer une voiture avec les fils électriques ne fait de vous un ingénieur automobile. Malheureusement, de nombreux journalistes et écrivains sont dupes et emploient le mot "hacker" pour décrire les crackers; ce qui irrite les véritables hackers au plus haut point.

La différence essentielle est que les hackers construisent des choses et que les crackers les cassent.

Si vous souhaitez être un hacker, poursuivez votre lecture. Si vous voulez être un cracker, abonnez-vous au groupe de discussion alt.2600 et apprêtez-vous à faire cinq à dix ans de prison après vous être rendu compte que vous n'êtes pas aussi intelligent que vous ne le pensiez. Je n'en dirai pas davantage sur les crackers.

L'attitude du hacker

1. Le monde regorge de problèmes fascinants à résoudre.
2. Aucun problème ne devrait être résolu deux fois.
3. Le diable est dans l'ennui et la corvée.
4. Vive la liberté.
5. L'attitude ne remplace pas la compétence.

Les hackers résolvent des problèmes, construisent des choses et croient en la liberté et en l'entraide volontaire. Pour être accepté comme hacker, vous devez adopter ce type d'attitude. Et pour l'adopter, vous devez être absolument convaincu par ses valeurs.

Mais si vous ne songez à cultiver votre attitude hacker que pour être bien accepté, vous vous trompez d'objectif. Croire en ces choses est important pour vous et peut vous aider à apprendre et à rester motivé. Comme pour tous les arts créatifs, le meilleur moyen de devenir un maître est d'imiter l'état d'esprit des maîtres, non seulement intellectuellement mais aussi émotionnellement.

Ou, comme le formule un poème Zen moderne:

Pour suivre le chemin:
regarde le maître,
suis le maître,
marche avec le maître,
vois par le maître,
deviens le maître.

Donc si vous voulez être un hacker, répétez les mantras suivants jusqu'à en être convaincu:

1. Le monde regorge de problèmes fascinants à résoudre.

Etre un hacker est très amusant, mais c'est un type de divertissement qui nécessite beaucoup d'effort. L'effort requiert de la motivation. Les athlètes tirent leur motivation d'une sorte de joie physique qu'ils éprouvent en poussant leur corps à accomplir des prouesses et en se dépassant au-delà de leurs limites physiques. De même, pour être un hacker, vous devez tirer une excitation essentielle du fait de résoudre des problèmes, d'aiguiser vos compétences et d'exercer votre intelligence.

Ressentir naturellement les choses comme cela est essentiel. Sans cela, vous verrez votre énergie de hacking sappée par des distractions telles que le sexe, l'argent et l'approbation sociale.

(Vous aurez également à bâtir une certaine foi en votre propre capacité d'apprentissage, une croyance dans le fait que même si vous ne savez pas tout ce dont vous avez besoin pour résoudre un problème, en vous attaquant un aspect et en apprenant ce qui lui est nécessaire, vous pourrez atteindre l'aspect suivant, etc... jusqu'à la résolution complète du problème.)

2. Aucun problème ne devrait être résolu deux fois.

Les cerveaux créatifs constituent une ressource précieuse et limitée. Ils ne devraient pas être gâchés à ré-inventer la roue alors que tant de nouveaux problèmes fascinants les attendent.

Pour vous comporter comme un hacker, vous devez considérer que le temps de réflexion des autres hackers est précieux. Si précieux que vous devriez vous faire un devoir quasi-moral de partager l'information, de résoudre les problèmes et d'en révéler les solutions de telle sorte que d'autres hackers puissent résoudre de nouveaux problèmes au lieu d'avoir à régler les anciens encore et encore.

Notez néanmoins que "Aucun problème ne devrait être résolu deux fois" n'implique pas que vous deviez considérer toutes les solutions existantes comme étant sacrées ou qu'il n'existe qu'une seule bonne solution à un problème donné. Bien souvent, nous pouvons en apprendre beaucoup sur un problème en commençant par en étudier une solution. Il est acceptable et souvent nécessaire de croire que nous pouvons faire mieux. Sont moins acceptables les barrières artificielles techniques, légales ou institutionnelles (telle que le code propriétaire) qui empêchent la réutilisation d'une bonne solution et qui forcentles gens à réinventer la roue.

(Ne vous sentez pas obligé d'offrir toute votre production, même si les hackers qui le font sont ceux qui suscitent le plus grand respect de leurs pairs. En vendre assez pour payer votre nourriture, votre logement et vos ordinateurs est en accord avec les valeurs des hackers. Monnayer vos compétences de hacker pour subvenir aux besoins de votre famille ou même vous enrichir ne pose aucun problème tant que cela ne nuit pas à votre loyauté envers votre art et vos comparses hackers.

3. Le diable est dans l'ennui et la corvée.

Les hackers (comme toute autre personne créative) ne devraient jamais s'ennuyer ou perdre leur temps à trimer sur des travaux stupides et répétitifs. En effet, lorsque cela leur arrive, ils ne sont plus en train de faire ce qu'eux seuls peuvent faire: résoudre de nouveaux problèmes. Ce gâchis affecte tout le monde. L'ennui et les corvées sont de ce fait bien plus que de simples désagréments, ils constituent de véritables maux.

Vous comporter comme un hacker implique que cette conviction doit être assez grande pour vous pousser à automatiser au maximum tous les aspects rébarbatifs, pour vous-même comme pour les autres (en particulier pour les autres hackers).

(A première vue, ceci semble souffrir une exception: les hackers font parfois des choses qui pourraient sembler répétitives ou ennuyeuses à un observateur extérieur. Ils le font dans le but de clarifier leur esprit, d'acquérir une compétence ou d'expérimenter quelque chose auquel il n'y a pas d'autre moyen d'accès. Mais c'est un choix; aucun être pensant ne devrait subir une situation qui l'ennuie.)

4. Vive la liberté.

Les hackers sont naturellement anti-autoritaristes. Une personne qui vous donne des ordres peut vous empêcher de résoudre un problème qui vous fascine; et vu le fonctionnement d'un esprit autoritaire, cette personne trouvera généralement une raison complètement stupide d'agir ainsi. Il faut donc combattre l'attitude autoritaire systématiquement pour éviter toute répression envers vous ou d'autres hackers.

(Cela ne veut pas dire qu'il faille combattre toute autorité. Les enfants ont besoin d'être guidés et les criminels contraints. Il se peut qu'un hacker accepte une certaine forme d'autorité pour atteindre un objectif qu'il juge plus important que le temps qu'il perd à suivre les ordres. Mais il s'agit là d'un compromis limité et conscient, bien loin de la reddition personnelle souhaitée par les autoritaristes.)

Les personnes autoritaires s'épanouissent dans la censure et le secret. Ils se méfient de la coopération volontaire et du partage d'information: la seule "coopération" qu'ils apprécient est celle qu'ils contrôlent. Pour vous comporter comme un hacker, vous développerez donc une hostilité instinctive envers la censure, le secret, l'utilisation de la force ou de la tromperie visant à soumettre des adultes responsables. Et vous sentirez prêt à vous battre pour cette conviction.

5. L'attitude ne remplace pas la compétence.

Pour être un hacker, vous développerez certaines facettes de cette attitude. Mais copier une attitude ne fera pas plus de vous un hacker qu'un athlète ou une star du rock. Devenir un hacker vous demandera de l'intelligence, de la pratique et de l'ardeur au travail.

Ainsi, vous vous méfierez de la seule attitude et respecterez les compétences réelles. Les hackers ne perdent pas leur temps avec les prétentieux. Mais ils vénèrent la compétence, en particulier si elle touche au hacking, même s'ils accordent de la valeur à tout type de compétence. Il est bon d'être compétent dans un domaine exigeant que peu maîtrisent, et si ce domaine implique acuité cérébrale, habileté et concentration, c'est encore mieux.

Révérer la compétence vous poussera à développer la vôtre; l'ardeur au travail se transcendera en un plaisir intense plutôt qu'en une corvée. Cette attitude est vitale pour devenir un hacker.

Les compétences essentielles du hacker

1. Apprenez à programmer.
2. Procurez-vous un Unix open-source et apprenez à vous en servir.
3. Familiarisez-vous avec le World Wide Web et sachez écrire en HTML.
4. Travaillez votre anglais véhiculaire.

L'attitude du hacker est vitale, mais les compétences le sont encore davantage. L'attitude ne remplace pas les compétences et vous devrez en posséder certaines avant qu'on puisse vous qualifier de hacker.

L'ensemble des compétences requises évolue avec la technologie. Il fut un temps où la programmation en assembleur en faisait partie alors qu'HTML n'y a fait son apparition que récemment. Mais aujourd'hui, cela implique les choses suivantes:

1. Apprenez à programmer.

La compétence du hacking par excellence. Si vous ne connaissez aucun langage de programmation, je vous conseille de commencer par Python. Sa conception est claire, il est bien documenté et relativement simple pour les débutants. Excellent comme premier langage, Python est aussi puissant, souple et adapté aux gros projets. J'ai rédigé une évaluation plus détaillée de Python. De bonstutoriels sont disponibles sur le site officiel de Python; vous en trouverez aussi un excellent sur les cercles de l'informatique et sur Guru99.

J'avais l'habitude de conseiller Java comme langage à apprendre assez tôt mais cette critique m'a fait changer d'avis (cherchez-y "les pièges de Java comme premier langage de programmation"). Un hacker ne peut pas aborder la recherche de solutions comme un plombier dans un magasin de bricolage; il doit parfaitement comprendre ce que font les composants. De ce fait, je pense qu'il vaut probablement mieux apprendre C et Lisp, puis Java.

Plus généralement, lorsqu'un langage en fait trop, il peut être à la fois adapté aux applications opérationnelles mais inadapté à l'apprentissage. Ce problème ne se limite pas aux langages; les socles techniques web tels que RubyOnRails, CakePHP ou Django permettent d'atteindre très facilement un niveau de compréhension superficielle qui s'avère complètement insuffisant dès que l'on s'attaque à un problème ardu ou tout simplement que l'on souhaite déverminer la solution d'un problème simple.

Pour aborder sérieusement la programmation, vous apprendrez le C, le langage phare d'Unix. C++ est très lié au C; si vous en connaissez un, apprendre l'autre ne posera pas de problème. Mais aucun des deux n'est un bon langage à apprendre en premier. Par ailleurs, plus vous éviterez de programmer en C, plus vous serez productif.

C est très efficace et peu gourmand en ressources système. Malheureusement, cette efficacité du C exige de votre part une gestion manuelle des ressources de bas niveau (telle que la mémoire). Tout ce code de bas niveau est complexe, propice aux erreurs et vous coûtera de longues heures de déverminage. Vue la puissance des machines d'aujourd'hui, il est plus judicieux d'utiliser un langage qui exploite moins bien le temps de la machine mais bien mieux le vôtre. D'où Python.

D'autres langages ont une importance particulière aux yeux des hackers comme Perl et LISP. Cela vaut la peine d'apprendre Perl pour des raisons pratiques; il est très utilisé pour la génération de pages web et pour l'administration système, donc même si vous n'écrivez jamais de Perl vous-même, vous devriez l'apprendre pour être capable de le lire. Nombreux sont ceux qui utilisent Perl pour les mêmes raisons qui me poussent à vous conseiller Python: pour éviter de programmer en C lorsque son niveau de performance n'est pas indispensable. Et vous devrez comprendre leur code.

LISP vaut le détour pour l'illumination profonde que vous ressentirez lorsque vous aurez compris sa philosophie. Cette expérience fera de vous un meilleur développeur pour le reste de votre vie même si vous n'utilisez pas souvent LISP lui-même. (Vous pouvez vous faire une bonne première expérience de LISP en écrivant ou en modifiant des modes d'édition de l'éditeur de texte Emacs ou des plugins Script-Fu pour GIMP.)

Le mieux, en fait, est d'apprendre les cinq: Python, C/C++, Java, Perl, et LISP. En plus d'être les principaux langages du hacking, ils représentent des approches très différentes de la programmation qui auront chacune un effet bénéfique sur votre apprentissage.

Mais accumuler des langages ne vous fera pas atteindre le niveau de compétence d'un hacker ni même d'un développeur; vous devrez appréhender les problèmes de programmation de manière plus globale, indépendamment de tout langage. Pour être un véritable hacker, vous devez en arriver au point où vous pourrez apprendre un nouveau langage en quelques jours en croisant sa documentation avec vos connaissances. Vous devez donc apprendre quelques langages très différents les uns des autres.

Je ne détaillerai pas ici la façon d'apprendre à programmer: c'est un domaine complexe. Mais je peux vous dire que vous n'apprendrez pas dans les livres ou en suivant des cours: parmi les meilleurs hackers, certains, voire même la plupart, sont autodidactes. Les livres transmettent des éléments de connaissance tels que les fonctionnalités d'un langage, mais l'état d'esprit qui fait de ces connaissances une compétence active ne peut s'acquérir que par la pratique et l'apprentissage. Voici ce qui fonctionne: (a) lire du code et (b) écrire du code.

Peter Norvig, hacker de haut niveau chez Google et co-auteur du livre le plus populaire en IA, a écrit un excellent essai intitulé apprenez à programmer par vous-même en dix ans. Quelle est sa "recette"?

L'apprentissage de la programmation s'apparente à celui de l'écriture d'un langage naturel. Le mieux est encore de lire des textes d'auteurs reconnus, d'écrire un peu soi-même, de lire beaucoup, d'écrire un peu, de lire beaucoup, d'écrire un peu plus... jusqu'à ce que vos écrits commencent à refléter l'intensité et la concision de vos modèles.

Je détaille ce processus d'apprentissage dans Comment Apprendre Le Hacking qui propose une progression simple mais pas nécessairement facile.

Il fut un temps où trouver du code de qualité à lire n'était pas chose facile car rares étaient les gros programmes dont le code source était disponible; les hackers novices ne pouvaient pas donc pas le lire ni bricoler avec. La situation a complètement changé: les logiciels open-source, les outils de développement et les systèmes d'exploitation (construits par des hackers) sont maintenant accessibles à tous. Ce qui m'offre une transition toute trouvée pour le sujet suivant...

2. Procurez-vous un Unix open-source et apprenez à vous en servir.

Je pars du principe que vous disposez d'un ordinateur ou que vous pouvez en emprunter un. (Prenez un instant pour mesurer la portée de cette assertion. La culture hacker est née à une époque où les ordinateurs coûtaient si cher qu'un particulier ne pouvait pas s'en offrir un.) La première étape la plus importante pour un débutant est de se procurer une distribution Linux ou BSD, de l'installer et de la faire fonctionner.

Oui, il existe des systèmes d'exploitations alternatifs aux Unix. Mais ils sont distribués sous forme exécutable: vous ne pouvez ni lire ni modifier leur code. Apprendre à hacker sur une machine Microsoft Windows ou sur tout autre système propriétaire revient à apprendre à danser les jambes dans le plâtre.

Sous Mac OS X, c'est possible, mais seule une partie du système est open source; vous rencontrerez probablement de nombreux obstacles et il vous faudra éviter de prendre la mauvaise habitude de dépendre du code propriétaire d'Apple. Si vous vous focalisez sur l'Unix caché sous le capot, vous pourrez apprendre quelques petites choses utiles.

Unix est le système d'exploitation d'Internet. Bien que vous puissiez apprendre à utiliser Internet sans connaître Unix, vous ne pourrez pas hacker Internet sans comprendre Unix. C'est la raison pour laquelle la culture hacker est aujourd'hui plutôt centrée sur Unix. (Cela n'a pas toujours été le cas et certains hackers de la première heure ne s'en réjouissent pas, mais la symbiose entre Unix et Internet est devenue telle que même la puissance de Microsoft ne semble pas pouvoir l'ébranler.)

Donc prenez un Unix; pour ma part, j'aime bien Linux mais il en existe d'autres (et oui, on peut faire tourner Linux et Microsoft Windows sur la même machine ). Apprenez à vous en servir. Faites-le tourner. Bricolez avec. Connectez-vous à Internet avec. Lisez son code. Modifiez son code. Vous aurez de bien meilleurs outils de programmation (dont C, LISP, Python, et Perl) que sous Microsoft Windows, vous prendrez du plaisir et vous acquerrez inconsciemment de nombreuses connaissances jusqu'à devenir un maître hacker.

Pour en savoir plus sur Unix, lisez le loginataka. Vous pouvez également jeter un oeil à l'art de programmer sous Unix.

Pour vous procurer Linux, allez sur son site officiel: vous pourrez le télécharger, ou (meilleure idée) trouver un groupe d'utilisateurs de Linux qui vous aidera à l'installer.

Au cours des dix premières années de la vie de ce document, je trouvais toutes les distributions Linux équivalentes du point de vue d'un nouvel utilisateur. Mais en 2006-2007, l'une d'entre elles a surpassé les autres: Ubuntu. Si d'autres distros (= distribution) ont chacune leur domaine de prédilection, Ubuntu est de loin la plus facile d'accès pour les débutants sous Linux. Attention toutefois à l'interface "Unity", horrible et quasi-inutilisable, qu'Ubuntu a proposé en standard quelques années plus tard; préférez les variantes Xubuntu ou Kubuntu.

Vous trouverez aide et ressources concernant les Unix BSD sur www.bsd.org.

Une bonne manière de prendre la température est de booter (= démarrer votre ordinateur) sur ce que les passionnés de Linux appellent un live CD, une distribution qui travaille à partir du CD sans avoir à modifier votre disque dur. C'est lent parce que les lecteurs CD sont lents mais c'est un moyen simple et sans engagement d'évaluer les possibilités.

J'ai écrit une introduction sur les bases d'Unix et d'Internet.

Par le passé, j'ai déconseillé aux débutants d'installer Linux ou BSD eux-mêmes. Aujourd'hui, les installeurs automatiques rendent cette tâche possible, même pour un débutant. Pour autant, je renouvelle mon conseil d'entrer en contact avec un groupe local d'utilisateurs de Linux et de de demander de l'aide. Cela ne peut pas faire de mal; au contraire, cela pourrait vous aider au démarrage.

3. Familiarisez-vous avec le World Wide Web et sachez écrire en HTML.

Pour la plupart, les produits de la culture hacker fonctionnent de manière imperceptible pour le grand public: ils contribuent au bon fonctionnement des usines, des bureaux et des universités sans avoir d'impact évident sur le mode de vie des non-hackers. Le Web est une exception notable, ce bon gros jouet de hacker dont même les politiciens admettent qu'il a changé le monde. Ne serait-ce que pour cette simple raison, vous apprendrez comment fonctionne le Web.

Cela ne veut pas dire apprendre à utiliser un navigateur (tout le monde peut le faire) mais apprendre à écrire en HTML, le langage de balises du Web. Si vous ne savez pas programmer, écrire en HTML vous donnera quelques habitudes qui vous y aideront. Donc, construisez une page d'accueil. Essayez de respecter le XHTML, un langage plus rigoureux que le HTML classique. (Vous trouverez de bons tutoriels pour débuter sur le Web. En voici un.)

Mais avoir une page d'accueil est loin de faire de vous un hacker. Le Web est plein de pages d'accueil. La plupart sont vides et sans intérêt, mais tentent de le cacher derrière une apparence très soignée (j'approfondis ce point sur l'enfer du HTML).

Pour en valoir la peine, votre page doit offrir du contenu; elle doit être intéressante et/ou utile aux autres hackers. Ce qui nous amène au sujet suivant...

4. Travaillez votre anglais véhiculaire.

En tant qu'Américain et de langue maternelle anglaise moi-même, j'étais plutôt réticent à suggérer cela, craignant d'être taxé d'un certain impérialisme culturel. Mais plusieurs locuteurs natifs d'autres langues m'ont vivement conseillé de souligner le fait que l'anglais est le langage de base de la culture hacker et d'Internet, et que vous en aurez besoin pour faire partie de la communauté des hackers.

En 1991, j'ai appris que de nombreux hackers pour qui l'anglais était une langue seconde l'utilisaient dans leurs discussions techniques bien qu'ils eussent la même langue maternelle; on m'a dit à l'époque que l'anglais avait un vocabulaire technique plus riche que les autres langues et qu'il était donc un bon outil pour ce type d'échange. Pour des raisons similaires, les traductions de livres techniques écrits en anglais sont rarement satisfaisantes (lorsqu'elles existent).

Linus Torvalds, un Finlandais, commente son code en anglais (il ne lui est apparemment jamais venu à l'esprit de faire autrement). Sa maîtrise de l'anglais a joué un rôle important dans sa capacité à recruter une communauté mondiale de développeurs pour Linux. Un exemple à suivre.

Avoir l'anglais comme langue maternelle ne garantit pas que vos compétences linguistiques soient suffisantes pour agir en qualité de hacker. Si vos écrits sont truffés de fautes d'orthographe ou de grammaire, de nombreux hackers (moi inclus) auront tendance à vous ignorer. Une écriture peu soignée n'implique pas systématiquement une réflexion désordonnée mais nous avons souvent constaté que la corrélation était plutôt grande et nous n'avons que faire de cerveaux désordonnés. Si vous ne savez pas écrire de manière satisfaisante, développez cette compétence.

Le statut dans la culture hacker

1. Ecrivez des logiciels open-source
2. Aidez à tester et à déverminer des logiciels open-source
3. Publiez des informations utiles
4. Contribuez au bon fonctionnement de l'infrastructure
5. Soutenez la culture hacker elle-même

Comme la plupart des cultures où la notion d'argent est absente, la culture hacker est basée sur la réputation. Vous résolvez des problèmes intéressants, mais à quel point le sont-ils? Les seuls qui soient aptes à en juger sont ceux parmi vos pairs qui ont au moins votre niveau de compétence.

De même, ce que pensent les autres hackers de vos compétences sera votre principal critère d'évaluation (ce qui explique que vous ne soyez pas vraiment un hacker tant que d'autres hackers ne vous reconnaissent pas systématiquement comme tel). Ceci est estompé par l'image qu'a le hacking d'un travail solitaire et par un tabou (en recul constant depuis la fin des années 1990 mais toujours présent) qui voudrait que l'égo ou la validation externe n'entrent pas en ligne de compte dans la motivation des hackers.

Plus précisément, les hackers ont ce que les anthropologues appellent une culture du don. Vous gagnez en statut et en réputation non pas en dominant d'autres personnes, ni en étant beau, ou en possédant ce que veulent les autres, mais bien en faisant des dons. En particulier en donnant de votre temps, de votre créativité, et en donnant les produits de vos savoirs-faire.

Pour être respecté par les hackers, vous pouvez faire l'une des cinq choses suivantes:

1. Ecrivez des logiciels open-source

La première (la plus importante et la plus coutumière) est d'écrire des programmes que d'autres hackers trouvent amusants ou utiles, et de faire don des sources afin que d'autres puissent s'en servir.

(Nous avions l'habitude d'appeler ces travaux des "logiciels libres", en anglais "free software", mais le mot "free" était trop ambigu [NDT: en effet, "free software" peut signifier "logiciel libre" ou "logiciel gratuit"]. La plupart d'entre nous préfèrent aujourd'hui le terme "logiciel open-source").

Les demi-dieux les plus vénérés par les hackers sont des gens qui ont écrit de gros programmes efficaces qui répondaient à un besoin répandu et qui en ont fait don pour que tout le monde puisse s'en servir.

Faisons un peu d'histoire: les hackers ont toujours admiré les développeurs open-source qui forment le noyau dur de leur communauté. Pourtant, avant le milieu des années 1990, la plupart des hackers travaillaient essentiellement sur des logiciels propriétaires. C'était toujours vrai quand j'ai rédigé la première version de ce document en 1996. Il a fallu attendre que les logiciels open source se généralisent après 1997 pour changer cet état de choses. Aujourd'hui, la "communauté des hackers" et les "développeurs open-source" sont deux expressions décrivant essentiellement la même culture et la même population, mais il est bon de se souvenir qu'il n'en a pas toujours été ainsi. (Pour approfondir ce point, voyez la section intitulée "Note historique: hacking, open source et logiciel libre".)

2. Aidez à tester et à déverminer des logiciels open-source

La contribution de ceux qui maintiennent et déverminent les logiciels open-source est également très utile. Dans ce monde imparfait, nous passons inévitablement l'essentiel de notre temps de développement logiciel en phase de déverminage. C'est pourquoi tout auteur censé de logiciels open-source vous dira que les beta-testeurs (qui savent décrire les symptômes clairement et localiser l'origine des problèmes, qui tolèrent les erreurs d'un premier jet et qui consentent à suivre certaines procédures de diagnostic) valent leur pesant d'or. Un seul beta-testeur peut suffire à transformer une phase cauchemardesque, interminable et épuisante en une simple nuisance salutaire.

Si vous êtes débutant, trouvez un programme en cours de développement qui vous intéresse et soyez un bon beta-testeur. Tester des programmes vous amènera à les déverminer puis à les modifier. C'est un excellent moyen d'apprendre et d'établir un bon karma avec des gens qui vous aideront en retour.

3. Publiez des informations utiles

Il est également très utile de synthétiser des informations importantes et de les publier sous la forme de pages web ou de documents (questions fréquentes...).

On gagne quasiment autant de respect en maintenant une FAQ technique de première classe qu'en développant des logiciels open-source.

4. Contribuez au bon fonctionnement de l'infrastructure

La culture hacker (tout comme la conception et le développement d'Internet) repose sur le volontariat. De nombreuses tâches ingrates sont nécessaires pour l'entretenir: administrer les listes de diffusion, modérer les forums, maintenir les gros sites d'archivage et de téléchargement de logiciels, développer les RFCs et autres standards techniques.

Ces travaux forcent le respect car chacun sait qu'ils sont chronophages et moins amusants que de toucher au code. Les mener à bien prouve votre dévouement.

5. Soutenez la culture hacker elle-même

Enfin, vous pouvez soutenir et contribuer au développement de la culture elle-même (en écrivant par exemple un manuel d'introduction expliquant comment devenir un hacker :-)). Vous devrez pour cela avoir un peu d'ancienneté et être connu pour l'un des quatre premiers types de contributions.

La culture hacker n'a pas vraiment de dirigeants mais elle a ses héros, ses vieux sages, ses historiens et ses porte-paroles. Quand vous aurez passé assez de temps les mains dans le cambouis, vous en ferez peut-être partie. Attention, les hackers se méfient du poids de l'égo chez leurs vieux sages, ce type de célébrité est donc à double tranchant. Mieux vaut la laisser venir à soi que de la rechercher à tout prix; et si cela vous arrive restez modeste et digne de votre statut.

Le lien hacker / nerd

Contrairement à la croyance populaire, tous les hackers ne sont pas des polars technophiles [NDT: pas facile de traduire "nerd"]. Ca aide bien sûr et de nombreux hackers le sont. Etre asocial permet de rester concentré sur les choses importantes telles que la réflexion et le hacking.

Nombreux sont les hackers qui se présentent plutôt comme des "geeks", se défaussant ainsi d'être asociaux (et d'adorer la science fiction et les jeux de stratégie, des goûts partagés par de nombreux hackers). Le terme "nerd" avait ce sens dans les années 1990: il était un tantinet péjoratif mais "geek" l'était bien davantage. Peu après l'an 2000, ils ont été inter-changés, du moins dans la culture populaire nord-américaine, et l'on sent aujourd'hui une certaine fierté à se dire "geek" même chez les non-technophiles.

Si vous parvenez à vous consacrer suffisamment au hacking pour y exceller tout en menant une vie sociale normale, bravo. C'est plus facile aujourd'hui que lorsque j'ai débuté dans les années 1970: la culture de masse est devenue bienveillante envers les polars technophiles. Et un nombre croissant de personnes se rendent même compte que les hackers sont souvent de bons amants et de bons conjoints.

Si le hacking vous attire parce qu'il n'y a rien d'autre dans votre vie, aucun problème; au moins, vous ne vous disperserez pas. Vous aurez peut-être une vie sociale plus tard.

Eléments de style

A nouveau, pour être un hacker, vous devez en adopter l'état d'esprit. Certaines activités s'effectuent loin du clavier et peuvent vous y aider. Rien ne remplace le hacking, mais de nombreux hackers les pratiquent en se sentant en résonance avec l'essence du hacking.

• Apprenez à bien rédiger dans votre langue naturelle. Contrairement à ce que laissent croire les stéréotypes, un nombre surprenant de hackers produisent des écrits de qualité.
• Lisez de la science fiction. Allez aux conférences qui y sont consacrées (c'est une bonne opportunité de rencontrer des hackers et des proto-hackers).
• Rejoignez un club de hackers et construisez quelque chose (une autre bonne opportunité de rencontrer hackers et proto-hackers).
• Pratiquez un art martial. La discipline mentale requise par les arts martiaux semble assez proche de celle que suivent les hackers. Les arts martiaux les plus populaires chez les hackers sont sans aucun doute les arts asiatiques qui se pratiquent à mains nues tels que le tae kwon do, les nombreuses formes de karaté, le kung fu, l'aïkido ou le ju jitsu. Certains sont adeptes de l'escrime ou des arts asiatiques de combat à l'épée. Là où c'est autorisé, le tir au pistolet a gagné en popularité depuis la fin des années 1990. Les hackers se sentent plus proches des arts martiaux qui mettent l'accent sur la discipline mentale, la conscience apaisée et le contrôle plutôt que la force brute, l'athlétisme ou l'endurance physique.
• Pratiquez une technique de méditation. Celle qui connaît un succès durable auprès des hackers est le zen (élément important: on peut adopter le zen sans entrer en religion ou sans avoir à en abandonner une). D'autres écoles sont certainement valables, faites juste attention à ne pas en choisir une qui vous incite à croire en des choses délirantes.
• Développez votre oreille musicale. Apprenez à apprécier des types de musique particuliers. Apprenez à bien jouer d'un instrument ou à chanter.
• Apprenez à apprécier les jeux de mots.

Si vous êtes en résonnance avec ce qui précède, vous avez de bonnes bases pour devenir un hacker. Pourquoi choisir ces activités-là, ce n'est pas très clair mais elles semblent liées par un dosage de compétences "cerveau gauche/cerveau droit" qui aurait son importance. Les hackers ont besoin de passer instantanément d'un mode de raisonnement logique à un autre où ils font abstraction de la logique apparente d'un problème.

Travaillez aussi intensément que vous jouez et jouez aussi intensément que vous travaillez. Pour les véritables hackers, les frontières entre "jouer" et "travailler", "la science" et "l'art" ont tendance à disparaître ou à fusionner en une allégresse créative intense. Ne vous contentez pas non plus d'un champ restreint de compétences. Bien que la plupart des hackers se qualifient de développeurs, ils sont souvent plus que compétents dans des domaines connexes tels que l'administration système, la conception web et la réparation matérielle de PC. De même, un hacker administrateur système sera certainement compétent en programmation de scripts et en conception web. Les hackers ne font pas les choses à moitié: quand ils s'investissent dans un domaine, ils finissent par y exceller.

Enfin, quelques petites choses à ne pas faire.

• Ne choisissez pas d'identifiant ou de pseudonyme idiot ou pompeux.
• Evitez la guerres du feu sur Usenet (et partout ailleurs).
• Ne vous présentez pas comme un "cyberpunk" et ne perdez pas de temps avec ceux qui le font.
• Ne postez aucun billet ni email truffé de fautes d'orthographe ou de grammaire.

Déroger à ces règles vous donnerait mauvaise réputation. Les hackers ont une mémoire à long terme; ils pourraient mettre des années à pardonner vos erreurs de jeunesse et à vous accepter.

Le problème des pseudonymes mérite qu'on le souligne. Dissimuler votre identité derrière un pseudo est une attitude juvénile et stupide, caractéristique des crackers, des utilisateurs de warez et d'autres formes de vie encore moins évoluée. Les hackers ne se comportent pas comme cela; ils sont fiers de ce qu'ils font et souhaitent l'associer à leur véritable nom. Abandonnez votre pseudo si vous en avez un: dans la culture hacker il ferait de vous un tocard.

Note historique: hacking, open source et logiciel libre

Les conditions qui m'ont amené à rédiger la première version de ce document fin 1996 ont énormément évolué depuis. Revenir brièvement sur ces changements clarifiera peut-être la relation qu'entretiennent l'open source, le logiciel libre et Linux d'une part et la communauté hacker d'autre part. Si cela n'attise pas votre curiosité, passez directement aux questions fréquentes et à la bibliographie.

La philosophie et la communauté hacker telles que je les décris sont bien antérieures à l'émergence de Linux après 1990; je m'y suis impliqué pour la première fois aux alentours de 1976 et l'on peut suivre leurs traces jusqu'au début des années 1960. Mais avant Linux, on pratiquait le hacking soit sur des systèmes d'exploitation propriétaires, soit sur des systèmes faits-maison et quasi-expérimentaux (comme l'ITS du MIT) qui n'ont jamais été déployés en dehors de leurs berceaux académiques. Certes, il y a eu quelques tentatives avant Linux pour faire évoluer cette situation mais leur impact a été plus que marginal et elles n'ont pas quitté le cercle des passionnés purs et durs, minoritaires même parmi les hackers.

Ce que nous appelons aujourd'hui "open source" remonte aussi loin que la communauté des hackers mais cette pratique populaire n'est devenue un mouvement conscient, théorisé et documenté qu'en 1985. La préhistoire s'est terminée lorsqu'en 1985, un éminent hacker appelé Richard Stallman ("RMS") a donné un nom à ce mouvement: "le logiciel libre". Mais plus que de le nommer, il revendiquait ce mouvement; il a donné une connotation idéologique au "logiciel libre" qui n'a pas su séduire les masses. Le label "logiciel libre" a donc été rejeté haut et fort par une minorité substancielle de hackers (principalement ceux d'Unix BSD) et utilisé avec de sérieuses réserves (mais non exprimées) par la plupart des autres (moi inclus).

Malgré ces réserves, la revendication par RMS de définir et de guider la communauté des hackers sous la bannière "logiciel libre" a globalement tenu le choc jusqu'au milieu des années 1990. C'est l'avènement de Linux qui l'a sérieusement remise en cause. Linux a donné un environnement naturel au développement open-source. De nombreux projets que l'on qualifierait aujourd'hui d'open-source ont migré des Unixes propriétaires vers Linux. La communauté Linux s'est développée exponentiellement, devenant bien plus importante et hétérogène que ne l'était la culture hacker avant Linux. RMS essaya de coopter toute cette activité dans le mouvement du "logiciel libre" mais sa détermination s'avéra insuffisante face à l'extraordinaire diversité de la communauté Linux et au scepticisme affiché de son fondateur, Linus Torvalds. Torvalds continua à utiliser le terme "logiciel libre" faute de mieux mais il rejeta l'idéologie que RMS lui avait associé. De nombreux jeunes hackers en firent autant.

En 1996, lors de la publication de la première version de ce document, la communauté des hackers se réorganisait autour de Linux et de quelques autres systèmes d'exploitation open source inspirés d'Unix BSD. Le souvenir des décennies passées à développer des logiciels propriétaires sur des systèmes d'exploitation propriétaires était encore très prégnant mais cette époque semblait définitivement révolue. Les hackers étaient de plus en plus attachés aux projets open-source tels que Linux ou Apache.

Toutefois, le terme "open source" n'émergea qu'en début 1998. Six mois après que je l'eus proposé, la majorité de la communauté des hackers l'avaient adopté. Les réticences minoritaires venaient de ceux qui restaient attachés à l'idéologie liée au terme "logiciel libre". Depuis 1998, et particulièrement après 2003, les notions de "hacking" et de "développement logiciel open-source (et libre)" ont pratiquement fusionné. Il est aujourd'hui très difficile de les distinguer et cet état de fait semble durable.

Mais il est bon de se rappeler qu'il n'en a pas toujours été ainsi.

Autres ressources

Paul Graham a écrit un essai intitulé Les grands hackers, et un autre sur les étudiants, tous deux empreints de sagesse.

Comment devenir un développeur est un excellent complément. Il donne de bons conseils sur le codage et les compétences, mais aussi sur l'esprit d'équipe.

J'ai également écrit une brève histoire du monde des hackers.

J'ai écrit un papier, La cathédrale et le bazar, qui explique en détail le fonctionnement des cultures Linux et open-source. Sujet que j'ai repris dans le document qui l'a suivi à la conquète de la noosphère.

Rick Moen a rédigé un excellent document sur la manière d'animer un groupe d'utilisateurs de Linux.

Rick Moen et moi avons co-rédigé un autre document expliquant comment poser des questions intelligentes. Cela vous aidera à solliciter de l'aide en augmentant vos chances de l'obtenir.

S'il vous souhaitez comprendre le fonctionnement de base des ordinateurs personnels, d'Unix et d'Internet, lisez le guide pratique des fondamentaux d'Unix et d'Internet.

Quand vous publiez des logiciels ou des correctifs, essayez de suivre les recommandations du guide pratique de la publication de logiciels.

Si le poème zen vous a plu, vous pourriez également apprécier L'administrateur non-administré: les koans Unix de maître Foo.

Questions fréquentes

Q: Comment savoir si je suis déjà un hacker?Q: Pourriez-vous m'apprendre à hacker?Q: Dans ce cas, par où commencer?Q: Quand faut-il commencer? Suis-je trop âgé pour apprendre?Q: Combien de temps va durer mon apprentissage du hacking?Q: Visual Basic est-il un bon langage pour faire ses premiers pas?Q: M'aideriez-vous à craquer un système ou m'apprendriez-vous à craquer?Q: Comment récupérer le mot de passe du compte de quelqu'un d'autre?Q: Comment puis-je avoir accès, lire et surveiller les mails de quelqu'un d'autre?Q: Comment puis-je m'arroger les privilèges système d'un canal IRC?Q: Je me suis fait craquer. M'aiderez-vous à me protéger contre d'autres attaques?Q: Je rencontre des problèmes avec Windows. Pouvez-vous m'aider?Q: Où puis-je rencontrer de véritables hackers avec qui discuter?Q: Pourriez-vous suggérer quelques livres utiles sur les sujets liés au hacking?Q: Dois-je être bon en maths pour devenir un hacker?Q: Quel langage devrais-je apprendre en premier?Q: De quel type de matériel ai-je besoin?Q: J'aimerais contribuer. Pourriez-vous m'aider à choisir un problème sur lequel travailler?Q: Dois-je haïr et fustiger Microsoft?Q: Mais ces logiciels open-source ne vont-ils pas empêcher les développeurs de vivre de leur art?Q: Où puis-je me procurer un Unix libre?

Q: Comment savoir si je suis déjà un hacker?

A: Posez-vous les questions suivantes:

• Etes-vous à l'aise avec le code?
• Vous identifiez-vous aux buts et aux valeurs de la communauté des hackers?
• Un membre établi de la communauté des hackers vous a-t-il déjà qualifié de hacker?

Si vous pouvez répondre oui à ces trois questions, vous êtez déjà un hacker. Deux ne suffisent pas.

Le premier test concerne vos compétences. Vous le passerez probablement avec succès si vous avez les compétences techniques minimales décrites ci-avant. Vous le passez haut la main si vous avez déjà produit un certain volume de code accepté par un projet de développement open-source.

Le deuxième test concerne votre attitude. Si les cinq principes du hacker vous paraissent évidents, qu'ils ressemblent plus à une description de votre mode de vie qu'à quelque chose de nouveau, vous êtes déjà à moitié qualifié. L'être complètement dépend de votre degré d'identification aux projets à long terme de la communauté des hackers.

Voici une liste non exhaustive mais assez indicative de certains de ces projets. Cela vous tient-il à coeur que Linux s'améliore et se propage? La liberté des logiciels vous passionne-t-elle? Etes-vous hostile aux monopoles? Etes-vous animé par la conviction que les ordinateurs peuvent être les instruments d'une responsabilisation qui rendra le monde plus riche et plus humain?

Une certaine prudence s'impose ici. La communauté des hackers a des intérêts politiques spécifiques, essentiellement défensifs, comme de défendre la liberté d'expression et de repousser toute prise de pouvoir sur la "propriété intellectuelle" qui viserait à rendre l'open-source illégal. Certains de ces projets de long terme prennent la forme d'organisations de protection des libertés civiques comme l'Electronic Frontier Foundation, qu'il est d'usage de soutenir. Mais à part cela, la plupart des hackers considèrent avec soupçons les tentatives de systématiser leur attitude en un programme politique; nous avons appris, dans la douleur, que ces tentatives sont clivantes et perturbatrices. Si quelqu'un essaie de vous recruter pour renverser votre gouvernement au nom de l'attitude des hackers, c'est qu'il n'a rien compris. La bonne réponse serait probablement: "ferme-la et montre leur ton code".

Le troisième test renferme un problème de fermeture transitive. Je remarquais dans la section appelée "Qu'est-ce qu'un hacker?" que le fait d'être un hacker consistait en partie à appartenir à une sous-culture particulière ou à un réseau social ayant une histoire commune, un dedans et un dehors. Par le passé, il y avait beaucoup moins de cohésion et de conscience de soi qu'aujourd'hui chez les hackers. Mais l'aspect réseau social a pris de l'importance ces trente dernières années grâce à Internet qui a permis de tisser et de maintenir des relations avec le coeur de la sous-culture des hackers. Un indice comportemental évident de ce changement est que, dans ce siècle, nous avons nos propres T-shirts.

Les sociologues, qui étudient les réseaux du type de celui de la culture hacker sous l'intitulé "universités invisibles", ont noté que l'une des caractéristiques de ces réseaux était d'avoir des gardiens: des membres centraux ayant l'autorité sociale d'affilier de nouveaux membres au réseau. Comme la culture hacker est une "université invisible" informelle, le rôle de gardien l'est aussi. Mais s'il y a une chose que tous les hackers comprennent naturellement, c'est que tout hacker n'est pas un gardien. Les gardiens doivent avoir un certain degré d'expérience et de réussite avant d'être anoblis. Ce degré est difficile à quantifier, mais tous les hackers le détectent naturellement lorsqu'ils le rencontrent.

Q: Pourriez-vous m'apprendre à hacker?

A: Depuis la première publication de cette page, je reçois plusieurs demandes par semaine (souvent plusieurs par jour) pour "enseigner tout sur le hacking". Malheureusement, je n'ai ni le temps ni l'énergie de le faire; mes propres projets de hacking et mon travail de défenseur de l'open-source me prennent 110% de mon temps.

Même si le faisais, le hacking est une attitude et un ensemble de compétences que vous devez vraiment acquérir par vous-même. Vous vous rendrez compte que même si les véritables hackers acceptent de vous aider, ils ne vous respecteront pas si vous les implorez de vous nourir de leurs connaissances à la petite cuillère.

Commencez par apprendre quelques petites choses. Montrez que vous essayez, que vous êtes capable d'apprendre par vous-même. Vous pourrez alors poser aux hackers des questions précises.

Si vous demandez conseil à un hacker par email, sachez deux choses. La première: les gens qui sont trop paresseux ou négligents par écrit ont généralement un mental trop paresseux et négligent pour faire de bons hackers; donc prenez garde à orthographier correctement, soignez votre grammaire et votre ponctuation, sans quoi vous serez probablement ignoré. Deuxièmement, n'imaginez même pasdemander que l'on vous réponde à une adresse différente de votre adresse d'expédition; ceux qui font cela utilisent généralement des comptes volés et nous n'avons aucun intérêt à récompenser ou à aider les voleurs.

Q: Dans ce cas, par où commencer?

A: Le meilleur point de départ est certainement d'assister à une réunion d'un LUG (Linux User Group). Vous trouverez ces groupes sur la page d'information générale du LDP; il y en a probablement un près de chez vous, peut-être associé à une université ou une école d'ingénieur. Les membres des LUG vous donneront probablement une distribution Linux si vous le leur demandez et ils vous aideront certainement à en installer une et à faire vos premiers pas.

Prochaine étape (première étape si vous ne pouvez pas trouver de LUG près de chez vous): trouvez un projet open-source qui vous intéresse. Commencez à en lire le code et prenez connaissance des problèmes techniques non résolus. Apprenez à contribuer et rejoignez le projet.

Le seul moyen est de travailler à améliorer vos compétences. Si vous me redemandez en privé comment débuter, je vous répèterai exactement la même chose car je ne connais aucun raccourci magique. Et si vous manquez d'endurance pour lire cette foire aux questions jusqu'au bout et comprendre que le seul moyen de devenir un hacker est de développer vos compétences, vous êtes sans espoir.

Une autre possibilité intéressante est de vous rendre à un club de hackers. Un nombre florissant de personnes créent des lieux physiques où ils peuvent se rencontrer pour travailler sur des projets matériels et logiciels, ou encore travailler en solo dans une atmosphère agréable. Les clubs de hackers mettent souvent en commun des outils et des équipements spécialisés qu'il serait trop coûteux d'acheter ou de stocker en tant que particulier. Les clubs de hackers sont faciles à trouver sur Internet; il y en a peut-être un près de chez vous.

Q: Quand faut-il commencer? Suis-je trop âgé pour apprendre?

A: L'âge n'a aucune importance tant que vous êtes motivé. Le hacking semble susciter un intérêt chez la plupart de ses adeptes entre 15 et 20 ans, mais je connais des exceptions au-delà et en-deçà.

Q: Combien de temps va durer mon apprentissage du hacking?

A: Tout dépend de votre talent et des efforts que vous y consacrerez. La plupart des gens qui s'y mettent sérieusement acquièrent des compétences solides en un an et demi à deux ans. Mais dans le hacking comme dans de nombreux autres domaines, il faut compter environ dix ans pour atteindre un certain niveau d'expertise. Et si vous êtes un véritable hacker, vous consacrerez le reste de votre vie à l'apprentissage et au perfectionnement de votre art.

Q: Visual Basic est-il un bon langage pour faire ses premiers pas?

A: Si vous posez cette question, c'est probablement que vous songez à essayer de hacker sous Microsoft Windows. C'est une mauvaise idée en soi. Je ne plaisantais pas lorsque je comparais l'apprentissage du hacking sous Windows avec celui de la danse en ayant les jambes dans le plâtre. N'essayez pas, c'est atroce et cela n'est pas près de s'arranger.

Visual Basic, en particulier, souffre du problème de non-portabilité. Bien qu'il existe des implémentations open-source de Visual Basic, les standards ECMA ne couvrent qu'une portion congrue de ses interfaces. Sous Windows, l'essentiel de sa plateforme est propriétaire, dépendant d'un éditeur unique: Microsoft. A moins d'être extrêmement prudent quant aux fonctionnalités utilisées (plus qu'un débutant n'est capable de l'être), vous vous rendrez captif des seules plateformes supportées par Microsoft. Si vous débutez sous Unix, de meilleurs langages et bibliothèques sont disponibles. Python par exemple.

Par ailleurs, comme les autres Basics, Visual Basic est un langage mal conçu qui vous donnera de mauvaises habitudes. Non, ne me demandez pas de les décrire de manière exhaustive: cela prendrait un livre entier. Apprenez plutôt un langage bien conçu.

L'une de ces mauvaises habitudes est de dépendre d'un éditeur unique de bibliothèques, de composants et d'outils de développement. De manière générale, tout langage qui n'est pas complètement supporté au moins sous Linux, l'un des BSDs et/ou sous trois systèmes d'exploitation d'éditeurs différents est un mauvais langage pour apprendre à hacker.

Q: M'aideriez-vous à craquer un système ou m'apprendriez-vous à craquer?

A: Non. Même si j'avais le temps pour faire du tutorat, un lecteur de cette FAQ encore capable de poser cette question serait trop stupide pour être éduqué. Tout email allant dans ce sens et m'étant adressé sera ignoré ou suscitera une réponse plus qu'impolie.

Q: Comment récupérer le mot de passe du compte de quelqu'un d'autre?

A: Ca, c'est du cracking. Allez-vous en, idiot.

Q: Comment puis-je avoir accès, lire et surveiller les mails de quelqu'un d'autre?

A: Ca, c'est du cracking. Allez vous faire voir, imbécile.

Q: Comment puis-je m'arroger les privilèges système d'un canal IRC?

A: Ca, c'est du cracking. Hors d'ici, crétin.

Q: Je me suis fait craquer. M'aiderez-vous à me protéger contre d'autres attaques?

A: Non. Jusqu'à présent, tous ceux qui m'on posé cette question étaient des idiots qui faisaient tourner Windows. Il est impossible de vraiment sécuriser Windows contre les attaques système; le code et l'architecture ont trop de défauts de conception, ce qui rend la sécurisation de Windows aussi difficile que d'écoper un bateau avec une passoire. La seule prévention est de basculer sous Linux ou un autre système d'exploitation conçu un tant soit peu pour la sécurité.

Q: Je rencontre des problèmes avec Windows. Pouvez-vous m'aider?

A: Oui. Ouvrez une invite de commandes DOS et tapez "format c:". Quel que soit le problème rencontré, il sera résolu en quelques minutes.

Q: Où puis-je rencontrer de véritables hackers avec qui discuter?

A: Le meilleur moyen est de trouver un groupe local d'utilisateurs d'Unix ou de Linux et de vous rendre à leurs réunions (vous trouverez des liens vers plusieurs listes de groupes d'utilisateurs sur le LDP).

(J'avais pour habitude de dire qu'on ne trouvait aucun véritable hacker sur IRC mais il me semble que la situation évolue. Apparemment, certaines communautés de véritables hackers, attachés aux logiciels comme GIMP ou Perl, ont maintenant des canaux IRC.)

Q: Pourriez-vous suggérer quelques livres utiles sur les sujets liés au hacking?

A: Je maintiens une liste de lecture Linux que vous pourriez trouver utile. Le Loginataka pourrait également vous intéresser.

Pour commencer en Python, lisez le tutoriel sur le site officiel Python.

Q: Dois-je être bon en maths pour devenir un hacker?

A: Non. Le hacking utilise très peu de mathématiques formelles ou d'arithmétique. En particulier, vous n'aurez généralement pas besoin de trigonométrie ni d'analyse (sauf dans certains domaines tel que le graphisme en 3 dimensions). Il est bon d'avoir quelques connaissances en logique formelle et en algèbre booléenne. Quelques bases en théorie des ensembles peuvent s'avérer utiles (états finis, combinatoire et graphes).

Beaucoup plus important: vous devez être capable de penser logiquement et de suivre un raisonnement précis comme le font les mathématiciens. Si le corps des mathématiques ne vous aidera pas, la rigueur et l'intelligence nécessaires à cette discipline seront indispensables. S'il vous manque l'intelligence, il y a peu d'espoir pour vous en tant que hacker; si vous manquez de rigueur, tâchez de progresser dans ce domaine.

Un bon moyen de savoir si vous avez les bases nécessaires est de vous procurer un exemplaire du livre de Raymond Smullyan Quel est le nom de ce livre?. Les énigmes logiques et ludiques de Smullyan reflètent bien l'esprit hacker. Etre capable de les résoudre est bon signe; y prendre du plaisir en est un encore meilleur.

Q: Quel langage devrais-je apprendre en premier?

A: XHTML (le dernier dialecte d'HTML) si vous ne le connaissez pas déjà. Vous trouverez de nombreux mauvais livres certes bien léchés sur HTML, mais malheureusement peu de bons. Celui que je préfère est HTML: The Definitive Guide.

Mais HTML n'est pas un langage de programmation. Si vous êtes prêt à débuter la programmation, je vous suggère de commencer par Python. D'autres conseilleront Perl mais ce dernier est plus difficile à apprendre et (à mon avis) moins bien conçu.

Le langage C est très important mais il est aussi beaucoup plus difficile que Python ou Perl. N'essayez pas de l'apprendre en premier.

Aux utilisateurs de Windows: ne vous contentez pas de Visual Basic. Il vous donnerait de mauvaises habitudes et il n'est pas portable en-dehors de Windows. Evitez-le.

Q: De quel type de matériel ai-je besoin?

A: Il fut un temps où les ordinateurs personnels étaient plutôt faibles en puissance de calcul et en mémoire vive, ce qui limitait artificiellement le processus d'apprentissage des hackers. Tout a changé au milieu des années 90: une machine dotée d'un Intel 486DX50 ou plus est bien assez puissante pour les travaux de développement, pour faire fonctionner une interface graphique et accéder au réseau Internet, et les plus petits disques du commerce sont aujourd'hui bien assez gros.

Le plus important pour une machine sur laquelle vous allez apprendre, c'est qu'elle soit compatible avec Linux (ou avec un BSD, selon vos choix). Ce qui est vrai pour la quasi totalité des machines modernes. Les seules parties vraiment récalcitrantes sont les modems et les cartes réseau sans fil pour lesquels certaines machines ont des équipements spécifiquement développés pour Windows et qui ne fonctionnent pas sous Linux.

Il y a une foire aux questions concernant la compatibilité matérielle dont la dernière version se trouve ici.

Q: J'aimerais contribuer. Pourriez-vous m'aider à choisir un problème sur lequel travailler?

A: Non car je ne connais ni vos talents ni vos centres d'intérêt. Sans auto-détermination, vous ne tiendrez pas le cap, ce qui explique que se laisser guider par d'autres personnes ne fonctionne quasiment jamais.

Q: Dois-je haïr et fustiger Microsoft?

A: Non. Non que Microsoft ne soit pas détestable, mais une culture hacker existait bien avant Microsoft et continuera d'exister bien après que Microsoft sera devenu de l'histoire ancienne. Employez votre énergie à aimer votre métier plutôt qu'à haïr Microsoft. Produisez un code de qualité, cela fustigera Microsoft bien assez sans pour autant polluer votre karma.

Q: Mais ces logiciels open-source ne vont-ils pas empêcher les développeurs de vivre de leur art?

A: Cela semble peu probable: jusqu'à présent, l'industrie du logiciel open-source semble créer plus d'emplois qu'elle n'en détruit. Si nous considérons que de développer un logiciel a économiquement plus de valeur que de ne pas l'écrire, un développeur sera rétribué que ce logiciel devienne open-source ou non après son développement. Et il semblerait que peu importe le nombre de logiciels libres écrits, la demande de nouvelles applications sur mesure continue à croître. J'ai approfondi ce sujet sur ces pages concernant l'Open Source.

Q: Où puis-je me procurer un Unix libre?

A: Si un Unix n'est pas déjà installé sur votre machine, j'ai inclus dans cette page des liens qui vous mèneront aux principaux Unix libres. Pour être un hacker, vous avez besoin de motivation, d'initiative et de la faculté d'auto-apprentissage. A vous de jouer...

source : http://thomasgil.com/hacker.html